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.

A Document Interface

One of our trading partners is sending us clinical documents from their EHR system. These are plain text documents. The documents are being sent in HL7 v2.3 ORU^R01 messages.

They are sending us the document in a single OBX segment with line breaks in the OBX-5 field. I have seen other systems send each line in a separate OBX segment. I call that the "card punch" format, because each line of the report is on its own data card, just like the old days.

This is what one of the messages looks like:

MSH|^~\\&|DOC|K|DOC|WSUPG1|20110328082244||ORU^R01|Q1484927743T1489224997||2.3|||AL
PID|1|...
PV1|1|CD:123456||CD:9999|||0000000000^SMITH^ZACHARY|||...
ORC|RE||...
OBR|1||999999999|PROGN^Progress Note^^^xxx SICU Progress Note|||...
OBX|1|TX|PROGN^Progress Note||...NOTE GOES HERE~New Line~Another New Line||||||F|||20110328082242||

They are sending us the following document types (the left value is the code that I recieve, and the right side is the corresponding LOINC code):

DISCH^Discharge Summary ==> code="18842-5" displayName="DISCHARGE SUMMARIZATION NOTE"
PROGN^Progress Note ==> code="11506-3" displayName="Subsequent evaluation note"
HP^History and Physical ==> code="34117-2" displayName="History and Physical Note"
CONS^Consultation ==> code="11488-4" displayName="CONSULTATION NOTE"
OPRPT^Operative Report ==> code="11504-8" displayName="Surgical operation note"
ADMN^Admission Note ==> code="34862-9" displayName="Admission Evaluation Note"

The document type code appears in the OBR-4 field and the OBX-3 field. The project manager has me filtering out the H&P documents because they are not in scope for the first phase of the project. I added a filter to discard the H&P documents, and I will get to remove that later.

The only other interesting thing is that I have to look up the National Provider Identifier (NPI) for the providers in the PV1 segment. The remote system is sending us their provider ID, and we need the NPI to match on. So, I have a database look-up that retrieves the NPI and places that in the message. I am performing the look-up on the PV1-7 Attending Doctor, PV1-8 Referring Doctor and the PV1-9 Consulting Doctor fields. I then take whichever of these three fields has an NPI (and is therefore, one of our doctors) and place that value into PV1-7.

NextGen will match on PV1-7 and will place the document into the doctor's PAQ (Provider Approval Queue). The document was already signed by a doctor at the sending facility (unless it is a Progress Note, in which case it may be signed by a non-doctor), so our Doctor's are not really "approving" the document. This is just a way to ensure that our doctor's see the document.

NextGen will also add the document to the appropriate patient's chart.

We are doing some final testing on this interface before moving it into production.

HL7/IHE Health Story Implementation Guide Consolidation Project

This crossed my emailbox yesterday. I will be participating in my role as Publishing Facilitator for the HL7 Structured Documents Work Group.

-----

On behalf of the Health Story Project and HL7 Structured Documents Work Group I am pleased to announce and invite your participation in the launch of the HL7/IHE Health Story Implementation Guide Consolidation Project.

The Project will take place under the auspices of the Office of the National Coordinator (ONC) Standards & Interoperability Framework and is a collaborative effort among the Health Story Project, Health Level Seven (HL7), Integrating the Healthcare Enterprise (IHE) and interested Healthcare industry stakeholders - collectively, the Consolidation Project Community.

ONC has launched a wiki page to support the project community which you can access here:

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

NOTE: When you first click the link, you will need to Register for a JIRA wiki account and request a login before you can access the page.

FIRST MEETING: January 4, 2011

# Recurring meeting: Tuesday @ 11:00 AM EST - 12:30 PM EST
# Conference line: 1-770-657-9270, Participant Passcode: 310940
# Webmeeting: tbs

In short, the Project will:

1. Republish all eight HL7/Health Story Implementation Guides plus the related/referenced templates from CCD in a single source.

2. Update the templates to meet the requirements of Meaningful Use, in other words, augment the base CCD requirements to meet the requirements of HITSP C32/C83.

3. Reconcile discrepancies between overlapping templates published by HL7, IHE and HITSP.

The Project will not develop new content. (There is a parallel project starting up under ONC to address new content requirements – this is not that project.)

The Project wiki includes links to source material including the HL7 Project Scope Statement.

Please let me know if you have any questions. I look forward to a successful collaboration.

Radiology Orders and Results Interface

Here is another interesting interface project.

We want to send Radiology Orders from our EHR system to our trading partner and want the Radiology Results document to be returned electronically and placed into the patient's chart in the EHR.

Simple. Right.

Except, the scheduling system at our trading partner will not receive the order. I suggested that we send them an order message (ORM), a scheduled appointment (SIU), and a registration message for a future encounter (ADT). They told us that they could not process any of those HL7 messages into their scheduling system. So, we settled on this kluge. I will convert the order message into an email that I will send securely to the scheduling department. They will then manually key the appointment into their system. Hopefully, they will remember to key our Order Number so that I can match the result to a patient. Securely? Well, yes. The appointment will contain PHI, so I will utilize the secure email function of our email system. They wanted some data that the EHR could not place into the order, so I had to look that data up from the database and place it into the email.

So much for the outbound "order." Now, for the returned results.

A Radiology Result is just a special type of Clinical Document.

We have an existing document interface which we use to receive clinical documents from this trading partner as ORU^R01 messages. They will place these radiology documents into that stream and I will have to select those messages, process them a little bit differently and send them to the EHR. I will need to look up our patient identifier and put it into the message in place of their patient identifier. I will also look up the NPI for each of the incoming providers and place that into the message. The sending system gives us their internal identifier for each provider, and the EHR would like to see the NPI instead.

We are still developing this interface. The outbound orders seem to be working fine. I have built the results processing route and am waiting to get a test result to see if I have built that correctly.

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#