More Stupid CCD Tricks

I got this problem observation from another trading partner.

<observation classCode="OBS" moodCode="EVN">
    <templateId root="2.16.840.1.113883.10.20.1.28" assigningAuthorityName="CCD"/>
    <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5" assigningAuthorityName="IHE PCC"/>
    <id/>
    <code code="" displayName="" codeSystem="" codeSystemName=""/>
    <text>
        <reference value="#problem-93333"/>
    </text>
    <statusCode code="completed"/>
    <effectiveTime>
        <low value="20081119000000"/>
        <high nullFlavor="UNK"/>
    </effectiveTime>
    <value xsi:type="CD" nullFlavor="UNK">
        <translation code="466.0" codeSystem="2.16.840.1.113883.6.103" codeSystemName="ICD9CM"/>
    </value>
</observation>

The problem type needs to be specified in the Code element. This is the error from the validator.

Error: HITSP/C83 Conditions Problem Type SHALL be coded as specified in HITSP/C80 Section 2.2.3.1.2 Problem Type. The Problem Type code element SHALL contain a code attribute that identifies the SNOMED CT code for one of the following seven conditions: Finding (404684003), Symptom (418799008), Problem (55607006), Complaint (409586006), Condition (64572001), Diagnosis (282291009, Functional limitation (248536006). See HITSP/C83 Section 2.2.2.7.3, rule C83-[DE-7.02-1].

Error: HITSP/C83 Conditions Problem Type SHALL be coded as specified in HITSP/C80 Section 2.2.3.1.2 Problem Type. The code SHALL contain a codeSystem attribute that identifies the SNOMED CT codeSystem (2.16.840.1.113883.6.96). See HITSP/C83 Section 2.2.2.7.3, rule C154-[DE-7.02-1].

The Problem Type is to be taken from the Problem Type Value Set (Table 2-60).

Concept Code	Concept Name (SNOMED Fully Specified Name)	Definition	Usage Note
404684003	Clinical finding (finding)	Not Available	Finding
418799008	Finding reported by subject or history provider (finding)	Not Available	Symptom
55607006	Problem (finding)	Not Available	Problem
409586006	Complaint (finding)	Not Available	Complaint
64572001	Disease (disorder)	Not Available	Condition
282291009	Diagnosis interpretation (observable entity)	Not Available	Diagnosis
248536006	Finding of functional performance and activity (finding)	Not Available	Functional limitation

Then the value needs to be taken from the Problem Value set. This is constrained SNOMED-CT.

Element	Description
Identifier	2.16.840.1.113883.3.88.12.3221.7.4
Name	Problem Value Set
Source	Veterans Administration/Kaiser Permanente (VA/KP)
URL	http://evs.nci.nih.gov/ftp1/FDA/ProblemList/
Purpose	Problems and Diagnosis
Definition	See VA/KP Problem List Subset of SNOMED CT This describes the problem. Diagnosis/Problem List is broadly defined as a series of brief statements that catalog a patients medical, nursing, dental, social, preventative and psychiatric events and issues that are relevant to that patients healthcare (e.g., signs, symptoms, and defined conditions)
Version	20081203
Type	Extensional
Binding	Dynamic
Status	Active
Effective Date	Unknown
Expiration Date	N/A
Creation Date	Unknown
Revision Date	20090331
Code System Name	SNOMED CT
Code System Source	National Library of Medicine UMLS

What they are saying here is that patient has a problem, Acute Bronchitis. They coded it internally using ICD9. But, they don't know the SNOMED-CT code for this concept. They need to provide the SNOMED-CT code for this, which is 10509002.

I wonder if I am the only one that works with vendors that don't get it?

2011-2012 Hockey

I start playing hockey again this week.

Moosejaw will be playing on Monday nights, this year. The league has four teams and five goalies. They have a goalie schedule and rotation. I will not play every week. I will also play for each of the other teams, once. It will be confusing. We're playing at the Arctic Pond. We played there once before in a different league.

Here is the schedule:

http://www.allprosoftware.net/ARCTIC_45_TEAM/ls96.htm

I begin playing with the Wednesday drop-in group this week. I've played with this group of guys for many years. For a while, most of the best players would end up on one team. They beat me like a rented mule. I finally got fed up and played against them every week. When you are the first goalie on the ice, you get to pick the goal that you will play in. I got to the point where I was beating them regularly, and they asked why I never played for them. I told them that I wanted to face the tougher shots.

Last year, they started drafting teams each night, so I never knew who would be shooting at me.

It will be good to be back on the ice.

Changing Roles

Healthcare IT is different from other IT in that our customers typically operate 24/7. Thus, our maintenance windows are usually in the wee hours of the morning. You cannot work on healthcare IT any other time.

I've been involved in these early morning sessions for eight years. In my new role as architect, I don't have any real work to do. But, old habits die hard. We performed a maintenance change to a customer's Master Patient Index (MPI) earlier this week. We were able to start that process shortly after 9pm, which is when the last clinic closed. I joined the bridge line and watched the webex as the team worked through the process. I recorded start and stop times for each of the steps in the process and produced a summary for leadership. Even though I wasn't actually at the keyboard doing the work, I felt that just being there and contributing one or two suggestions showed the team that I was part of the team.

This weekend, we are upgrading one of my sites and activating another. The window to perform this work begins at midnight on Sunday morning. I'll try to dial in and listen to progress. I work with a great team, so they will be successful.

ONC S&I Framework Face to Face Meeting in October

This arrived in my inbox yesterday.

I attended the first ONC S&I Framework Face to Face Meeting in DC back in June. I'm not sure that I will get to go to this one, but I will put in the request. I am one of the team leads for the CDA Implementation Guide Documentation Work Group.

Our next S&I Framework is just around the corner.

Make sure you mark your calendars so you don't miss these important working sessions.

See the attachment or contact us via email for more details.

We hope to see you in Arlington in October!

--
ONC October F2F Support Team

October-F2F-Support@siframework.org

S&I Framework F2F Meeting | October 18-19, 2011

Hyatt Regency Crystal City at Reagan National Airport

2799 Jefferson Davis Highway, Arlington, VA 22202

ONC S&I Framework F2F

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.