ONC Meaningful Use

HITSP C32/C83 Examples

January 25, 2011

 

This folder contains a collection of examples relevant to the current ONC Meaningful Use requirements. The ONC requirements point to the HITSP C32 v2.5 specification, which in turn points to various other HITSP, IHE and HL7 specifications for clinical documents. A complete listing of specification dependencies can be found at http://healthcare.nist.gov/use_testing/faq.html .

 

This folder also contains an XML transform, WebViewLayout_CDA, that when invoked produces a human readable html view of the data. The transform only presents data that appears in the <text> element of each <section>; it does not reach down into the <entry> elements for specific coded information. In particular, it does not check for consistency of information in <section>/<text> with coded data in the <entry>s. There may be some unintended <section>/<text> versus <entry> inconsistencies in these examples.

 

MU_Rev0_HITSP_BaseC32v2.5_RequiredTemplateIds_FourErrors

This example clinical document contains the four templateIds in the document header that are required by HITSP/C32 and its referenced specifications. Note that the HL7 CCD templateId is not required in the document header; instead, the other templateIds require that CCD templateIds be used in certain section and entry elements of the document. Also note that a HITSP C32 valid document is not required to contain any sections, so a valid document can be almost completely vacuous. This example document validates to the HITSP C32 v2.0 validator at: http://xreg2.nist.gov/cda-validation/validation.html . However, when validated against the NIST Meaningful Use validator at the same web site, http://xreg2.nist.gov/cda-validation/mu.html , returns exactly four errors. This is because ONC Meaningful Use requires that every valid document minimally contain at least Allergies, Problems, Medications and Results sections. This 4-section requirement raises an issue not faced by a general C32 document, i.e how to code a valid section for which there is no known information. The next example shows one way this can be achieved.

 

MU_Rev1_HITSP_C32C83_4Sections_NoInformationEntries_NoErrors

This example clinical document adds the four ONC Meaningful Use required sections to the previous example, i.e. it has explicit Allergies, Problems, Medications and Results sections. It addresses the problem of how to satisfy all of the requirements of a required C32 section in the absence of known medical information for that topic. Where appropriate it relies on SNOMED identifiers for “no known allergies”, “no current problems or disabilities”, or “drug treatment unknown”. For laboratory or diagnostic results we could not find an appropriate SNOMED or LOINC code that explicitly states “no known results”; instead we chose a LOINC code for “care area assessment (CAA) results” in an <observation> element with the <value> element of that observation containing the original text “no known results”. There may be other more appropriate LOINC or SNOMED codes to record an absence of information on a specific topic, and there may be other more appropriate XML structures to use for presentation, but this example does not violate any HITSP, IHE or HL7 requirements for these four sections.

 

MU_Rev2_HITSP_C32C83_4Sections_MeaningfulEntryContent_NoErrors

This example deletes the four “no known information” sections from the previous example and replaces them with sections that have meaningful clinical content. The information included in the <entry> elements of each <section> is minimal in that some information that is recommended but not required by the referenced specifications is not included. Sometimes information presented in <section>/<text> will not be captured in any subordinate <entry>.

 

MU_Rev3_HITSP_C32C83_4Sections_RobustEntries_NoErrors

This example adds to the above “Rev2” document additional information that is sometimes recommended by HITAP and/or IHE specifications for the four required sections. In situations where HITSP and IHE recommend different potential vocabularies, a code from one vocabulary is given with a <translation> to a code from a different vocabulary.