Why Terminology Matters

 Hi fellow Clinical Informaticists, CMIOs, CNIOs, and other HealthIT friends,

A short post this time - Just sharing how terminology management can impact EMR usability. 

Managing an enterprise EMR is a lot like owning a closet. Information is stored in certain virtual 'drawers', where people (users) get used to storing and finding the information they need to do their jobs.

The problem is, just like closets - Exactly where and how people like to store this information is an intensely personal, cognitively-driven process. If you have ever had to share a closet, you probably know how challenging it can be to share a closet with another person. 

Now, imagine having to share a closet with 500 people. The first step would be getting all 500 people together for a meeting, and discussing/reviewing : 

• Where should we keep the socks?
• Where should we keep the pants?
• Where should we keep the shirts?

Some people may have different opinions about where and how to keep things, but ultimately, you will need to make some final, group-based decisions. 

Still, some people may start working for your company after those group discussions/decisions are made, so it's helpful if you :

• ... have an easily-identifable pattern associated with your information storage and retrieval, and...
• ... if you label things correctly. 

Today's post is really about labeling things correctly. For teaching purposes, I sometimes simplify it as this : 

"Call it what it is."

It can sometimes be difficult to spot terminology issues, so I'll start with a simple hierarchy that helps explain the confusion that can create frustration for end-users :

Keep in mind that these are simple, real-world examples that we are using as proxies for more complicated, real-world clinical scenarios.

In any case - when labeling a button, folder, or other item in an EMR, it's important to have the appropriate level of granularity and accurate clinical terminology, or else you can lead to confusion for end-users : 

Suppose a user is looking for an apple. 

• In scenario #1 above, if we just refer to apples and oranges as "fruit" - users will need to spend time clicking through both boxes, looking for the apple. It might be in the left box, or the right box - They are both labeled "Box of Fruit", and fruit is not a granular enough term to identify the exact tool the user is looking for (an apple).

• In scenario #2 above, it's easy to find an apple. The first box is labeled, "Box of Apples".

So it's always very helpful to :

• understand and anticipate what the user will be looking for, and...
• understand the clinical terminology and associated hierarchies, and...
• call it what it is.

Some people might argue "Well, if both apples and oranges are fruit, why not keep them in the same 'fruit' folder?" For sure, there are some scenarios where this may make sense, especially if there are not many items to look for under a folder. 

However, keeping too many items in a folder can also lead to unnecessary time spent looking for things. 

So ideally, especially when storing a large number of items - It's helpful to understand the clinical role, the clinical context, the clinical terminology, and the higher/lower level concepts, to help identify the right term to label buttons in your EMR, for maximum efficiency and less clicks.

Hope this helps shed some light on common terminology issues that every organization has to manage as they configure their EMRs. If you're not sure about a term, reach out to your local Clinical Informaticist for guidance, tips on how to reduce clicks, and other common clinical workflow design issues.

Remember, this blog is for educational/discussion purposes only, and your mileage may vary. If you have any terminology tips or suggestions, please leave them in the comments box below!

Culture, Terminology, and EMR Usability

Hi fellow Informatics friends and colleagues,

When sharing the secrets of electronic medical record (EMR) usability, some people are surprised at how much culture and terminology impacts user satisfaction. Allow me to explain.

EMRs are essentially tools used to store and retrieve patient care information. When configuring an EMR, the most common mistake is thinking it's 'like paper', simply a bunch of words, lines, and boxes on a page. EMRs are different - Buttons open menus that lead to other tools and actions, so it's more helpful to think of it more like you are organizing a closet: 

• Socks go in the sock drawer.
• T-shirts go in the t-shirt drawer.
• ... and so on.

Only an electronic patient record literally contains hundreds of drawers, each containing as few as a handful, or as many as hundreds of documents, images, vitals, or other data elements. E.g. : 

... and when you click on the button "RADIOLOGY ORDERS", one would expect to find the orders related to diagnostic and therapeutic/procedural radiology modalities.

So a key design element to consider : 

• How many items do you need to store in a chart, for patient care purposes?
• In which 'drawers' will you store them?

And so when organizing a closet at home, most people realize they don't have room for a separate drawer for every piece of clothing, so they will use some categorization scheme (that makes sense to them) to combine related items in the same drawer, E.g. : 

• Top Drawer = Undergarments (Socks, Underwear, and T-shirts)
• Bottom Drawer = Outer garments (Shirts / Pants)

We don't consciously think about categorization schemes very much, but our brains do this naturally, to try to make sense of the world, and establish a pattern that will ultimately help us get dressed in the morning. 

Anyone who's ever had to share a closet, however, knows there can be disagreements about categorization schemes, resulting in some interesting household debates. If you have children, you also know it's helpful to label drawers, or explain the categorization scheme, so your kids can find their clothes in the right drawers. Food pantries and refrigerators are common sources of domestic debates, because different family members might have different ideas about ideal organizational schemes.

So it's no surprise that people who are responsible for configuring and organizing an EMR often stumble upon the many cultural differences in thinking and terminology between "healthcare tribes" - E.g. between physicians, nurses, pharmacists, radiologists, laboratorians, ancillary services, medical records, finance, etc.

Here's a good teaching example to better understand what I'm talking about, and how these terminology issues have real-world impact in user EMR satisfaction : 

Imagine it's the year 2050. 

You run a hospital with an EMR. It is suddenly discovered that tomatoes save lives, so you prepare to have tomatoes in your hospital, keeping them in your Pyxis machine, and create tomato orders in your EMR, to order and release the tomatoes for patient care (when needed). 

After meeting with your available subject matter experts (SMEs), many of whom, for scheduling reasons, just happen to be from clinical Tribe A - your analysts build the "Tomato" order, and make it available under the "Vegetable" menu choice below :

Shortly after building this, you suddenly get complaints from Tribe B users, who couldn't show up to the earlier meeting but say, "Hey wait, tomatoes are technically berries, which are technically fruit - Here is the evidence : https://en.wikipedia.org/wiki/Tomato - So they should be listed under the "Fruit" menu choice instead! Those of us who know this can never find the Tomato order!"

You also get complaints from Tribe C users, who say, "What's a Tomato? We've never heard of that. Oh, wait, you mean that red thing we put in our salads/sauces/sandwiches? We've been doing this for 20 years, and in our experience, we've always called it a Golden Cherry."

Do you :

• OPTION 1. Listen to Tribe A, and file the tomato order under the "vegetable" menu, and educate Tribes B and C that tomatoes are red fruit that grow on a vine, are commonly used to make sauces/salads/sandwich toppings, and most commonly thought of as vegetables?

• OPTION 2. Listen to Tribe B, file the tomato order under the "fruit" menu, and educate Tribes A and C that tomatoes are red fruit that grow on a vine, are commonly used to make sauces/salads/sandwich toppings, and correctly categorized as fruit? 

• OPTION 3. Listen to Tribes A and C, rename the tomato order to a golden cherry order, file it under "vegetable", and educate Tribe A that tomatoes will now be referred to as a golden cherry and will be filed under the vegetable menu? 

• OPTION 4. Listen to Tribes B and C, rename the tomato order to a golden cherry order, file it under "fruit", and educate Tribe B that tomatoes will now be referred to as a golden cherry, and will be filed under the fruit menu? 

• OPTION 5. Bring Tribes A, B, and C together for a meeting, review the concepts, terminology, and taxonomy of tomatoes together, and agree to a functional definition (for your glossary!) that meets the needs of all three tribes : 

Tomato ('golden cherry') - A common red fruit/vegetable that grows on a vine in temperate climates, that is commonly used to make salads, sauces, and sandwich toppings. 

... and then build the tomato order, attach a synonym of 'golden cherry', and then file it under :

• the "vegetable" menu choice? 

• the "fruit" menu choice? 

• BOTH the "vegetable" and "fruit" menus? (making Tribe A complain that it shouldn't be making the fruit menu look messy, and Tribe B complain it shouldn't be making the vegetable menu look messy) 

• Or build a hybrid "vegetable/fruit" menu choice? 

... or more options we haven't considered yet?

How these terminology, taxonomy, and conceptual issue get managed will ultimately impact the satisfaction of users who are trying to find a tomato ('golden cherry') in the EMR for patient care.

Hope you enjoyed chewing on this interesting EMR terminology challenge! If you think terminology issues might be impacting your workflow, feel free to ask your local clinical informaticist for help! (#whyinformatics!)

Remember this blog is for education and sharing purposes only. Have other examples of terminology and classification systems impacting EMR usability and satisfaction? Or have you struggled with this yourself? Feel free to share in the comments section below!

Some Factors Underlying Efficient Change Management

Recently I had a great discussion with a non-healthcare person about the role of Informatics in EMR implementation, and what kind of things CMIOs look for to estimate whether a particular EMR implementation will be successful or not.

The discussion was a great opportunity for me to really think about the big picture issues, and try to distill them into something more tangible to a non-healthcare, non-informatics audience. 

What it finally came down to, for me, was the successful planning and budgeting for the whole EMR implementation - both the go-live, and the eventual optimization and continued maintenance that come afterwards. It's not unlike buying a car - To be successful at car ownership, you have to budget for both the car (necessary at go-live) and the gas/maintenance (necessary after go-live to make the car go forward) :

While researching for this blog post, I found out this is one of the reasons why the mandatory price stickers on all new cars (known as the Monroney sticker) must contain both the price of the car and an estimate of the gas mileage :

Not only does this allow consumers to select cars with better fuel efficiency, it also helps a consumer answer the question "Can I afford this car?" before they actually buy it - A major factor for successful car ownership.

With most healthcare technology, it's pretty easy to budget for the car - vendors know this number well - but it's not as easy to budget for the gas. Vendors will often estimate the cost of optimization, upkeep, and maintenance for you, but how do you really know if their estimate is correct? Will you see the same gas mileage in your experience?

This then raises the question - What exactly are the factors that go into 'gas mileage' for an EMR? CMIOs, CNIOs, and other Informatics professionals struggle with these questions all the time, because they are important to help budget for successful EMR implementation :

• Budget well for the ongoing optimization, maintenance, and upkeep - And your EMR implementation will likely be successful.
• Budget poorly for the ongoing optimization, maintenance, and upkeep - And your EMR implementation may be fraught with struggle.

What experienced Informatics professionals know is that a large part of the 'fuel-efficiency' of EMR ownership comes from the organizational change management - How well-suited is the organization to make change? Does it contain the infrastructure and configuration needed to support efficient change management? 

These change management issues are so key to EMR implementation that in 2013, the website www.HealthIT.gov published this great primer on EHR change management :

https://www.healthit.gov/sites/default/files/tools/nlc_changemanagementprimer.pdf 

 ...which provides a great high-level overview about change culture, along with some fantastic references. (A helpful document and a must-read for any healthcare executive considering an EMR installation or replacement!)

But what are the other factors that experienced informatics professionals look for in change management? Are there other factors to look for that help better estimate your gas mileage, and thus your eventual cost of ownership? To help share some insights, I've created the following table, with some factors that I believe influence an organization's ability to manage change efficiently - In estimating the price of your gas, some factors to consider (in no particular order) include : 

While this list is by no means comprehensive, these are some of the bigger factors that experienced Informatics professionals consider before advising organizations how to best budget for their EMR implementations.

In the end, enterprise EMR success depends on correctly budgeting for the purchase, maintenance, and upkeep of your technology. It's not just your go-live that matters. Knowing the price of both the car and the gas before you invest will help you have a successful long-term implementation.

This post is for educational and discussion purposes only - Please consult your own Informatics professional before budgeting for any technology purchases. If you have any feedback, thoughts, or other factors to consider, please leave them in the comments section below!

Should Clinical Informaticists be licensed?

Hi readers,

I was recently talking with a group of informatics professionals about the issue of clunky workflow and 'click burden', which is a constant issue in EMR adoption. The conversation raised a question I've been wondering about recently - Should Clinical Informaticists be licensed? To help answer this question, I thought it would be fun to take a trip back in time and see if history can help guide us. 

Our trip back started recently when I was reading about the history of the area where I live - Northampton, MA, which sits in western Massachusetts, at the foothills of the Berkshire mountains, along the Connecticut River. I was really surprised to learn about the history of a little stream that runs along Route 9, the Mill River - Which in 1874 was the site of a horrible tragedy, which eventually helped contribute to advancements in safety and engineering that we benefit from today.

To start our journey, I'd like to thank Elizabeth M. Sharpe, PhD, the author of this great reference that nicely summarizes the events : https://pvhn3.wordpress.com/1800s/mill-river-flood-of-1874/ 

In short - The Pioneer Valley, as it's known, was once the site of great industrial strength, like many New England towns. Buttons, cloth, brushes, and paper were all produced by factories in this area, and shipped off for sale to other places via a rail system that used to connect the area with other parts of the country. 

And like many industrial areas prior to widespread electricity, these factories depended on waterways for energy. The Mill River, about 15 miles long, was one of those waterways.

So back in the 1870s, a group of local factory owners, disappointed with their inability to produce goods during prolonged droughts, developed an idea : To build a big reservoir up in the hills, in a little nearby town called Goshen - So if there was a drought, the idea was, the water could be let out into the Mill River, and the factories could stay in business.

So the factories commissioned the building of a big, 100-acre reservoir up in the Goshen hills. From the Dr. Sharpe's site https://pvhn3.wordpress.com/1800s/mill-river-flood-of-1874/  : 

"In the absence of state regulation on dam construction, the reservoir company was free to design and build the dam as they pleased.  Frustrated with the $100,000 cost of a design prepared by professional civil engineers, the company opted to dictate their own design to an incautious local engineer who wrote general specifications.  The company then hired careless contractors for $24,000 who made the inadequate design worse.  Despite repairs, the dam leaked and slumped for eight years.  Anxious valley residents who questioned the dam’s safety were reassured by the manufacturers that the dam would hold.”

Sure enough, on May 16th, 1874, the weather had been unusually rainy, and the dam gave way. Millions of gallons of water suddenly spilled down the Mill River, sweeping houses, barns, bridges, roads, factories, and people, and down the river, killing 139 and making over 700 people homeless. The New York Times took two days to figure out what happened (before the telephone), but eventually reported this : 

(NYTimes, May 16, 1874)"ACCOUNTS FROM SPECIAL CORRESPONDENTS.""THE CONSTRUCTION OF THE DESTROYED DAM - THE RUSH OF THE FLOOD DOWN THE VALLEY - THE VILLAGES DESTROYED. PARTIAL LIST OF THE DEAD. MORE BODIES FOUND. PROBABLE LOSS BY THE FLOOD.""Northampton, Mass., May 16. - The beautiful valley of the Connecticut River was laid waste to-day, and five villages totally destroyed. The heavy rain of Friday night and this morning caused a rapid rise in Mill River, on the banks of which were built the villages of Williamsburg, Skinnerville, Haydenville..."

What strikes me most about the story came from the hearings following the disaster : 

"A coroner’s inquest thoroughly investigated the disaster’s cause.  The verdict named five parties at fault: the reservoir company which owned the dam; the contractors who built it; the engineer who provided an inadequate design; the county commissioners who inspected and approved it; and the Massachusetts legislature which chartered the reservoir company without requiring any assurance that it was safe.  There were no indictments, no fines, and no subsequent law suits.  A year after the flood, in 1875, Massachusetts passed its first legislation regarding reservoir dam design, construction, and liability.  Considered weak by today’s standards, the law was, nevertheless, a first step toward safer dams."

And so, through disasters like this (and the similar Johnstown Flood of 1889), eventually America came to learn that all engineers actually needed to be licensed. See the National Society of Professional Engineers page commemorating this achievement here :  http://www.nspe.org/resources/press-room/resources/100-years-engineering-licensure 

As a result, today, the houses we live in, the elevators and cars we ride, and the water we drink has all been designed by a trained and licensed engineer, whose responsibility it was to ensure the successful design and safety of the project.

And so the house, car, and elevator you got into all followed basic engineering principles and started as blueprints, which were tested before they were built, inspected, and approved for use.

Historically, healthcare did not apply these engineering principles to workflow development. Generally, doctors and nurses built these workflows organically, through informal agreements about how to take care of patients made over many years - Typically with no blueprints, no project plans, and no formal approval process. But with the advent of modern EMRs and ACOs, we now need to engineer workflows to a higher standard. 

This brings us to the question of licensing Informaticists. Despite the significant efforts of AMIA, ANIA, and HIMSS to formalize and standardize the role, there still are still a number of "Informaticists” who have no real training on CDS or clinical workflow design. Similarly, there are some people doing CDS and clinical workflow design with no formal Informatics training, or even recognition that they are working as Informaticists (because they have other job titles like “Clinical Knowledge Expert” or “Solutions Engineer”) - 

While certificates, degrees, and board certification in Informatics goes a long way in improving the quality of workflow design, healthcare still has a long way to go in recognizing the importance of this certification, and why it's important to have trained, certified engineers (Informaticists) designing the orders, order sets, protocols, documentation, and workflows in the EMR, to help streamline clinical workflows and reduce click burden.

So the Mill River teaches us that it's better to have a dam built by a trained, licensed engineer, with legal responsibility for the outcome, than to have one built by an “engineer” with no formal training. And this is why organizations seeking to improve click burden and streamline their workflows might be well-served to have trained, certified Informaticists leading their EMR configuration. And to help achieve this primary goal, it's helpful to call Clinical Informaticists what they really are - Clinical Informaticists.

I hope this post has been a fun trip back in history, and helpful to you in developing your own Informatics platform.

Remember these posts are for open discussion and educational purposes! Have any thoughts or feedback? Leave them in the comments section below!

Problem Lists - What exactly is the "Past Medical History"?

Hi readers,

Happy 2016! For today, I'm going to try to tackle an interesting conceptual and terminology issue around problem list management, and how it relates to the Past Medical History (PMHx).

Many people, working to optimize their EMRs, work hard to try to 'curate the problem list' - WIthout good curation, problem lists can become very lengthy, and include issues like "Cough" under Past Medical History - 

1. Some people see this as a failure of HealthIT ("Why is cough under the Past Medical History, when it's not a diagnosis?") - 
2. Other people see this as a failure of the doctors using the system ("Why didn't anyone remove cough from the Past Medical History?") - 

What I find particularly interesting about this discussion is the wide variation in practice, when I read admission history and physicals. I think most docs, billers, and coders believe that, on admission, the doctor should document whatever the 'acute medical issues' or 'active medical issues' are - But what do these terms mean, exactly?

1. If a patient with stable diabetes is now admitted with cellulitis, and the doc continues the diabetic medication - Should diabetes be on the active medical issues list?
2. Or should the doc only code for the cellulitis?

In discussing this many times over the years, I find that many docs use the terms 'active medical issues' and 'acute medical issues' almost interchangeably. Are they really interchangeable?

So I Googled the terms "Active Medical Issue" and "Acute Medical Issue", and found a number of good articles, including this 2010 post by A Country Doctor on Kevin MD and this excellent 2005 discussion on Past Medical History by John Gazewood, MD. Finally, the US National Library of Medicine offers this good explanation of acute versus chronic conditions.

But how are acute and active medical issues different? While these are are all good treatises on medical issues, I was wondering if I could approach this from a design standpoint, as a physician informaticist, with good conceptual definitions for the terminology, to make sure there is real clarity around the discussion. 

So, in trying to tackle this informational design issue, I've hammered out the following DRAFTED definitions, depicted on the following two slides, for your examination and discussion (the same concepts are on both, but each is displayed slightly differently) :

Slide 1 - "Bucket" depiction

Slide 2 - Same concepts, different depiction

I created these slides to try to create conceptual 'buckets' that problems/issues could easily fall into, allowing physicians to move items from one bucket to another as the patient moves from one provider to another - And then labeled them with terminology (and synonyms) that I believe best fit the concepts. (Please use your own judgment before adopting any of this terminology.)

What these slides do, however, is shed some light on why maintaining the problem list is more challenging than you might expect. It requires enormous clarity just to discuss the issues, and then when you examine the concepts in detail, there seems to be some breakdown in the definition of "Past Medical History". 

For example, in the scenario where the patient with stable diabetes is admitted for cellulitis - On writing the admission H&P, a doctor might code for both the Unstable (Acute) issue ("Cellulitis"), and the Stable (Chronic) Issue ("Diabetes, Type 2, Controlled"), since he/she has made the active medical decision to continue the diabetic medication while treating the cellulitis. 

However, on discharge, what do you do with these two Current(Active) issues (Stable and Unstable) in the EMR? 

• The cellulitis might be moved to the Prior(Inactive, Resolved) Issue list, but 
• the diabetes is still a Stable (Chronic) issue - which falls under the category of Current(Active) issues - 

So the problem is that, I suspect, most doctors would conceptually define "Past Medical History" as the items found in these three buckets : 

1. Prior Procedures
2. Prior (Inactive, Resolved) Issues
3. Stable (Chronic) Issues - which conceptually falls under the category of Current (Active) Issues - 

It's the incongruence between "Past Medical History" and "Current (Active) Issues" that I find most interesting - Past isn't really in the past, if it's still in the present. 

It's also interesting to note that the commonly-used term "Reason for Admission" typically only includes issues that would fall under the Unstable (Acute) issues bucket - But the Admission H&P typically includes more issues, especially if they involve active medical decision-making (E.g. both Unstable (Acute) issues + Stable (Chronic) Issues)

In practice, I find many docs will only include as many Stable (Chronic) issues as time (and patient census) allows - It's interesting to ponder how this impacts coding and billing on the national level.

Finally - I believe these slides support the argument that the terms "Active Medical Issues" and "Acute Medical Issues", although related, are in fact not interchangeable. (I suspect that Acute is really a sub-type of the concept of Active medical issues.)

While my post today doesn't have any great answers, I hope these slides, and this discussion, have at least shed some light on the concepts and terminology surrounding problem list management, and how they impact EMR usage, coding, and billing on the national level.

Have any thoughts about problem list management? Leave them in the comments section 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!

Improving organizational Informatics by leveraging your Intranet

1. THE PROBLEM

A common problem with EMR and EHR implementation in a hospital is usually : How do we get enough Informatics staff?

You need the Informatics talent to help with the initial implementation. You need them later to help with the maintenance and training. You need them to help with "special new clinical projects" which require engineering many tools to a higher standard than you did in the paper world. You need them to help achieve Meaningful Use. You need them to help ensure the steady flow of good clinical data to quality management. You need them for expert advice on workflow redesign and systems issues.

The problem is that many hospitals don't have as much Informatics support as they'd like. Why?

• Informatics is commonly confused with IT, making for difficult budgeting decisions when trying to build an Informatics platform.
• The term "Informatics" is used so loosely, many people just don't really know what they're looking for.
• Even if you know what you need, and have the budget - There are not a lot of well-trained, experienced Informaticists around!

So if you're a lonely Informaticist in a large organization, you might be facing the challenge of : How do I help everyone in our organization to achieve their dreams and accomplish their goals, when it's just me?

Often the stretch on Informatics resources makes it almost impossible to help everyone achieve the workflow clarity they need.

So it's not uncommon that Informaticists start to fantasize, "What if I could teach people in every department some basic Informatics so they could manage their own projects that will work with our EMR?" You're never going to get them all to take the AMIA 10x10 class, but what if you could get them to start thinking differently about their tools so they could engineer them better BEFORE they approach your Informaticists and Clinical IT Analysts?

2. THE PLANNED SOLUTION

There's a little tool most hospitals have, that can help you bring clarity to virtually everyone in your hospital - It's your Intranet. Yep, that page that comes up every time you open a web browser - Is it helping your organization as much as it can? Are you using it to publish your important documents internally?

Some signs that your Intranet needs some updating include :

• You don't really look at it much.
• You only use it to get to Up-to-Date, or to the phone paging system.
• You have trouble finding what you're looking for.
• It's very lengthy.
• You set your home page to Google rather than your Intranet.

Remember - This is the one place virtually every person in your organization starts off with - Why isn't it helping them more? 

The challenge, of course, is to make it as chock-full of deliciousness as you can. Cut out the waste, and only include the good stuff. And not just for the docs, or the nurses, but for *everyone* - Administrators, pharmacists, respiratory therapists, etc...

So after developing the CMIO's checklist, it dawned upon me that one could leverage their Intranet home page in a way that would :

• Bring clarity about the documents your organization manages.
• Bring all of the documents "close" to that home page in an organized, methodical way.
• Give a little "drop" of Informatics education at every click.
• Create real ownership of all of your important documents.
• Creates real organizational transparency for those documents you want to be transparent.
• Create linguistic harmony in your organization (to help meetings run more efficiently)
• Facilitate supervision of your employees and committees

So by putting apples-with-apples and oranges-with-oranges, you can use the definitions from your organization's CMIO's checklist in a way that puts virtually every piece of paper within (I estimate) five clicks of that Intranet home page. Here's what it hypothetically could look like :

DRAFT - MAIN INTRANET PAGE
--------------------------------------------------------------------------------

1. Telephone Numbers - Tools to contact a person
2. Emails, Screen Savers, and Posters - Tools to help send a short message
3. Schedules - Tools to show who is responsible at what date/time
4. Policies and Procedures - Tools to learn organizational standards and how to achieve them
5. Guidelines - Tools to help educate and guide staff towards a desirable outcome
6. Documentation - Tools to record and transmit information
7. Orders - Tools to document and transmit instructions to deliver care
8. Order Sets - Tools to standardize and expedite the ordering process for a common scenario
9. Clinical Protocols - Tools to standardize and automate a clinical process
10. Clinical Pathways - Tools to standardize daily care for a diagnosis
11. Education Modules - Tools to help educate patients/staff
12. Dashboards and Reports - Tools to help you monitor something
13. Templates - Tools to help make a document
14. Wikis - Tools to help organize information/links for  a department
15. Committee Charters - Tools to assign committee duties and responsibilities
16. Committee Minutes - Tools to record committee activities
17. Glossary of Terms - Tools to learn organizational definitions for common terms

--------------------------------------------------------------------------------

Need to add something to this page? Call Dirk Stanley at 555-1212 or email him at dirkstanley@_____.com.

First, you'll notice at the end I have a link about "add something to this page" - That's your cue to bring a user to the documentation they need to understand when making/drafting one of the tools. It's not too hard to write a page or two on "how to write a protocol" or "how to write a policy" - This puts that documentation in their hands, easily-found, in the same-place-everytime, and empowers them to help organize their projects before they approach the Informaticist.

Next, you'll notice there is less clutter. It keeps your Intranet home page tidy and makes every link meaningful. Aesthetically it's pleasing, even as text. Could look even better with some good graphics design.

It also fits nicely into a Drupal-style framework - Flexible, easy-for-departments-to-maintain, and your organization's history is well-documented.

Finally - if you keep this same sort of format throughout your entire Intranet, then I predict :

• Users will learn about the tools and their definitions every time they look for a document
• Users will learn that "it's more than just order sets" that are involved in clinical changes
• You will make it very easy to link these electronic documents to your EMR for various purposes (e.g. reports, protocols, etc.)
• Virtually every important document will end up about 5 clicks from the home page
• Users will find the Intranet a high-value site
• It won't just be the clinical side that "goes electronic"
• Your Intranet Home Page will become a tool and a resource for everyone in your organization.

I haven't fully implemented this framework myself, yet - Make no mistake, achieving this level of efficiency on your Intranet is no small task, and will likely require an entire team and a lot of buy-in from your organization. But it's the conceptual framework I am working on - Tight, efficient, smooth information flows that bring employees together in one place, rather than allowing technology to separate them.

Remember, your mileage (and definitions) may vary! Would love to know if any readers have achieved this level of informational efficiency. How did it go? What were the setbacks and successes you had along the way? We're all both teachers and students, so I always welcome comments!