#SpeakFlower : A model for interconnectivity in US Healthcare

UNIQUE IDEA ALERT

So in my last post, I discussed the "patient identifier problem", and how it contributes to poor connectivity between systems. I discussed some of the political problems with sharing health information, and some common, differing perspectives. I also briefly discussed some of the models being developed, including NHIN/Direct (now officially called "The Direct Project").

One thing I forgot to mention that makes this all more complicated are the myriad of privacy laws - Not just HIPAA, but also various state laws about transmitting or even storing data about HIV and other transmissible diseases.

The challenge is then, how do we overcome these issues in the US?

There are a lot of issues to be worked out, clearly, but I think one of the major issues is simply making organized change with all of these political, financial, and technical obstacles in place.

I. WHO'S THE BOSS?

So let me first ask - Who's the most powerful person in healthcare?

I sometimes ask friends and family this question, and it's interesting to hear people's guesses. "Obama?" "Hillary Clinton?" "The insurers?"

My response : It's the patient.

I think people forget : The patient is the boss. They are the ones who pay the tab for healthcare, whether it's the insurance premiums they pay, or the taxes they pay... They are the one making the choice about where to go, and so they have enormous influence about who succeeds in healthcare.

When it comes to healthcare reform, there is often talk about laws, and doctors, and insurance companies, and nursing unions, and medicare and medicaid - But I think patients are an untapped resource in the healthcare reform discussion.

The problem is that, from my experience, a lot of patients are sort of like the substitute teacher we all had in grade school - Even though they are technically in charge, they're new, they just showed up today, they don't entirely understand the routine, and so they sometimes lack confidence and can be subject to "But-Mrs.-Smith-we-ALWAYS-have-three-hours-of-recess"-type arguments that sometimes steer them.

So I've often wondered - What if a group of coordinated, informed patients could really assert their power?

II. COORDINATING A CHANGE

The problem is, as I said, most patients are too new, or too inexperienced to know what to look for. When doctors and nurses become patients themselves, they can be some of the most challenging patients - Why? Because they know what to look for and how to assert their power.

So then I wondered - Could we somehow train all patients to know what to look for? Could we get patients to ask for different care? How would they know what to ask for?

So I thought - To help patients assert their power to make change, we need to make it easy for them to ask for change. 

So then I thought of solutions. For those readers who are multi-lingual, or amateur linguists, you'll appreciate this : Language is fluid. It's not as precise as most people think. Even though modern English has been around since about 1550, linguists know this : words enter and leave the lexicon all the time.

So what if we employed a linguistic feat and came up for a new word for this new type of healthcare? Something evidence-based, efficient, affordable, and connected?

How could we get patients to ask for this type of healthcare? What if we could get lots of patients to ask for this type of healthcare?

III. DEVELOPING THE STANDARD FOR INTERCHANGE

The first trick is, defining a standard for this future model. From the ground up, the new healthcare paradigm has to be built. The informational framework for healthcare has to be laid to allow hospitals to run efficiently, and for patients to be able to - only if they wish - bring their data with them. That is, one patient = one chart. So when a patient moves from one office to another, the systems will talk to each other and allow true data portability - Without having to push or pull the data.

Why would a patient want a standard for data portability? Why would they care that other doctors can read their chart from another hospital?

• It reduces errors (because doctor A knows what doctor B has been doing)
• It reduces unnecessary tests (because doctor A knows what doctor B already ordered)
• It reduces costs (because fewer tests means lower bills)
• It reduces waiting times (because doctors don't have to spend time trying to research your history)

What if we could make a standard for data portability? Obviously, many patients would refuse, citing personal privacy reasons - But would other patients ask for this?

IV. THE SPEAKFLOWER PROPOSAL

The next trick would be, naming the standard something easy. A lot of "Health IT standards" have names like HL7, CCR, CCD, LOINC, DRG, ICD-9, etc.... Not too tangible to the average patient.

But what if we named this standard something really warm and friendly and tangible... Like "SpeakFlower"?

In other words, "SpeakFlower" is a placeholder for a standard that allows a patient to ask for a doctor/hospital/office to have all of their medical records transferred to a central site that the patient controls, so that other doctors could look at it in the future. It means not only building a particular HealthIT standard into the EMR, but also adopting the practices needed to employ it.

Could we get patients to ask for SpeakFlower? What if they did?

V. SELLING THE CONCEPT

The joke goes, "Standards are like toothbrushes - Everyone knows what they are, but nobody wants to use yours." We have lots of different EMRs, and a few standards, and yet there doesn't seem to be universal agreement on which standard to use, and how to use them.

Why? I think there are a lot of reasons - Complexity of our healthcare system is one, but there's also privacy issues and a lot of competing financial interests. In the end, fighting for a national standard is very challenging.

So what if a coordinated group of patients developed a 100% optional, national standard and how to use it? And what if they called this optional standard SpeakFlower?

Could we sell this concept of an optional national standard? I think so.

After developing the SpeakFlower technical framework (HealthIT standards, central servers, HIPAA-secure gateways, etc.) - You then need to teach patients about SpeakFlower. And how to do this?

Imagine a commercial on the Superbowl, where Wilford Brimley comes out and says :

"You know, my primary care doctor almost ordered something that interfered with something my cardiologist gave me last week, because she didn't know what my cardiologist had prescribed. And my cardiologist almost ordered a test I had last week in the ED because he didn't know what the ED doctor had done. And all of these extra tests, bills, and waiting time are really getting me down... But now, with SpeakFlower, all of my doctors can share my information easily and I get to keep track of it. So ask your doctor... Do you SpeakFlower?"

Why Flower? Because flowers are ubiquitous. They come in every shape and size, are found in every country in the world, and no matter what it looks like, it's still a flower. Flowers are friendly, peaceful, and represent growth, life, and vitality. This optional standard that patients might ask for should represent peace and life.

Oddly enough, if you diagram the model that puts the patient at the center of the medical record, and have all of the providers/hospitals/labs/pharmacists as connections to the patient in the center - The diagram almost invariable ends up looking like a flower.

Why speak it? Because like a person trying to communicate in a foreign language, we might ask for someone to speak the language we know. Asking to SpeakFlower is asking a doctor/hospital's EMR to speak a particular language - It says, "Please have your EMR speak the language I need to accomplish the goal I'm asking for."

VI. REALLY?

The hope would be that simply discussing an optional, national standard for healthcare data interchange would be enough to get all vendors, doctors, and hospitals to adopt the standard and implement it for those patients wanting their charts to be portable. It would also help simplify the privacy discussion, because patients would actively seek out SpeakFlower - Makes the whole discussion on "opt-in-or-opt-out?" much simpler. It would also allow docs and hospitals to generally keep their legacy systems - Implementing SpeakFlower does not require painful amounts of programming, just adherence to the SpeakFlower standards.

But if the discussion wasn't enough, then the hope is that the Wilford Brimley commercial on the Superbowl could spur the discussion - in the same way pharmaceutical companies have gotten patients to ask for drugs, patients could start showing up saying, "Dr. Stanley, do you SpeakFlower in your office?" and have an understanding of the benefits of SpeakFlower.


And even if 30% of my patients asked me to SpeakFlower,  I'd probably have little choice but to make sure my EMR SpokeFlower, for those patients requesting it. So I'd speak to my vendor and ask them to make sure my EMR can SpeakFlower.

VII. SPEAKFLOWER TODAY

If only...

There is a SpeakFlower.org web site, which I started to develop with two colleagues in our spare time,  but you'll notice the web site is outdated and quite frankly, we realized planting SpeakFlower in our national garden would require much more time and capital than we currently have. (Namely, weekends and nights.)

But we're still trying to build it and transplant it to the right FlowerPot. Our hope is to make SpeakFlower a force of good in healthcare. We also have a #SpeakFlower hashtag on Twitter that we apply to tweets that discuss patient-centered electronic medical records.

Healthcare needs innovative ideas. If you're interested, follow @SpeakFlower on Twitter, feel free to use the #SpeakFlower hashtag, and look for the SpeakFlower gardening team as we look for the right pot to plant in. :)

As always, I welcome any comments and thoughts. 

"Why don't these systems talk to each other?"

Another frequent question I get asked in my job is, "These systems are all plenty expensive - Why don't they talk to each other?"

What this is referring to, of course, is the common phenomenon that the EMR at one hospital may not seamlessly transfer a patient's record to another EMR down the street.

There are actually a few reasons why this is so, but one of the most interesting ones is a phenomenon called the "patient identifier problem."

Q: DIRK, WHAT EXACTLY IS THE "PATIENT IDENTIFIER PROBLEM"?

Here's what it boils down to : It's much harder to identify a human being than you might imagine.

Allow me to explain. (Names below are purely fictional, just for teaching purposes.) :)

So at first glance, it should be easy to identify a human being. After all, we have names, right? When we see our neighbor John mowing the lawn, riding his mower - His name is John - We recognize him - Yep, that's him. Easy, right?

Well the problem is what happens when we actually try to identify someone on paper - That is, have a record that we can match to an actual human being.

At first, we might try to label a chart "John's Chart". The problem with this approach is that there may be lots of Johns, so in a small town (even on a small street), you might have two "John's Charts".

So you might add the last name : "John Smith's Chart". This might work in a small town, but when you expand to collect charts for your whole state, or the whole country, you might find over 700 "John Smith's".

So names are generally a bad way to label a chart for a few reasons :

1. There might be over 700 "John Smiths" across the country - How will you know which chart is the right one to look for?
2. Your neighbor, John Smith, might register at Clinic A as "John Smith", at Clinic B as "Johnathan Smith", and at Clinic C as "Jon Smith". This could potentially make three records. How will you know which is the proper record to search for?
3. Names may also be misspelled by registration staff - If a "Karen" registers in a clinic, will the registration staff write "Karen", "Caryn", "Karin", or "Karyn"?
4. Ethnic names, over a large country, also may suffer from the poor understanding of the host country. How exactly does one spell Dimitry? Dimitri? Dimytri? Moroch? Morocz?

So one might try to straighten this out with some simple recipe - One I often hear first is, "Why not use the first three letters of the first name, first three letters of the last name, and the date of birth?"

The problem with this approach, again, is that someone might register with a different name in a different clinic. Is it going to be "JOHSMI01011970" (John) or "JONSMI01011970" (Jon)?

Then the suggestions usually continue...

Q : "Dirk, what about by the Medical Record Number?"

The medical record number for this patient at your hospital (123456) may not be the same as the medical record number for the office down the street (654321).

Local medical record numbers might work for a hospital, or a small regional group (if you have centralized registration), but they generally don't work across different healthcare systems.

Q : "Hmmm... Why not use the social security number to identify people?" 

The social security number suffers from a few problems too :

1. There is no check-digit in the social security number. A check-digit is a number (or series of numbers) that are mathematically linked to the other numbers, so you can figure out if the number has been falsified. The social security number was invented back in 1935, before things like "identity theft" were around. As a result, the social security number is probably one of the most abused identifiers, often used for fraud by criminals. 
2. The social security number is a 9 digit number - So in total, we should be able to issue about 999,999,999 of them, BUT... because of certain restrictions (e.g. no numbers that start with 666, no numbers with -13- in them, no numbers with all of the digits the same), there is really only a pool of about 820 million to draw from. Currently the U.S. population is about 350,000,000. Which sounds OK, except that we maintain that number by having some people die every year, and some new babies added every year. In total, about 620 million numbers have already been handed out, so we could potentially run out of social security numbers sometime around 2100. Yes, that will be some time from now, and hopefully we will be able to fix that before it happens - but in our current political climate, will the government ever be able to assign a personal identifier again?

It's funny - I've spoken to informatics people around the globe, and they usually ask me "Dirk, why are you guys in America having so much trouble getting a national health record? In our country it's very simple - Either :

• "...our national government maintains our national health record." 
• ... or ...
• "...our national government assigns a health identifier for all citizens."

Well, the problem is that we're Americans. Authors like George Orwell and Ayn Rand have left a significant impression on our national consciousness. We just don't like the idea of the government assigning a number to track all of our health information. In fact, in 1998 Congress forbade the HHS, by law through HIPAA, from creating a health information identifier - Despite many groups asking for an identifier, and an estimated $77 to $154 billion savings in healthcare that a national patient identifier could provide. And perhaps (just to be fair), this is for good reason - see this letter opposing government-issued medical identifiers and this document summarizing the potential abuses. (Please note : I'm not taking sides, just presenting both sides of the argument.) 

Q : "So Dirk, how does the VA (Veteran's Administration) do it? I heard they saved lots of money through their VISTA/CPRS medical record, and their record is a major source of data for reasearch."

The VA essentially has a national patient record because, well, most veterans have a different opinion. When you ask most vets, "Do you care if the government has a number to track you?", they say things like "No, the government has been keeping a file on me since the day I enlisted!" right before they rattle off their rank and military ID number from memory. In reality, the VA has also been using Social Security numbers, but I understand there is currently a movement underfoot to move away from those identifiers to another number - I'm not an expert on the VA architecture, but this might explain why they divide the VA record up into different VISN systems. (Any VA Informatics people reading this willing to help explain the architecture?)

In short - 

• The culture at the VA supports a nation-wide medical record number.
• The culture of private and teaching hospitals (the "rest of America") does not.

This is why, when I get asked :

Q : "Dirk - The VA has free EMR software - Written by the government, so it's public domain - Why don't private hospitals use it?"

I usually answer, "Private hospitals *could* use it, but because of these culture differences they probably wouldn't see the cost and efficiency benefits that the VA did."

(In reality, there are also other support reasons why a private hospital might not implement CPRS/Vista - But that might be changing some with cool open-source projects like OpenVISTA.)

Q : "So Dirk, is there any hope for a national EMR? Will patient data ever be truly portable?"

Well, currently there is the NHIN/Direct project (see http://www.directproject.org and http://wiki.directproject.org) which seeks to allow physicians to transmit patient data, securely, between different offices - But without a common patient identifier, this may not have the workflow some patients and most physicians ideally want. Still, it would allow a maximum of privacy and patient control, and it's at least a step in the right direction.

There are also a number of regional Health Information Exchanges currently in use, and new ones being built - But without a common patient identifier, nobody seems to be sure about how this is going to work on a bigger, national level.

So yes, if you're traveling from Texas to NYC for vacation - You had probably better bring your medication list and medical history written on a piece of paper, just in case you need medical care.

Finally - I think there is actually some hope for a solution to this that could fly politically in America.  I've tested the idea with both republicans and democrats and oddly, both seem to like it. It's called the voluntary patient identifier. Unfortunately, I think so far this effort suffers from poor understanding, poor marketing, and quite frankly, poor patient interest. 

But I think there is a way to change that - I'll describe it in my next post.

(Ooh - Cliffhanger ending!) :)

Always glad to share - Feel free to leave comments, thoughts, and questions! :)

Where Exactly Do My Med Orders Go?

Where Exactly Do My Med Orders Go?

Ever wonder where your orders go? One of the things I do when training a doc on CPOE is explain to them the basic medication delivery workflow in a standard hospital. When a doc "goes CPOE", he/she is suddenly confronted with some hard realities of the ordering process - Exactly what they order, and exactly how they order it, will largely determine their success in getting a drug at the right time in the right place.

(PLEASE NOTE WITH THIS DISCUSSION : YOUR MILEAGE MAY VARY GREATLY - This workflow is a general summary, but lots of other hospitals may do things differently, and for a very good reason - I'm just summarizing some general themes, but for specific information, ask your directors and informatics staff.)

 

So I usually start to frame the discussion with the basic unit of care - A doctor, and a patient. (You'll notice these slides borrow from my piece on "What is Med Reconciliation, anyway?", where the physician and patient lovingly spend time with each other in an area I call the "patient care cubicle") -

• Inside a hospital, this "patient care cubicle" is an "inpatient care cubicle".
• Outside a hospital (or in an ambulatory setting like an ED or day surgery), it is an "outpatient care cubicle".

Let's focus first on the inpatient care cubicles, where a lot of medications are ordered as patients are admitted into a hospital :

It's first important to consider how exactly an order is created. If the doctor and patient are sitting next to eachother, then the basic unit of care (from the physician perspective) is the physician order - On this slide, it's labeled the "MD ORDER".

First, let's look at this "MD ORDER" for a medication in the INPATIENT setting :

I. MD ORDER FOR A MED : THE INPATIENT SETTING

There are then basically three different ways a med order can come into existence :

1. As a written order - This is an acceptable way of making an order - Even the VA, during downtimes, allows written orders. Most hospitals with EMRs still allow some form of written orders for downtimes or other complicated orders. The problem : This type of order requires a nurse or pharmacist to transcribe it, so if the doctor has poor handwriting, this can result in a small percentage of error. 
2. As a telephone / verbal order - This is also an acceptable way of making an order, especially if the physician's hands are tied up doing a procedure or surgery. The problem : This type of order also requires a nurse or pharmacist to transcribe it, so if the doctor doesn't speak clearly, this too can result in a small percentage of error. ("Did you say Metoprolol 15 or 50mg?") Another problem : This legally requires a physician to go back and sign this order afterwards - This is very complicated and time-consuming for most physicians.
3. As a CPOE order (Computerized Physician/Provider Order Entry) - This is the entry method preferred by most hospitals, regulatory bodies, and the government. I suspect this is primarily because there's no intermediary who needs to transcribe the orders, so there is the common belief that this is less error-prone. I haven't seen really good data about this yet, but I do believe that good CPOE requires good training. There is also some data to suggest total medication turnaround time decreases with CPOE use - See this HHS piece on Medication Turnaround Time.)

So no matter how a physician creates the order on the floor, the order gets made. Let's say, for our little example, that the order is "Ativan 2mg IV x1 dose STAT".

Any idea where the order goes next? If you guessed "Pharmacy", you're right!

Whether you're in an electronic hospital, or a paper hospital, Joint Commission requires all inpatient medication orders for acute care hospitals to be "verified" by pharmacy. ("Verify" is basically a fancy word for "double check".)

So a pharmacist suddenly sees the medication order - "Ativan 2mg IV x1 dose STAT". And there are a few things a pharmacist can do to try to help ensure the safety of this order :

• They can check the allergy profile of the patient.
• They can check the dose of the drug.
• They can check for drug-drug interactions.
• In some hospitals, they can even sometimes do fancier checks, like check the renal dosing of the drug, weight-based dosing of the drug, etc. (this sometimes varies considerably, depending on the types of services offered)

What pharmacists can't really do well is verify the need for the drug - They usually aren't sitting in front of the patient, with the patient's chart - So if you order heparin on a patient with a bleeding ulcer, a pharmacist is probably not going to be able to prevent that type of error. (Nurses, usually right in front of the patient, are generally much better at finding that sort of error.)

Anyway, after a pharmacist does his/her best to verify the safety and dosing of the order, or adjust the order, they generally click a button to "verify" the order, and then the order travels back to the floor where it does two things :

1. It unlocks the Pyxis drawer (in this example the Ativan drawer)
2. It creates a blank entry on the eMAR (electronic Med Administration Record, aka Cardex, aka Codex)

This then allows a nurse to take the drug out of the Pyxis drawer, give the drug, and chart it on the eMAR. Once it's charted, that's generally when a hospital gets to generate a bill for having given the drug. 

So that's generally the way it works in the inpatient world.

Any problem with this pharmacy verification workflow? Having a pharmacist double-check the orders helps reduce errors, so ... Is there any drawback a doc should be concerned about?

Well, imagine if you had a patient seizing in front of you, and you had to give them the "Ativan 2mg IV x1 dose STAT". How long exactly does it take a pharmacist to verify those medication orders? 

The interesting thing is that there are actual guidelines about this (these are approximate - Your state/region may vary on this) :

• Priority = STAT : In many places regulations allow up to 30 minutes (in reality, most inpatient pharmacies verify STAT orders in about 5-10 minutes)
• Priority = ROUTINE : In many places regulations allow up to 90 minutes (in reality, most inpatient pharmacies verify ROUTINE orders in about 10-15 minutes)

So if the regulations are typically around 30 minutes, and even if your inpatient pharmacy can do it in 5 minutes, can you wait 5 minutes to give a seizing patient ativan?

The answer, of course, is obviously no. So what can you do? You generally have two choices :

1. OPTION 1 : Call the pharmacy and say "I just put in an order for Ativan - Can you verify it ASAP so the nurse can take it out?"
2. OPTION 2 : BYPASS the system. In most hospitals, a "Code Blue" (or "Rapid Response") is a perfectly acceptable reason for a nurse to hit the "Emergency Bypass" button on most Pyxis machines - This allows a nurse to get the drug and give it in an emergency. 

Note that most Pyxis machines actually TRACK the number of times they have had an emergency bypass - There should be a valid reason to bypass this important safety mechanism, so a unit where there are more emergency bypasses than needed/expected may be a cause for concern and investigation.

So that's generally the way medication orders get created, verified, and followed in an inpatient setting.

II. MD ORDER FOR A MED : THE OUTPATIENT SETTING

Here's where it gets interesting - That pharmacy verification thing? Joint Commission, on seeing the success of this in reducing errors, thought 'Wouldn't it be nice to have pharmacist verification in the OUTPATIENT setting (e.g. Emergency Department, Surgical Daycare, etc?)'

And do you know what happened? Most emergency departments, for good reason, argued "We can't handle the time delay of verification!" - And so, as of yet, it's not a mandate to have pharmacy verification in the Outpatient setting. (Perhaps for good reason - The delays it could cause could create a whole different set of problems.)

So how exactly *does* it work in the outpatient setting?

ORDERING : Generally the same process - A doctor can use either :

1. Written order (same as above)
2. Telephone / Verbal order (same as above)
3. CPOE order (same as above)

The difference is, however, that without pharmacy verification, where exactly does the order go?

In most hospitals with electronic systems, then, this order then will simply go to the eMAR. (It makes a space in the software for charting the administration of the drug.)

So then the typical workflow is this :

1. Nurse sees order in EMR or eMAR
2. Nurse opens Pyxis (in most EDs, the Pyxis will open up automatically)
3. Nurse gives the drug
4. Nurse charts the administration on the eMAR

Again, after charting the administration, this usually lets a hospital generate a bill for having given the drug.

So in most Emergency Departments (mostly for reason of avoiding delays), there is no pharmacist between the doctor and the nurse part of the workflow. There are still two people double-checking every order - The physician, and the nurse.

III. SO WHY DO I CARE?

The reason you, as a physician, might care about these workflows is that often, inpatient doctors are asked to admit patients from the Emergency Department.

And how exactly does a computer know which workflow to follow - The inpatient or outpatient workflow?

Let's recall - In both settings :

• The physician usually places the order via written, telephone/verbal, or CPOE methods.
• The nurse usually gives the drug to the patient
• The nurse usually charts the administration on the eMAR.

So how does the computer know whether to follow the inpatient or outpatient workflow for a medication order?

Q : "Dirk, is it by physician type? Like, orders from ED docs follow the outpatient workflow, and orders from Hospitalists or other inpatient docs follow the inpatient workflow?"

A : Usually not. If systems were built to do that, then a Hospitalist would have significant challenge in running a code on a patient physically located in the ED.

The answer is usually, as we say in New York, "Location, location, location." That is, the location of the patient determines which workflow most EMRs will use on the order.

So for example - A patient in a location, and the workflow :

• ED Room 1 = Outpatient
• ED Room 2 = Outpatient
• ED Room 14 = Outpatient
• ED Holding Unit = Inpatient *
• Room 125B = Inpatient
• Room 202A = Inpatient
• ICU Bed 3 = Inpatient
• ICU Bed 4 = Inpatient

* - Remember - Most holding unit beds are actually an inpatient level of care, and so they follow the inpatient workflow.

IV. AGAIN - WHY DO I CARE?
There are a few reasons why I teach this to the docs I'm training on CPOE. They are :

1. You are going to be a working doc - You need to know how to troubleshoot the system, just in case of emergencies.
2. You might admit someone from the ED to an inpatient bed.

Reason #2 is especially important for Hospitalists and other inpatient docs to understand. Why? Because if you are admitting a patient, and the computer still shows the patient to be in an ED bed (e.g. ED Room 1), then those orders entered into your EMR may not be verified by pharmacy - Orders not verified by pharmacy means the Pyxis machine won't open up when the patient gets up to the floor. This is when you get that call from the nurses : "Dr. ____________, remember those orders you put in while the patient was in the ED? For some reason, the Pyxis machine isn't opening up now - Can you re-enter those orders in the computer?"

This, of course, leads to delays and frustration. So what's the best thing you can do as an inpatient doctor, if you get called by the ED to admit a patient to your service?

1. First, go down to the ED and see and evaluate your patient
2. Look on the computer at their location -
     - If it says "ED Room 1" - Ask your registration to change their bed to an inpatient location.
     - If it says "ED Holding Unit" or "125B" or "204A" or "ICU 3" - Go ahead and start your orders.

Again, please remember - Your hospital's workflows may vary - This is a gross generalization for teaching purposes only. Please ask your local regulatory agencies, your local administrators and directors, and your local informatics people for more details about the workflows in your hospital.

Hope you enjoyed this post - Feel free to send questions, I love the feedback and I'm always glad to create posts to answer them!

Informatics Curriculum for Medical Schools

There are currently lots of hospitals and doctor's offices looking to "go electronic" by getting an electronic medical record.

Some of those offices/hospitals, however, won't be able to make the conversion without a lot of pain.

Why can some places do this easier than others?

Part of the reason, the one that's commonly given, has to do with willingness to change - Will you be willing to support your EMR implementation? Will you pay for the software AND the support? Will you be willing to send your doctors and nurses for training? Will your doctors and nurses embrace the change?

And then there is another more difficult topic - Is your clinical paperwork well-designed?

Organizations that have well-designed paperwork will generally have an easier time of "going electronic". Organizations that don't, won't.

So what is "well-designed paperwork?"

This brings me to a topic that sometimes pops up in clinical informatics discussions - The need for some education on clinical informatics in medical school. 

Medical schools already have so much to teach - So whatever informatics education I can convey has to be short and sweet. So I started to dream of what I would teach, if I were invited to lecture at a large medical school, to help the students with their medical careers and running their practices/hospitals in a way that facilitates an easy transition to an EMR...

Doctors who generally understand these tools and design their paperwork by these divisions will have an easier time "going electronic". Doctors who mix these tools on the same paperwork will have a harder time "going electronic".

(So without further ado... Start the spacey, dream-sequence fuzzy-image noise...!)

--- START OF CURRICULUM ---

CLINICAL INFORMATICS 101 - LECTURE SUMMARY

Instructor : Professor D. Stanley 

Date : Now

Location : The comfort of your computer

Hi folks - Nice to meet you. I'm here to prepare you for thinking in a way that will help you in your future clinical practice.

No matter what you do clinically, you're going to be expected to work in a team. Good teamwork requires good communication. So it's really important, for you, your patient, and your other teammembers, that you know how to communicate properly.

In addition to being friendly, and well-spoken, and being a good listener - It's very useful for you to understand the informational tools you're going to be using to take care of patients.

So I'd like to tell you a little bit about those tools, so that you design and use them well.

1. ORDERS

An order is an instruction for a defined person to deliver a defined type of care to a defined patient in a defined way for a defined amount or duration. You'll notice I used the word "defined" five times in that sentence. It's because orders, to be safe, should be as well-defined as possible. Orders are the smallest unit of initiating patient care. (If you're going to be a doctor, you're going to be creating a lot of them, so you should learn to make them safely.)

One of the first mistakes people make is mistaking other things for orders. As a general rule, orders should not be more than a line long - If they are, it's usually a red flag that what you're writing may not actually be an order.

In the paper world, putting other things down as orders isn't so bad because human brains will still be able to sort through the different types of tools, and nurses will know what to do with them. In the electronic world, however, poor order organization will lead to difficult EMR installations and HealthIT implementation problems.

Generally, orders are categorized by the people who are expected to follow them. So for example, you might find :

A. Pharmacy/Medication Orders - Used by nurses and Pharmacists

B. Nursing Orders - Used by Nurses

C. Diet Orders - Used by Nurses and Dietary Staff

D. Respiratory Orders - Used by Nurses and Respiratory Therapists

E. Activity Orders - Used by Nurses and Physical Therapists

F. Laboratory Orders - Used by Nurses, Phlebotomists, and Laboratory Staff

G. Imaging Orders - Used by Nurses and Radiology Tech staff

Another common mistake : Writing protocols as orders. Protocols are any "if-then" statements you might think of writing - If it's got a condition, where you expect a nurse to interpret a condition before taking another action, it's a protocol.  For example, "Give aspirin 325mg PO x1 dose STAT unless patient is bleeding" is actually a protocol. Even the text "These orders are only to be used while the patient is in radiology" is actually a protocol.

And another common mistake : Writing patient instructions as orders, e.g. "Change catheter dressing every 7 days after discharge" might sound like a nursing order, but it's really an order to the patient.

Some examples of good and bad orders, with comments :
- Aspirin 325mg PO x1 dose STAT - good order
- Morphine 2mg IV q30min PRN moderate pain - Because it has no duration, this could be a dangerous order if it's not automatically re-evaluated in 2-3 hours
- Morphine 2mg IV q30min PRN moderate pain x 3 hours - By assigning a duration, this becomes a safer order
- Morphine 2mg IV q30min PRN moderate pain x 3 hours Comment : Hold for sedation - By adding a comment reminding the nurse to hold the drug if the patient becomes sedated, this becomes a safer order
- Aspirin 325mg PO x1 dose STAT Comment : Hold if patient is bleeding - Because there is a conditional (IF/THEN) statement, this is actually a protocol.
- Change catheter dressing every 7 days : Unless the patient is actually in the hospital for 7 days or more, this is more likely a patient care instruction than a nursing order.
- Chest X-ray STAT : While this might be acceptable, it does not contain an indication and there may be billing problems. It also does not tell a radiologist what you are looking for, so they could miss what you're looking for.
- Chest X-ray STAT Indication : Cough, sputum, acute shortness of breath, rule out aspiration - By adding an indication, this will avoid billing problems. By adding detail, the radiologist can cue in on the clinical question you're asking. 
- Advance diet as tolerated - This does not help a nurse understand what diet they should be aiming for, nor how to advance the diet, nor in what timeframe they should try to advance it. Because this actually has a great deal of IF/THEN logic, in short, this is really a protocol.
- Advance diet to regular diet as tolerated - This helps a nurse understand that you're aiming for a regular diet - Better than the above diet order, but it is still a protocol.
- Advance diet to regular diet, no texture modification, no liquid modification as tolerated - This is even better because it tells a nurse what diet to advance to AND the texture and liquid modification that the patient might need - But from an informatics perspective it is still a protocol.
- If K+ < 2.5 then give KCl 40 mEq PO x1 dose - First, because it has an IF/THEN, this is actually a protocol. Next, writing "KCl 40 mEq PO x1 dose" could be misread as "KCl140 mEq PO x1 dose".
- If K+ < 2.5 then give Potassium Chloride 40 mEq PO x1 dose - Still a protocol, but at least there's no chance for the "l" in "KCl" to be mistaken for a 1.
- Percocet 5/325mg 1 tab PO QID PRN - Some folks might not realize that QID actually has set times - 8am, 12pm, 4pm, 8pm - So technically this could only be taken during daytime hours. (Is that the intent?) The PRN also does not specify the reason to take the Percocet, so a patient could take it for any pain. (Is that the intent?)
- Percocet 5/325mg 1 tab PO q6h PRN - This is a little better, because it would allow a patient to take it every six hours, even overnight. Still does not describe the circumstances in which the doctor would recommend to take the Percocet.
- Percocet 5/325mg 1 tab PO q6h PRN moderate pain (4-6) - This is even better, because the PRN is better described, so the nurse/patient knows when to consider giving the Percocet.

The best way to know whether or not an order is a good or bad order is to test the order in a test environment - Have a doctor write or enter the order on a "dummy" patient, and have a nurse read it. Then interview the nurse about how they would act and what they would do. It also helps to ask someone with experience/training in ordering safety.

The take-home point : Orders should always be well-defined for safety. Always test them if you have any questions.

2. ORDER SETS

Order sets are groupings of orders used to standardize and expedite the ordering process for a common clinical scenario. Unlike protocols, order sets contain orders that are started, modified, and stopped by a physician/LIP.

For safety and proper functioning, order sets should only contain orders. (See above.) Protocols, policies, procedures, guidelines, patient instructions, and staff instructions should generally not be built into order sets.

Optimally, for efficiency, order sets should be divided into one of three categories :
      - a. - Admission order sets - Those that standardize the ordering process for a common admitting scenario.
      - b. - Diagnosis order sets - Those that standardize the treatment for a common diagnosis/procedure
      - c. - Convenience order sets - (e.g. "Quick pick" lists) - Those that standardize the ordering process for a common clinical objective not described in a. or b. above. 

3. CLINICAL PATHWAYS 

Clinical Pathways are groupings of order sets used to standardize the treatment of a common clinical diagnosis. They contain orders which are started, modified, and stopped by a physician/LIP, and are generally used daily throughout a patient's hospitalization.

4. PROTOCOLS

Protocols contain orders which are started/modified/stopped by a nurse, pharmacist, or other healthcare professional based on a well-defined condition. They contain the IF/THEN logic that helps automate and standardize a clinical process, and if well-designed, can actually help increase safety and efficiency.

The challenge with protocols is designing them well. Because they contain orders which are started, modified, and stopped by a nurse, pharmacist, or other healthcare professional based on a well-defined condition ("discrete data element" in informatics terms), they require significant safety evaluations.

Common examples of protocols might be the "Heparin titration protocol", the "alcohol detoxification protocol", and even the "PPI Substitution protocol". These should all be published in a similar manner, executed in a similar way, and re-evaluated continuously.

5. GUIDELINES

Guidelines are general instructions about how to accomplish a particular task, but have much less medicolegal weight than a protocol or policy/procedure. Guidelines are generally more flexible, and can be useful for a clinician to understand a clinical process but still allow modifications depending on clinical circumstances.

6. POLICY/PROCEDURE
A policy is a written standard of the organization. A procedure is a set of detailed steps which describe how to achieve the policy objective. For this reason, they are commonly published together on the same document, although technically, a procedure does not have to be a mandated standard.

As a rough outline, policies are usually divided into :
  - Clinical Policies (and procedures) - Those that describe standards related to patients and patient care
  - Administrative Policies (and procedures) - Those that describe standards related to employees and employee issues.

Because policies and procedures should be 'written with maximum clarity for them to be effective, they generally should only be written by people with experience or formal training in policy writing.

For easy access, policies and procedures should be published in a common, easy-to-access area.

Algorithms can be thought of as graphical representations of procedures.

7. DOCUMENTATION / FORMS
Documentation/Forms are the tools used to record patient condition, vitals, responses, therapies, and outcomes in date/time order. If designed properly, these can also help standardize clinical processes and streamline care. Types of documentation can include :
   - Notes (e.g. H&P, discharge summary, nursing notes, respiratory therapy notes, etc.)
   - Checklists
   - Consents
   - Flowsheets (e.g. vitals, pain, drips, vents, etc.)
   - Labs
   - Radiology/Imaging
   - Other technology results

8. STAFF EDUCATION MODULES
A Staff Education Module is a document that teaches a staff member about a particular educational objective. It could contain text, photos, videos, or other tools needed to communicate the educational objective to someone else. For effectiveness, it should contain a short quiz to document understanding of the educational objectives.

9. PATIENT EDUCATION MODULES
A Patient Education Module is a document that teaches a patient about a particular educational objective. It could contain text, photos, videos, or other tools needed to communicate the educational objective to a patient. For effectiveness, it should be very clear, and should contain a short quick to document understanding of the educational objectives.

10. CLINICAL STAFF SCHEDULES
A clinical staff schedule is a document that outlines the employee(s) responsible for patient care at a particular date/time. It should be published in a standardized manner in a standardized location.

11. TEMPLATES
A template is a document used to help build, standardize, and expedite the building of another document. Some common examples might include the "Order set template", the "Admission H&P Template", the "Discharge Summary Template", and the "Policy Template".

Because templates can be used to expedite and standardize the creation of another document, great care should be taken to avoid "auto-documentation"-type workflows which can run into billing/legal issues.

12. GLOSSARY
A glossary is a document with a list of commonly-used terms in alphabetical order, along with their definitions. By having an organizational glossary in a common area, it allows all members of the organization to standardize their definitions and language.

--- END OF CURRICULUM ---

I hope this was useful to you all - Again, your mileage may vary greatly, so please check with your local laws and regulatory bodies before setting up your own paperwork and processes - but from a functional, pure-informatics standpoint, these would be the chapters in my "clinical informatics book".

Feel free to write with any comments or questions - Discussion on this blog is always welcome! :)

Secret weapon of the Informaticist : Good policy writing

I've been speaking with various CMIO types, and Informatics types, and found an interesting pattern :

1. "Newbies" - Generally focused on the technology, the software, the bells-and-whistles
2. "Grizzled Veterans" - More focused on governance and change management.

In short, it's probably helpful if you have a little bit of both characters. You will need to worry about the software, the menus, the dialog boxes, the MLMs, your hosting, and your tablet computers if you want to garner support for your EMR implementation. 

But when it comes to making organizational impact, nothing beats being a solid policy writer. A smart policy writer can have much more influence than the best politician/salesman in trying to organize things.

So even though I've written about policies before, I thought I'd write a little bit about the "tricks of the trade". This is the little trick you'll want to keep hidden, your lightsaber you'll carry on your belt. Only wield it when needed, and only use it for good. 

POLICY TRICKS OF THE TRADE 

The first thing, to really get solid with policy writing, is to really grok what a policy is. (For those of you who don't know the word "grok", it comes from Robert Heinlein's book, "Stranger in a Strange Land" - Wiktionary defines it as "to fully and completely understand something in all its details and intricacies.".)

A policy is your opportunity to set a standard. It's a document defining the standard.

The procedure (often linked to a policy by being on the same document) is the steps you take to achieve that standard.

Profound! You could, in fact, write a policy saying that you will be brought a coffee and donut every morning when you show up for work!

What would such a policy and procedure look like?

POLICY : All readers of Dirk's Blog will be brought a coffee and donut on their arrival for work in the morning, according to the procedure outlined below.

PROCEDURE :

1. Minion will bring money to store at 7am.
2. Minion will purchase (1) large coffee with cream and sugar.
3. Minion will purchase (1) chocolate glazed donut.
4. Minion will transport coffee and donut (described above) to office.
5. Minion will await arrival of Dirk's Blog Reader.
6. Minion will give donut and coffee to Dirk's Blog Reader, on their arrival.

It's really as simple as that. And yet, it's complicated...

It's complicated because people don't generally think that clearly without training. It's really easy to get clouded up, especially in healthcare, where you are trying to satisfy many regulatory issues, and dealing with very technical procedures.

But alas, I'm here to provide some guidance!

THE POLICY

The basic format of a policy can be written using this template :

[ who/what ] will [ what ] [ how ] [ when ] [ where ] [ why ]

Where : (blue = mandatory, brown = optional) 

[ who/what ] = The person/thing that is being standardized

[ what ] = The standard that is being applied to the who/what above

[ how ] = How the standard will be achieved ("according to procedure below" is OK!)

[ when ] = Optional, only use if it helps clarify when the standard should be applied

[ where ] = Optional, only use if it helps clarify where the standard should be applied

[ why ] = Optional, only use if it helps clarify the purpose of the standard

  Try it out! Here are some examples of good policy statements :

1. All patients will receive low-fat meals.
2. All patients over age 60 will receive a pneumonia vaccination before discharge.
3. All policies will be clearly written, according to the procedure outlined below.
4. All order sets will be evidence based and built according to the procedure outlined below.

And some examples of bad policy statements :

1. Patients should receive low-fat meals because it helps prevent heart disease. (Wordy, and never use the word "should" in a policy - "Will" is a stronger word!)
2. Pneumonia vaccines are helpful in preventing pneumonia, and so this will be given to any susceptible patients over age 60 before they are discharged by the nurse. (Too unclear and wordy!)
3. It is imperative that policies should be written in a manner consistent with easy comprehension. Policies should be developed in a clear, logical manner. Policies will be kept in the policy manual after approval. (Too wordy, vague, and starts to put procedure into the policy statement!)
4. All order sets will be evidence-based. (Nothing pointing a reader to the procedure below which, hopefully, explains how to build them in an organized fashion.)

Once you've mastered writing a good policy statement, you can proceed to the procedure.

THE PROCEDURE

The procedure is the "how to achieve the goal."

The best way to write a clear procedure is, again, to explain the who, what, when, where, how, and why, which together will tell you "how to achieve the goal".

Again, a template for thinking about it - You will need a series of steps :

1. [ who ] will [ what ] [ when ] [ where ] [ how ] [ why ] 
2. [ who ] will [ what ] [ when ] [ where ] [ how ] [ why ] 
3. [ who ] will [ what ] [ when ] [ where ] [ how ] [ why ] 
4. [ who ] will [ what ] [ when ] [ where ] [ how ] [ why ] 
5. [ who ] will [ what ] [ when ] [ where ] [ how ] [ why ] 
6. ... and so on ...

Where :

[ who ] = Person who will actually perform the task

[ what ] = Task they will perform

[ when ] = (usually optional) when / until when they will perform it

[ where ] = (usually optional) Where they will perform it - Only use if needed for clarity

[ how ] = (usually optional) How they will perform it - Use only if needed for clarity

[ why ] = (usually optional) Why they will perform it - Use only if really needed (rare)

Think of it as a recipe - In fact, most recipes are procedures! From Allrecipes.com you can find this New York Cheesecake Recipe and easily convert it to a procedure :

1. Baker will preheat oven to 350 degrees
2. Baker will grease a 9-inch springform pan
3. Baker will, in medium bowl, mix graham cracker crumbs with melted butter
4. Baker will remove mixture from medium bowl and press mixture onto bottom of springform pan
5. Baker will, in a large bowl, mix cream cheese with sugar until smooth
6. Baker will blend in milk
7. Baker will mix in eggs one at a time
8. Baker will mix in sour cream, vanilla, and flour until smooth
9. Baker will pour filling into prepared crust
10. Baker will place crust and mixture into preheated oven for 1 hour
11. Baker will turn oven off and let cake cool in oven with the door closed for 5-6 hours
12. Baker will remove cake from oven and chill in refrigerator

Of course, seeing all of the "Baker will..." statements is sort of cluttered, so you might make it look a little tidier :

Baker will :

1. preheat oven to 350 degrees.
2. grease a 9-inch springform pan.
3. in a medium bowl, mix graham cracker crumbs with melted butter
4. remove mixture from medium bowl and press mixture onto bottom of springform pan
5. in a large bowl, mix cream cheese with sugar until smooth
6. blend in milk
7. mix in eggs one at a time
8. mix in sour cream, vanilla, and flour until smooth
9. pour filling into prepared crust
10. place crust and mixture into preheated oven for 1 hour
11. turn oven off and let cake cool in oven with the door closed for 5-6 hours
12. remove cake from oven and chill in refrigerator

And of course, in healthcare, this can be even a little more complicated, because you may have multiple characters. If you do, then you just have to separate the characters based on the role they will play in achieving your policy standard. For example, if the policy goal is "All dance performances by Fred Astaire and Ginger Rogers will leave audiences happy", then your procedure might be :

A. Fred Astaire will :

1. approach Ginger Rogers on dance floor.
2. listen to current music
3. choose dance style that is appropriate for current music.
4. lead dance that is appropriate for music.

B. Ginger Rogers will :

1. follow dance led by Fred Astaire.
2. demonstrate amazing dancing.
3. smile for audience.

C. Audience will :

1. observe talented dance performance by two dance superstars.
2. applaud after dance performance is completed.

IN CLOSING 

Remember, the key to good policy and procedure writing is clarity. Less is often more. "Generous use of white space" is what was recommended to me once. It takes some practice, but once you learn the pattern to good writing, it doesn't need to take too long. In fact, you eventually get to the point where someone is discussing a problem, and you can start to envision the policy and procedure in the top of your head.

This is why good policy writers are worth their weight in gold - Good policies can help you make change, achieve clarity, and save your organization time and money. Bad policies do not make any organizational change, do not achieve any clarity, and will cost your organization in both time and money.

I hope this helps turn you into a policy ninja! Remember, use your powers only for good, and go out there and write good policy!

Would love to hear other people's stories about writing policy and how it related to their EMR implementations! If anyone has any questions, please let me know! :)

Are physician informaticists cost-effective?

Another common question you get asked in informatics, especially as a physician is, "Do we really have to pay a physician to do this work?"

This is certainly a valid question - In times when budgets are tight, it's important to question why an organization is paying a physician to do informatics work.

I'm going to present the case about why I think a physician informaticist is cost-effective.

I. BACKGROUND : HOW TO MAKE A CHANGE

The first thing you need to know, to understand the argument, is "How do I make a change?"

To answer this, I'd like to break down the roles you played when you sent your last email - After all, the purpose of all email is to help make some sort of change (either "to own a book from Amazon" or "to inquire about renting a house") :

1. Owner
2. Builder
3. Tester
4. Approver
5. Publisher
6. Monitor

"What's that?", you say? Yes, you actually did all of these roles.

1. Owner - You subconsciously decided, "I need to send an email" and "I will be responsible for what I write" and "I will follow-up on the success of the email."
2. Builder - Based on your decisions, you started to draft an email
3. Tester - You decided to proofread the email before you sent it, to see if it met your quality standards.
4. Approver - After proofreading, you decided "This email is good enough to use!"
5. Publisher - You published the email by clicking "SEND".
6. Monitor - You waited for a response and checked your return emails to see if your email was successful. If needed, you might go back to Step #1.

To make a change in a clinical setting, you basically have to do the same steps, but since you're doing it for someone else, there is a crucial extra step you will need :

1. Owner - Person who owns the tool
2. Builder/Informaticist - Person who designs the tool with the Clinical IT Analyst
3. Tester - Person who tests the tool to "make sure it works as designed" before approval.
4. Approver - Usually a committee who examines the purpose, and the testing data, and approves the tool for use
5. Publisher - Person who publishes the tool for use in the clinical setting (EMR or Printshop)
6. Educator/Implementor - Person who trains clinical staff on the tool - Educates them about how it's published (where to find it), and how to use it.
7. Monitor - Person who monitors the success of the tool after it's implemented, and troubleshoots any problems

And finally, to get to the full list of responsibilities required for designing / testing / implementing clinical tools in the electronic era - there are two last players we will need :

1. Clinical workflows are notoriously difficult to analyze, and so it's helpful to have a Subject Matter Expert, who answers detailed questions about clinical operations and evidence-based practices.
2. Clinical IT systems are very complicated (much more so than sending an email), and so we will need a Clinical IT Analyst to know the programming needed to build these clinical tools, together with the Informaticist. (This role was not needed in the "paper world".)

So this brings us to the final roles that need to be filled to make a successful change in the technologically-advanced clinical setting :


1. Owner - Person who owns the tool
2. Builder/Informaticist - Person who analyzes the workflows and develops standardized tools in conjunction with the Clinical IT Analyst
3. Clinical IT Analyst - Person who develops standardized tools in the EMR in conjunction with the Clinical Informaticist
4. Subject Matter Expert - Person who is responsible for knowing the details of the workflows and being able to cite evidence-based practices
5. Tester - Person who tests the tool to "make sure it works as designed" before approval
6. Approver - Person/committee who reviews the purpose of the tool and testing data and approves the tool for use
7. Publisher - Person who publishes the tool, after approval, for use by your clinical staff
8. Educator/Implementor - Person who trains clinical staff on the tool - Educates them about how it's published (where to find it), and how to use it
9. Monitor - Person who monitors the success of the tool after it's implemented, and troubleshoots any problems.

II. IF YOU HAVE A NON-PHYSICIAN INFORMATICIST :

If your institution has an informaticist who is not a physician, you might have the roles filled as such - Take, for example, the implementation of an order set for your Hospitalist group :

1. Owner = Hospitalist Director
2. Builder/Informaticist = Your non-physician Informaticist who works with your Clinical IT Analyst to build draft of tools
3. Clinical IT Analyst = Person who works with the Informaticist to build draft of tools
4. Subject Matter Expert = Hospitalist Director
5. Tester = Informaticist + Hospitalist Director
6. Approver = (Your order set committee)
7. Publisher = Your Clinical IT Analyst (who publishes the draft by moving it from TEST to PROD environment)
8. Educator/Implementor = Hospitalist Director
9. Monitor = Hospitalist Director

This is a perfectly acceptable setup, but your Hospitalist Director may not have time to fill all of those roles successfully :

1. Ownership - Deciding this does not take long, but...
2. Subject Matter Expert - This can take many meetings to help explain the clincal workflows and evidence-based practices - And depending on how much your director works clinically, he/she may have trouble answering detailed workflow questions.
3. Tester - This can take many hours reviewing tools and workflows and making sure they meet standards for approval - Again, depending on how much your director works clinically, he/she may not be helpful in testing the tool.
4. Educator/Implementor - This can take many hours explaining to staff how to use the tool and where to find it (especially if it's a new tool or something complex)
5. Monitor - This can take many hours to review the effectiveness of the tool - Are the hospitalists using it? Are they using it successfully?

And in a modern medical practice, the changes are coming fast and furious - Every time QA, or an insurer, or a regulatory body say "Jump this high or you won't get paid" - You will need someone to update/maintain all of those tools :

• All of the hospitalist order sets will need constant maintenance
• All of the hospitalist documentation will need constant maintenance (forms, notes, checklists, flowsheets, etc.)
• All of the fancy tools will need constant maintenance (clinical pathways, protocols, etc.)

Every time the FDA makes a change - You will need to maintain all of these tools.

It's a lot for a modern clinical director to manage.

III. ENTER THE PHYSICIAN INFORMATICIST (AKA "EMBEDDED INFORMATICIST" OR "CLINICAL JEDI")

The physician informaticist works with the Department Director to help save time and continously maintain the clinical tools for the department, to keep up with the myriad of evidence/regulatory/billing needs. By training a hospitalist physician in informatics practices, you can develop the following arrangement :

1. Owner = Hospitalist Director

2. Builder/Informaticist = Your physician informaticist

3. Clinical IT Analyst = Your person who works with the physician informaticist to build a draft of tools in TEST environment

4. Subject Matter Expert = Your physician informaticist

5. Tester = Your physician informaticist

6. Approver = Your (order set committee)

7. Publisher = Your Clinical IT Analyst

8. Educator/Implementor = Your physician informaticist

9. Monitor = Your physician informaticist

So in this way, your physician informaticist will play all of these roles :

1. Builder/Informaticist
2. Subject Matter Expert
3. Tester
4. Educator/Implementor
5. Monitor

ANOTHER OPTION : 

You *could* ask your Hospitalist Director to fill these roles, but you will have to pay him/her the salary for this time - Which, as Hospitalist Director ($250k/year?) is probably higher than the physician informaticist ($200k/year?)

ANOTHER OPTION :

If you have a non-physician informaticist, you *could* divide the roles this way :

1. Builder/Informaticist = Your non-physician informaticist
2. Subject Matter Expert = Your hospitalist director
3. Tester = Your hospitalist director
4. Educator/Implementor = Your hospitalist director
5. Monitor = Your hospitalist director

But again, this will mean :

• Having to hire a non-physician informaticist (This could be $50k/year for maintenance.)
• Having to pay your hospitalist director for the extra time it takes to fill all of those roles properly (Even at 0.1 FTE spent on that, that could be $25k/year for maintenance.)

The physician informaticist, by combining so many roles, saves a tremendous amount of time and money, and I believe you will have better maintained/updated/used tools.

By having a hospitalist trained in informatics, he/she can spend 0.8 FTE clinically, and 0.2 FTE on maintaining informatics for the hospitalist group and accomplish most of the maintenance very well, at a cost of about $40k/year for maintenance.

This then sets up the following structure :

1. Hospitalist Director = Makes all of the big decisions about "how things will be run"

2. Hospitalist Informaticist (aka "Physician Informaticist", "Embedded Informaticist", or my personal favorite, "Clinical Jedi") = Helps make Director's dreams a reality and worries about the details to implement them properly and quickly.

In this way, the Physician Informaticist becomes an essential tool of change. And because the tools are built by a hospitalist, buy-in problems are virtually eliminated.

So the next time QA says "Every hospitalist patient will need _________", the Hospitalist Director can work with his/her Hospitalist Informaticist, and relax knowing the details will be worked out, the tool will be rapidly changed, and the implementation will run smoothly.

IV. IN CONCLUSION

For all of these reasons, I believe the "Physician Informaticist" :

• saves both time and money
• improves change-management
• improves departmental accountability (by having an expert in the department managing changes)
• improves quality
• improves reimbursements

... and so, I see this as a rapidly growing role in modern medicine, especially in hospitals who are going EMR or have gone EMR.

Would love to hear any thoughts/comments! Feel free to leave your experiences with physician informaticists!