Daniel Essin, MA, MD

Recently I've mentioned two Institute of Medicine (IOM) reports (“To Err is Human” and “Improving Diagnosis in Health Care”). If you’ve read them you know that, although a great deal is known about medicine, our knowledge is woefully, unavoidably incomplete. This, coupled with the fact that patients refuse to get sick in the ways the textbooks say they will, interferes with accurate diagnoses. You also know that even with best intentions, errors are difficult to eliminate. It will require more people and assistive technology if the error rate is to significantly reduced. In short, the expectations of both practitioners and the community at large are greater than what is possible today. We are, quite simply, limited by a lack of knowledge, too few people and not enough money. Our ‘eyes’ are bigger than our ‘stomachs’.

A long-time colleague of mine has, of late, begun to think about this subject and had an epiphany. He independently arrived at conclusions similar to those of the IOM. He contacted me excitedly with the idea that we could develop a ‘killer app’ that would address some of the problems. This was my response to him:

I have followed this field pretty closely, always from my skeptical and increasingly philosophical point of view. I have watched the software that Octo Barnett and Homer Warner created, and other stuff that mimicked theirs, as time has passed. The names applied to the apps have changed regularly but there has been little evolution and only rarely has a new species appeared on the scene. What today’s apps can do is severely constrained by their inheritance. That’s why all the big players sell ‘legacy systems’ - legacy is another word for inheritance. For all the reasons enumerated by Daniel Kahneman, people can’t bring themselves to abandon their inheritance: Greed, risk aversion, sunk cost fallacy, etc.

One might also say, with some justification, that it would be unwise to abandon their legacies and cash flow without an idea of what to do differently/better. It is my contention that the initial designs of these systems was 

 and pragmatic. The pioneers (understandably) built the first thing that came to mind that seemed to fall within the scope of what the available technology could support and was likely to perform some useful function immediately. The designs were not based on theory - there wasn’t any. The developers had administrators breathing down their necks and had to produce results. Taking the long view would have interfered. Octo says much the same thing in his undated piece, “History of the Development of Medical Information Systems at the Laboratory of Computer Science at Massachusetts General Hospital”.

In particular, the great failing of the early (and hence current) designs is that, rather than unifying the creation of records that succinctly describe the patient’s condition and treatment with the collection of the specific, discrete data elements needed for process-control and analysis, they treated the two as separate subjects. The majority of effort was concentrated on data collection (it’s what computers do best and easiest), while documentation was an afterthought forced to ride in the system’s rumble seat.

Now people are confronting the truth. The data that is being collected is divorced from its context. Its meaning is difficult to ascertain with certainty even immediately after collection and whatever meaning it might have will have a very short half-life.

Take a physician order as an example, the order-entry system creates the context necessary for the order to be processed. It is sent along with sufficient identifying information to the pharmacy that, in turn, know what to do with pharmacy orders. There is little certainty, however, that the doctor ordered the correct med. The system may (as does Cerner at the County) display every drug that can be ordered by any user of Cerner anywhere in the country. There is no indication which meds and which dosage forms are available at our pharmacy - you just have to ‘know’. That kind of unwritten context may work in the short-term but who, 10 years from now, will appreciate the subtlety of the challenge facing the doctor and imagine what mistakes might have been made to account for the otherwise inexplicable data than drug x was prescribed, and perhaps administered instead of drug y.

Kahane from Harvard is a prominent exponent of big data and how it’s going to make the future of medicine bright. All that is required to realize big data’s promise is to overcome about two dozen poorly understood technical hurdles, and a few sociological ones), something he believes likely in the near future.

I dream of the same goal. I just don’t believe it’s possible to realize that goal by continuing to follow the same path that has failed to fulfill these expectations in the past. It’s a bit like the search for the Northwest Passage. We had to wait for a new paradigm (global warming) to assert itself. Once the ice clears, and when medical records contain material that is equally meaningful to both people and machines, the prospects of reaching both destinations will improve greatly.

People regularly lament diagnosis and treatment errors and have ideas about what could/should be done. The merit of many of those ideas is almost self-evident. How to get there, not at just an isolated institution, but globally, is not evident at all. In my opinion it would be next to impossible today to build a generalized ‘killer app’ that would be game-changing and, even if it was possible, the likelihood of it being a success given the regulatory environment and the state of the market is low.

My hypothesis is that the current systems will ‘hit the wall’ in the not too distant future. The trigger-event will be the advent of some new technology (or regulation) that forces that many systems need to be replaced in a short span of time with ones (that don’t exist) that meet new/different requirements. What paradigm, what theory and principles will inform the design of these new systems? At the moment there isn’t one, except for what I’ve written about in this blog, and on that subject I’ve said about all I have say. It’s all there in the archive should anyone care to reread or study it.  

For this reason, I’m shifting my attention away from analyzing and discussing the already obsolete systems of today. Instead I will attempt to articulate a theoretical framework that might be useful when it comes time to develop that next generation of systems. That will take some time and a lot of effort, so it’s good bye for now. I’ve enjoyed the writing. I hoped you’ve found the articles informative or provocative.

Au Revoir, Sayonara, Hasta la vista, Arrivederci

Articles

The promise of technology in healthcare has yet to be realized and it will take a paradigm shift to get us there. 

The EHR Game Has Yet to be Decided

, and I'll take the low road, And I'll be in there afore ye”

There isn’t any data that’s so important that I would disrupt a practitioner’s life or spend $150 billion to collect it. The purpose of interoperability (interop) must be to help physicians take care of patients. HIMSS (Healthcare Information and Management Systems Society) 

“Interoperability describes the extent to which systems and devices can exchange data, and interpret that shared data. For two systems to be interoperable, they must be able to exchange data and subsequently present that data such that it can be understood by a user."  

Unfortunately talk is cheap. If you listen to the regulators and pundits, they more concerned about collecting and exchanging structured (discrete) data between systems than they are exchanging information between practitioners. You remember (of course) that data is not information. Information is facts in context. Data are the result of transforming and simplifying information to satisfy specific needs, usually to support specific processes, such as ordering.

EHRs (I can't say this often enough) are not primarily medical records, they are elaborate data collection and process control devices. It's true that somewhere within their bowels one can find narrative notes and other materials that contain sufficient context to constitute information, but the systems have little ability to make any productive use of it. That’s why they insist that the staff duplicate their work on data entry screens.

My interest is to have access to a patient's prior notes, lab reports, and images. Once I have read the past history and understand its implications, I rarely need to look at those records again. I may summarize what I have learned or perhaps copy a few salient sections and include them in my notes, but the bulk of the prior records will have served their purpose. Hence there is no need to import them into my system and store them forever. Think about it. How often do you look at last night's I/O or vital signs? When following serial electrolytes how often do you look at the values from last week? If a patient has had an uncomplicated surgical procedure such as an appendectomy, how likely are you to read anything but the operative report and discharge summary?

So… how do we get there from here? "There" being "presenting the old records in a way that can be easily understood by a practitioner." Well, we can get there the hard way (high road) or the easy way (the low road). Imagine that I want to get from my house to the one directly east of me - the distance is approximately 100 yards. I have two choices: 1) I can walk out my front door and across the street. 2) I can walk out my back door and travel 20,609 miles (the circumference of the earth at my latitude) in a westerly direction until I reach the house across the street.

1) Display documents that the practitioner can read or

2) I can decompose the contents of those documents into thousands of fragments (called structure data) each of which has to be defined and agreed to in advance. Then transmit those fragments, one at a time, to a receiving system where a process examines each fragment and finds a suitable location in which it can be stored (if one exists). Then reassemble them into a human readable form.

- Does the source of the material have the patient’s permission to send it?

- Should the incoming data be trusted (considered equivalent in every to values your institution might have generated) or should be viewed skeptically?

- How long should imported data be retained?

- Should the material be “pushed” whether or not someone needs it or “pulled” on request? If pushed, how will the practitioner be notified that there is material available to view?

Since a picture is worth a thousand words, here are pictures of the two roads. Which one would you take?

********************************************************

--><component><section><code code="10153-2" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/><title>Past Medical History</title><text><list><item><content ID="a1">Asthma</content></item><item><content ID="a2">Hypertension (see HTN.cda for details)</content></item><item><content ID="a3">Osteoarthritis, <content ID="a4">right knee</content></content></item></list></text><entry><Observation classCode="COND"><code code="39154008" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="clinical diagnosis"/><effectiveTime value="1950"/><value xsi:type="CD" code="195967001" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Asthma"><originalText><reference value="#a1"/></originalText></value><reference typeCode="XCRPT"><ExternalObservation><id root="123.456.789.23.17"/></ExternalObservation></reference></Observation></entry>

MSH|^~\&|LCS|LCA|LIS|TEST9999|199807311532||ORU^R01|3630|P|2.2
PID|3|2161348473|20923085580|01572633|20923085580^TESTPAT||19730204|
M|||^^^^00000-0000|||||||86427531^^^03|SSN# HERE
PV1||I|^802^1||||8625^Physician^Michael|86-7468^||xxx|||||||||V1001
ORC|NW|8642753100013^LIS|20923085580^LCS||||||19980728000000|||PEED
OBR|1|8642753100013^LIS|20923085580^LCS|083824^PANEL 083824^L|||19980728083600|||||| CH13380|19980728000000||||||20923085580||19980730041800|||F
OBX|1|NM|150001^HIV-1 ABS-O.D. RATIO^L|||||||N|X
OBX|2|CE|001719^HIV-1 ABS, SEMI-QN^L||HTN|||||N|F|19910123|| 19980729155700|BN
NTE|1|L|Result: NEGATIVE by EIA screen.
NTE|2|L|No antibodies to HIV-1 detected.
OBX|3|CE|169999^.^L||SPRCS|||||N|F|||19980728130600|BN
NTE|1|L|NOTE: Submission of serum
NTE|2|L|separator tube recommended
NTE|3|L|for this test. Thank you
NTE|4|L|for your cooperation if you
NTE|5|L|are already doing so.
OBX|4|CE|169998^.^L||SPRCS|||||N|F|||19980728130600|BN
ZPS|1|BN|LABCORP HOLDINGS|1447 YORK COURT^^BURLINGTON^NC^272152230|8007624344

When it comes to interoperability, there is a high road and there is a low road. Right now, we’re forcibly getting the low road.

Interoperability: The Hard Way or the Easy Way?

Interoperability (interop) means different things to different people depending on their technical knowledge, background, and objectives. The most common definitions relate to the (relatively) instantaneous transfers between geographically separated locations. I’ll call this spatial interop. Depending on your circumstances, spatial interop may be critical or irrelevant. It may, for example, be more important to ensure continued access to information you have gathered as time passes. I’ll call this temporal interop. To meet my needs as a physician, I find spatial interop to be trivial. The real challenges are posed by the continuous and rapid changes to the underlying technology that have the effect of making today’s information inaccessible in the future.

First, let’s consider spatial interop. I want access to records of care the patient received in the past with minimum time and effort. In the old days (before EHR), I knew how to do this. It involved using the phone, the fax machine, and sometimes, the mail. I have even gotten the access I needed by driving to another facility and reviewing the records.

Then there is temporal Interop. Apparently many physicians would like to switch products. Will they be able to migrate the contents of an existing EHR to a new one? This should be the first question you ask an EHR vendor but it is rarely asked until it’s too late. In my experience, physicians that have expected to preserve their records during a migration have been seriously disappointed. Some have ended up losing everything.  If you don’t think this a problem, try to open a Word or PowerPoint document from the early 90s in the latest Microsoft apps. Neither Microsoft, Apple nor your EHR vendor have any real interest in you and your data. Their interest is to lock you into their ecosystem. Just look at the ELUAs (End User License Agreement), e.g. “ITUNES TERMS AND CONDITIONS: The Graphic Novel” instead [

Practitioners trust their vendors to provide both types of interop, but that trust is misplaced. Vendors have even less incentive to facilitate an exodus from their product than ensuring it interoperates spatially (with other vendor’s products). Not only don't practitioners and patient care really matter to vendors, they don’t really matter to federal regulators either. The regulatory definition of interop is that it takes place between machines, not between people.

When interop works, look below the surface you will discover a simple standard. For  example:

• Every car that uses unleaded is built with a filler opening that matches the diameter of the pump nozzle. Leaded gas and diesel nozzles don’t fit.

• In the U.S., 15 amp 110 volt AC outlets all use the same pattern and appliances that draw 15 amps or less use a matching plug. There are other patterns for other voltages and higher currents.

• Virtually all email messages conform to RFC 2822, the Internet Message Format.

• PCs have expanded because IBM made a simple electrical “bus,” an interconnect scheme that allows add-on cards to be plugged in, part of its original design. The bus has a simple specification. When IBM tried a second time with the Micro-Channel bus, it flopped; the specification was too complicated and expensive to implement.

What do these successful standards have in common that correlates with their success? They define a simple structure (like drawing a line down the middle of the road or the diameter of a fuel nozzle). The Internet Message Format specifies how to delineate those portions of the mail message that carry the sender, recipient, subject, etc. They don’t specify who the recipient is, only how to flag it so that the email server can find the address. These standards work because they are “content agnostic.” They can applied widely and readily accommodate new content and, new content doesn’t invalidate existing content so no “conversion” is required every time new is introduced.

Simple structure-based standards can be defined, agreed, put to use, and then “put to bed” so to speak. When this has been accomplished, the foundation for interop is laid. You can bring a British car into the US and it’s your problem how to figure out how to drive it on the right.

Healthcare standards concentrate on defining specific content, creating more problems than it solves:

• Not everyone needs or cares about the same elements.

• Even if they do, their system may not contain them.

• Even if they do, the meaning is not guaranteed to be consistent.

• The process of adding content items to a standard is so laborious that all of the “essential” items have not yet (after 25 years) been addressed.

• Had they been, many would be obsolete and irrelevant by now.

• Tomorrow will bring with it new ideas, changed agendas, and the need for elements that were never dreamed of before.

The job specifying the content can NEVER be finished. The kind of interop envisioned by bureaucrats, finance types, and regulators that depends on specific data element will NEVER be achieved. Their fixation on data elements is interfering with achieving the kind of practical interop that physicians need - the ability to access the patient’s medical records. I’ve said this before and I’ll keep saying it until people get the message.

The kind of EHR interoperability envisioned by vendors and regulators will never be achieved and is not practical for healthcare. 

Bureaucrats Will Never Achieve EHR Interoperability 

This is true whether IT refers to information technology or just "it."  What is "it?" It's the "it" in the movie, "Oh, God" with George Burns and John Denver         .

Well, have you read the papers lately? It ain't workin'!

That's why I came - to tell everybody I set the world up so it can work. Only it's up to you. You can't look to me to do it for you.

It ain't workin' in healthcare either. Everyone gripes that there is inadequate interoperability. To a doctor, interoperability means being able to find out what happened prior to the time the patient arrives at your door. Doctors can achieve interoperability without fancy systems or mountains of regulations. It only requires telling (writing) a clear, concise, meaningful narrative that tells the patient’s story: Who, what, where, when, how and why and then, either giving it to the patient or sending it when requested.

 To regulators and expert panels, however, interoperability means something else -it means that everyone collects the same pre-defined elements, regardless of whether they are correct, relevant, or meaningful. This sounds nice, but in practice it’s impossible. The universe will reach the end of its life before a task like this is completed, and until it’s complete, people will always be griping about the lack of interoperability because their pet data element hasn’t been addressed yet.

Committees (the way these things are decided) can never arrive at a useful end-point. As interested parties join the committee, the number of opinions grows exponentially. To avoid endless conflict, hardly anyone dares to say what they actually think. So what happens is that someone with an agenda commandeers the group and everyone else ends up just nodding their heads in agreement. When the meeting ends and people get out in the hall, their real opinions come spewing out to no effect.

 It's also not working for the healthcare process. Procedural errors of all sorts abound. Humans can only keep track of about seven things at once, not hundreds. These were detailed by the Institute of Medicine (IOM) in 1999 ("To err is human"). In response, more committees were formed. Quality improvement projects were undertaken. Some produced local, limited improvement, but being resource intensive, none are guaranteed to be permanent. The good ideas don’t automatically become part of the nationwide standard of care. In fact, hardly anyone else even knows about them. In the past 15 years, in spite of having made errors a big deal, very few classes of errors have been structurally and permanently eliminated from the healthcare system.

 Errors of the kind discussed by the IOM in 1999 should be easy to remedy compared to the "diagnostic errors" described in the latest IOM report ("Improving diagnosis in healthcare" 2015). The new report identifies practically every factor that might lead to a diagnostic error. To reduce the errors all that needs to be done is for someone (God?) to change virtually everything - the complexity of the human organism, the kind of uncertainties introduced by the environment, the way medicine is taught and practiced, and the way doctors and patients behave.

These reports have defined problems that are so massive, so complex, and so pervasive that it boggles the mind of someone who contemplates tackling them head-on. However, doing something needn’t be complicated. The things that aren't working can be separated into two broad categories: 1) things that are well understood, inherently predictable and thus, controllable and 2) things that are not understood or are inherently unpredictable.

There is not much that one can do about the second group except to be prepared to be surprised, so there is no point in agonizing about them. To make a dent in the first group, reduce their cognitive overload. Allow time to think, remember, reason, and do everything that they intended to do. Stop requiring them to code and enter data.

Confine computers in the healthcare setting to functioning as assistive devices for physicians, don’t let them act as agents of the CFO or of the government. If patient care matters, patient care should be the focus of Health IT. Billing should be handled in some back room by people and systems specifically devoted to that function. Data to support billing should be derived from what doctors have written in their notes. Patient care systems should not be compromised by being forced to double as a cash register.

To paraphrase what God said: it's up to you. You can't look the government or your EHR vendor to suddenly understand what they have not understood in the past. The government is not going to suddenly replace its senseless mandates with sensible ones. Vendors aren't going to suddenly make their unusable systems usable. God has already told us the he or she is out of the loop and it’s up to us.

My message to physicians: The patient is in your care and should be the focus of your time and attention. If someone thinks that a non-clinical task is essential, that person should take the responsibility for completing it. If they are not willing to supply the time and money and it’s non-clinical, it should be left undone. The world wouldn’t come to an end if meaningful use was dumped.

Physicians must choose between playing the patient-care game or the government-mandated data-collection game. The movie "War Games" suggests the take-home lesson. "The only winning move is not to play…" the data-collection game. There can be no winners there because data are inherently meaningless and therefore, almost worthless.

It’s up to physicians to make IT work as it should, assisting in the care of a patient. Don’t rely on vendors and government mandates. 

Author | Daniel Essin, MA, MD

Articles