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.



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.

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.

The relationship between Documents, Sections and Clinical Statements

The content for a clinical document is specified using Sections and Clinical Statements as building blocks.

Each Clinical Document contains exactly one header. The content of the Header is defined by the US Realm Header Template.

Each Clinical Document contains one or more sections. The content of a section is defined by its Section Template.

Each Section contains zero or more Clinical Statements. Some Sections are “narrative only” and do not contain any Clinical Statements. The content of a Clinical Statement is defined by its Clinical Statement Template.

This approach allows each document that contains an Allergy Section to use the same rules for constructing that section.

This approach allows each section that contains a Procedure Activity to use the same rules for constructing that Clinical Statement.

What is a Null Flavor and How is it Used?

I wrote this for the ONC CDA IG Consolidation project. Well, actually Keith Boone rewrote the first paragraph.

IT solutions are designed to store and manage data, but sometime we do not have the data for various reasons. Typically, in these cases, a special value, known as NULL is stored. There may be several reasons why the data isn’t available. In some cases, it may not be available or known, in others, it is not relevant, and in others it may not be computable or measurable. In HL7, these different reasons for why the data isn’t available are described as the flavor of NULL. This supports the management of the missing data. Let’s look an example.

If a patient arrives at an Emergency Department unconscious and with no identification, the system would represent the lack of information by use of a null flavor. The patient’s birth date would be unknown and would be represented using a null flavor. In this case, the appropriate null flavor would be “NAV” which is the code for “temporarily unavailable”. This information is not available, but is expected to be available later. In this example, when the patient regains consciousness or a relative arrives in the ER, we expect to know the patient’s birth date.

<birthTime nullFlavor=”NAV”/> /* coding an unknown birthdate */

Here is another example of using a null flavor for a patient who does not have a home phone.

<telecom nullFlavor=”NI” use="HP"/> /* coding a patient who does not have a home phone */

For those constraints that require the presence of an attribute that is unknown (SHALL be present with a cardinality of at least one (1..)), use a null flavor.

• NI = No Information. This is the most general and default null flavor.
• NA = Not Applicable. Known to have no proper value (e.g., last menstrual period for a male).
• UNK = Unknown. A proper value is applicable, but is not known.
• ASKU = asked, but not known. Information was sought, but not found (e.g., the patient was asked but did not know).
• NAV = temporarily unavailable. The information is not available, but is expected to be available later.
• NASK = Not Asked. The patient was not asked.

There are a handful of other codes. See the null flavor vocabulary table for the complete list.

ONC CDA IG Consolidation Project Publishing

I volunteered to work on what is now called the Documentation workgroup of this project. Keith Boone of GE Healthcare and I are leading the workgroup.

Basically, what we are doing is deciding what content should go into the Implementation Guides (IGs), and the contractors that the ONC has working on the project will make it happen. I may end up writing some content.

The content needs to be finalized and sent to HL7 for the ballot by March 30.

The issues so far include:

Format for the Conformance Statements. Today, they read like one of those 1970s user manuals that has been translated from Japanese to English by either a machine, or by someone that does not really understand English or the application. Here is an example.

[IHE] SHALL contain [1..1] statusCode, which SHALL be selected from ValueSet ConcernEntryStatus STATIC

OK. This says that this conformance requirement comes from IHE. The section is required to contain a single statusCode which must be from the ConcernEntryStatus value set, which is a static value set.

We'll have a computable version of the conformance statements, so there is little reason for the statement in the IG to read so formally. We'd like the statements to still be precise, but not as clunky. We're going to come up with some examples of what we think the verbage should look like and then present the top 3 or 4 to the larger group. If we get fifty or more people arguing over where a comma should be, it will not be productive.

Format for the graphical representation of the model fragments. We think that each section and entry should have a graphical representation (some people understand pictures better than words). If we use standard UML, our wider audience will understand it, but the HL7 folks will expect the HL7 version of the UML diagram to be present in an HL7 publication. If we use UML only, we will get negative votes from HL7 members who expect the HL7 style graphics to be used in an HL7 publication. If we include both, the document will be much bigger, but that may be our best option. I think that we will make a decision and report that back to the full work group.

A format for the "table view" of the Header, Section and Entries need to be decided on. The HL7 Heirarchical Message Description (HMD) or the HITSP style tables are under consideration. We could possibly come up with a hybrid of the two. I think that we will make a decision on this and then report back to the full work group in the next couple of weeks.

This IG will be viewed and voted on by many people who are not normally voting on HL7 standards. We will need to explain a lot of this to them. Some years ago, when the EHR Functional Model was ballotted, the EHR Work Group faced a similar issue. They put together a separate document that explained the process to newbies. I will find a copy of that and use it as the basis for a document that we will include in the ballot package.

The Header and each section and entry will have a fully populated XML example. The trick will be to have a meaningful example that doesn't obscure the important stuff. We should probably use the HL7 Cast of Characters from the Publishing Facilitator's Guide for our examples.

http://www.hl7.org/v3ballot/html/help/pfg/pfg.html#storyboardnames

There will also be a complete example of each document type containing annotations indicating the conformance statement that the data satisfies.

The Documentation Workgroup meets on Wednesdays at noon eastern!

Every Wednesday from 12-1pm EST | Dial-in: 1-888-998-2663 | Pass-code: 9065865
Webinar: https://www.livemeeting.com/cc/dt/join?id=docWG&role=attend
Sign-up for this workgroup by e-mailing admin@siframework.org

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

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.

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.