Tuesday, December 14, 2010

Find any document in your hospital in five clicks?

It's December. The squirrels have gathered their nuts. The leaves have fallen. People are having their holiday parties. It's a time for reflection, as we anticipate the new year 2011 that lies ahead. Healthcare is changing faster than ever before, and those who want to survive, need to keep up.

I've spoken in previous blog posts about the tools we commonly use to deliver care in modern healthcare. So as I've been thinking about how to streamline organizational efficiency in healthcare, one of the major challenges most hospitals face is : How do we manage all of this information?

Some people will immediately look to IT for solutions, since we think of information as living inside a computer, but IT can only build a system as organized as you ask them to build. The problem is : If you had chaos before, making things electronic will only perpetutate the confusion.

(I've spoken to plenty of healthcare informatics types who complain about not being able to navigate their web sites, shared electronic folders that never get updated, and not having "intuitive" organization of their information.)

I find the comment, "We don't have intuitive organization of our information" particularly interesting. Everyone seems to have a different idea of what is intuitive.

All of this speaks to the need for standardization in healthcare, and education to support those standards. (Nobody teaches this stuff in medical school, nursing school, or pharmacy school.)

So I hope I've attracted your attention with the title of this blog. My proposal : We develop a standard "document tree" that can be used to organize virtually all of your hospital's information. (Except emails, of course, which generally are private and not shared.)

The Healthcare Informational Tree

So I thought about all of the common tools we use in healthcare (the CMIO's Checklist and the Informatics Toolbelt), and sorted them first by function and then by division (Clinical versus Administrative) - And this is what I got as a final list :

  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 clinical scenario
  9. Clinical Protocols - Tools to standardize and automate a clinical process
  10. Clinical Pathways - Tools to standardize care for a diagnosis throughout a hospitalization
  11. Education Modules - Tools to help educate patients/staff
  12. Templates - Tools to help make a document
  13. Wikis - Tools to organize information / links for a department
  14. Committee Charters - Tools to assign committee duties and responsibilities
  15. Committee Minutes - Tools to record committee activities
  16. Glossary of Terms - Tool used to learn definitions for common organizational terms

I believe that by using the above directory/tree hierarchy, you could arrange your tools on your intranet in a way that you can essentially find any document in your hospital in five clicks - Each link, from this main page, then divides up into clinical and administrative divisions, e.g. :

  • Clinical Templates = e.g. Admission H&P template, Procedure Note template, Transfer Summary template, etc.
  • Administrative Templates = e.g. Policy and Procedure template, employee evaluation template, etc. 


  • Clinical Documentation = e.g. Admission H&P, Procedure Note, Transfer Summary, Vitals Flowsheet
  • Administrative Documentation = e.g. Employee Evaluation Form, Room Change Form, Maintenance Request Form


  • Clinical Policies = e.g. Pharmacy Policies, Infection Control Policies, Nursing Care Policies, etc.
  • Administrative Policies = e.g. Human Resources Policies, Safety Policies, etc.

The interesting thing about making such a tree is it shows you, pretty quickly, how much work you are actually doing in your hospital, how much it actually takes to run a hospital, and why you need people to worry about all of these tools.

It also can help you find your work products much quicker, and it interfaces nicely with the tools that you need to make a change in the clinical setting.

Adopting such a tree is not a small project, but it sure can tidy up your intranet homepage. It also helps reinforce informatics education by making almost everyone in your organization review the basic tools you use, and what they do, every time they look for something. By having centralized publishing, this also helps keep your intranet a "high-value" site that people will use to find things.

As someone who wants to see American healthcare be the best that it can be, I think it's an admirable goal. Those of us working to organize Health2.0 should be keeping this tree in mind as we develop our healthcare informatics policies.

Remember, my advice is free, and you get what you pay for. Your mileage may vary. :)

Would love to hear comments about potential additions/changes you would make to the tree at your organization! :)

Saturday, December 4, 2010

What is Medicine Reconciliation, anyway?

So recently I've been hearing and reading a lot about medicine reconciliation.

Medicine reconciliation is the safety practice that, it seems, The Joint Commission has recently announced they will set new expectations for.

A friend of mine, who went to an IHI conference last year, told me that on a wall full of posters of "problem subjects", the "Med Reconciliation poster" seemed to have the most hospitals reporting challenges.

So what is this Med Reconciliation thing, anyway?
  • Is it a mythical creature that people see, but nobody ever really gets a picture of?
  • Is it something that inspires poets and artists, because it's so intangible?
  • Is it something that we can even achieve?
Most practicing physicians learned in medical school that it's "good practice to rip up and re-write all the orders when a patient comes out of the OR". Most practicing physicians are also used to documenting the patient's home medication list in an admission H&P. The interesting thing : These are both different facets of the same med reconciliation picture.

So then, I think one of the biggest challenges in implementing "Med Reconciliation" is that it's so hard to nail down. What is it, exactly? Who does it? And how? 

So I thought I'd share some answers.


 First, the premise is simple : It's all about safety.

Med reconciliation is built on the basic premise that a physician and a patient work best together, when they're with eachother. For the purposes of this discussion, I've lovingly decided to call the "place where they work with eachother" the "Patient Care Cubicle" (instead of the industry term, "Level of Care" which is a little confusing.).

The process is then pretty simple. To perform med reconciliation, a physician needs two separate documents :
  1. The 'home medication list', to know what the patient is 'usually on'.
  2. The 'active medication list', to know what the patient is 'currently on' while sitting in this "patient care cubicle".

And the steps for doing med reconciliation? A doctor should basically follow these four steps :
  1. Look at the Patient
  2. Look at the HomeMedList
  3. Look at the CurrentMedList
  4. Make a new CurrentMedList!

This allows a physician can make the decision : What meds does the patient need to be on right now.

So remember, the recipe for med reconciliation needs these four ingredients :

   MED RECONCILIATION = [ Patient ] + [ Physician ] + [ HomeMedList ] + [ CurrentMedList ]

(While they are connected, remember - Med reconciliation is NOT the process of collecting the home med list - But you will need to collect the home med list before a doc can do med reconciliation.)

So... when does a physician actually do these four steps of "med reconciliation"? Optimally, it happens at two times :
  1. When the patient appears in your cubicle (in hospital terms this is known as a "change in level of care")
  2. When the patient has had some significant event (like delivering a baby, a code blue, a surgery, etc.)

So far, so good. Now comes the implementation challenges.


The first thing you might do to map out the implementation of med reconciliation, is to make a general map of all of the "patient care cubicles" your patient might pass through, when he/she goes through your hospital. Typically, this map will start with the outpatient cubicle, and end with the outpatient cubicle. (On discharge, then, you need to do med reconciliation one last time to define the "new home med list", aka the "discharge medication list").

So if each "cubicle" has the patient and a physician :
  1. The physician covering the "outpatient cubicle" is the primary care physician.
  2. The physicians covering the other cubicles are the ones you assign.
And so if you need two lists - The home med list, and the current med list - To perform med reconciliation, you can see by the above slide that the first challenge will be getting the home med list available in your ED.

This brings us to some challenges with med reconciliation...


The first challenge is just getting the home med list in your ED. How long does it take to actually assemble the list of home medications? (Remember : THIS IS NOT MED RECONCILIATION YET - Collecting this list is probably the thing most commonly confused with the term "med reconciliation".)

I did an informal study of this, while working clinically last year, and found that my median time for most adult medical inpatients was about 20 minutes. About 2/3 of my population was less than this, but about 1/3 of my patients were more than this, and there were some significant outliers - some patients took up to 45 minutes or more. (While slightly tongue-in-cheek, I called the standard I used the "mother standard", figuring I would work to achieve the same accuracy I would expect for my own mother.)

The reason it can take some time to assemble is this : There are up to seven data sources a person can use to assemble the home medication list. They include :

  1. The patient - Who usually knows their home med list... but not always.
  2. The family - Who is often helpful at establishing an accurate med list, but not always
  3. The PCP - Who is usually accurate, as long as the office is open and they know what the specialist might be prescribing, so...
  4. The specialist - Who sometimes needs to be contacted for clarification about new specialty medications
  5. The outpatient pharmacist - Can be helpful to get a broad view, assuming the pharmacy is open and the patient doesn't use a mail-order pharmacy
  6. The previous chart - Can also be helpful, assuming the last visit wasn't too long ago
  7. The "insurance-based electronic prescription database", available at some hospitals - Which also still sometimes takes time to sort through, and you have to make certain assumptions...
So if the first step is to assemble this list in the ED, then the first challenge is to figure out who will assemble this list, and how?

Curiously, if you examine med reconciliation needs in the ED department, it usually falls along these steps :
  1. Triage desk Officer : Generally drug classes are most important, not actual drug names. (E.g. a triage officer may consider bringing someone in if they are on blood thinners, or antibiotics.)
  2. ED physicians : Generally drug names are most important, sometimes doses. Most ED visits are short, so there has not traditionally been much focus on doing med reconciliation in the ED. Of course, if we expect ED physicians to perform med reconciliation, they will need more information. (Some patients do miss medication doses while waiting for care in the ED.)
  3. Inpatient Physicians : Here is where the drug, dose, route, frequency, indication, and last dose are most important, because the patient staying in-house will need to continue the right medications at the right times.
Because of these varying needs, at these different levels, it's sometimes hard to figure out who's responsible for how much of the puzzle.

The second challenge, assuming you can get the home med list assembled in the ED, is figuring out : Which physicians will be responsible for actually doing med reconciliation in each cubicle?

While it's tempting to answer :
  1. ED - Would be performed by ED physicians, 24/7
  2. Floor - Would be performed by hospitalist physicians, 24/7
  3. ICU - Would be performed by intensive care physicians, 24/7
  4. Etc...
...the PreOP setting/OR/PACU usually presents some unique challenges (challenge #3)

The challenge for many ORs/PACUs is this : Operating room schedules are tight. Hospitals count on maximum efficiency in an operating room. Even small delays can be magnified into cancelled procedures if everything doesn't run like clockwork. Also : Surgeons and anesthesiologists spend a good part of their day in procedures that simply can't be interrupted. Briefly pulling a hospitalist out of a family meeting to "do med reconciliation" will have a very different cost than briefly pulling a surgeon / anesthesiologist out of a surgery.

To accommodate with these demands, many anesthesiologists focus mainly on anesthesia meds, and many surgeons write post-operative orders in the PACU. If the patient goes up to the floor, after the PACU, then the nurses depend on the post-op orders written by the surgeons in the PACU. Unless you create a cubicle where the PACU has the same level of care as the floor, you might have to do med reconciliation again after the patient reaches the floor.

Figuring out this workflow can be very challenging. It's why my friend, going to the IHI conference last year, saw Med Reconciliation as one of the 'top challenges' hospitals face.

The fourth, and final challenge, is deciding on the "triggers" you will use for med reconciliation. As described above, there are typically two things that should trigger a physician to actually perform med reconciliation :
  1. Patient arrives in your patient care cubicle (aka "Change in level of care") - This is usually pretty easy to enforce electronically.
  2. Patient has a significant change in status (e.g. delivery, surgery, code blue) - This can only be enforced by a policy/clinical practice.

So you will need to decide on these two triggers, knowing that
  1. For your EMR to trigger med reconciliation electronically, you will need to organize your levels of care and their relationship to your patient locations.
  2. For your staff to trigger med reconciliation during a significant patient event, you will need good policy design and education.


Fear not, my reader! This may seem daunting, but the problem can be solved! Many hospitals have started down this pathway already, and many more will continue as The Joint Commission and other regulatory bodies reinforce med reconciliation practices.

To help you, I've offered the following recommendations and steps you can take to advance the discussion in your own hospital.

  1. Define who is responsible for collecting the home med list in the ED
  2. Define what home medication information they will collect, and how? (It's challenging to figure out how many of the seven potential data sources to use, but until our whole country is wired together electronically, your organization will need to decide this.)
  3. Define where this home med list will be kept, once assembled, so that every doctor in the "chain of cubicles" will be able to access it and use it to perform and document "med reconciliation".
  4. Define your "patient care cubicles", where your EMR can help trigger the med reconciliation process.
  5. Define your policy that will help educate physicians about clinical scenarios in which you expect med reconciliation to be performed (e.g. delivery, code blue, surgery, etc.)
  6. Define which physician's will be responsible for the med reconciliation process in each cubicle, 24/7.
Regarding the unique challenges that most Operating Rooms/PACUs present, this is a very common challenge, but I'll present the following possible scenarios I came up with :
  1. Your hospital might consider asking the surgeons to perform med reconciliation after the patient arrives back up on the floor. (This may cost your hospital in OR time/efficiency.)
  2. Your hospital might consider transferring all post-op patients to your hospitalist group, to allow the hospitalists to perform med reconciliation on the floor. (This may cost your hospital by needing more hospitalists to care for these patients.)
  3. Your hospital might consider hiring a Physician's Assistant (PA) or Nurse Practitioner (NP) to assist the surgeons with the med reconciliation process. (This may also cost money, but I believe in most settings this would be more affordable than option #1 or  #2 above.)
Enjoy - I hope this discussion has been helpful. A good sample policy to support med reconciliation is available here from the University of Wisconsin Hospital and Clinics.  Again, I'm eager for any feedback folks have. Feel free to leave your own stories about tackling med reconciliation! :)

Sunday, November 21, 2010

Converting paper order sets to electronic

If you're reading this, I hope you're the person in your institution trying to "convert the paper order sets to electronic ones".

Don't worry - you're perfectly normal. The job is usually a lot harder than it looks. And no, you're not the only one who hears, "Why can't you just take the paper order sets and put them on the screen?"

(Most people think it's simple, until they actually start to dissect the order sets.)

First, let's start with some of the challenges of paper order sets :
  1. Paper order sets generally keep multiplying - Let's say you decide to fix the paper order sets, and so you need to take the old versions "off the shelves". Beware - People tend to make copies of paper order sets. So the old ones can turn up weeks and months later.
  2. Paper order sets are often engineered differently - In the electronic (CPOE) world, orders are very concrete. You may have specific safety features put into your electronic PCA (Patient-Controlled Anesthesia) order. How will you put those safety features into your paper order set? You may also have hidden "protocols" in your paper order sets. What will you do with those protocol (conditional) orders? 
  3. Paper order sets are sometimes ignored, after a hospital "goes electronic" - If you ignore your paper order sets, what will your hospital use during electronic downtimes? Can you afford not to have paper backup order sets, if your OR/ED are busy?
Believe it or not, how you address these paper-order-set problems will be vitally important in your long-term electronic success. Ignore the paper order sets, and you will miss an opportunity to really set up a robust electronic platform.

Let's look at each of these issues in a little more detail :

1. The "Multiplying paper order sets" -
This is a phenomenon many organizations struggle with. The solution : Centralize all of your order sets on one common electronic web site, and publish them as non-editable .PDF files. Create a clinical policy where "If it's not on this site, it's not an acceptable order set".  It will take you a while to get the site together, and organize all of your paper order sets there, but in the end, you will have a way of controlling the paper order sets in use. 

2. The "Engineering differences" between paper and electronic order sets
Some organizations, on going electronic, focus on developing electronic order sets, while the paper order sets continue to be produced in the way they "always have been built". If you have two separate processes (an electronic and a paper process), the problem is that you will start to have significant engineering differences between the two. 
If you have different paper and electronic order sets, you will then encounter :
  • Paper order sets that don't meet the engineering standards needed for order entry in your EMR, so they will be very hard to "send-to-pharmacy-so-someone-else-can-do-the-order-entry"...
  • Paper order sets that don't match the electronic order sets
  • Two cultures : Docs who use electronic order sets, and docs who use paper order sets. (If your organization does a "flip-the-switch" approach to EMR/CPOE, then this won't apply to you. If you do a "gradual conversion", then this will apply to you.)
The way you fix this, of course, is to develop simultaneous paper and electronic order sets. Set up your informatics platform, update your policy on order set development (to include paper and electronic order sets), and ask your informaticists to develop the paper and electronic order sets simultaneously. Have them tested by the same people, and approved by the same committee. This will ensure that they match, and even if you are a "100% CPOE" organization, you will still appreciate having matching paper order sets during electronic downtimes.
Remember, the solution isn't to make electronic orders that mirror your bad paper processes. Make good, solid, and safe electronic orders, and then use those in your updated paper order sets.
A final tip : Embedded "protocol" (conditional) orders generally need to get pulled out of the paper order sets, before you can "make them electronic" - and you will need to decide what to do with those : A. publish them as new protocols, or B. throw them out. This will take work and can be politically challenging. 

3. The "Ignored Paper Order Sets"
Some organizations, on going electronic, ignore the paper order sets, thinking, "We don't need them anymore, right?". My advice : Don't ignore them. Not only will you need to figure out what your pharmacy will do if they end up getting faxed paper orders, but you will still need them for computer downtimes.

If all of this sounds complicated, and it sounds like a lot of work, you're right - It is. This is why order sets are the political and organizational challenge that they are. A good informaticist can help sort out the issues and put a plan and process into place for your organization, where it doesn't have to be too painful. Unfortunately, because healthcare doesn't have standards in clinical processes, every organization handles this conversion differently, and as a result, order sets are notoriously hard to standardize. (Think of them as a "custom-fitted suit".)

One last tip : Beware the "quick fix" - There are consultants who will "easily and quickly convert your paper order sets to electronic ones". The way they usually do this is by taking the paper orders, no matter how they are engineered, and simply build new electronic orders that match them. In the short term, this may appear to work, but in the long term, it may leave the nurses with orders which are unclear (and may create extra pages to doctors to clarify), since some paper orders are not as well-defined as their electronic counterparts. You may also miss out on the opportunity to streamline your clinical processes, and miss out on the time and cost savings that an EMR can really bring. My recommendation : Build the new paper order sets to match the engineering standards of your electronic order sets - Not the other way around. 

As always, my advice with order sets : There are no quick fixes. Hire a good informaticist to help you with this. :)

Hey, by the way, I'm open for questions - If anyone has any EMR conversion or informatics questions that you'd like to chat about, feel free to leave a comment here or email me. I'll try to devote my next posts to reader questions! So send me stories, questions, or whatever else you'd like to discuss in upcoming posts - I look forward to hearing from folks! :)

Saturday, November 6, 2010

What's in the Informatics Toolbelt?

QUESTION : Dirk... How do I make change in a clinical setting?

A lot of modern healthcare asks for standardization. Common questions I get asked are focused on change and standardization, such as:
  1. "How can we make sure the doctors use the order sets?"
  2. "How can we make sure the doctors document ______ properly?"
  3. "How can we make sure the doctors enter orders for ventilator changes?"
  4. "How can we make sure the nurses document the vitals properly?"
  5. "How can we make sure the pharmacists document the medication substitutions properly?"
The first tool most people reach for, to standardize care, is the order set. As a result, order sets are notoriously political. In the paper world, they generated enough debate, but in the electronic world, it often gets worse, as the political power shifts from a physician-centered process to a more organization-wide process.

Question : Huh? Dirk? Electronic order sets have a different political structure than paper order sets?

The short answer is yes. Why?

In a paper order set, most hospitals let doctors type their commonly-used orders on a piece of paper, put little check boxes next to each order, and a committee reviewed them - if the group of orders looked safe and met the right formatting requirements, and didn't have any unapproved abbreviations, the order set was generally approved, and the doctors could use them. End of discussion, for the most part, until the order set had to be updated. The doctors wrote what they wanted, and the organization approved them as long as there wasn't any major safety or organizational problem.

In an electronic order set, every electronic order (in the order set) has to be built by a programmer. So quite often, those programmers design the orders with extensive safety in mind. To figure out how to make them safer and more effective, the programmers ask the entire team (not just the doctor) for advice on how the order should be built. So programmers may ask the pharmacists, "How can we make this order safer?". They may ask the respiratory therapists, "What should this order look like?". They might ask the nurses, "What should the doctors really be asking for in this order?". They might ask the dietitians, "What should a diet order look like?". They might even add evidence-based links to the orders, on the order sets, to help guide the physicians about when best to use which orders.

As a result of these discussions with all of these different parts of the hospital, it's not uncommon for the programmers to design the electronic orders to look and behave differently than the paper orders did.

For example, a common safety tool used by programmers, after these discussions, is to build mandatory fields into the orders, that the doctors have to complete for the order to be accepted. As a result, the doctors are suddenly forced to think differently about these electronic orders, than they used to think about the paper orders.

I know it's still still sort of complicated, but a good example of this phenomenon is the diet order.
  1. In the paper world, most paper order sets simply refer to an order, "REGULAR DIET".
  2. In the electronic world, however, after discussion with speech therapists and dietitians, many electronic diet orders are built with mandatory fields for texture and liquid modification, so a doctor HAS to think about texture and liquid modification just to be able to enter a diet order. As a result, many electronic diet orders, on an electronic order set, will refer to the diet order, "REGULAR DIET, NO TEXTURE MODIFICATION, NO LIQUID MODIFICATION".
So doctors moving from the paper world to the electronic world will generally sense this loss of control - Suddenly, dietitians and pharmacists and radiologists can have enormous impact on the way they order something. In the paper world, doctors could simply write whatever they felt was best.

As a natural result of this political shift, electronic order sets often generate even more political discussion and debate than the paper order sets did. And this is another reason you may want to hire a CMIO, to help guide your doctors past the political debates and focus on good patient care.

Question : Aha. Interesting... Never thought about that. So what about this "Informatics Toolbelt" you mentioned?

The reason I bring up the "Informatics toolbelt" is because, as a hospital tries to standardize care by crafting workflows, everyone seems to reflexively reach for one tool : The order sets. By fixing the order sets, we can standardize care, right?

While order sets are certainly a good tool to help standardize care, they are not the only tool. Just to remind you that there are other tools, I present the following list of tools which I think sit in the Informatics Toolbelt : (Remember, most of these tools can be published either on paper or electronically...)
  1. An order - A medicolegal instruction to provide a defined portion of patient care, via a defined route, at a defined rate, for a defined period of time. (Remember, in the paper world, you didn't have to "build" orders - In the electronic world, you have to "build" them, so you can actually engineer them to your advantage - The source of much political debate.)
  2. An order set - A grouping of orders, to help standardize and expedite the ordering process for a common clinical scenario. Physicians generally start, modify, and stop the orders on an order set.
  3. A protocol - A document that allows a nurse or pharmacist to start, modify, or stop orders based on a well-defined clinical condition.
  4. A guideline - (aka care plan, etc.) A document that educates care team members about desired outcomes and processes, but generally carry less medicolegal weight than a protocol or policy, more negotiable, so they are engineered differently.
  5. A policy (clinical or administrative) - A defined organizational goal or rule. 
  6. A procedure - The steps requires to achieve a goal (or policy).
  7. Documentation - (aka a forms, a flowsheet, etc.) - A permanent recording of patient status, activities, responses, and outcomes in time, authenticated by the signature of a licensed medical professional.
  8. A patient education module - A document with media (written, video, or other) that explains a defined set of educational objectives to patients.
  9. A staff education module - A document with material (written, video, or other) that explains a defined set of educational objectives to staff members.
  10. A committee charter - By creating a charter, you can create a committee that helps standardize your care and monitor your processes
  11. Committee minutes - By creating minutes, you can show effective supervision and committee activity to meet the organization's goals.
  12. A staff meeting - Can be helpful for education and organizational purposes.
  13. Email, paper mail - Can also be helpful for educational purposes.
There are probably other tools to put into the Informatics Toolbelt, but these are the most common ones. And a good informaticist can help you figure out the right mix of tools to craft the workflows you want to create to improve safety and standardize care.

(Using these tools to craft a workflow, in the electronic world, is an art known as electronic decision support. This is why a clinical informaticist is a key role in managing your clinical processes in the electronic world.)

Hope this helped remind you that order sets are a good tool to help craft a workflow and standardize care, but not the only tool. If you forget about the other tools, you may be missing out on other opportunities. A good clinical informaticist will help you figure out which tools to use for which scenarios. :)

Friday, November 5, 2010

A Few Words About Education in Healthcare and Life

So I recently got a very nice email from a person at a healthcare informatics consulting company, asking me to participate in a webinar on healthcare informatics. Two pieces of the email that really made me smile :
"Your blog was sent to me by a colleague who found it extremely educational on the topic of medical informatics. I quickly agreed; you discuss what can be very complicated systems and the politics of implementing an EMR in terms a layperson such as myself can easily understand. It has become a great resource for our staff as we continue to learn and grow within the HIT community."
"We were very impressed by the information in your blogs along with your conversational style..."
So I'm thrilled that someone picked up on what I try to do - Educate in a painless, simple way that people actually enjoy. A great example of this style can be found in the NPR Radio Show This American Life, where every week Ira Glass and various other writers/readers tell stories that are actually very educational. On This American Life, they have recently tackled subjects as complicated as the economic meltdown, credit default swaps, and other hairy political, legal, and financial issues, all told through stories that people share about their lives.

A great example of painless education told through story is their show about the financial meltdown, called The Giant Pool of Money. This is a true educational masterpiece. Every sentence in the show show lures you in, grabs you, and explains world banking and finance in a way that is totally tangible and palpable by the masses. You leave the piece feeling full of amazement at what you just learned.

This is the style of education I try to emulate in healthcare informatics. There are a lot of discussions in healthcare that are full of drama and intrigue, worthy of a Shakespearean drama. I try to convey it that way. :) (Although admittedly, I don't have as much time, creativity, or talent to emulate the TAL writers.) :)

Anyway, this gets me to my subject of education in healthcare, and in life.

Education is not something that has to be painful. It just has to require work. The first step is approaching a subject with :

  1. An open mind
  2. Eagerness to learn
  3. The humility to admit you might not understand something
If you can achieve that, then you will be a great student and will learn a great deal, in school and in life. As social human beings, I think it's our nature to be BOTH a teacher and a student, as long as we live, and we have that responsibility to play both roles to keep our society intact.

I think part of the educational problem is that people don't appreciate how much work it takes to make education painless. Good teachers are worth their weight in gold and platinum. We also think of education as ending after high school, or after college. Yes, we pay attention to higher education too, but there are many, many ways we educate eachother, as humans :

  1. We go to grade school, high school, and college
  2. We talk to our friends and neighbors
  3. We watch eachother and watch our children play on a playground
  4. We tell stories at family reunions
  5. We ask questions (to learn and to teach!)
  6. We scribble ideas on cocktail napkins
  7. We create and watch movies and videos
  8. We write and read books and web pages
  9. We write and listen to songs.
  10. We write laws and policies.
Although the law, and most discussion centers around #1 as an educational medium, there are many other ways to achieve an educational goal.

One of my favorite stories I collected during medical school was when my parasitology professor, Dr. Calum Macpherson, told us about his time spent fighting parasitic diseases in Africa. In one story, he described a particular disease, echinococcus, which was causing disabling and life threatening liver and abdominal cysts in animals and people in a particular region.

The challenge to him and his team, he reported, was preventing the behavior where people would feed pieces of these large, salty, abdominal cysts from dead animals to the dogs in the neighborhood. (Gruesome, perhaps, but when you have dead animals, and hungry dogs, it only makes sense.) This behavior, unfortunately, perpetuates the life cycle for the parasite, and the disease continues to spread.

So how to prevent the behavior of feeding these cysts to neighborhood dogs? One way: To educate the village. So they developed a creative solution. Working with local people, they created a children's song that could be performed and sung at a playground, during playtime. They made the song catchy enough that kids liked to sing it.

Apparently, many years later he went back, and still found the kids on the playground singing the song they wrote about "not feeding cysts to dogs".

A creative approach, and effective. Perhaps the first example of a viral idea.

In conclusion : Don't let education intimidate you. It takes work, but it doesn't have to be painful. :)

Monday, October 25, 2010

Why not let docs have their own order sets?

Last week, I was asked a question I'd been asked many times before, by someone who was helping another hospital set up their EMR :

"Why shouldn't we let our docs make their own order sets?"

The reason I was asked this is because many EMR packages have this feature, where docs can make their own order sets for their own convenience. 

  1. Every doc struggles with efficiency, and making your own order sets certainly is tempting. Why not make order sets that accomplish exactly what you want? After all, if I'm a practicing physician, and I know what orders I 'always put in' in certain scenarios, why shouldn't I be able to make my own order sets?
  2. We could save so much committee time if the docs could just make their own order sets!
  3. If the docs could make their own order sets, they would probably feel "more comfortable" with order sets and CPOE, in general - Wouldn't this help us with our EMR implementation? Wouldn't we get a higher CPOE rate faster?
  4. It would save the time and labor of converting their old paper order sets - (Which, as I've discussed in past postings, are often loaded with embedded protocols which are expensive and time-consuming to engineer out!) - Just let the doctors make their own order sets!
  5. If docs could make their own order sets, then they probably wouldn't blame some poor informaticist for making a bad order set for them.
  1. If every doc can make their own order sets, you have no centralized mechanism for clinical decision support. For example, if your pharmacy previously paid a lot for omeprazole, and it suddenly gets a good deal on pantoprazole, you will probably want all of your doctors to take advantage of the cost savings by steering them towards pantoprazole (when backed by good evidence) - If they all have their own order sets, you won't be able to help guide physician behavior and take advantage of this cost savings. 
  2. If every doc can make their own order sets, you also have no centralized mechanism for standardizing care. E.g. an appendectomy could get very different care, depending on which physician was using which appendectomy order set. (Most hospital administrators are trying to standardize care to improve quality and reduce costs.)
  3. Order sets need to be maintained regularly, to be kept safe, evidence-based, and efficient. If every doc can make their own order sets, you may quickly end up with many, many different order sets which can be a challenge to maintain, from a technical standpoint. What are you going to do when new guidelines suggest you should be using different drugs to treat pneumonia? How will you find which order sets you need to update? Do you have the resources to keep ALL of your order sets updated? 
  4. If every doc can make their own order sets, you will miss out on the opportunity to teach your physicians what informatics is, and how they can improve their own care through evidence-based practice and standardization of processes.
I will admit, as a practicing physician, myself, there are times where I wish I could just make my own order sets. But I will also admit that being challenged on my own order sets is a great learning experience, and ultimately, sharing the discussion with my colleagues, and reviewing the literature is the best learning experience of them all. 

(Apparently I'm not the only one who frowns on personal order sets - A final web page, worth reading even though the author is unclear and this looks more like a comment than a legitimate argument : 

Ultimately, every hospital will need to make this decision for themselves, but remember, as I said - With order sets, there are no free lunches. The rule still applies. :)

Friday, October 1, 2010

Top things to do with your new CMIO

Dear CMIO-owner,

Congratulations on your new CMIO! With a few simple care instructions, your CMIO will serve you well and last a long time.

Here are some of the things you can do with your new CMIO :

1. Ask him/her to help design and develop an informatics platform for your healthcare organization.
2. Ask him/her for advice on how to budget for your next clinical IT project.
3. Instruct him/her to do clinical workflow analysis before you implement your next EMR rule.
4. Ask him/her for expert advice on clinical decision support - What it is, and why it could help your hospital.
5. Ask him/her to help fix and update your order set process to include evidence-based order sets.
6. Ask him/her to help dissect and improve your paper order sets.
7. Ask him/her to help design training curriculum for your physicians, and develop a training plan.
8. Ask him/her about "EMR Governance" and why people seem to write so much about it.
9. Instruct him/her to attend your Medical Executive Committee meetings and give expert input about clinical workflow issues.
10. Ask him/her to develop ARRA/HITECH educational summaries for your senior leadership.
11. Ask him/her to develop EMR implementation strategy.
12. Ask him/her for policy help in developing policies needed to support your EMR.
13. Ask him/her "What is informatics?" and "Do we need it?" and "Is this something other people should know about?"
14. Ask him/her to help develop physician buy-in for CPOE, Order Reconciliation, and other enterprise-wide EMR projects.
15. Ask him/her to build approval policies for your clinical tools.
16. Ask him/her to manage software upgrade projects.
17. Ask him/her to design informatics education materials for your department directors.
18. Ask him/her to network with other CMIOs to look for workflow solutions that meet the tough compliance questions.
19. Ask him/her to develop datamining solutions, so you can get quality data OUT of your EMR.
20. Ask him/her to work with your Chief Medical Officer (CMO), Chief Nursing Officer (CNO), and other leaders to fully implement your EMR and the order sets, protocols, and policies needed to support it.

We recommend keeping your CMIO out of direct sunlight, make sure he/she has a warm place to sleep, and most of all, never feed him/her after midnight.


The Manufacturer

Wednesday, September 8, 2010

Hollywood and CPOE : Why you don't want to take the humans out of the silos

As a CMIO doing front-line informatics, I sometimes get asked, "Can't we make the computer automatically delete that order?"

This is a hard question to answer. The short answer is always "Well, yes....", but the longer answer is usually, "...but you probably don't want to do that."

The explanation why "you probably don't want to do that" takes some time, but interestingly, Hollywood can sometimes provide some good teaching examples. (Even if they are fictional, they are still useful to demonstrate the real answer.)

One of the most influential movies for me, growing up in the early 80s, was the movie Wargames, directed by John Badham and starring Matthew Broderick and Ally Sheedy. Interestingly, it provides some useful teaching examples for healthcare informatics. Allow me to demonstrate :

Pay close attention to this opening clip which parallels what nurses experience every day. Two men, in a nuclear missile silo, show up for work and get an electronic order to launch a missile. The codes authenticate, they have clear procedures and protocols to follow. And yet, before launching missiles that could kill millions of people, one of the men smartly asks the question, "Does this seem right?".

(Note, because he doesn't trust the electronic order he's received, he smartly picks up the phone and tries to get a human being to clarify for him - AKA he tries to page the doctor to make sure the order is real.)

I think most nurses watching this clip can relate to these two men.

I suppose some of it is human nature, to trust a human being more than a machine. We are tribal, and so it seems intuitive to want to speak to a human being, before carrying out an order received from a machine. A written order, despite all of its flaws, carries a certain amount of intuitive trust - The physician's pen hit the paper, the ink is dried in place, this is the handwriting of the doctor I usually work with - It provides much more confidence for a nurse.

An electronic order does not deliver the same trust. We worry that the machine may have interpreted the instruction wrong. Or perhaps the programmer didn't think of this particular scenario. We're trained from childhood on how to figure out machines that don't work. We know they sometimes make mistakes.

So getting back to the question about "automatically canceling orders", and "why you probably don't want to do that".

After this opening scene of the movie, the very next scene shows technicians ripping the chairs out of the missile silo, while a team of strategists deep inside the NORAD missile command say, "We had to take the men out because we learned we couldn't trust them to push the button... So now we've wired the WOPR computer directly to the button."

This then sets up the plot for the rest of the movie - The WOPR computer is wired directly to the button, and when David Lightman (Matthew Broderick's character) hacks into the WOPR to make it malfunction, they are stuck - There is no human being between the computer and the missile launch.

What does this teach us about the importance of human beings carrying out your order protocols, rather than the computer "just doing it automatically?"

Because computers are unforgiving. If you ask them to do something, they will do it. 100% of the time. No questions asked.

The problem with a computer discontinuing an order, then, is this : What happens if you ever have a patient, who for some bizarre and unplanned reason, shouldn't have the order automatically discontinued? What if this one patient, in a million, actually needs the order to continue longer?

1. If you have a computer automatically discontinue the order - That one patient will suffer the problems of being "the one-in-a-million" exception.
2. If you have a nurse following a protocol to discontinue the order - Then you actually have a chance that the nurse will ignore the protocol, knowing "it's the right thing to do". (Yes, good nurses know when to ignore orders and protocols if they could harm the patient.)

What does this clip help demonstrate?
1. Electronic Order Entry comes with an inherent fear, and rightfully so - This is why nurses page us to clarify orders, and when they do, we as doctors should be glad nurses are asking questions - I never want a nurse who is an automaton.
2. For patient safety and good care, communication between nurses and physicians should be ample, easy, and painless. Nurses should never feel forced to press a button without understanding the impact and reasons why they are being asked to do it. If the situation doesn't make sense to them - You want them to call!
3. Nurses are the last safety gap before the delivery of care / button gets pressed. (See the men in the movie clip above!) We should respect their professional judgement - It's there for very good reasons.
4. You generally don't want to take the nurses out of the silos. Imagine the risks of EMR software actually delivering the medications! :)
5. For safety reasons... you generally don't want the computer to automatically cancel the order. Why?
    a. Because a computer canceling it 100% of the time may not be safe for 100% of the patients.
    b. Because you can never create a protocol that is 100% safe for 100% of patients.
    c. Because for safety, in that unplanned circumstance - you want a nurse to know when to say "no".

Who works in Health Informatics?

So I have had a number of people recently talk to me about health informatics jobs. Being a physician, they are mostly physicians looking for informatics jobs.

The interesting thing is, I get the sense the healthcare industry NEEDS informatics, but isn't really ready for it. The CMIO position, despite being almost 20 years old, is still too new to most healthcare administrators, and from what I see and hear, many hospitals don't really know what to do with one. The job functions, from hospital to hospital, vary so widely.

And then there is the question about exact titles - what's the difference between a "CMIO", a "CNIO", a "Physician or Nurse [Embedded] Informaticist", a "Physician Champion", and a "Superuser"?

I will attempt to wax philosophic here, just in the name of starting the discussion on formal titles and formal job descriptions - which the healthcare industry needs badly, if it wants to take advantage of informatics help. Perhaps eventually this will turn into the holy grail of formalization - An actual Wikipedia page. :)

1. The CMIO (Chief Medical Informatics Officer) - Yes, you do informatics, so you have to believe in political neutrality. Yes, you try to guide the rest of the hospital about informatics issues.  You talk about EMR strategy, you help discuss budgeting issues for a solid informatics platform, you stress the importance of proper training. You monitor and guide the politics of CPOE and EMR in the Medical Executive Committee. You worry about administrative, physician, and nurse buy-in. You may do some training, but mostly you guide the education process. You may do some data mining and quality work. You get involved in project management, and help develop physician and nurse informaticists to work with you. This position is heavily involved in policy, however, and you should prepare to analyze and write a great deal of clinical policies. Lots of regulatory work too. In a smaller hospital, your salary line will probably come from a clinical line, and you will still work clinically. In a larger multi-system hospital, your salary line may come from an IT line, or other administrative line, and you probably won't be working clinically anymore.

2. The CNIO (Chief Nursing Informatics Officer) - The nursing equivalent of the CMIO. Yes, there is a big need for this role. The CNIO worries about administrative and nursing buy-in, and continues to work clinically.

3. The Physician or Nurse Informaticist (aka Embedded Informaticist or my affectionate term, Clinical Jedi Informaticist) - Think a mini-CMIO, but in an individual department. A physician informaticist (or nursing informaticist) is a slightly broader term, and could be an outside consultant called in to help the informatics development of a department in your hospital. The much cooler (and reliable and useful position) is the Embedded Informaticist, the doctor/nurse in a clinical tribe whose paid responsibility it is to develop the informatics platform for their clinical tribe. If the CMIO still works 25% clinically, the embedded informaticist works 75% clinically (and 25% informatics). In an ideal world, the hospital CMIO gets to work with an embedded informaticist in each clinical tribe, to coordinate the workflows between different departments. The embedded (physician or nurse) informaticist then analyzes their own tribe's workflows, maps them, redesigns them, and sees the changes through committees, policy work, and brings them to the Clinical IT staff to make it happen. Since they are embedded, they can also easily train and support the new workflows in their tribe. And because they are embedded, buy-in is never a challenge. The EMR works better, the docs and nurses feel more loved. This is an extremely effective model, by my experience. (If it's supported by administration.) This, I think, is the position that is going to explode in demand in the next year or two. Look out for it. The AMIA 10x10 class will train most of these embedded informaticists. 

4. The Physician Champion - This is a physician who is asked, or paid, to rouse the troops. Your main mission is to be a cheerleader. You encourage the docs around you, and you may get involved in training directly. Exposure to policy and strategy discussions will probably be minimal. You probably won't have the pay or time budget to do much data mining, and you won't be managing other informaticists. Your ability to motivate is much more important than knowing every detail of every workflow. For reasons I don't understand, nursing usually doesn't need a champion, but this may change.

5. The Superuser - This is probably the most misunderstood positions in healthcare informatics today. The superuser is a really, really advanced, highly-skilled educator. They need to know the details of the software and every detail of every workflow. Think of the superuser as an embedded informaticist without the workflow redesign responsibilities. Superusers have to be patient and love education. They don't get involved in the politics or budgeting discussions. And they need to be available, especially at the time of new software or hardware rollouts, to help smooth the transition between classroom training and the clinical front. Superusers are worth their weight in gold, and you can never have enough of them. Not having well-trained superusers makes any clinical go-live a challenge.

Unfortunately, these are all roles in healthcare informatics, but only the CMIO has any semi-reliable job descriptions and pay data. (And trust me, even for CMIOs, the human resources data is still pretty scarce.) Eventually, these all should be recognized, formal roles, but I'm having a hard time imagining a want ad saying :


So until we formalize the CMIO, the CNIO, the physician and nurse informaticist, the physician champion, and the superuser - Healthcare won't really be able to take advantage of these very important positions.

In the meantime, I'll keep working on it. :)

Tuesday, August 31, 2010

The Cost of Hidden (Embedded) Protocols in your Order Sets

I've recently been paying a lot of attention to the cost of hidden and embedded protocols in healthcare. When physicians argue about the efficiency of EMRs, I think this is really what they're talking about.

Let me explain.

Know that tool we commonly use in healthcare, known as the "clinical protocol"? Common examples of this tool found in most hospitals include the "heparin protocol", the "insulin protocol", and the "STEMI protocol". You've probably heard of them.

So what exactly is a protocol?

A protocol is a set of well-defined care instructions and conditional statements which allow nurses, pharmacists, respiratory therapists, and other licensed medical professionals to initiate, modify, or discontinue an order, on behalf of the ordering physician, as instructed by the protocol. Any conditional statements (IF/THEN arguments) in a protocol should refer to a discrete, well-defined data element. Protocols are primarily activated/deactivated by a physician order, but may in rare instances be activated by a clinical policy in situations where regulatory laws permit (e.g. "pharmacy substitutions" are a common protocol/policy combination). Protocols are typically published through a printshop or an electronic site.

Where did that definition come from? CMS? Joint Commission? Neither. I actually penned it. It probably could use work, but it's a start, and since neither AMIA, HIMSS, Joint Commission, or CMS endorses a particular definition of this tool, I had to write it myself. (Feel free to use the definition for your own uses, and comments are definitely welcome!)

Protocols are generally loved by physicians - They generally allow other healthcare professionals to automate a process on behalf of the physician. The Heparin protocol allows nurses to titrate heparin on their own. Respiratory protocols generally allow a respiratory therapist to manage a vent automatically. And so on.

And here's the surprise : Protocols are sometimes found in many more places than just those sheets.

I think the easiest way to spot a protocol hiding somewhere else is the reference to a conditional statement - An IF/THEN - That allows someone to initiate, modify, or discontinue an order on behalf of the physician who ordered the protocol, as defined by the protocol.

So if you use the "IF/THEN" as your guide, try taking a look at your old paper order sets - you may be surprised when you start to notice a bunch of conditional statements (hidden protocols) in them, such as :

1. "Advance diet as tolerated"
2. "Out of bed as tolerated"
3. "These orders are only supposed to be active in the _______ department."
4. "Titrate sedation for comfort".
5. "Use this drug, unless patient is allergic, then use this other drug" (or some variation of that theme...)

From an engineering standpoint - Having all of these little pieces of embedded protocols hidden in your order sets makes it very difficult to convert a paper order set to the electronic form. Why?

Because computers are unforgiving.
  1. Electronic Order sets generally go in one specific section of your EMR.
  2. Protocols (If/then statements) generally go in another section of your EMR (or your hospital intranet, depending on how you publish them.)
So how did they live, so long, hidden in your paper world?

Because paper is forgiving.
  1. Paper Order sets can have "IF/THEN" and other conditional statements in them.
Q : "So Dirk, what exactly is the cost issue then?"

Here's the challenge : In converting paper order sets to electronic order sets, often, depending on the design, you have to decide what to do with these hidden embedded protocols.
You basically have two choices :
  1. Develop the protocol, but this often takes a significant amount of time and committee and policy work, OR....
  2. You simply leave the protocol out of the new electronic order set.
What ends up happening, often? Order set designers are forced to simply leave out most of these conditional orders (embedded protocols) in the new electronic world.

As a result, this is why, often, the electronic order sets :
  1. Don't LOOK like the paper order sets.
  2. Don't FUNCTION like the paper order sets.
Q: "So Dirk, again, where's the cost issue?"

Well, here it is : If your electronic order sets have been stripped of all of the hidden, embedded protocols found in your paper order sets -

Then your physicians, on "going electronic", may notice many more phone calls from nurses looking to clarify orders that were previously initiated, modified, or discontinued by these embedded protocols.

And you may notice efficiency changes after you "go electronic".

Q : "Wow. And is there any way to help avoid this?"

It takes a lot of work, but fixing this "hidden protocol cost of EMR implementation" will depend on various factors :
  1. How many "hidden protocols" you had in your paper order sets, to begin with. (They generally appear more often in specialties that are not in-house 24/7.)
  2. How reliable your protocol framework is.
  3. How efficient your committees are at examining protocols for safety and approving them.
  4. Your informatics resources, to analyze the workflows, and re-engineering those protocols absolutely necessary for safe workflow to continue.
The cost of not fixing it? Your physicians may sense a significant slowdown after your EMR go-live.

This is where the lack of a Joint Commission-endorsed, or CMS-endorsed definition, causes a problem. By not having a standard definition for hospitals to work with, many protocols go hidden in policies and order sets. (When there isn't a good definition for a protocol, it's easy to engineer them into the wrong tools.)

Avoid the problem by :
  1. Trying to avoid these hidden, embedded protocols in your paper order sets, as much as possible.
  2. Having a robust informatics platform before your EMR and CPOE and documentation go-live dates, to help analyze the paper order sets and begin re-engineering those protocols that are absolutely essential for proper functioning of your hospital.
  3. Making sure your committee structure can analyze these necessary protocols for safety, and approve them in a timely manner.
Again, enjoy! I hope this helps! :)

Thursday, August 26, 2010

EMR Training and moonlighting staffing changes

Another change I've noticed in hospitals that "go electronic", especially private hospitals (those without residents), is that the training needs are often hard to meet. I've heard this from several other CMIOs that I speak with.

The training needs for a hospital with an EMR are challenging. Not only is there the initial training (that most software vendors supply at your go-live), there is the training for every new physician you hire, and then there are training needs every time you update your software. In hospitals which employ a best-of-breed approach, which often have many clinical systems, sometimes the training challenges can be daunting.

So it's important for every CMIO to keep tabs of the "minimum training requirement" - That is, what does it take to initiate a new physician to your electronic environment?

Often, especially in a best-of-breed setting, it also means tailoring the training to the specific needs of the physician's clinical specialty.

The challenge, however, is that this training is often no small task. It's not unusual for it to take 3-5 hours as you introduce a new physician to :
  1. Your overall electronic landscape and their passwords / accounts
  2. Your key workflows that they will be operating in. (The main workflows are important, because they help a new physician trouble-shoot when a portion of the delivery system gets delayed)
  3. Your particular EMR, Order Sets, CPOE, and Electronic Documentation
  4. Any ancillary systems you may use (e.g. Dictation, Radiology, Billing, etc.)
The difficulty often arises, then, when you have a moonlighter who doesn't prepare for this training time. I'm not sure how the big staffing companies handle this in their contracts, but it seems many companies provide coverage with little advanced notice.

But how will you handle a moonlighter who shows up on the day they are supposed to provide coverage? Or what if you only use the moonlighter "in emergencies"? Or what if the moonlighter only works in your organization once every 3-4 months?

I think, in general, that moonlighting companies will need to respond to the pressures of increased EMR adoption by either :

1. Budgeting and writing contracts that allow the moonlighter for the necessary training time.
2. Perhaps allowing hospitals some preference for moonlighters who have experience with "their EMR"?

Will doctors start adding their EMR experience to their CVs, as a hiring qualification?

The EMR shadow is cast well-beyond the boundaries of the hospital setting! :)

Wednesday, August 18, 2010

The CMIO's checklist

So as someone who thinks a lot about the informational flows behind a hospital's day-to-day operations, I read a lot about people who are having challenges with "EMR governance issues".

The governance issues you hear about are basically related to change management and implementation issues. After you have an EMR, your training needs expand dramatically. You may need to engineer your paperwork differently. You have workflow issues to contend with, and decision support issues to tackle.

And the committee structure you had before your EMR may not hold up under the new workload demands. Make too small a committee, and you may not get the right input. Make too large a committee, and you may never be able to make a decision.

If the committee charters aren't well-designed, some committees will be overburdened, while others are looking for work to do.

And if you don't have the support to implement your basic tools, then the "ejection fraction" of your committees will drop. (E.g. the committee will decide on a new policy, but if nobody knows about the new policy, then the committee can make lots of decisions that don't really get executed on the floor.)

In short - it helps if you lay out a strategy for how to deal with all of these issues.

So I created this simple little tool, to help a CMIO (or CMIO-like person) figure out how to help orchestrate the "overhaul" to meet your new needs. I affectionately call it, "The CMIO's Checklist". (See the spreadsheet above for an idea of how to build your own.)

With this tool, you first have to come up with a list of your common paperwork design challenges. As an example, most hospitals generally struggle with the timely design, testing, approval, publication, and implementation of the following :
  1. Clinical Policies (ALWAYS ON) - A statement describing an organizational standard. Commonly fall into standards for patient care (clinical policies) and employees/non-clinical functions (administrative standards). Typically published through a printshop or an electronic site.)
  2. Procedures - Tools which include the detailed steps on how to achieve an organizational standard or defined goal. Typically published attached to a policy statement or in a separate procedure manual.
  3. Guidelines - Tools more flexible and negotiable than a policy that are used to outline desired actions and outcomes of therapy.  
  4. Clinical Protocols (ON/OFF) - Tools used to standardize and automate care for a common clinical scenario, containing those conditional (IF/THEN) statements that allow a nurse, pharmacist, or other licensed medical professional to start / modify / stop a patient care order on behalf of a physician. All conditional (IF/THEN) statements in a protocol should refer to a discrete, well-defined data element. Protocols are primarily activated/deactivated by a physician order, or in some scenarios by a clinical policy. Common examples include : Heparin Protocol, alcohol protocol, PPI substitution protocol, etc. Protocols are typically published through a printshop or an electronic site.
  5. Order Sets -  Tools which include a grouping of orders which can be started / modified / stopped by a physician, used to standardize and expedite the ordering process for a common clinical scenario. Typically categorized as either admission order sets, diagnosis order sets, or convenience order sets, and commonly published either through a printshop or an EMR.
  6. Orders - Tools used to instruct a licensed person to deliver a defined type of care to a defined patient at a defined time in a defined manner for a defined duration. Medication orders, referring to the delivery of medications, are typically compiled in a medication formulary and are commonly published via printshop, electronic site, or EMR.
  7. Clinical Documentation - Tools used to record and sometimes transmit information about a patient's history, activities, therapies, and responses in time, legally authenticated by a licensed medical professional. Commonly includes notes, checklists, forms, flowsheets, tables, fields, images, movies, and other media. Clinical documentation is typically published through a printshop or an EMR.
  8. Templates - Tools that help expedite and standardize the creation of a document.
  9. Staff Education Modules - Tools used to educate staff about a common clinical scenario, often including text, slides, videos, recordings, and other media. All staff education modules will include at least three competency questions. Typically published through a printshop or an electronic site.
  10. Patient Education Modules - Tools used to educate patients about a common clinical condition or activity, often including text, slides, videos, recordings, and other media. Follow-up questionnaires are recommended. Typically published through a printshop or an electronic site.
  11. Staff Schedules - A tool used to define which staff member(s) is/are responsible for a specific type of care at a defined date and time. Typically published through a printshop or an electronic site.
Then, going down the left-hand border of the CMIO checklist spreadsheet, are the following questions that everyone goes through when creating any tool:
  1. What is the definition and main purpose of this tool?
  2. Who owns this tool?
  3. Who builds this tool?
  4. Who tests this tool? (Director of Regulatory Affairs? MD? RN? Clinical Director? Risk Management representative? CMO? CNO? COO? What committee(s)?)
  5. Who approves this tool? (Med Exec Committee? Forms committee? P&T?)
  6. Who codes this tool? (Who comes up with the coding scheme for this tool?)
  7. What coding schema do you use? (E.g. a number like #2.12 or ABC-123?)
  8. Who publishes this tool? How will your staff be able to find it to use it? In a common place?
  9. Who tracks this tool? (What database tracks the tool, it's code, and its approval date?)
  10. Who educates/implements this tool? (Who is responsible for spreading the word that a new tool has entered your clinical arena?)
  11. Who monitors this tool? (Who looks at the tracking database and checks your quality data to look for problems with the tool or its design process?)
Building and completing a CMIO's checklist is a good way to :
  1. Generally figure out where your informatics issues may arise, after you go-live with your EMR.
  2. Generally figure out what committee(s) you will need to approve the maintenance of these tools, and how to build those committees.
  3. Help your committee chairpeople to better define their charters.
  4. Help your middle managers know who is responsible for each part of each tool, when they need to make changes to the clinical setting.
  5. Help the people who design these tools understand the definitions, so that you don't have the "feature bleed" problem I've talked about in previous posts.
  6. Help employees understand the role(s) they play in the overall functioning of your organization.
You will probably want to try completing one of these BEFORE you go-live with your EMR. If you don't, you may have to adjust your governance issues AFTER your go-live.

Remember - Every hospital will have slightly different definitions of these tools, and fill in different titles and committees into each of these boxes. Why? Because unfortunately, there are not universally standard policy-worthy definitions for each of these tools - CMS and Joint Commission curiously don't seem to endorse definitions - I'm not sure why. (What I've written above is just my own example - You may need to adjust the definitions to suit your needs.)

Enjoy! Hope it helps! Remember, your mileage may vary!

Monday, August 9, 2010

Still no order set short cuts

So today I spent a good part of the day with folks from a hospital preparing for their EMR go-live. I went over the role of the CMIO, how to get buy-in, how to develop an informatics platform, and other things that you need to do before you "go-live" with your EMR.
Remember, in the formula for EMR implementation :
  • The CAR = your EMR
  • The GAS = 1/2 clinical IT staff, 1/2 Informatics (IS) staff
So we talked about how to budget for your gas, and other issues in getting physician buy-in.
And then, the subject came up about "the order sets". Especially, all of the work that goes into "fixing" the old order sets.
So they reported to me that they were hoping to save some time by just abandoning their old paper order sets, and using some of the "generic electronic order sets" that come with their EMR.
And then I had to break the news to them : Even this won't save you time.

Q : Huh? Dirk, you have posted about how hard it is to fix the old paper order sets. So why can't you just use the order sets that came with your EMR, and tailor them to your needs?

Here's the reason.
Most of your paper order sets (the ones you made before your EMR go-live) actually have little snippets of protocol in them.

Remember, protocols are the "if/then" conditional statements that help automate some nursing process, generally, so your physicians don't get a phone call. (The most common example is the "Heparin protcol", or the "Insulin Protcol", which most people understand fairly well.)
But you probably have other pieces of protocol in your other order sets. Don't believe me? Look at your paper order sets and look for any text that says "If" or "Discontinue when" or "For use in the _____ only", which are all synonyms for "If _____ then ______" - Or, in other words, these are all hidden pieces of protocols.

So the problem you'll have, if you simply abandon your paper order sets and use whatever came with your EMR, is that suddenly all of those pieces of protocol (which are serving you every day) will disappear from clinical function.

And when those hidden, embedded pieces of protocol suddenly disappear from your clinical setting, your docs will suddenly start getting large numbers of phone calls from nurses to clarify these many clinical scenarios.

And this will lead to your CMIO dilemma : When you have your CPOE go-live, suddenly the docs will sense a "serious decrease in efficiency", and the obvious target of their anger will be your EMR. (This is a good way to lose physician buy-in.)

My advice : Repeat the mantra, "There is no such thing as a free lunch when it comes to order sets". Before you decide to adopt this strategy, take a look at your paper order sets. Highlight any pieces of embedded protocol you find (now that I taught you how to find them.) Realize that these protocols will disappear in the electronic world, unless you have the policy mechanism to re-create them as published protocols.

So if you go through all of your paper order sets, and find a lot of pieces of protocols, I wouldn't advise simply getting rid of your paper order sets - Your docs will suddenly feel a loss of productivity and efficiency when you "go CPOE".

I suppose, if you go through all of your paper order sets, you don't find any hidden pieces of protocols, then you may proceed with caution, but if your paper order sets are that well-designed, and your policy mechanism handled protocols well in the past, then these paper order sets won't be too hard to "make electronic" anyway.

(I have yet to meet anyone who has old paper order sets that are built to that level of engineering, but your story may be different.) :)

My closing take-home points :
  1. If Informatics were easy, you wouldn't get paid to do it.
  2. If Informatics were easy, there wouldn't be schools for it.
  3. There is no such thing as a free lunch.