Structuring and Focusing Information #hcr #myhealthdata #EMR @symtym

A few weeks ago I saw a 40 year old male patient in the ER for chest pain, episodic over 2 days. He had diabetes for 15 years, hypertension for 20 years, and hyperlipidemia for 7 years. Four months prior he had a NSTEMI, 5–way coronary bypass, and 2 stents placed. Since that hospitalization he has had one followup with a cardiologist (unknown name), continues to smoke in excess of one pack of cigarettes a day, continues to drink vodka daily, and ran out of “some” medicines last week. He received his heart surgery and stents in one health system in our community, sees a cardiologist within another health system, and comes to the ER of a third health system.

Not an uncommon presentation for the ER. And not an uncommon problem where health information is spread across multiple health systems and multiple providers—some unnamed and unknown. Medications, that are unnamed and have run out, were filled at the “you know…over there” pharmacy. He also reports that the unknown cardiologist performed some test 3 weeks ago that was “OK”—big thing was put over chest.

In the ER, 2 EKGs show no evidence of prior myocardial infarction and no acute changes consistent with present injury or ischemia. Two sets of cardiac markers are negative. The chest pain was not relieved with nitroglycerin nor with aspirin—but with Protonix and Reglan. During this time we have waited for faxes from the hospital where the bypass occurred and waited for a family member to bring in the identity of the cardiologist who performed “a test” 3 weeks ago—the “appointment card is at home.”

Medical records arrive via fax (20 pages) and reveal that he has severe 3–vessel coronary artery disease and had a 5–way bypass and 2 stents. Subsequently, I was able to talk with the oncall cardiologist, for the patient’s cardiologist, and he confirms a “normal” Cardiolite study 3 weeks ago.

Patient was able to be discharged home after several hours in the ER with followup in 2 days with the now named cardiologist and medications refilled. The entire course, from the treating–physician’s perspective, was captured on a hand–written paper template and supplemental dictation.

What drove this patient’s disposition from the ER was information that he did not know and needed to be aggregated from 2 sources. The most critical information consisted of 9 words: “severe 3–vessel coronary artery disease” and “subsequent normal Cardiolite study.” Both sources provided unstructured information (data) from their electronic heatlh (medical) records (EHR/EMR).


Structured data is data that is computable (able to be read by a machine) and human comprehensible. Unstructured data is data that is non-computable. In this example the unstructured data was the fax received from one health system and the telephone conversation with the oncall cardiologist. This unstructured data was added to with my paper template and dictation and what the patient took with him as the memorialization of his ER visit—memories of conversations and printed discharge forms.

A simple example of how historical data might be structured:

Structuring Historical Data

<problem>severe 3–vessel coronary artery disease</problem>
<study>subsequent normal Cardiolite study</study>

Adding structure, in the form of a simple tagging convention, is only the start of creating a non–human interchange of information. Beyond lies, and requires, a common acceptance of a tagging convention. The meta-information conveyed in the tags allows for the non–human mediated meaninful exchange of information. In this case, hours may have been saved in arriving at a disposition and followup care from the ER—if humans and unstructured data were removed from the exchange equation. Similarly, the current information generated during the ER visit might be tagged for the patient’s future health events:

Structuring New Data

<test>EKG 1: no acute changes</test>
<test>EKG 2: no acute changes</test>
<test>Cardiac Markers Set 1: negative</test>
<test>Cardiac Markers Set 2: negative</test>


Conventionally, our health systems are not patient–centric in terms of the information model—they are enterprise–centric. Patients are the subject of the informational model, and enterprises (e.g., hospital, clinic, physician, etc.) are the actors. Consistent with the prevailing model is the necessity of re–amalgamating the patient’s informational state event–to–event when there is a change in enterprise providing the service. In the example (supra), the current informational state of the patient was only arrived at from the interplay of 4 sources (or nodes) of information: hospital where bypass was done, cardiologist, patient’s recollections, and ER determinations).

When the patient goes to his next health event, 4 nodes expands to an interplay (exchange) of 5 nodes to place the patient’s informational state on a par with the most recent ER visit for a similar presenting complaint (problem). As the number of health events increases to separate and distinct health enterprises, so does the number of exchanges required to arrive at a given informational state parity. The core issue being the partial representations of the patient’s informational state, at any given event in time, is unfocused.

Health Events Unfocused

Unfocused Nodes

The enterprise, as the center pieces of our patient’s informational model, is inherently defocusing. Sure health information exhanges (HIEs) are the conceptual cure, but that is predicated upon large scale adoption, use and long–term commitment for funding. Where there is small scale utilization of HIEs the number of nodes may decrease, but the focusing isssue will remain.

Where the informational model is shifted from enterprise–centricity to patient–centricity, focusing may be less problematic. A patient–centric informational model is about the creation of a non–enterprise specific data repository where all the patient’s health information is stored. A single amalgamated storage construct alleviates the need for each health event to assemble a germane assortment of enterprise–generated informational stores. It also affords a dedicated storage capacity for the event–generated information and provides downstream information continuity and fidelity. There is also no defocusing with an increase in scale.

Health Events Focused

Focused Nodes

Changing the focal point for our health informational model may give us (as practitioners) and our patient’s the clearest informational representation of their health possible. Structuring will allow this information to flow easily to/from permanent storage and event–driven storage. It also places the patient centrally in any discussion on ownership, privacy, and security.



Tagged as: , , , ,

Great post… I’ve been *working* with Tim on a side project for a few weeks…. he is a brilliant ER doc who has a very clear understanding of the *data difficulties* we (ALL OF US) have when meandering our way through our fractured health care system. This post articulates those *difficulties* very well !!!
Well done @symtym


About hjluks

A busy Academic Orthopedic Surgeon, Digital Strategist, Chief Medical Officer and father... intently and efficiently navigating the intersection of Social Media and Health Care.
This entry was posted in Uncategorized and tagged , , , , . Bookmark the permalink.

One Response to Structuring and Focusing Information #hcr #myhealthdata #EMR @symtym

  1. jeffbrandt says:

    Howard, Good post, The patient centric system makes sense but you have to change the way the system works today. Full disruption to the current system of health care facilities thinking that they own the data. I love this health banking idea where the patients records are stored in a secure place where the patient has control of the access and transfer of data. Kind of like the banking system where you can go almost anywhere in the world and stick your ATM card in a machine and get money. When a request is made from an ATM, regardless of the interconnect system, the request still has to be sent to the issuing bank to see if you have the money to fill the request. One of the biggest challenges in data and system architecture is that it is always difficult to be backwards compatible. If we had a clean slate to start from it would be much easier. The federated data system is the most difficult to interconnect and normalize. Even with standard federated data is a many to many relationship rather that one to many.We will find a solution, it will just take time (and money).Jeff

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s