The problem of "Feature Bleed"

Another common question I get asked is, "What can we do to prepare for 'going electronic'?"

Most hospitals will, in these times, gather their order sets, in the hope of "making them electronic".

It's then, that you may notice the first problem. I like to call it "Feature Bleed".

"Feature Bleed" is when you have order sets that have pieces of :

1. Order sets
2. Protocols
3. Documentation

This is VERY, VERY common - Most paper-based hospitals aren't disciplined enough to have their order sets and protocols and documentation well-separated.

Take a look at your paper order sets - See something called "Advance Diet as tolerated" or "Up ad lib" or "Do not start any other CNS depressants without checking with the anesthesiologist first"? These are all protocols!

Take another look at your paper order sets - See something like "Write patent's PTT here : ___ ___ ___" or "Write patient's neuro checks q6h here : ____ ____ ____" - These are all documents!

Take one last look at your paper order sets - Are they labelled something like "Alcohol Withdrawal Protocol / Order set / Flowsheet"? This is a sign that you may have feature bleed. (Ask yourself which tab in the paper chart you have been putting this order set into - If you're not sure, that's a warning sign of "Feature Bleed")

How does this happen, and why is it so common? In the paper world, it's very easy to make an order set where :

[ Order set ] = [ Order set ] + [ Documentation ] + [ Protocol ]

The problem is, when you go electronic, you will have different places ("buckets") where you need to organize those things.

1. The "Order set" bucket
2. The "Protocol" bucket
3. The "Documentation" bucket

And to organize this, it will mean :

1. Significant redesign of your paper order sets
2. Significant redesign of your clinical protocols
3. Significant redesign of your clinical documentation

And to handle this? You'll need to define, for each of these informational tools :

1. A good policy definition of the informational tool (to help guide builders in the right direction and prevent future "Feature Bleed")
2. How will the informational tool be built? (By who, and how? What format?)
3. How will the informational tool be tested before it "goes live"?
4. How will the informational tool be approved in your organization?
5. How will the informational tool be published
6. How will the informational tool be tracked.

If your organization was very disciplined in the paper world, and you have good policy definitions of these tools, your conversion to EMR will go a lot easier.

And if not, you're like about 80% of the places I talk to. :) Just be prepared to deal with this organizational redesign issue at some point - Preferrably earlier, rather than later.

Why don't the order sets work anymore?

One of the most frequent questions I get asked is :

Q : Why is it so hard to make the paper order sets work in our electronic EMR?

Sometimes, this is accompanied by stares of disbelief, or better yet, a suspicious glance, wondering if I'm 'just making this up'.

Here's the sad truth : No, you can't just put the paper orders on the computer screen and make them work.

Why that is, is a complex answer. I'm going to share two simple ways of looking at it.

THE LINGUISTIC ANSWER :

Some people have tried to equate the electronic world and the paper world as "two different languages" - Anyone who has ever tried to translate between two languages will show you how difficult it is to translate idioms. E.g. "Hit the Road!", "Drop Dead!", "Happy as a clam!" are all idioms that don't translate too well into other languages.

This is where you see the cultural differences between electronic medicine and paper medicine - It just doesn't translate well.

The problem with this example is that people who aren't bilingual won't really appreciate this difference. (Many people seem puzzled to find out that the best interpreters are only about 95% accurate... Usually, 90% is good enough for most communication, so it generally works.)

THE INFORMATICS ANSWER : (Easier to understand, trust me!)

The Informatics answer to this question requires one to understand some basic premises of information science.

1. An order set is a group of lab and medication orders which can either be ordered, or not, depending on a physician's or nurses's decision when they execute the order set.

2. Clinical Documentation is something your clinicians will write on a piece of paper, or a form, to document what's going on with the patient.

3. Clinical Protocols are essentially "if-then" instructions that tell your staff how to react in a particular patient situation, to achieve a certain goal.

So here's the problem most people face when trying to translate from the electronic world to the paper world : Most "paper-based" hospitals have paper order sets with pieces of documentation and clinical protocols built into them.

Q : Huh? How is that possible? My order sets have policies and documentation built into them?!?

The truth is often : Yes.

Q : How did that happen?

Basically - Paper is flexible. You can write anything you want on it.

Computers are much more fussy about :

1. Where protocols go (read-only)
2. Where documentation goes (read/write, for your clinicians to use)
3. Where order sets go

Q : I'm still not sure I get it.

Let's look at this another way.

• On paper : [Protocol + Order set + Documentation] = All on one sheet of paper, often labelled "Order Set"
• Electronic : [Protocol] + [Order set] + [Documentation] = All go in different places in your EMR.

Q : So what do I have to do, then, to make my paper order sets electronic?

It takes work - To fix this, then, means someone has to separate your paper order sets into :

1. Clinical Protocols
2. Order sets
3. Documentation (Notes, forms, etc.)

Q : Can you give me some examples?

Sure. Let's make up a hypothetical order set - Not based in reality, I assure you, but not uncommonly seen before a hospital "goes live with CPOE"...

Sometimes on a paper order set you will see things like this :

[Line 1] ( ) Tylenol 650mg PO q6 hours PRN mild (1-3) pain

[Line 2] ( ) Percocet 5/325 (1) tab PO q6h PRN moderate (4-6) pain

[Line 3] ( ) Morphine 2mg IV q30 minutes PRN severe (7-10) Pain

[Line 4] These orders are only to be used in Emergency Department!

[Line 5] ( ) If O2sat is less than 85% check ABG STAT and call MD.

[Line 6] Please assess vitals and assess respiratory rate : ________ breaths/minute

[Line 7] If patient respirations less than 10 then give Narcan 0.4mg IV x1 dose STAT and call MD.

Let's examine this hypothetical order set above...

• Line 1 = Fine order. No problem putting this into an electronic order set.
• Line 2 = Fine order. Again, no problem.
• Line 3 = Fine order. Glad to see pain levels specified for patient safety! Again, no problem.
• Line 4 = Problem. By saying "These orders are only to be used in the ED", this is technically a clinical protocol. Essentially, it tells a nurse : "If the patient is discharged from the ED, these orders must be discontinued by a nurse."
• Line 5 = Similar problem. This is actually a clinical protocol. Needs to be written into a separate document, instructing a nurse what to do if the O2sat drops below 85%.
• Line 6 = This is also a problem, because it's clinical documentation. Needs to go on a separate form to work with this order set.
• Line 7 = Another clinical protocol. It also suffers from the problem : How do you execute an order for Narcan at some point in the future, when you're running this order set now? Again - This needs to be a clinical protocol.

So to fix this paper order set would require designing new documentation and new clinical protocols to function with this order set. You typically end up making a whole lot of new clinical policies and documents and need the committee structure that can handle this in a nimble way. Phew!

Q : This seems like a lot of work, isn't there some simpler way to do this?

It is a lot of work! And there isn't a really simple way to do this. If there were, hospitals wouldn't often look for specialist help to convert to the electronic world.

Next article, we'll talk about "Why didn't the vendor give us order sets that work?!?!". Stay tuned. :)

Occupational Hazards of the CMIO

In the last few weeks, I've had a few people ask me more questions about the CMIO role.

Q : "What do you do exactly?" - My parents

A : I implement computing systems and integrate clinical IT. (Makes perfect sense, right?) :)

Q : "Who do you report to, the CIO or the CEO?" - Many Healthcare IT types

A : I report to the CIO - But every CMIO has a different story to tell.

Q : "How do you handle those weird hours?" [in reference to trying to balance clinical time with administrative responsibilities?] - My friends (mostly non-healthcare types)

A : It ain't easy.

Q : "Are you a Chief Medical INFORMATION officer or a Chief Medical INFORMATICS officer?" - Mostly IT vendors or newspaper people.

A : For me - Informatics. I'm proud of the discipline I represent. Geek is cool. :)

Q : "Are you an 'IT doc'?" - Mostly IT vendors or clinicians.

A : Nope. IT is the hardware/software. Informaticists are the folks who implement the IT.

And my recent favorite question deserves a post of its own :

Q : "What kinds of problems do CMIOs have?"

There are a few occupational hazards to being a CMIO. Let me list some.

1. Jaw erosion : From the number of times you'll be explaining why "you can't take the paper order sets and just put them on the screen, it's more complicated than that."
2. Giddiness : From the number of times you'll be accused of "making this more complicated than it needs to be" or "You just made up that word 'informatics'."
3. Depression : From turning your passion for technology into a job, only to find out that the technology is the easiest (and smallest) part of the job.
4. Back pain : From the burden of trying to lift healthcare technology (and healthcare) into the next generation.
5. Angst : From the number of late nights you'll stay awake thinking about "How am I going to integrate all of these legacy systems when we don't have a defined exchange protocol?" and "How are we going to host and publish our clinical apps?" and "Will the docs like my new eSignature MLM?"
6. Eyestrain : From all of the regulations and policies you'll be reading.
7. Dry Mouth : From all of the regulatory and policy questions you'll be asking about and then discussing at many, many meetings.
8. Fatigue : After the "coolness factor" of being in a "new emerging job" wears off, you will soon realize that an enormous amount of sweat equity goes into implementing and maintaining all of these clinical systems.

On a more serious note, I think the hardest issues to contend with are the following :

1. Trailblazing - You're in a job that doesn't have well-defined characteristics! Exciting, right? As a result, there are CMIOs all around the country serving a very wide variety of roles. The fun part: You get to be a trailblazer. The hard part : You can easily work yourself into many, many projects that seem logical to accomplish the goal, which will keep you in the hospital/office for long days.
2. Regulatory / Compliance issues - I think a lot of CMIOs start their jobs because they "like technology". My opinion : This is the wrong reason to become a CMIO. Technology is only a small part of the job. Yes, you're there to "make the technology work", but on a day-to-day basis, you're very removed from the technology. Regulatory and Compliance questions are a mainstay of all clinical integration. When you're mapping out new workflows for your CPOE, you have to be prepared to deal with all of the "messy details" of CMS and The Joint Commission. Prepare to read a lot of regulations, many of which will be vague and outdated, and prepare to make your best estimation of "how things SHOULD work". (The take-home point : It's not going to be as much fun as buying a new iPad and loading your favorite apps onto it!) :)
3. Finance Issues - While a lot of CMIOs have a "dream list" of "what we would like to have happen", often there are budgeting issues to contend with. You'll be helping to decide on projects. You'll be helping to prioritize. But ultimately, you'll be a one-stop-shopping for upset clinicians, and sometimes not have the budget to meet every demand. Part of your job : Help manage the expectation and delivery of different projects.
4. Politics, politics, politics - The job is highly political. Every CMIO has stories of "personality management" and careful delegation that went into their EMR/EHR selection process. Expectation management is also a big part of the job - Many clinicians look to Healthcare IT as a "magic bullet" to prevent everything from med errors to infections to cardiopulmonary arrests. Your job : Make sure people have reasonable expectations about your technology.
5. Education - Most hospitals, after implementing an EMR/EHR, find themselves needing more clinical education resources than ever before. You'll be working on a lot of education pieces, and trying to distill the right message for the right clinicians. And you'll be doing a lot of education yourself, both in meetings and in classroom / training room settings. You'll be teaching everything from CPOE and informatics, to new workflow designs, to statistical data analysis and database queries.
6. Vendor / Technology burnout - The unfortunate truths : Sometimes vendors over-promise. Sometimes government certification committees change their mind. Sometimes clinical circumstances change. Sometimes statewide and national IT initiatives are poorly coordinated. Sometimes certification committees make fast, hard decisions to try to achieve a national goal. Implementing effective solutions can be tough! It's like trying to hit a rapidly moving target while you're standing on a ship in stormy seas. You'll start to ask questions like : "Can anyone deliver on any promises?" "How the heck did we get the telephone to work?" and "I'm amazed that we agreed on 110 volts in all regular houses!".
7. Acronym / Informatics Burnout - Do you have an EMR or EHR? Is ONCHIT or CCHIT in charge of your destiny? What does ARRA say? What about CMS? Do your Dragon voice templates use a push or pull model? Who's connecting your local hospital, a HIE, RHIO, or REC? You'll be learning new acronyms and learning a new language every day. You'll even be going to conferences just to learn the difference between the different acronyms. And then you'll have to translate this new language for your administration and your clinicians.
8. Order Sets, CPOE, Clinical Documentation, Health Information Management, Meaningful Use, Protocols, Data Dictionaries, Workflows - There's a reason no informatics folks are on any primetime medical dramas - It sounds painfully boring. (Can you imagine House, MD, at his next case : "If the damn admission order set were built right, we would have diagnosed this dextrocardia earlier!") :) If the idea of discussing the oevre and gestalt of your General Admission Order Set sounds painful, then this may not be the job for you.

And then, at the end of the day - You think back on all of those early technology innovations. Like AC current. Like 110 volts. Like American Standard plumbing. Like Rotary and touchtone telephones. Like traffic lights. Like driving on the right side of the road. Like the first IP packets being sent over ARPANET. And you think back : Some unsung heroes in past generations worked through all of this to make it a national (or international) standard for us today.

And that's when you get the reward of knowing : I'm helping to build the healthcare delivery model for our children. Maybe it's worth the occupational hazards.

Go into the field at your own risk. :)

So you want to be a CMIO?

So I recently had an interesting discussion with a physician actually asking me, "How do I become a CMIO?".

So far, all of the other CMIOs I know have very interesting stories about how they got into the position. Most of them sound more like accidents than planned career choices, mine included.

Still, I'm totally happy being a CMIO. Yes, it's tough. The hours, balancing clinical and administrative time, can be brutal. And sometimes you feel like you're endlessly herding cats, trying to get people to play nicely as you move your EMR implementation forward.

So I thought tonight I'd write a little bit about the CMIO role.

Question 1 : "What does it take to be a good CMIO?"

I think there are some personality traits that are conducive to being a good CMIO.

1. First, you have to believe in change. And you have to know, and accept, a basic truth : Change is hard. It it was easy, people wouldn't be interested in paying you to do it.
2. It also helps to be nice. If your personality is too strong, people will see you as authoritarian and paternalistic. If you're too weak, you'll never get anything done. You want to be the middle of the road. Top of the bell curve.
3. You need to be able to tolerate ambiguity. If you're the sort of person who needs an idea super-well formed, before you start working on it - You'll never survive. If you're the sort of person who needs every hour of every day planned out - You'll never survive.
4. You need patience. A lot of the job deals with policy and regulatory minutiae. If the idea of writing policies or reviewing CMS regulations makes your skin crawl, this may not be the job for you.
5. It helps to be super-passionate about technology. While Informatics is, in itself, not related to IT (a common mistake!) - It really is important to embrace technology, warts and all.
6. A good CMIO knows when to be detail oriented, and when to let go. Part of the skill is knowing when to be which.
7. A good CMIO is an awesome teacher. There's a big difference between people who call themselves teachers, and people who are teachers. Real teachers are a valuable commodity. Remember, we're all students and teachers all our lives. CMIOs are committed to real teaching.
8. A super-talented CMIO will have "Jedi Skills" when it comes to personality management. Sometimes you have to negotiate politically between competing clinical areas, to reach an agreement, and this can mean some tricky political discussions. They should strive to be as Yoda-like, or Obi-Wan-like, as possible, when it comes to these discussions. Being forceful right out of the gate is often a big mistake. Subtlety and humor are two powerful tools, if used the right way.
9. Finally : It helps to keep a foot in the door clinically. While it's not entirely necessary, realize that the currency that a CMIO spends, to get the job done, is physician buy-in. If the physicians don't respect your opinions, you'll have a hard time.

CMIO magazine recently had an excellent article on CMIOs : Who are they, where did they come from, what do they get paid, etc : See it at http://tinyurl.com/yabcdb9 (or via their web site at http://www.cmio.net ) I highly recommend reading this article if you're considering moving into a CMIO position.

Question Two : "How do I get myself into a CMIO position?"

This is the hard part. Most CMIOs I know have stories about falling into the position. Either they were hired almost by accident, or they were the "loudest complainers" in their hospital, or they were super-involved in their IT department meetings. I think they all share a common pathway : They demonstrated real passion and commitment to change.

The reason it's still hard, is because of the common budgeting pitfalls :

1. Most hospitals don't know what a CMIO is.
2. Most hospitals aren't really sure what Informatics is, so they don't budget for it. (The truth : Most hospitals lump informatics together with IT.)

So when you go looking for a CMIO position, they don't happen often. An organization looking for a CMIO will generally be progressive, have a good understanding of what Informatics is, and have budgeted for informatics. If they didn't do all three, they probably aren't going to be looking for a CMIO.

So my advice : Look for a progressive hospital that knows what Informatics is. And they probably will either have a CMIO, or potentially be looking for a CMIO. And if you're already at a hospital that needs a CMIO, you can create the position by first spreading the word of how important Informatics is for your EMR implementation, and then let your current leaders create a budget for this. (Then recommend yourself for this position.)

That's how a lot of people got into the position - They were active and vocal when the hospital realized they needed someone to help implement their EMR.

Next post, I'll talk about some common pitfalls for CMIOs, and how you can rapidly get seasoned in this new, emerging position.

Medicine Reconciliation and Chaos Theory

So a lot has been written about "What is Medicine Reconciliation?"....

What exactly is this beast?

Yes, medication errors have been reported (such as in this article) to affect 1.5 million people every year (according to the Archeives of Internal Medicine), costing between $77 billion and $177 billion a year.

How do these medication errors occur? Because little is actually known about the information flows for medicine reconciliation.

Here's the problem : Nobody has a good plan for organizing enough to answer the question, "What meds is the patient actually on?"

Here's the scenario : A 60-year-old male shows up in the Emergency Room needing urgent care.

You're the doc responsible for this patient. How are you going to figure out what meds the patient is actually taking?

Potential sources of data include :

1. The patient - Works for some patients, but many don't know the details of their meds.
2. The family - Works for some, but many don't know the details of the patient's meds.
3. The PCP - Works sometimes, but may not know what the specialist prescribed last week.
4. The Specialist - Works sometimes, but may not know what the PCP prescribed last week.
5. The Pharmacy - Works sometimes, but many pharmacies close after 5pm, many aren't electronic, and a lot of patients go to many pharmacies (including mail-order)
6. Electronic "Insurance databases" - Works sometimes, but mainly only with insured patients - Doesn't work if the patient pays out-of-pocket
7. Herbal medications - Often missed as a data source
8. The old hospital record - Sometimes helpful, but sometimes out-of-date. Also remember, except for the VA, virtually no hospital shares pharmacy data with the outside PCPs.

So which of these data sources are you going to use?

What you start to realize is - It's almost impossible to know with 100% accuracy what meds a patient is on.

(Well, maybe in a best-case scenario : A well-educated, non-intoxicated patient, only on one or two medications - Maybe then, you can achieve 100% accuracy. Outside of this scenario, you're generally working at 95% accuracy or less.)

So for the majority of patients, you will never achieve 100% accuracy.

So you have to ask yourself - What level of accuracy is acceptable?

I'm proposing a new standard, which I lovingly call : The Mother Standard.

The Mother Standard is "The amount of data you would collect to achieve a level of accuracy that you would find acceptable for your own mother, knowing that 100% is impossible." I figure, for most people, this is a level of accuracy of >95%.

And this is my proposal, for an acceptable way to perform Medicine Reconciliation to the degree of the Mother Standard (>95%) :

Step 1 : Ask the patient what meds they are on - Including herbal medications. If you, as a clinician, do not feel you've met the Mother Standard - Proceed to step 2.

Step 2 : Ask the family what meds the patient is on - If still not the Mother Standard, proceed to Step 3.

Step 3 : Ask the pharmacy(ies) what meds the patient is on - If still not the Mother standard, proceed to Step 4.

Step 4 : Ask the PCP what meds the patient is on - If still not the Mother Standard, proceed to Step 5.

Step 5 : Ask the specialist what meds the patient is on - If still not the Mother Standard, proceed to step 6.

Step 6 : Check the old hospital/office chart for what meds the patient is on - If still not the Mother Standard, proceed to step 7.

Step 7 : Check the electronic insurance report - If still not the Mother Standard, then at least you can say you made every attempt to achieve the Mother Standard, and were unsuccessful.

So why are there so many errors nationally, every year? Because patients who don't have their meds clearly tracked require an enormous amount of work, just to try to get to the Mother Standard - And in some cases, it's just impossible.

Looking at the coordination of care among multiple specialists, sometimes even multiple PCPs, and hospitals - If the patient, or their family, does not keep track of the meds - Then achieving the Mother Standard is virtually impossible.

Fortunately, doctors are trained to work with incomplete information, but when incomplete information isn't enough, we have to ask ourselves : Who can fix this?

I'm hoping that SpeakFlower (http://speakflower.org) helps our country move into this realm, gradually.

Anyway, I'm hoping to do some research into the time it takes to reach the Mother Standard. Will try to publish what I can shortly. Stay tuned.

Seven things to watch in 2010

Since we're at the end of the year, I thought I'd give you seven things to think about in 2010. These are trends I see happening in healthcare IT, especially with the Meaningful Use criteria upon us. Remember, my list is free, and you get what you pay for. :)

1. Embedded Informaticist - If you don't know what this is today, you will soon. These are the key, crucial people you will need to make your EMR and CPOE efforts work. Without them, your C-suite will eventually confront : Do we rewire our hospital's departments, policy mechanism, and educational/training mechanism, or do we unplug our EMR? Having a good CMIO will help you organize them. Look for a labor shortage in Clinical Informatics as soon as the ink dries on Meaningful Use. Look to the AMIA 10x10 class to help you grow your own embedded informaticists. If you don't have them early in your EMR/CPOE/clinical documentation implementations, you will eventually throw your money away.

2. "CMIO" versus "Physician Champion" - Many places confuse the two. Confuse them at your own peril. In 2010 a lot of places will be learning about the difference between the two.

3. Flower - This project is noble and has teeth. I'm one of the early architects, so how can I not tout it? If you're not sure what Flower is, it's basically a way of cutting through chaos and competition, and developing a clear national healthcare IT standard so that patients medical information is more portable and accessible. We're developing the technical details and marketing. The point? It's going to be a patient-led effort to organize healthcare. Remember : The patient is the boss. Ignore them at your own peril.

4. Confusion - Meaningful Use should be ready soon, and the political landscape is shifting RAPIDLY. The Beacon Communities funding opportunities will be forging new healthcare landscapes and political alliances that nobody ever thought possible. While all of this is promising, how it will actually pan out, and who will not be able to keep up, is harder to predict. Should be an interesting year.

5. Transparency - I see healthcare as needing to become more transparent - The patients are demanding it. Prepare to open balance sheets, have frank conversations that you never thought reasonable, maybe even (gasp!) doctor/administrator/patient partnerships to help build a better community. With healthcare reform in the air, partnerships will be crucial. If your organization isn't politically nimble enough, or your C-suite doesn't get energized on this, the next few years will get more difficult.

6. Healthcare shortages - While most of the healthcare reform seems to be focused on proving more access, little else other than HITECH has any muscle to improving efficiency or costs. As the baby boomers age, we don't have enough resources to provide the care they grew up with. The current healthcare bills don't address tort reform, and in my opinion both the House and Senate bills lack the muscle to turn around our current system. In my head, the bills are like a tiny parachute trying to stop a car from hitting a brick wall. The problem : Some people will point to the bills (tiny parachute) as the "reason the car hit the brick wall". A bigger parachute would help, but in our current system we don't have the political support for that. I expect the "give more access and don't fix the efficiency" approach will be a problem. Be ready for a lot of people to point to the tiny parachute as the reason the car hit the wall.

7. Patient-led reform - As I described in #3 above, the patients are our bosses - Ignore them at your own peril. I'm very impressed with the ePatient initiatives - The patients are figuring out why healthcare isn't meeting their needs - We're all too busy competing! (It's important that they know - They're the boss!) I anticipate the ePatient movement will continue to grow as social media allows them to organize and discuss their beef with modern healthcare. Look for the strong leaders in this movement to accomplish what government and insurance companies and healthcare can't. ePatient leaders also help educate the many, many people who have strong opinions about healthcare reform who actually have little actual experience with healthcare. If there is one place healthcare reform can happen, it's in the ePatient political arena. If I had to fix the nation's healthcare, I would look to some of these people to help lead the political movement, and partnerships between them and front-line clinical staff will be crucial. They have political clout nobody else has.

That's it for now - Hope everyone had a good 2009, and let's all work together to make our good healthcare system even better in 2010!

Flower Power

So a few months ago, myself, and two of my healthcare IT colleagues, Kipling Morris and Nicholas Boisjolie, were sitting around discussing, "Why don't we share information effectively in healthcare?".

As we traced down the multiple reasons, they boiled down to :

1. Government regulations

2. Poor implementation of current healthcare IT technology (many hospitals lack the informatics support to use their EMR well)

3. Competition between EMR vendors.

4. Competition between hospitals.

5. Competition between doctors.

6. A lack of a common standard technical "Esperanto" to let the data flow.

Google Health and Microsoft Healthvault have "cloud-based" EMRs (generally called a PHR - Personal Health Record) - And there are SOME hospitals which transfer their data to these, but it's mainly because Google/Microsoft developed partnerships with these particular hospitals, and invested heavily in developing electronic interfaces.

Still, these required a significant effort to get these places up-and-running. And the rest of us? We would still hypothetically have to send our paper reports to a scanning company who will then make it electronic and transfer it to Google Health / Microsoft HealthVault.

Even though there are a handful of common protocols (.CCD - Continuity of Care Document) and .CCR (Continuity of Care Record) - Most EMRs don't have a standard way of sending the data to these PHRs.

So Kip, Nick, and I were talking about the lack of communication, and how it impacts patient care. We are working hard to improve this, but it seems to be an uphill battle, frought with issues :

1. Political issues
2. Financial issues
3. Educational issues
4. Technical issues
5. Regulatory issues
6. Clinical issues

So we then wondered - Suppose we even DEVELOPED this electronic healthcare "Esperanto" - How would we get all hospitals to start using it?

(If I were a patient, I would want a hospital that spoke this language!!)

So then we wondered : "Why don't patients ask for this?"

The obvious answer : Patients know there is difficulty coordinating their care electronically - And they want better - They just don't know how to help a hospital do this better. (The technical standard to do this would be quite complex!)

So then we wondered : How can a patient ask a hospital to use a particular electronic standard?

And then we thought : What if we gave a NAME to this technical standard - So that a patient could ask for it?

Then we started to imagine : What if Wilford Brimley had a commercial on the Superbowl, where he talked about a hypothetical standard for information interchange : Flower.

"I almost had a medication error because my primary doctor didn't know what my cardiologist had just ordered... And then I almost had an extra echocardiogram in the emergency department because they didn't know what my cardiologist had ordered. But now, with Google Health, powered by FLOWER, all of my doctors can trade their information easily!"

This would introduce the American patient to some concepts :

1. Medication errors happen because of poor information interchange.
2. Extra tests happen because of poor information interchange.
3. Flower is a way hospitals could trade information better.
4. Sharing information better could improve their healthcare.

So then, we imagined : What would happen if patients started asking for Flower by name :

"Dr. Stanley, does your office speak Flower?" "Dr. Stanley, does your hospital speak Flower?"

1. Patients would suddenly show up asking for Flower.
2. Front-line doctors would suddenly start asking administrators about Flower.
3. Hospitals would start asking their EMR vendors about Flower.
4. EMR Vendors would suddenly hear a lot about Flower.
5. To remain competitive, EMR vendors (even legacy systems) would need to speak Flower.

I shared the idea a bunch of times on Twitter, with almost nobody noticing, but it was during a particularly passionate blog thread about patient care where I re-posted it, and suddenly, the idea caught on.

So, it appears I've launched a healthcare technology revolution.

For it to be successful, however, this has to be patient-focused.

We've already given it the formal Twitter hashtag : #hcflower

Keep your eyes peeled - We'll see where this goes...