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.



Re-identification and Patient Consent

I am working with a customer that is a state-wide Health Information Exchange (HIE) to extract data from the state's clinical data repository (CDR) and send it off to a Business Intelligence (BI) system that will be used to conduct population based research into clinical outcomes.

This type of research has been difficult to perform today because most of the data is on paper charts and information has to be re-keyed into the BI system. We will be able to extract data from the state's CDR, normalize it and then create research "data marts" that can be further manipulated. This will give us actual data that can be used to determine what treatments work and what treatments are a waste of time and money.

The state has an "opt out" privacy policy, which means that patient's data will be shared unless they explicitly choose to "opt out" of data sharing. Other states that have adopted this type of consent policy have reported that only two to three (2-3) percent of patients choose to "opt out" of data sharing. These states also report that of those patients that have chosen to "opt out" of data sharing, seven percent of those choose to change their status to "opt in" each year.

Here is the tie in.

The state wants to send *all* patient data, after it has been de-identified to the researchers. I have cautioned them that we must exclude the data on patients that have "opted out" from the feed to the researchers.

The state responded, "well, the data is de-identified, so we haven't really shared the patient's data."

1. Some data cannot be de-identified enough to actually mask the patient's identity. There may only be one patient in a city or zip code with a rare disease. No amount of de-identification would truly hide that patient's identity.

2. Researchers have the ability to "re-identify" the data and find out who the patient is if they discover something unusual and decide that they would like to contact the patient to ask further questions.

Both of these cases mean that we would be sharing identified data about the patient against the patient's explicit wishes. Imagine if you will that you have chosen to opt out of sharing data and then recieve a phone call from a researcher asking to talk to you about the effectiveness of your herpes treatments?

I am advising the state to remove data from patients that have "opted out" of data sharing from the research project. If necessary, I will involve our lawyers. I don't know what the penalty is for disclosing a patient's data against their wishes is in this state, but I hope not to find out.

RIP:Google Health

Google made an announcement last week that they are discontinuing Google Health.

As we just announced in the Official Google Blog, we will be discontinuing the Google Health service and platform over the next several months. For more context around this announcement, please check out our blog post.

Many folks in HIT have commented on this. Here is my two cents.

I created a Google Health account while taking a class in my Medical Informatics program. It seemed ok, but I was really not sure what to do with it. I am healthy and do not visit doctors unless something breaks, so I could not really find a use for it. The only data in there was information that I keyed in.

Google Health hitched their wagon to CCR and not CCD which seems to me to be a big mistake.

So, Google slinks off, tail between its legs. They thought that they could "fix" healthcare. They ended up building a product that people did not think was useful.

The most insightful comment that I read was:

... and nothing of value was lost.

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.

2011 Stanley Cup Finals

The Boston Bruins play the Vancouver Canucks for the Stanley Cup!

I did not expect the Canucks to make the finals, but Roberto Luongo finally started to play some good games in goal, and here they are. In my Stanley Cup preview, I thought that either the Bruins or the Lightning would be the Eastern Conference's representatives, so I got that right.

The schedule starts off kind of odd this year. Game 1 is on Wednesday, June 1 and Game two is not until Saturday. Those games are in Vancouver. I don't understand the extra day off, but it is probably to keep NBC happy. The teams then fly to Boston for Games 3 and 4. The series will settle down to the normal "every other day" schedule that makes the NHL playoffs much more watchable than the NBA playoffs. All games start at 8pm eastern, even those in Vancouver.

If the series goes to six or seven games, I will be on the road and will acutally be on a flight back to Detroit during Game 7. If it comes to that, I will have to figure out some way to watch the game from the plane.

I expect a close series. There is really not too much that separates the two teams. Vancouver has more offensive weapons. The defenses are pretty even. I give the Bruins the edge on goal, simply because I trust Tim Thomas more than I trust Roberto Luongo in goal.

I am looking forward to another fine series!

CDA IG Consolidation Ballot Reconciliation

The ballot for the ONC S&I Framework Consolidated CDA IGs closed earlier this month. The response was overwhelming.

There were a total of 554 comments submitted. Of these, 277 were negative.

The HL7 ballot process requires that all negative comments be addressed, resolved and withdrawn by the submitters. So, there is a lot of work to be done before the consolidated guides are approved. This is important, because the ONC would like the consolidated guides to be used for Meaningful Use Stage 2.

The HL7 Structured Documents Working Group (SDWG) resolved 56 negatives during the Orlando Working Group meeting.

A number of the negative votes are publishing related, and we will begin looking at these during today's CDA Documentation call.

Reconciliation will continue to take place on the two ONC calls on Tuesday and Wednesday and during the regular HL7 SDWG call on Thursdays.

I hope to map out a strategy for getting the final Consolidated Guides published using MDHT. We will start that work and not wait for reconciliation to be completed.

It should be a busy summer.

The ONC S&I Framework teams will meet next month in Washington, DC for two days and we hope to get more work done then.