Why document management and archetypes matter

QUICK QUIZ : What do the following pictures all have in common?

San Cave Art, taken by Valroe at en.wikipedia [Public domain], from Wikimedia Commons

Graffitti in Northampton, MA, taken December 2012

  

Artwork from Thomas Stanley, age 4 (from Jan 2013)

ANSWER : They are all powerful reminders of the anthropologic relationship between human beings and their documentation. In other words, I think that very human attempt at self-understanding, expression, and communication :

... is still very much reflected in the organizations and businesses of today :

In other words, I think one way to help understand organizational dynamics is to see an organization as just many, many iterations of this same loop :

... by asking yourself :

• A - Who are the people in the organization?
• B - What are the documents in the organization?
• How do A and B interact?

This is why document management matters. Documents are tools - Every document serves a unique function.  So the way you manage your documents and information will, at least in part, determine the actions and behaviors of your employees, and collectively the functioning of your organization :

• Give them the right tools to express themselves, in the right way, at the right time - and you will empower your directors and managers to make changes in your organization. (WRITE)
• Publish those tools in the right place, in the right way, at the right time - and you will empower your staff to learn your values, beliefs, and operational standards. (READ)
• Update those tools regularly, and you will make sure that both your documents and employee behaviors are current, and reflect your ongoing changing needs. (GOVERNANCE)

And so, you want to make sure :

• Your managers/directors make the best tools.
• Your tools are published the best way, so people can easily find, read, and learn from them.
• Your tools are updated regularly.

What exactly are those tools? I outlined some common healthcare-related tools in the CMIO's checklist, but they vary from industry to industry. But what you *do* want to make sure of is :

• Each tool has a specific, well-defined purpose. (E.g. Apples=Sweet, Onions=Spicy)
• Your managers have clear guidelines about how to develop the tools (So they grow apples and onions, and don't build a hybrid apple/onion that people are confused by)
• You have some kind of quality check before tools are published (e.g. to weed out the occasional apple/onion hybrid.)
• Your front-line staff knows where to find those tools (so they know to find apples in the apple bucket and onions in the onion bucket) 
• Your front-line staff knows when and how to use those tools (e.g. apples for baking pies, and onions for making soups).

The reason I bring up the issue about hybrid tools is because, unlike real-world, physical tools - The engineering and safety of paper tools is not quite as intuitive.

For example, a hammer is fairly intuitive :

• It serves one purpose : To drive in nails. 
• Its safety is fairly intuitive : You can see it, touch it, and feel its weight, and once you hit your thumb by accident, you'll quickly learn how not to do that again. 
• Its utility is fairly intuitive : If the hammer doesn't successfully bang the nail in, you'll quickly know you need a bigger hammer. And it's fairly easy to see that you shouldn't use a hammer to put in a screw.

Paper tools are tricker. 

• It might not be as immediately clear if the purpose is vague, ambiguous, or serves multiple purposes.
• You might not immediately notice any safety issues, or know when the tools is malfunctioning.
• You might not quickly see if the tool isn't serving its purpose.

This is why it's important to ask yourself about how your paper tools are designed and used. For maximum efficiency, you'll want them to work the best they can - And that means not just designing good clinical documentation, but reviewing it properly, approving it properly, publishing it properly, and monitoring it properly.

Think of your paperwork as the lifeblood of your organization. If the blood doesn't flow from heart, to finger, and back to the heart - Then it's not doing it's job : To transfer information from the center to the periphery, and back again, in a continuous loop.

This is why document archetypes are important in healthcare - They are a big help when it comes designing your paperwork - Which can be a big influence with the READING part of the loop between your employees and your leaders.

SO WHAT EXACTLY IS AN ARCHETYPE?
This is one of those terms that Informaticists sometimes use, that can sound scary or weird, until you know how simple it is - and then it becomes very friendly and helpful.

According to Wikipedia, an archetype is a "universally understood symbol, term, statement, or pattern of behavior, a prototype upon which others are copied, patterned, or emulated..." Think of it as the mold you are going to use to cut your cookies - If you want round cookies, then it helps to have a round cookie-cutter :

• If you wanted a compelling hero template that could serve as a role model (template) for all heroes, to write a blockbuster science fiction movie, then you might make a superhero archetype and name the character "Luke Skywalker".

• If you wanted a compelling policy that could serve as the role model (template) for all policies, to have a blockbuster policy manual, then you will similarly need a superpolicy archetype to set the example for all of your policies.

(One quick unrelated side note : In this way, I think comic book superheroes actually benefit society - By creating templates/archetypes that kids can use to model at least some of their behaviors. I think this is also why it's unusually heartbreaking to see sports heroes sometimes fall from grace: We hold them up as archetypes of goodness, teamwork and fairness - and then feel great disappointment when we find out that they're actually only human.)

Anyway, having well-defined archetypes helps make sure that every document / tool serves a common purpose, and is developed, used, and monitored in a standardized way. It's that predictability that creates harmony, clarity, and efficiency in your organization.

So ask yourself - What are your documentation role models/archetypes? Perfection is near impossible, but you still probably want your documents to be pretty close to superheroes. Are they already superheroes, or do they need help? Once you have some super archetypes that your employees can use to model behaviors and communication, you will generally start to see a real improvement in your quality, operation, and efficiency. 

Remember, these posts are only for fun, education, and friendly discussion - Remember to check with your own experts and superheroes before you take any actions! And I'm always interested to hear people's thoughts and feedback, so feel free to comment below! :)

Rethinking the Committee Charter

Modern healthcare needs people to work on it. Like a garden, it needs pruning, trimming, weeding, planting, and a lot of care to keep it alive and vibrant. You will probably need committees to help you do this.

Committees are the workhorses of an organization - They help you get things done, hopefully, by coordinating the actions of different parts of your organization, and so they are useful in coordinated change management. From Google :
According to Wikipedia, committees are :

• "a necessary aspect of organizations of any significant size" and are
• "a way to formally draw together people of relevant expertise from different parts of an organization who otherwise would not have a good way to share information and coordinate actions" and
• "can also be empaneled with experts".

The exact parliamentary practices here seems to vary broadly, from Robert's Rules of Order to other blogs and books on parliament, but committees typically come in one of three flavors :

• Executive Committee - A committee with well-defined executive powers usually spelled out in a charter or organizational by-laws
• Standing/Permanent Committee - A subunit of a political or deliberative body established in a permanent fashion to aid the parent assembly in accomplishing its duties.
• Working/Ad Hoc Committee - A group established to accomplish a particular task or to oversee an ongoing area

By the way, for more about committees, see :

• This 1915 full, public domain version of Robert's Rules
• This Dummies.com Robert's Rules cheat sheet

Anyway, committees also have their challenges. The problem with committees, generally, is that operationally :

• You need them to carry out a significant amount of work for your organization, but
• ...they have to be staffed with several highly-trained people, and so ...
• ... if they're not run efficiently, they can be a drain on resources.

So ideally, you want a committee to be well-run, efficent, and productive. 

How to get a committee to be well-run, efficient, and productive?

I find one of the most challenging things when creating a committee is defining the committee to achieve clarity. So I looked at some of the most common questions I hear about committees : 

• Why does it exist?
• Who created it? When?
• Who's going to run it?
• Who's going to participate in it?
• What powers/authority does the committee have?
• How often will they meet?
• Who will it report to? Who will oversee it?
• How will it vote? Who will vote?
• What's the quorum?

And so to help achieve clarity on these issues, I rethought the "Committee Charter", and drafted the following sample one-page template :

This DRAFTED charter template, in one page, then facilitates operational clarity by encouraging both committee members and the overseeing body to define their terms, and agree to :

• Committee mission (Why is the committee needed?)
• Committee responsibilities (What is the expectation for this committee?)
• Committee chairperson(s) (Who will run this committee, set the agendas, conduct meetings, ensure minutes are kept and approved, and report the activities/actions of the committee?)
• Committee membership (both voting and non-voting members - Who can vote? Who can't?)
• Meeting frequency (How often will this committee meet?)
• Delegated authorities (e.g. "to send emails on behalf of another person/committee"?)
• Voting Type (How will the members approve motions?)
• Quorum (What's the minimum number of people that need to be in a room for an official meet?)
• Charter Review (How often will this charter be re-examined? When will it be reapproved?)
• Measures of success (How will we know if the committee is effective?)
• Oversight body (Who will this committee report to?)

It's pretty short-and-sweet, but in one page I think it gets the job done quite well. As always, if my writing inspires you, remember to tailor it to your needs. Let me know if you have any other charter templates you like, and why you use them!

Remember, this is all just academic discussion, and your mileage may vary! Check with your local regulatory bodies before developing governance tools in your area. Feel free to send thoughts, comments, or questions - I always enjoy getting feedback from other people looking to improve healthcare!

What exactly is "Alert Fatigue"?

Clinical Decision Support (CDS) - It's the mythical creature that every healthcare administrator and informaticist is hunting, to help reduce costs and improve care. Loosely, it can be broken into a few different areas :

1. Electronic decision support (e.g. CPOE Alerts to help prevent errors)
2. Order / order set design (e.g. to help prevent errors / guide docs to evidence-based care)
3. Workflow/documentation redesign (e.g. tools used to standardize high-risk decisions, e.g. procedure checklists)
4. Workflow/protocol design (e.g. tools used to automate high-risk procedures)

One of the hardest to tackle is #1 - CPOE Alerts. Are there too many, or too few? Everyone I know seems to be struggling with the same issue :

• Wanting to provide CPOE alerts to avoid errors, but
• Providing "too many alerts" could cause docs to ignore the "important alerts".

This phenomenon is loosely called alert fatigue, and has been fairly well-documented in literature as, paradoxically, a potential risk. 

When you hear Informatics professionals discuss alert fatigue, the challenging part is actually knowing when alert fatigue exists. Docs sometimes complain about it, but the response docs get to this is often skepticism - After all, how can an alert be bad? Maybe the doc just complains too much? And who is going to turn off the alert? Is it safe to turn off the alert? What if this opens up other problems? When is it too much? When is it too little?

So when you ask docs to define alert fatigue, they typically use general, loose definitions, like :

• "It's when the system gives me too much information and I miss the important stuff."
• "It's when the system tells me about the Tylenol interacting with Colace, but I miss out on the Coumadin/Bactrim interaction."
• "It's when I can't read all of the alerts."
• "It's when I just keep clicking 'Bypass' without actually reading the alert."
• "It's when I just keep clicking 'Acknowledge' without actually reading the alert."
• "It's when I click 'bypass' within 3 seconds, so I know I didn't read the alert."

And recently, when I asked some informatics colleagues for their definition of alert fatigue, I again got a myriad of responses, followed by the same sort of response Supreme Court Justice Potter Stewart gave in 1964, when defining "obscenity" in the Jacobellis v. Ohio case : "I know it when I see it."

Unfortunately, this doesn't help much for those of us who are really working to combat alert fatigue. 

The problem with all of these definitions is that they are fairly loose and subjective, and don't make a good litmus test to answer the question : Do you have alert fatigue?

So I'm going to use some reason and inference, to try to develop a better definition of alert fatigue that is quantifiable. (I used to be a mathematician/statistician, so please forgive the quasi-mathematical approach.)

Since it seems the "undesired scenario" nobody wants is made up of two steps :

• An EMR providing a confusing alert environment, and
• A doc displaying signs of poor response to that environment

So I'd like to submit two proofs, for two conditions which then go into a third proof. Here they are :

PROOF1 : "AlertOverload"

1. [AlertOverload] = [Bad] > [Good]

2. [AlertOverload] = [Noise] > [Signal] 

3. [AlertOverload] = [Low-value alerts] > [High-value alerts]

4. [AlertOverload] = [Low-risk alerts] > [High-risk alerts] 

5. [AlertOverload] = [# of low-risk alerts] > [# of high-risk alerts] 

6. [AlertOverload] = [Number of low-risk alerts in a time period] > [Number of high-risk alerts in a time period]

7. [AlertOverload] = When the number of low-risk alerts exceeds the number of high-risk alerts for a given physician in a given time period

PROOF2 : "AlertLoss"

1. [AlertLoss] = [Bad] > [Good]

2. [AlertLoss] = [BypassedAlert] > [AcknowledgedAlert] 

3. [AlertLoss] = [Number of bypassed alerts in a given time period] > [Number of acknowledged alerts in a given time period] 

4. [AlertLoss] = When the number of bypassed alerts exceeds the number of acknowledged alerts in a given time period

If one were to accept proof #1 and #2 as true, then I would propose this final proof/definition of AlertFatigue :

PROOF3 : "AlertFatigue"

1. [Bad] = [Bad] 

2. [AlertFatigue] = [Bad]

3. [AlertFatigue] = [AlertOverload] + [AlertLoss] 

4. [AlertFatigue] = Exists when a given physician experiences [AlertOverload] and displays [AlertLoss] in a given time period

So voila - My proposed definitions :

1. Alert Overload = When the number of low-risk alerts exceeds the number of high-risk alerts for a given physician in a given time period
2. Alert Loss = When the number of bypassed alerts exceeds the number of acknowledged alerts in a given time period
3. Alert Fatigue = "When a given physician experiences alert overload and displays evidence of alert loss in a given time period."

It's certainly not a universally-recognized definition, and I'm curious if other people are aware of any other professional, practical, policy-grade definitions that exist out there. Obviously, this definition now needs to be peer reviewed, tested, validated, and professionally accepted, so please don't use it in your own organization without consulting a legal professional, informatics professional, and your local regulatory agencies first.

Remember : As always, this discussion is for educational purposes only! Remember, your mileage may vary! Always enjoy thoughts, comments, and ideas!

Recipe for baking matching electronic and paper downtime order sets

EMR downtimes occur. Hopefully not often, but when they do, you'll want to make sure you have order sets for your docs to use. If you don't have downtime order sets, easily available for them to use, you'll probably notice a downgrade in their clinical efficiency, as they struggle to write out all orders by hand from scratch.

Much has been said about physician over-reliance on order sets, but the truth is that they become tools that physicians rely on, much like a carpenter might rely on an electric screwdriver to help put in screws. In a downtime, could the carpenter make do with a manual screwdriver, or a Swiss Army knife, for that matter? Sure. But you want to keep things running smoothly and predictably, so it's helpful if there are order sets available during downtimes.

The problem is, it's sometimes hard to maintain paper downtime order sets. Some reasons include :

• After a hospital "goes electronic", the focus of order set development is often the electronic order sets.
• Not all EMR software has functionality to "print out" an order set.
• Sometimes, printing out an electronic order set makes a funny-looking order set that docs may not intuitively know how to use
• The exact functions and formats of the paper and electronic order set, often, do not entirely match.

So it's easy to leave the paper order sets behind, as you work to optimize your order set strategy.

And this is why I've been asked, "How can I consistently make matching, high-quality paper and electronic order sets?"

Here's my recommended recipe. You may want to add some touches, depending on your needs.

THE BASIC RECIPE :

Ingredients - What you'll need :

• A standard EMR, chock full of well-built electronic orders.
• A standard word processor and hard drive.
• A standard Order Set template, to help the Clinical Informaticist maintain consistency in order set headings and order types.
• A standard indexing system for your order sets, so you'll know how staff will search, find, and track them (e.g. "Order Set #1" vs. "ABC-123" vs. "Pneumonia Order Set")
• A standard Order Set Style Guide, to help the Clinical Informaticist make sure the format all looks the same.
• A Clinical Informaticist, willing to help examine workflows and draft paper order sets.
• A Clinical IT Analyst, willing to help build electronic order sets in your EMR.
• A Clinical Director, willing to own (test, monitor, maintain, and educate) the order set and round up end-users for testing.
• An electronic page on your Intranet where you'll publish your paper order sets for electronic downtimes.
• Some end-users to help test your order sets (e.g. a willing physician, nurse, pharmacist, and/or other users).

INSTRUCTIONS FOR BAKING :

STEP 1 : Clinical Director determines need for an order set and asks Clinical Informaticist for help.

STEP 2 : Clinical Informaticist examines workflow, and ensures resources (ingredients) are available for development.

STEP 3 : Clinical Informaticist decides on category for order set :

• Admission Order Set (e.g. "Admit to ICU", "Admit to CCU", "Admit to Med/Surg")
• Diagnosis Order Set (e.g. "Pneumonia Order Set", "Knee Replacement Order Set", "CHF Order Set")
• Convenience Order Set (e.g. "Hypercoagulable Workup Order Set", "Blood Transfusion Order Set", or "Insulin Drip Order Set")

STEP 4 : Clinical Informaticist names the order set and uses a standard word processor and electronic orders to create a DRAFT paper order set :

• Name the DRAFT paper order set according to proper category (from Step 3 above), index it properly, and label it "DRAFT".
• Use your organization's standard order set template and style guide to start!
• Look up each electronic order in the EMR, and review the function and necessary fields in the electronic order.
• Create a matching paper order, with those necessary fields.
• Gradually start to collect those matching paper orders to draft a paper order set that matches the standards in your electronic orders.
• Any discharge instructions? Put them on a drafted discharge instruction sheet!
• Any protocols? Put them on a drafted protocol sheet!

STEP 5 : Clinical Informaticist gives the drafted paper order set over to Clinical IT Analyst to build a matching DRAFTED electronic order set in TEST system. (Because the Clinical Informaticist used the standards of the electronic orders, when making the paper draft, this will be very easy to do!)

STEP 6 : Clinical Informaticist and Clinical Director now review the :

• DRAFTED paper order set (labeled "DRAFT")
• DRAFTED electronic order set (in TEST environment)

STEP 7 : Clinical Informaticist, Clinical Director, and end-users (usually a minimum of physician, nurse, and pharmacist) "test" both paper and electronic order sets using some realistic "mock scenarios"

• Consider collecting any "testing" data, e.g. physician/nurse/pharmacist satisfaction, time-to-completion, etc.
• If any changes arise during testing, Clinical Informaticist and Clinical IT Analyst can correct both paper and electronic order sets simultaneously, to make sure they match.

STEP 8 : Once testing is completed, Clinical Informaticist and Clinical Director develop education and go-live plan for order sets.

STEP 9 : Clinical Informaticist and Clinical Director present, to your organization's formally-chartered approval committee :

• DRAFTED paper order set (labeled "DRAFT")
• DRAFTED electronic order set (in TEST environment)
• DRAFTED discharge instructions (if any exists from step 4 above)
• DRAFTED protocols (if any exists from step 4 above)
• Testing results/data
• Educational Materials
• Go-live plan

for their final review and approval.

STEP 10 : After approval, you remove the "DRAFT" label from the paper order set and publish :

• Paper order set - Put up on your intranet "Downtime Order Set" page, or some other common location your staff agrees to look for during electronic downtimes.
• Electronic order set - Move the draft from your TEST to your LIVE/PROD system.

STEP 11 : Clinical Director will deliver education, and continuously monitor the order set for safety, effectiveness, and new evidence/regulations.

STEP 12 : Clinical Director will return to step 1 as needed!

Bake at 350 degrees, or until golden brown!

I'm always interested in discussion! Feel free to leave comments about your process for developing matching order sets for your downtime! Questions are welcome!

Med Reconciliation and Midlevels

Sorry folks - I know it's been a few weeks since my last post. Blogging is fun, but it's hard work. New CMS regulations on Order Sets, Meaningful Use, HIE, EMR/EHR... It keeps a CMIO busy!

Anyway, so now onto this post. Working in front-line applied medical informatics, I see some general healthcare trends evolving. Some are predictable, other's aren't. Here's one of the things I've noticed recently, that might be encouraging to the midlevels (PAs, NPs, CRNAs, and Midwives) in the audience.

What I'm seeing : As three trends merge -

• Meaningful Use
• The National Patient Safety Goal for Med Reconciliation (See this great summary from the American Society of Health System Pharmacists)
• Relative polypharmacy

... it's becoming very clear to me that the demand for accurate electronic med reconciliation practices will go up inside hospitals.

The problem is that this is not the always the easiest thing to do. Just assembling medications and allergies at the point-of-entry can be complicated, having to potentially reconcile up to seven data sources (patient, family, PCP, specialist, pharmacy, chart, and med database). Many hospitals hire a position (pharm tech, or other equivalent position), just to compile the list of home medications.

But then, once you have the list, entering them into an EMR can be a challenge.

Once you have them in the EMR, then, you can perform electronic med reconciliation. It's one thing to do it at the point of admission and discharge to your hospital - It's another to do it at every transition of care.

But knowing that the goal is for med reconciliation at every transition of care, I sometimes wonder : Who will do this, and how? Especially in some areas where there are frequent transitions of care (e.g. your perioperative areas), how will you manage those medications?

Some feel surgeons should be responsible for med reconciliation of their patients in the perioperative period. The challenge, however, is that surgeons are often under intense pressure to get back to the OR, or else there are OR delays which cause a whole different set of issues.

It's also common for anesthesiologists to care for patients in the post-operative setting - But again they face pressure to go back to the OR, to avoid delays, so they mainly only focus on the immediate medication needs of the patient.

So it's not unusual for the conversation to then lead to hospitalists managing the medications for the surgical patients, especially in the post-operative period. (After all, who better to manage medications than someone trained in a medical specialty, right? :) )  The challenge here is often that hospitalist services may not be able to handle the additional workload, without expanding their workforce, and hiring an extra hospitalist can be pricy.

And so, I suspect many organizations will start to look at midlevels as a more cost-effective way of  helping to fill this need. And so, my impression : The demand for midlevels (PAs, NPs, RNAs, Nurse Midwives) will continue to increase in the near future.

How much will it increase? I suspect as long as midlevels are more cost-effective than hospitalists, the demand for them will go up. So if I wanted to play futurist, I would guess the increased demand would drive midlevel salaries up until they reach that of an average hospitalist - and at that point I think the demand would level off :

Of course, this trend will depend on many factors, including regulatory issues, licensing/credentialing issues, physician supply issues, and other state and federal controls on physician and midlevel training. And my prediction could be totally wrong! I'm going to keep scanning the horizon, but I suspect the healthcare organizations of the future will use midlevels with a solid oversight and supervision model, that allows them to give high quality care for less.

Any dissenting opinions? Feel free to comment below!

Secrets of EMR Governance

The following is essentially a repost of the piece I wrote for the June 2012 HIMSS Insider, with some slight modifications for my blog. (My apologies - my blog allows a higher word count!) :) :

Implementing an Electronic Medical Record (EMR)? Then you’ll want to know something about EMR governance. It’s a subject that’s not well-understood, but in this article I’ll try to provide some background. EMR governance is the process by which you standardize your clinical practices and set them up to work electronically. Without predictable clinical practices, you won’t be able to get predictable clinical outcomes - and because computers are programmed to behave predictably, your EMR implementation will be challenging.

What is governance? 
Although the Oxford dictionary defines governance as “the action or manner of governing,” a quick Google search reveals this NIST (National Institute of Standards and Technology) definition:

“…the controls and processes that make sure policies are enforced.”

So why should clinical professionals worry about policies? After all, aren’t they documents that administrators are paid to worry about?

What is a policy? 
The reason clinical professionals should care about policies is because they are the central nervous system that quietly controls your organization.

Policies are essentially your organization’s standards. They reflect your values and describe, in writing, what you’ve decided to do. If your standard is to give all patients a gluten-free, diabetic cupcake on admission, then your organization could decide to write that standard down on a piece of paper :

“All patients will get a gluten-free, diabetic cupcake on admission.”

Of course, you may decide to pursue more meaningful standards, but for now we’ll use this simple policy as a teaching example.

What is a procedure? 
If a policy describes what you do, then the procedure describes how exactly you go about doing it.

A good model for a procedure is a food recipe. Every line contributes to the end result. For example, to describe how to achieve the cupcake policy above, you might write this procedure:

1. Kitchen staff will bake 100 gluten-free, diabetic cupcakes daily.
2. Couriers will bring cupcakes to floor.
3. Nurses will give cupcakes to patients on admission.

You’ll notice a common theme in the procedure above: Each line answers, at a minimum, the who and what, but also can explain the when, where, why, and how. 
PLEASE NOTE : Some legal advisors recommend avoiding “will” and substituting other terms like “should” and “may.” Check with your legal counsel for advice before writing policies.

Then by having the directors of the Kitchen staff, Couriers, and Nurses review the policy before it gets approved, it allows them to :

• Review the expected workflow - so they can educate it to their staff once the policy is approved, and 
• Budget for it - Do they have the staff and material resources to uphold their part of the workflow?

You will want the directors and their staff to review the drafted policy before it gets approved, so be prepared to spend some time reviewing it with them before it goes for final approval.

When do I write a policy and procedure? 
By writing your policy standard and a procedure describing exactly how to achieve that standard, you now have a very valuable document. Together, these documents give you a meaningful change management mechanism.

Some people, when they learn about policies and procedures, suddenly want to develop policies for everything. Try to resist this urge. Too many policies can make it hard for employees to comply with them. On the other hand, too few policies might mean you’re not standardizing your operations. Ideally, you want a happy medium.

And so, you should only write policies when:

• The policy is required to meet a legal, regulatory, safety, or operations need.
• The policy addresses a common occurrence or practice.
• You have the resources to implement the policy.
• You can enforce the policy.

And, you should only write good policies.

What’s a good policy? 
A good policy is one that creates clarity and harmony in your organization. End-users should be able to find it, read it, and immediately understand your expectations. It should be a valuable management tool for leaders and directors, and should always reflect your values and current practices.

A bad policy is one that creates confusion, chaos, or in a best-case scenario, changes absolutely nothing. A bad policy conflicts with your values, does not reflect practice, is published where few people can find it, and many employees don’t know it exists.

So what about hospital governance? 
Before discussing IT and EMR policies, it helps to understand a little about the difference between administrative and clinical policies.

Let’s say you were building a hospital from scratch—you would need two teams to help you :

1. A clinical team, who know all about giving care, treating diseases, and doing surgeries and procedures
2. An administrative team, who know all about finance and operations and regulations and legal issues.

Neither team can live without the other; virtually all hospitals need both. So we generally divide their standards into:

1. Clinical policies – Those that define patient care and clinical standards.
2. Administrative policies – Those that define employee and administrative standards.

The key ingredient needed for these two teams to work together harmoniously is good communication at all levels of your organization.

So what about IT and EMR Governance? 
After you have a good understanding of your organization’s policy and committee structure, you can go about examining your current standards. Do you have any documents that spell out basic clinical practices such as:

• Electronic Documentation – How/when to create it, sign/authenticate it, use it?
• Medication Order Standards– How/when to order certain medications? Non-formulary medications? In code blue/emergency situations? Over the phone?
• Standards for lab/radiology orders– How/when to order certain tests?
• Training standards – How do you train new employees? Existing employees?
• Clinical Tool Development – How do you develop order sets? Policies? Procedures? Protocols? Documentation? Downtime documentation?

Look for these documents because you will need to examine them and probably modify them after your EMR implementation to help make your processes more efficient. In general, the standards get tighter, and the demand for resources increases after your EMR go-live.

Finally – A common question I hear is, “Where should I publish my IT and Informatics policies? In the administrative or clinical policy manual?” Surprisingly, most informatics and clinical IT policies belong in the clinical policy manual. While it’s tempting to think of them as administrative issues, most of them have a strong impact in clinical functions and strongly impact the day-to-day operations of clinicians. When in doubt, ask yourself: “Who is the end-user of this policy?”

10 DOs and DON’Ts to remember with EMR and Health IT Governance

• DON’T: …write policies in a rush. The more time you spend on them, the clearer and more effective they will become.
• DON’T: …write too many policies. They should only be for things that address absolutely necessary legal, regulatory, or workflow issues, and those that you have resources to monitor and implement. 
• DON’T: …make policies automatically punitive. Non-compliance with a policy should give a leader a reason to pause and reflect: Why didn’t the policy help reinforce the desired outcome?
• DON’T: … forget to document reasons why you knowingly didn’t comply with a policy. They carry legal risk and weight, so any non-compliance should be well-documented and discussed with leadership.
• DON’T: … keep policies hidden! For them to work best, it helps to keep them in a common place where everyone can find them.

• DO: … practice writing policies, and have end-users look them over to help check for clarity.
• DO: … spend time learning your organization’s governance structure, including your bylaws, policy manuals, policy writers, reviewers, and approval bodies.
• DO: … keep reading more and look for classes on operations and policy development.
• DO: … consult legal counsel when needed, especially to tackle tricky, high-risk or other compliance issues.
• DO: … network with other healthcare technology colleagues, to share tips, tricks, and lessons learned.

CMIO Survival Skills

While a CMIO is there to help implement the technology, so much of the job is process, workflow, and governance. So since I've now been in the role for five years now, I thought I'd take a moment to look back and reflect on the things I've learned in the last five years that I think are valuable CMIO skills.
Here are the 13 most important skills I can think of, off the top of my head, in my usual tongue-in-cheek style : (Remember, as always - Your mileage may vary, depending on your circumstances.)

1. Hospital Governance 101 -  It's not enough to just know the clinical side of governance. You need to know the administrative side too. Both of these wings of hospital governance intersect with each other in different places, and knowing where they meet with your bylaws is vitally important. You will be navigating both, so it pays to know the landscape. Bonus points are awarded if you can diagram your committee structure by heart. :)
2. Document Management - Understanding the basics of how documents are created, drafted, approved, and published is essential. Bonus points are awarded for knowing the details of these steps well - For starters, I wrote a post on the importance of knowing the difference between DEV, TEST, and PROD - These environments typically exist for computer projects, but in reality they apply to all construction and document development (even that email you just sent!). Know them well, why they exist, and how to use them to your advantage in your organization.
3. Definitions and structure of your Clinical Tools - You should know your clinical tools like the back of your hand - Exactly how your organization defines them, drafts and builds them, tests and reviews and vets them, approves them, and publishes them. You should be able to look at them and have opinions on whether they are as effective as they can be. For starters, the CMIO's checklist is a good place to start working on this. Bonus points are awarded if you can recite your organization's definitions off the top of your head. :)
4. Compliance with State and Federal Regulations - You will need to know these well, and will probably be asked to help your organization comply with some of them. Even if you don't know them very well, you need to have a good relationship with your regulatory people, and know where to look when you have questions. Bonus points are awarded as you gradually learn this landscape better.
5. Project Management and managing 'the technical details' - You will need to know the basics of this - Whether or not you have a separate project manager to work with, you will be involved in many projects. Knowing what to expect at different stages when undertaking large month- and year-long projects is very helpful. As for the technical details, you may not want to know how sausage is made, but if you (or your organization) wants to eat sausage (pardon the metaphor), then someone will have to worry about the technical details. If it's not you, then make sure you have a good relationship with the people who understand the details, and work with them closely when undertaking new projects. 
6. Parliamentary Basics - You will probably be asked to chair a committee or two, and be a member of others. Knowing how to properly run a meeting and conduct a committee is crucial. For starters, Robert's Rules of Order is a fantastic place to start. Also make sure you have a formal, written charter - It not only establishes your authority, it establishes the chain-of-command and is essential for good performance and when questions come up. And a tip : Always publish your minutes after approving them at the next meeting. If you wait to format and approve your minutes, they will just build up and you'll have to play catch-up later.
7. Meaningful Use, emerging Health IT Trends, and Workflow Analysis - It's almost impossible to keep on top of every detail, but you should have a good understanding of the Meaningful Use rules, timelines, and how your organization is responding to them. You should also understand the basics and be able to comment on various existing and emerging HealthIT, clinical, and legal trends, including your statewide HIE effort, NHIN, ICD-10, clinical decision support, mobile devices, HIPAA, eDiscovery, etc. Finally, you should understand the basics of workflow analysis and why it's necessary to implement all of this technology. A good way to learn to think in a linear fashion is to read food recipes - This will help you think about the relationship between process and outcomes, and help teach you to write a good procedure.
8. Safety through Information - Safety is not just resident workforce hours and barcoding your medications. Safety needs to be built into all of the documents and information you're overseeing. First, know what a good order set and a good protocol look like - Then learn what good documentation, good policies, good procedures, good guidelines, and good workflows look like. This is one of the big reasons organizations look for a CMIO, so always look for opportunities to improve safety with every tool you see.
9. Networking - Virtually every hospital is going through Meaningful Use together. You will help save yourself a lot of headache if you know the other CMIOs in your area. Use social networking (e.g. Twitter), or call them up, introduce yourself, and meet them just to talk shop every once in a while. The Interstate 91 Informatics group I've set up has been invaluable to me and others in helping to share lessons and best practices. Look to see if there's any regular gatherings in your area, and try to get to at least one of the national conferences every year (e.g. HIMSS).
10. Teambuilding, cheerleading, politics - You will undoubtedly meet other doctors, nurses, pharmacists, and other ancillary staff, and need to meet with them. Often, EMRs demand more collaboration between clinical specialties, so you will have to know how to encourage people to work together. Don't try to play sides or favorites - Treat everyone equally and you'll be able to build those teams.
11. Budgeting realities - Implementing an EMR is expensive. There are costs at every step of the way - Technical costs, training costs, costs to change workflows, staffing costs. "Flexible budgeting" is optimal, but in today's climate, most organizations are focused on cutting costs. Be prepared to work with your budgeting people, and always ask yourself, "What if we don't get everything we ask for?"
12. Informatics Education - Whether you're the "Chief Medical Information Officer" or the "Chief Medical Informatics Officer", you will be discussing Informatics with many people, probably while you are defining this emerging role in your organization. The term is sometimes frightening to people, until they start to understand it. Don't try to teach too much at once - Small, frequent feedings are better, so try to meet with leadership for frequent, short meetings. Bonus points are awarded if you help set up an entire Informatics department.
13. Statistics and Process Improvement - After your EMR go-live, you will probably be asked to help optimize the EMR - That means, looking at the results from go-live, and looking for ways to improve results, e.g. higher achievement of core measures, higher CPOE rate, etc. Learn how to get utilization data out of your EMR, and look for statistical relationships that help you improve your processes. Know what a Venn diagram, control chart, pareto diagram, and fishbone diagram are. Bonus points are awarded if you can write your own SQL code! :)

It has been enormously rewarding to me, and if you find yourself in the role, I hope it's equally rewarding to you. Although the first CMIOs appeared on the scene back in the 1990s, it's still a relatively new position (especially in the northeast), so be prepared for a lot of change and ambiguity when you start down the road. 

As always, I enjoy simultaneous teaching and learning - Feel free to leave questions, comments, or thoughts below!