The Data Model That Nearly Killed Me

A very interesting post:

The Data Model That Nearly Killed Me

in which Joe Bugajski describes how far we are from an electronic health record environment that would serve the patient. The situation described is one in which the patient, as he moves through the healthcare system, is called upon to answer questions, over and over again, in ways that give rise to multiple opportunities for inconsistency. Authoritative data about the patient's condition from the patient's own doctor is treated, at best, as just one minor ingredient in the mix.

One heroic medical professional, the first nurse I met in ICU, worked to create a consistent record of my condition, allergies, and medications in the hospital’s electronic health information system. She spent over one hour searching for previously entered data, correcting errors, and moving or reentering data. She argued with one doctor whose concurrent access to the hospital’s system blocked my nurse’s access to my information. She called the hospital’s pharmacy repeatedly to get my medications delivered. She met and called doctors several times. She even convinced one doctor and a pharmacist to come to my room to resolve data errors in person. Despite these heroic efforts, I never received correct medications during my stay. Indeed, my wife snuck one of my inhalers into my room. After I used it, I finally began to recover.

The inconsistencies arise, in part at least, from the absence of any consistent common framework for data entry on the side of the electronic health record. The HL7 RIM might conceivably contribute to filling this gap; but the RIM, as we know, is focused not on the patient's condition, or on the events transpiring on the side of the patient, but rather on the transactions of healthcare professionals. It rests, in other words, on a view of the electronic health record as a collection of statements “not about what was true of the patient but [about] what was observed and believed by clinicians” [1].

The exact causes of the problems documented by Bugajski are still to be determined. One way of summarizing the argument of this blog is that it seeks to make the case for a more incremental, evidence-based, and patient-centered approach to the EHR, and for a regime in which standards are imposed only when they have been proven in use.

[1] Rector AL, Nolan WA, and Kay S. Foundations for an Electronic Medical Record. Methods of Information in Medicine 30: 179-86, 1991.

Postlude (1) May 1, 2009
Another version of Bugajski's narrative can be found here, which points to do major problems which must be addressed if the vision of seemless interoperability of healthcare records is to be realized: the problem of building a consistent ontology of the enormous and rapidly evolving medical domain; and the shortage of people with the skills and training needed to realize this goal:

The first problem with modeling healthcare data is that models must represent certain concepts (and not others) that will remain stable and true long enough to be built into computer software then used by healthcare providers and patients. Mr. Obama, have you noticed just how much knowledge has, is, and will be accumulating in the medical sciences? Knowledge is codified using words - medical knowledge uses copious quantities of difficult words taken from several languages. Words that recur frequently in a particular context become imbued with a meaning that includes the context (e.g., the White House). Such words then come to symbolize a bigger idea than originally intended (i.e., a "house" that happens to be "white", versus your administration and not the house). In medicine, how many stable words exist? These words - nay, well-formed concepts, repeatable, agreed by the medical community - can be modeled and added to computers to store records. Go one step further. Specialization in ER, ICU, cardiac care, pulmonology, oncology, radiology, and other medical subjects exists because the cumulative knowledge defines a large ontology. The ontology, taxonomy, skills, and knowledge of an medical subject area then can be referenced with one word - the name of the specialty. Unfortunately, words that refer to a concept in one specialty often mean something different in another specialty.
The second problem is the lack of good modelers. These people, specialists in data engineering, a subfield of software engineering, transform concepts into graphical and lexical patterns that are used to create computer records. The concepts they model are words (nouns and verbs) plus concepts used by practitioners to describe a patient's medical condition, or a critical care pathway, medications, instructions to patients and nursing staff, tests, and diagnoses. Who among us has the modeling skills to encode this data? As information varies across specialties, how should it be encoded? Empirical evidence suggests that engineers who built the electronic health records network at the two facilities that "cared for me" tried to do this, but they failed. Their data model had irreconcilable silos of information spread across specialties and expressed as incomplete taxonomies (entities), inadequate ontologies (attributes), and poor associativity (relationships). Hence, when programmers added those bad data models to the health information systems, those systems later lost critical information about patients' condition, listed wrong medications,isolated prior diagnoses from current observations, in short, made very bad medicine.

Postlude (2): July 4, 2009
Joe Bugajski's Reply to "Proper Perspective Needed..." (April 21, 2009):

I admire, voted for, and strongly support President Obama. I support his vision of a National Health Network (NHN). I strongly disagree with his administration’s $20 billion conclusion that technology and technologists stand ready to build the NHN today. While I know little about practicing medicine, I am an authority (30 experience and many publications) in data interoperability and system integration. Hence, I cannot comment about treatment effectiveness - you and others generously provided these insights. I can write about data in the context of a system design.

The crux of the data model issue is this. If data cannot be made reliably available across silos in a single EHR, then this data cannot be made reliably available to a huge, heterogeneous collection of networked systems. Furthermore, poor quality data models and low quality user interface design convolve into serious data access and use problems for practitioners and their patients. Data models are my immediate concern relative to the NHN, but interface design also needs attention (also a fit subject for study in the NHN context). Further to data models, integration of information across an exceedingly complex, networked, data storage and retrieval topology remains an area of active research. (Indeed, my clients in every industry worldwide struggle with the issues daily - just for in-house systems.) Contrast data integration for NHN with the technology and expertise used to build the interstate highway system – 30 years of networked data knowledge versus 3000 years of road building knowledge. Consider too that technologically advanced, caring, and world-class medical institutions own and operate the troubled systems in question. These experts have immediate access to the best minds in computer, data, and network technologies. If they cannot reliably move data from one department to another, or across the street to from one to the other, how then do the rest of us cope?

--

New HL7 Ballot: Signs of Hope, but Confusion Remains

In 2007 the HL7 Board of Directors identified the need to review existing HL7 documentation in light of multiple unclarities and inconsistencies, some of them referred to in this blog (and also here). In the recently released Ballot Version 0226 of May 2009, we are perhaps beginning to see some evidence of the workings of this review, most notably in the fact that a much-cited nonsense passage present in earlier versions of the RIM documentation, according to which

there is no distinction between an activity and its documentation,

has been removed.

This is an important step, given the fundamental unclarity which has pervaded the RIM hitherto as concerns whether the items which the RIM calls 'Acts' are real processes (intentional actions) or records of such processes. HL7's official answer to this question thus far has been, absurdly, that the issue is moot, because there is no distinction between real processes and the records of such processes.

We hope now that the opportunity will be taken for further steps towards much needed clarity as concerns the interpretation of 'Act'. In the mentioned Ballot documentation we read:

Acts are the pivot of the RIM: domain information and process records are represented primarily in Acts. Any profession or business, including healthcare, is primarily constituted of intentional and occasionally non-intentional actions, performed and recorded by responsible actors. An Act-instance is a record of such an action.

Contrast earlier versions, where we were told that: "An Act-instance is a record of such an intentional action" (italics added). Are there now also some non-intentional actions the records of which we are allowed to count as Act-instances? If so, which ones? And what is a 'non-intentional action'? And what of of non-intentional events of other sorts, for instance snake bites, accidental poisonings, processes of infection, drug interactions, symptoms of disease?

Following on in the text, we read:

An Act-instance represents a "statement," according to Rector and Nowlan (1991) [Foundations for an electronic medical record. Methods Inf Med. 30.]

What is the meaning of 'represents' in such assertions? And what (if any) is the distinction between an Act and an Act-instance? Are we to accept three distinct entities: the action performed in the real world, the record of this action (which record?), the statement in the electronic medical record? Or is the record identical with the statement in the electronic medical record.

Acts as statements are the only representations of real world facts or processes in the HL7 RIM. The truth about the real world is constructed through the combination (and arbitration) of such attributed statements only ...

Do the authors of this documentation really mean 'The truth about the real world'? Or do they rather mean something like: the picture of or beliefs about the real world implied by a given body of documentation? What if the patient is dead, but the records do not show it?

A factual statement may be made about recent (but past) activities, authored (and signed) by the performer of such activities, e.g. a surgical procedure report, clinic note, etc. Similarly, a status update may be made about an activity that is presently in progress, authored by the performer (or a close observer), and later superseded by a full procedure report. Both status update and procedure report are acts, distinguished by mood and state (see Act.statusCode) and completeness of information: neither has any epistemological priority over the other except as judged by the recipient of the information.

Is a surgical procedure report truly an activity? Are a status update and a procedure report truly 'acts, distinguished by mood and state'? If so, are they also Acts? Lingering unclarities such as these are not resolved by the list of 'examples' presented by HL7 in the same document to help us understand correct usage:

Examples:
The kinds of acts that are common in health care include (1) clinical observations, (2) assessments of health condition (such as problems and diagnoses), (3) healthcare goals, (4) treatment services (such as medication, surgery, physical and psychological therapy), (5) acts of assisting, monitoring or attending, (6) training and education services to patients and their next of kin, (7) notary services (such as advanced directives or living will), (8) editing and maintaining documents, and many others.

If editing and maintaining documents are acts, then are the records (and if so which records?) of these processes of editing and maintaining documents Acts? What is the relation between 'acts' and 'Acts', and between both of these and activities (and actions)? And how can a goal be a kind of act? (or Act?)