Synergy

I was reviewing the HL7 ballot that opened this week and noticed something interesting. HL7 is ballotting an Emergency Medical Services (EMS) Domain Information Model. Among the items in this model is one titled "Automated Collision Notification." This model is described like so:

"This package represents data from automobiles equipped with automated telematic systems. When a vehicle so equipped has a collision, the system reports information to a central provider, who may forward the information to an emergency dispatch controller in the vicinity of the incident. "

Now, I started work for Covisint in May. Covisint developed and operates OnStar for General Motors. So, we are the "automated telematic system" that this standard talks about.

The way that this would work is like so:

* OnStar vehicle is in a collision.
* Message is sent from Vehicle to OnStar
* OnStar operator contacts the vehicle and gathers additional information.
* If necessary, the information on the collision and any injuries will be sent electronically to the EMS (instead of a phone call as happens today).
* This information can also be cc'd to the nearest Emergency Department to let them know
* The EMS can also enter additional information on what they did at the scene before transporting the patient(s) to the ED. This information can also be sent electronically to the ED that the patient(s) will be transported to.

So, we have most of the infrastructure in place. We'll just be adding electronic messaging of the information to the process.

This is still early in the process. The standards won't be ready until sometime next year, at the earliest. But, we should be able to implement this when the standards are done. If we make this work, it will save lives.

Validating CDA Documents

I received sample CCD files from a trading partner. I ran their sample files against the NIST validator and the first file had over 50 errors against the base CDA schema. They had used the data type PQ for all results in the results section. Some of those results were not physical quantities. Like so:

<value unit="ML/MIN/1.73M2" value=">60" xsi:type="PQ"/>

<value unit="MIU/ML" value="<2" xsi:type="PQ"/>

<value unit="UNK" value="///" xsi:type="PQ"/>

<value unit="UNK" value="NOT DETECTED" xsi:type="PQ"/>

<value unit="UNK" value="Negative" xsi:type="PQ"/>

<value unit="UNK" value="neg" xsi:type="PQ"/>

There is a LOINC code for Serum Cholesterol. All of the codes were either "0" or "UNK".

I went in and manually fixed the data type errors.

This is invalid:

<value unit="UNK" value="neg" xsi:type="PQ"/>

"neg" is not a physical quantity. Send this as a code, instead.

This is correct:


<value xsi:type="CD" code="260385009" displayName="Negative" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED-CT"/>

This is invalid:

<value unit="UNK" value="pos" xsi:type="PQ"/>

"pos" is not a physical quantity. Send this as a code, instead.

This is correct:

<value xsi:type="CD" code="10828004" displayName="Positive" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED-CT"/>

This is invalid:

<value unit="UNK" value="NOT DETECTED" xsi:type="PQ"/>

"not detected" is not a physical quantity. Send this as a code, instead.

<value code="260415000" codeSystemName="SNOMED-CT" displayName="Not Detected" codeSystem ="2.16.840.1.113883.6.96" xsi:type="CD"/>

This is invalid:

<value unit="MIU/ML" value="<2" xsi:type="PQ"/>

"<2" is not a physical quantity. Use interval of physical quantity as the data type, instead.

This is correct:

<value xsi:type="IVL_PQ">
<high unit="MIU/ML" value="2"></high>
</value>

This is invalid:

<value unit="ML/MIN/1.73M2" value=">60" xsi:type="PQ"/>

">60" is not a physical quantity. Use interval of physical quantity as the data type, instead.

This is correct:

<value xsi:type="IVL_PQ">
<low unit="ML/MIN/1.73M2" value="60"></low>
</value>

There are many undefined codes in the document. These need to be provided.

<code code="0" codeSystem="2.16.840.1.113883.6.12" codeSystemName="CPT-4" displayName="UNK">

<code code="UNK" codeSystem="2.16.840.1.113883.5.83" displayName="HDL CHOLESTEROL"/>

I asked the HL7 Structured Documents mailing list how they would deal with this document. Some vendors got defensive. It was an interesting exchange.



Using an HIE to Stalk a Patient

One of my state-wide HIE clients asked me the following question:

A battered woman moves from CityA to CityB and she doesn’t want her husband to find her so she opts out of the exchange. The woman seeks medical attention from a doctor in CityB. The doctor sends the woman’s new address to the exchange. Can a doctor who treated the woman in CityA see her new address or will the doctor only see the CityA address they have on file for the woman?

This one initially threw me for a loop. The purpose of an exchange is to allow doctors to see updated information on their patients. This state has a strong “opt out” policy that does not allow information to be exchanged if the patient has “opted out.” In the above use case, the patient has “opted out”, so we would not share clinical information. This state does not allow a provider to “break the glass” to override the patient’s decision to not share their information.

I think that we can configure the relationship between the Master Patient Index (MPI) and Clinical front end to prohibit the updated demographics from flowing from the MPI to the clinical system when the patient has “opted out” of data sharing.

The curious case here is that the patient would have to be stalked by either a doctor that had treated her previously, or a friend of a doctor that had treated her previously that was willing to violate HIPAA and share that information with the stalker. The real world is such a complex place that I am fairly certain that this will happen.

The bottom line is that technology is not foolproof and relies on policy and the law. Technology implements policy. If a user is willing to abuse the system and/or violate the law, they can do some unpleasant things.

This is certainly a use case that I had not considered.

First Week

I have had an exciting first week at my new job. It is a hectic environment, so I may be dragged into a meeting without any notice. Either someone will drop by my cube and ask me to join them, or I will receive an electronic meeting invitation ten minutes after the meeting started. It is not unusual to find that I have been "double booked." I've worked in similar environments before, and so far, I have managed to keep up.

I don't have my work email and calendar sync'd up to my Blackberry, yet, so I occasionally miss a meeting. I've submitted a request to have that done, so that should be taken care of in a few days.

I'm reviewing project proposals prior to our submitting a response. These are all for technologies that I have worked with, so I know what to look for. I've read proposals for three state-wide HIEs, and at least one for a regional HIE. It looks like I should be a part of the project teams for most of those.

I am being asked to consult existing project teams to explain technical options to them.

I've written use case narratives that will be handed off to developers.

I am getting better at finding my car in the parking structure after work. The first couple of days, I wandered around for five minutes or so before locating my car. I think that I have that figured out, now.

It has been a good week. I am looking forward to my second week.

PCAST, UEL, Molecules and green CDA

I listened to a discussion on Thursday's Structured Documents Work Group call about PCAST, UEL and the relationship to the templated CDA that HL7 uses. We had an earlier discussion about "green CDA".

As often happens, later in the day, it occurred to me that perhaps the UEL that PCAST is seeking could be met by "greening of templated CDA entries." Let me explain.

The President's Council on Science and Technology has called for the development of a Universal Exchange Language to exchange "atomic" health data. They feel that the current exchange standards are not granular enough.

HL7 feels that templated CDA should be sufficient and there is concern that an attempt to get too granular will result in data that lacks context and therefore meaning.

Green CDA is an attempt to create a simpler version of the xml than that which CDA currently is, and to provide transforms that will take a "full CDA" document and transform it into a "green CDA" document, and vice versa. The transforms will allow developers that are comfortable with "full CDA" to use that and to exchange documents with developers (and their systems) that are more comfortable with the simpler "green CDA."

Now, it occurs to me that we can use the concept of the "full to green" translation to take the full, templated CDA and extract the UEL molecule and transform the data into "green UEL." The process of moving from full to "green UEL" should maintain sufficient meta data in the molecule to maintain context.

The translation from the "green UEL" to "full CDA" is trickier and may require fetching data from elsewhere to reassemble a proper "full CDA" instance.

I'm not sure that this is a solution, but it just might work.

PCAST - Documents vs Atoms

In December, the President's Council of Advisors on Science and Technology (PCAST) released a report on HIT. We've been referring to this as "the PCAST Report"

Wes Rishel recently blogged on one of the more contentious issues contained in the report.

http://blogs.gartner.com/wes_rishel/2011/02/13/pcast-documents-vs-atomic-data-elements/

Basically, the report calls for a move away from the "record-centric notion that data elements should 'live' inside documents."

Now, I am all for "re-using" information. I expect that we will extract information from these documents and will repurpose that data in ways that none of us can fully understand, today. Indeed, we will extract a Patient's Medication History, Problem List and Allergies from a clinical document and import that into a recieving EHR system to feed into its Clinical Decision Support logic. However, I do see the danger of "taking things out of context" (pun intended).

If we extract "atomic" data from clinical documents and feed this data into other systems and processes, we may end up with GIGO (Garbage In, Garbage Out). The likelihood that the downstream systems may not fully understand the meaning of the "atomic" data and will mis-use it is great.

I cannot explain this any better than Wes does. Please read his analysis.

ONC Standards and Interoperability Framework CDA Implementation Guide Consolidation Project

I blogged about this project earlier.

http://jira.siframework.org/wiki/display/SIF/CDA+Consolidation+Project

Basically, this is a project that is sponsored by the Office of National Coordinator for Health Care IT (ONC) to consolidate and harmonize eight of the CDA IGs that are required for Meaningful Use. I am participatign in my role as the Publishing Facilitator for the HL7 Structured Documents Work Group, which owns the IGs and will be the sponsoring committee when the documents are ballotted in HL7.

Some very smart people have developed tools that will enable us to create a single library of CDA Templates and constraints and publish the IGs

The Model Driven Health Tools (MDHT) from the Open Health Tools (OHT) project will be used to generate the IGS. MDHT is based on the Eclipse workbench. The actual prose for the IGs will be created using the Darwin Information Typing Architecture (DITA). The tools will transform the models and DITA into a variety of output formats.

https://www.projects.openhealthtools.org/sf/projects/mdht/

http://docs.oasis-open.org/dita/v1.2/os/spec/DITA1.2-spec.html#ditaspec

I've seen Eclipse before, but this is my first exposure to MDHT and DITA. I think that I understand how the tool integrates the modelling and vocabulary information with the publishing aspect, but I am still learning.

The main group has been meeting since the first week of January. The publishing sub-group will begin meeting next week.

The intent is to ballot these IGs in the May HL7 ballot cycle, so we have a lot to accomplish in a very short period of time. We will also explore how we can better integrate the IG generation and publication process into the HL7 Publishing process. It would be good if all of the CDA IGs can be generated using these tools. This would enable consistent formatting.

There are two other S&I Framework projects that will kickoff next week. These are the Transition of Care (TOC) Initiative and and the Laboratory Interface Initiative. I do not have time to participate in either of those. I'll be busy enough with my day job and the CDA IG Consolidation project.

2010 in Review

It was an interesting year.

I started a new job in January. I'm building interfaces for the Wayne State University Physician Group in Detroit, MI. They have existing interfaces that were built by a person that is no longer there, so my first task was to redirect those interfaces to "pass through" the Rhapsody interface engine so that I could actually see the messages. I started planning for redirecting those interfaces when we replace our practice management system. The PM migration has taken longer than any of us expected.

I finished my Masters Degree in Medical Informatics in June. I went to Evanston for the graduation ceremony with my parents. I had family and friends over to my house to celebrate!

I spent another week camping "up north" with my dog, Sonny, in August. That helped me to recharge my batteries.

The lease on my Volvo S60 ended in December. I picked up a new Lincoln MKZ. I had three S60s and an S40, but, as Ford no longer owns Volvo, I decided to change. I also considered changing to a color other than black, but ended up with another black car.

I continue to play hockey. This time of year, I am playing three and sometimes four nights a week.

I was too busy to play much music while I was working on the Masters degree. Now that that is complete, I have been able to play my Chapman Stick more.

The holidays were nice. I had family over for both Thanksgiving and Christmas this year.

It was a pretty good year.

Patient List Interface

Here is a cute, little interface project that I knocked out in a couple of days.

One of our business partners is sending us what they call "patient list" data. This is information on patient groupings. For example, a patient could be on the "Gastroenterology Consults" list. This is information that does not come across in the organizations ADT stream, and the likelihood of getting it added to that was pretty low. Instead, they send us a patient list file which would contain a record for each patient and the patient list that they are on. They generate this as a Comma Separated Value (CSV) file and would send that to us as a flat file. I built a route and a mapping in the engine to take the flat file, generate an HL7 A08 (patient udate) message for each patient and place the Patient List information into the PV2-23 field (ClinicOrganizationName). The route then places each ADT message into the ADT stream for the appropriate system.

The A08 updates the basic patient demographic information by only adding the patient list information to the PV2-23 field ClinicOrganizationName. They can then select all patients that are currently in the Neurology list, for example. The receiving system gets the Patient List information with no changes required.

We already had a mechanism in place to exchange flat files, so they added this file to the stream. On the receiving end I have a script that looks at each file, identifies which one it is and routes it for processing. I added the new file to the script and built a new route to process the patient list file.

I then had to build a data structure for the CSV, which was pretty straightforward. I then built a special ADT structure that contained multiple A08 messages, and then a Map (that is the Rhapsody term, in Cloverleaf, this would be a Translate) to map the data from the CSV file to the ADT Message. After this, I added a DeBatch filter to the route to split each of the A08s into a separate message.

I had not built this sort of interface before, so I learned a little bit doing it. The trickiest part was getting the file structure definitions set up correctly. The actual mapping took about an hour to build and test.

First Evidence of Meaningful Use

We recently received an email from a laboratory system that sends us results. They currently send laboratory tests to us that are coded using "local vocabulary." They asked us if we could accept LOINC codes (http://loinc.org/) in the alternate codes.

What they are proposing is adding LOINC codes to the OBX-3 Observation Identifier field. The OBX-3 data type is Coded With Exceptions (CWE), The structure of this field is:

<Identifier (ST)> ^ <Text (ST)> ^ <Name of Coding System (ID)> ^ <Alternate Identifier (ST)> ^ <Alternate Text (ST)> ^ <Name of Alternate Coding System (ID)> ^ <Coding System Version ID (ST)> ^ <Alternate Coding System Version ID (ST)> ^ <Original Text (ST)>

So, they are proposing to send their local code in the first "triplet" of the CWE and the LOINC code in the second "triplet". This would change:

OBX|1|CWE|xxxxx^Local Test Value||result goes here.....

to

OBX|1|CWE|xxxxx^LocalTestValue^L^yyyyyy-y^Loinc Test Name^LN||result goes here.....

The first three subfields of obx-3 (aka the first triplet) are the local code (xxxxx), description (LocalTestValue), and the "L" indicates a local code. The second set of subfields (aka the second triplet) are the alternate identifiers and are the LOINC code for the test (yyyyyy-y), the description of the test from LOINC, and "LN" which specifies that the alternate code comes from LOINC.

This lab has been sending local codes for its tests for many years. The meaningful use requirements of ARRA/HITECH are nudging them to use LOINC.

Who says that we are not making progress :-)

Health Care Quality

Back when I worked in manufacturing, there was a saying that went:

What gets measured gets done. What gets rewarded gets done well.

Healthcare escaped the "quality revolution" that swept through many other industries in the 80s and 90s. That is about to change. When manufacturing changed from a culture and reward structure that focused on quantity (build to the numbers) and incorporated quality metrics into the evaluation and compensation packages of leadership, we saw a dramatic improvement in quality. As I heard it stated once, "It's amazing what you can accomplish when management is paying attention." Management pays attention when their performance reviews, bonuses and promotional opportunities are influenced by achieving quality metrics.

ARRA requires HCOs to report 27 Quality Measures to CMS to qualify for "meaningful use" financial incentives.

Some of the ARRA Quality Measures seem to be pretty straightforward. For example, there is a requirement to report "The percent of orders entered directly by physicians through CPOE." We all know that the error rate is greater when physicians write out orders and someone else enters the data for them than it is with CPOE. CPOE has significant advantages over the manual order writing system. As a local radio commercial says "even McDonalds doesn't use paper orders in 2009." So, one measure of how effectively an organization is using its EHR will be the CPOE Percentage.

Another measure is to report the percent of smokers offered smoking cessation counseling. This is the sort of measure that I have an issue with. So, you offer them counseling. Big Deal. Since we are concerned with outcomes, a better measure would be "the percent of smokers that quit smoking." Just measuring whether you offered smokers counseling reminds me of those kids camps where every kid gets a ribbon for showing up, so that we don't hurt their feelings.

We know that once CMS has this data, it will be made public. And then organizations will be able to compare their scores against their competitors (yes, virginia, hospitals do compete with each other). Also, consumers will be able to look at the scores for hospitals and doctors and use this as a determining factor in deciding where to take their health care business.

An important component of any Quality Management System is specifying what is to be measured. If there is any ambiguity in the description of what is to be measured, we will end up with inconsistent results and will be "comparing apples to oranges."

HL7 is balloting a Healthcare Quality Measures Format (HQMF). I did some work helping to put the document together.

http://www.hl7.org/V3ballot/html/domains/uvqm/uvqm.htm#

Meaningful Use

I work in Health Information Technology (HIT) and am working on a Masters in Medical Informatics (MMI) degree at Northwestern University. One of the hot topics in HIT is the American Recovery and Reinvestment Act (ARRA) http://www.recovery.gov/. The act will reimburse hospitals and other providers for the “meaningful use” of HIT. But the act doesn’t fully define the term.

ARRA defines “meaningful use” as:

1. ePrescribing
2. participation in an HIE
3. submission of quality measures

This is ok, but what does it really mean.

ePrescribing is well understood. When ePrescribing is implemented, your doctor no longer hand writes a paper prescription that you carry to your pharmacist. The prescription is entered into a computer system and it is electronically transmitted to a pharmacy that you select. Hopefully, the bottle of pills will be waiting for you to pick up when you get there. The advantages of this are that no one has to try to read the Doctor’s handwriting, unless, the doctor still writes out the order and has a nurse or a clerk enter the data for them. If the doctor is using Computerized Physician Order Entry (CPOE), they enter the order directly into the computer. Another advantage is that we can compare this prescription with your current medical conditions and other prescriptions that you are taking and a Decision Support System will flag any potential adverse drug event (ADE) that might occur. With CPOE, the physician is alerted when the order is entered. In the old paper based system, your pharmacist might catch the error and would have to phone the physician to get the prescription changed.

The second component of meaningful use is participation in a Health Information Exchange (HIE). What is a Health Information Exchange? An HIE is a network of Hospitals and other providers that will electronically exchange clinical information about patients. The idea is that if you go to see Dr. Smith, his office will be able to electronically retrieve information about your past treatments other doctors and hospitals in the region. The problem is that HIEs do not exist. Well, ok. There are some things out there that are called HIEs, but they are few and far between. CCHIT just published their certification criteria for HIEs last fall but many of the HIEs that are operational may not meet these criteria. The hope is that states and regions will build HIEs so that providers can participate in them.

The third component is the submission of quality measures. We still do not know what quality measures will be reported and to whom. When providers have EMRs in place, it should be fairly straightforward to collect these quality measures and to electronically transmit them to the appropriate agency. This is just the reporting of quality measures; there are no targets….yet. Expect to see quality defined as a measure of outcome, and not as a measure of effort. In other words, just giving the patient an aspirin should not be considered a measure of quality. Similarly, you shouldn’t get quality points for giving the patient the same “quit smoking” pamphlet that they have been getting for years. A better measure of quality might be “has the patient stopped smoking?” Many other industries have adopted quality measures that relate directly to the quality of the product and to customer satisfaction with a product or service.

So, when will we know what meaningful use means? National Coordinator for Health IT David Blumenthal said: “We hope to provide a direction and some specifications in the late spring, early summer.” He did not specify which year :-)

http://www.kaisernetwork.org/daily_reports/rep_index.cfm?DR_ID=58402

What’s the rush? Well we need to begin deploying these systems soon, because meaningful use must be achieved by 2012 in order for providers to get the full incentive money. Note that this refers to the federal fiscal year, so this really means October 1, 2011. These systems are complex and the timing is fairly tight.

Last month, the National Committee on Vital Health Statistics (NCVHS) met to discuss meaningful use. The meeting agenda and presentations can be found at the following link.

http://ncvhs.hhs.gov/090428ag.htm

One thing we can expect is that meaningful use will be a target that will change every year. Expect the bar to be raised each year. For example, once everyone has ePrescribing implemented I would expect to see the addition of Decision Support to check for drug interactions and to look for cheaper alternatives.

The HIT Standards Committee met on Friday, 5/15. There is a nice summary of the meeting on John Halamka's blog:

http://geekdoctor.blogspot.com/2009/05/first-meeting-of-hit-standards.html

That's enough of that. The Red Wings begin the conference finals this afternoon. Go Wings!