Readers Write 4/22/09

Sense of Reality
By Greg Weinstein

I have been working on clinical systems and integration in an academic medical center for 20 years now and I am watching with growing concern the frenzy of the standards writers. Prior to going to HIMSS, I took the time to read some of the HITSP specs – specifically. the C32 document sections related to medications. Everyone has a problem with sharing medication lists and everyone wants to do it right. But while C32 has over 30 data elements for each medication record (down to the lot# and bottle cap style) the only thing required was the text of the drug name. When I asked people how they could build a data sharing system (NHIN, RHIO, HIE) with only that requirement, they answer that, within each exchange, the “details need to be agreed on”. This sounds a lot like the failure of HL7 v2, though with a lot more baggage.

I visited the IHE Connectathon at HIMSS. What I saw was not encouraging, but entirely predictable. The scenario demonstrated a patient moving through a series of care facilities with CCDs used to transfer the patient’s record. Naturally one site included only the medication names (actually they stuffed long strings with the names, routes, frequencies, dose all together into the name field) and embedded this in their CCD. The next site expected to receive the medication name, route, dose, etc. as separate fields and was unable to import the data. The demonstrator began manually re-entering the data by reading the long multi-element strings and using the data entry form of his own system. This might have allowed entry of the data into his system, but almost certainly lost the data “provenance” (that it arrived via a specific signed CCD). 

After a few minutes, the crowd became restless and he gave up, skipping the last four medications. He then generated his CCD and transferred it to the next system in the scenario, which, amazingly, only saw the medications from the last CCD, where four medications had been omitted. In fact, the contents of the multiple CCDs reflected the system limitations of the various systems more than they did the actual patient state being represented in the scenario.

Against this background of non-success, we see CCHIT certification scenarios of ever-increasing complexity and new HITSP requirements to include every data function ever conceived. And then we see published research stating that no one has proven that any of this actually improves outcomes.

Regarding CCHIT, the entire focus of application certification is wrong. We ought to be asking providers to support certain functions. The CCHIT approach of application certification implies that a single system needs to do everything. Why couldn’t a provider choose to use more than one piece of software so long as their practice did what was needed?

I sincerely hope that someone will be able to calm the waters, make rational decisions on what data is most valuable to share (medications, allergies, problems, labs, images, and “documents”), and how to go about it.  Without some focus and reasonable expectations, we may waste an entire generation of software development activity, kill innovation, and crush smaller companies, all without tangible benefit.

MUMPS to Java … Caveat Emptor
By Richie O’Flaherty

I couldn’t let this pass un-commented, having had some direct experience in language translations many years back in which the organization I was a part of translated a number of applications (mostly in-house developed) from Meditech MIIS and MaxiMUMPS. While most of the pain occurred in the MaxiMUMPS translations due to extensive non-ANSI standard extensions in the language implementation, a common theme (pronounced "fly in the ointment") became apparent in the implementation of the resulting application.

This was the shocking performance impact of the translated code. Differences between how language components are coded in the source and destination languages can have crippling effect on the translated application. A primitive operator in the source language may or may not exist in the target language. If it doesn’t exist, an equivalent piece of code must be written and invoked everywhere it occurs in the source application code. That may involve many instructions or even many lines of instructions as well as overhead to invoke and clean up every time it is used. 

The difference in the number of machine cycles to execute these "equivalent" components can (and did) bring the translated application to its knees, requiring rethinking of hardware configurations as well as targeted application redesign in the resulting language to salvage the very life of the system which was the principal IT solution for a major outpatient clinic.

I am not a Java programmer so I cannot offer perspective on speed and efficiencies that Java may bring to the table, only that this is and was the massive piece of the iceberg in our translation efforts involving MUMPS. It should be noted however, that MUMPS (and MaxiMUMPS) cut their teeth supporting an impressive number of simultaneous users on hardware that had but fractional MIPS ratings. That these outmoded dinosaurs are yet running applications anywhere is a sure sign that the possess a level of efficiency that should be at minimum respected, but more advisedly investigated when seeking to translate them to anything. Iron is certainly cheap(er) these days, but I reiterate — caveat emptor.

Do You Know What’s In Your Medical Record?
By Deborah Kohn, Principal, Dak Systems Consulting

One must go back to ePatient Dave’s main point (albeit difficult to find given all the exchanges and text): "Do you know what’s in your medical record? THAT is the question worth answering."

It doesn’t matter if the data are stored on paper, on analog photographic film, or on a digital storage medium. The only way one will be truly responsible for one’s health is to get copies (analog or digital) of one’s complete, episodic medical record, review the record with one’s provider(s) if necessary, and if errors are are found, correct them. Because one deals with people, processes, and technologies, data inaccuracies occur all the time!

However, since the 1970s, patients have been allowed to access the information contained in their medical records, and since HIPAA "I", patients have been allowed to add addenda to their records. Similar to obtaining and correcting the data contained in one’s credit report, one must ask to do this.

As a health information management professional for over thirty years and long-time member of the American Health Information Management Association (AHIMA) whose banner remains "Quality Information for Quality Healthcare", I never NOT obtain copies of my episodic medical record for review, archive, and information exchange purposes. Hopefully your readership will do same.

For example, as a health information management professional (fortunately or unfortunately) I knew only too well that when I was hospitalized five years ago my clinical records (created and stored in both analog and digital formats) would contain inaccuracies. One operative report contained my correct demographic information in the report header but described me as male (I’m a female) with inoperable colon cancer in the report body. (Either the surgeon or the transcriptionist had mistakenly switched the dictation based on another case that day). Subsequently, these data were coded as such for billing /reimbursement purposes (ICD/CPT) and clinical purposes (SNOMED), making no difference had the data populated a Google or Microsoft or other PHR.

In summary, to answer another question asked in one of the blogs, " Who’s going to validate and correct the data?", the good news is that health information management professionals working in all types of healthcare provider organizations are not only trained but tasked to validate these data. The not-so-good news is that given staffing constraints and other similar issues, it is not and never will be possible to audit 100% of the medical record content in 100% of the cases. Therefore, only YOU, the patient, can and must review and correct the data.