Agile Health Services - A resource for the intersection of healthcare, computer science, and design: standards

Showing posts with label standards. Show all posts

December 16, 2014

Health IT's journey from messages... to documents... to APIs

The latest JASON report "Data for Individual Health" released last month continues to make the case for the adoption of open APIs to better support the interoperability of healthcare data. When I think back on the past ~25 years in Health IT, the story that this is painting feels like the gradual evolution of electronic health data from messages, to documents to APIs.

Clinical messages have always been an incomplete "soda straw" perspective of a very small amount of patient's clinical information. Messages are designed for communicating current information about a patient from one software system to another. HL7 v2 is the dominant industry standard used for expressing clinical messages.

HL7 v2 messages can be used to express different types of messages including Admissions and Discharges (ADT), Observation Result (ORU), Order Message (ORM). Additionally, HL7 v2 is a very old data standard, using a "pipe and hat format" approach to encoding the patient's clinical data. In order to parse an HL7 v2 message, you need to know the offset of data within an HL7 v2 message separated by "|" and "^" characters. For example, below is an example HL7 v2 message for a glucose reading.

MSH|^~\&|GHH LAB|ELAB-3|GHH OE|BLDG4|200202150930|
|ORU^R01|CNTRL-3456|P|2.4|PID|||555-44-4444|
|EVERYWOMAN^EVE^E^^^^L|JONES|19620320|F|||
153 FERNWOOD DR.^^STATESVILLE^OH^35292||(206)3345232
|(206)752-121||||AC555444444||67-A4335^OH^20030520
|OBR|1|845439^GHH OE|1045813^GHH LAB|15545^GLUCOSE||
|200202150730||||||||
|555-55-5555^PRIMARY^PATRICIA P^^^^MD^^|||||||||F||
||||444-44-4444^HIPPOCRATES^HOWARD H^^^^MD|OBX|1|SN
|1554-5^GLUCOSE^POST 12H CFST:MCNC:PT:SER/PLAS:QN||^182|mg/dl|70_105|H|||F

This makes for a very brittle standard, that is machine interpretable, but not very easy to work with. By design, you probably would not want to persist HL7 v2 messages as the authoritative source of the clinical information about a patient. It is not going to be anything more than a soda straw of a few data points. To this end, moving forward to the turn of the 21st century... clinical documents could help... a little.

Clinical documents are designed to express a more complete picture of a patient's healthcare information at a specific date and point in time. Notable clinical document standards have included the ASTM CCR. HL7's CCD, CCDA, and QRDA Category I. MITRE also developed a standard for both representing and exchanging clinical documents called hData. Clinical documents differ from clinical messages in that documents are designed to contain more information extracted from an EHR system at a specific date and possibly a timestamp.

An example of an old CCR XML document representing a patient with hypertension and height/weight vitals follows:

<?xml version="1.0" encoding="UTF-8"?>
<ContinuityOfCareRecord xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:astm-org:CCR CCR_20051109.xsd http://www.w3.org/2001/XMLSchema xmldsig-core-schema.xsd" xmlns="urn:astm-org:CCR">
<CCRDocumentObjectID>94461c3f-7dbf-4af1-aba9-ed4aac26bea4</CCRDocumentObjectID>
<Language>
<Text>English</Text>
</Language>
<Version>V1.0</Version>
<DateTime>
<ExactDateTime>2010-02-01T15:52:04Z</ExactDateTime>
</DateTime>
<Body>
<Problems>
<Problem>
<CCRDataObjectID>BB0001</CCRDataObjectID>
<DateTime>
<Type>
<Text>Start date</Text>
</Type>
<ExactDateTime>1990-08-07T06:00:00Z</ExactDateTime>
</DateTime>
<Type>
<Text>Diagnosis</Text>
</Type>
<Description>
<Text>Hypertension</Text>
<Code>
<Value>403.10</Value>
<CodingSystem>ICD-9 CM</CodingSystem>
<Version>2005</Version>
</Code>
</Code>
</Description>
<Status>
<Text>Active</Text>
</Status>
</Problem>
</Problems>
<VitalSigns>
<Result>
<CCRDataObjectID>BB0009</CCRDataObjectID>
<DateTime>
<Type>
<Text>Start date</Text>
</Type>
<ExactDateTime>2005-09-24T04:00:00Z</ExactDateTime>
</DateTime>
<Description>
<Text>Height & Weight</Text>
</Description>
<Source>
<Actor>
<ActorID>AA0002</ActorID>
</Actor>
</Source>
<Test>
<CCRDataObjectID>BB0010</CCRDataObjectID>
<Type>
<Text>Observation</Text>
</Type>
<Description>
<Text>Height</Text>
<Code>
<Value>50373000</Value>
<CodingSystem>SNOMED</CodingSystem>
<Version>2005</Version>
</Code>
</Description>
<Source>
<Actor>
<ActorID>AA0002</ActorID>
</Actor>
</Source>
<TestResult>
<Value>155</Value>
<Units>
<Unit>cm</Unit>
</Units>
</TestResult>
</Test>
<Test>
<CCRDataObjectID>BB0011</CCRDataObjectID>
<Type>
<Text>Observation</Text>
</Type>
<Description>
<Text>Weight</Text>
<Code>
<Value>363808001</Value>
<CodingSystem>SNOMED</CodingSystem>
<Version>2005</Version>
</Code>
</Description>
<Source>
<Actor>
<ActorID>AA0002</ActorID>
</Actor>
</Source>
<TestResult>
<Value>55</Value>
<Units>
<Unit>kg</Unit>
</Units>
</TestResult>
</Test>
</Result>
</VitalSigns>
</Body>
<Actors>
<Actor>
<ActorObjectID>AA0001</ActorObjectID>
<Person>
<Name>
<CurrentName>
<Given>John</Given>
<Middle>N</Middle>
<Family>Doe</Family>
</CurrentName>
</Name>
<DateOfBirth>
<ExactDateTime>1960-08-23T06:00:00Z</ExactDateTime>
</DateOfBirth>
<Gender>
<Text>Male</Text>
</Gender>
</Person>
<IDs>
<Type>
<Text>SSN</Text>
</Type>
<ID>555-55-5555</ID>
<Source>
<Actor>
<ActorID></ActorID>
</Actor>
</Source>
</IDs>
<Address>
<Type>
<Text>Home</Text>
</Type>
<Line1>Main Street</Line1>
<City>Fort Lauderdale</City>
<State>FL</State>
<PostalCode>33011</PostalCode>
</Address>
<Source>
<Actor>
<ActorID>AA0002</ActorID>
</Actor>
</Source>
</Actor>
</ContinuityOfCareRecord>

This allows for additional data to express a more complete (but admittedly incomplete) picture of that patient's health.

Fast forward to today... as laid out in the latest JASON report... the trend is less towards messages or documents, and more towards open Application Programmer Interfaces (APIs) to access and exchange a patient's data.

In the FHIR RESTful framework, transactions are performed on the server using the HyperText Transfer Protocol (HTTP) request/response. FHIR's RESTful framework allows for services to create, read, update, and delete information exchanged from one service to another over a network.

There's levels of authentication to gate access that can be built into FHIR at various levels of a patient's record. So, if you wanted to request all the clinical information about a patient from a service, you would simply perform a "GET" request on that patient's identifier. Similarly, you could request a subset of finer levels of granularity for information such as that patient's conditions, medications, allergies, etc.

There are even some sexy things that you can do with FHIR's search capabilities of clinical data. For instance, you could perform search for any patient with a gender that has a code "male" with a query like:

GET [base-url]/Patient?gender=male

The data exchanged with FHIR is still clinical documents, but there's now a shift away from the CDA-based HL7 documents that I have not been a fan of, to FHIR's own approach to expressing clinical documentation with FHIR resources within the FHIR RESTful API.

Ultimately, I think this is where we should be going; both with focusing on how data will be accessed and exchanged while simultaneously ensuring that the clinical data used between different services is designed to be simpler and stricter.

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. © Rob McCready, 2014.

October 8, 2014

Example of CDA limitations to interoperability: time intervals

The HL7 Clinical Document Architecture (CDA) is an XML-based markup standard intended to specify the encoding, structure and semantics of clinical documents for exchange. CDA is an ANSI-certified standard from Health Level Seven (HL7). The CDA is highlighted as a flexible framework that can contain any type of clinical content. Additionally, the details of the encoding of clinical data and associated aspects of that data are intentionally designed to be flexible.

That flexibility provides freedoms in various different systems' ability to export clinical data. However, that same flexibility is an increasing barrier to the interoperability of data as systems need to import that same data. My biggest pet peeve with the CDA and this problem is the flexibility that the CDA provides in the encoding of time intervals.

Based on clinical reason, the CDA provides the freedom to encode time intervals in eight (8) (VIII) different representations.

<low>
<width>
<high>
<low> <width>
<low> <high>
<center>
<center> <width>

This amount of flexibility in expressing something as simple as a time interval is an obstacle for any receiving system hoping to import and parse an HL7 CDA-based XML document without knowing the way that the generating system is going to express something as basic as a time interval. This permissive nature of the CDA's artifacts is common beyond this one basic example.

What is needed, and hopefully addressed in the emerging FHIR specification, is a more constrained approach to the foundational aspects of clinical data, such as how to encode time intervals. To reach a point with more interoperability of healthcare data, analysis is needed of the presence of types of structured clinical data concepts and associated clinical codes used operationally.

I feel that the healthcare standards community ultimately needs to identify a strict and simple constrained set of ways of expressing clinical concepts that healthcare Standards Development Organizations (SDOs) like HL7 should use to constrain existing permissive and complex standards. This could also be done to guide a stricter and simpler implementation to support interoperability via FHIR.

This could introduce significant and radical improvements in the interoperability of patient data in the US healthcare industry. This will better enable disparate healthcare software systems to work together without requiring point-to-point coordination. This could reduce, and eventually eliminate, these problems of point-to-point coordination that result in islands of automation.

This "loose coupler" approach will encourage HL7, or possibly new healthcare SDOs, to embrace a core set of strict and simple required attributes, over the current state of the practice using permissive and complex attributes.

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. © Rob McCready, 2014.

April 27, 2013

Example QRDA Category 1 XML for Meaningful Use Stage 2 Clinical Quality Measure Reporting

Last fall, I wrote about the QRDA Category 1 XML Standard as a way of expressing inputs to Clinical Quality Measures for the Meaningful Use Stage 2 program. More recently, I have become immersed in the QRDA Category 1 while leading the open source Cypress project for the Office of the National Coordinator of Health Information Technology (ONC) and the Meaningful Use Stage 2 CQM Testing and Certification Program.

Under ONC, the Meaningful Use Program tests and certifies EHR technologies as part of the Meaningful Use Program via Authorized Testing Laboratories (ATLs), who are the organizations that use the tools and policies identified by ONC. The Cypress project is the authoritative testing and certification tool used for the MU Stage 2 Clinical Quality Measures, and includes testing for the QRDA Category 1 XML specification.

Based on all the work our team has been supporting with the QRDA Category 1 XML, I thought it would be helpful to demonstrate how a CQM can define the data that would need to be expressed in a QRDA Category 1 XML file.

As an example, I am selecting NQF 0018 "Controlling High Blood Pressure", which measures the percentage of patients, aged 18-85 years old at the time of the CQM's measurement, and who had some sequence of encounters with a provider, and a diagnosis of hypertension, and whose blood pressure was adequately controlled (<140/90mmHg) during the measurement period.

If you wanted to see the full logic of this particular CQM, the visualization that is automatically generated from the open source popHealth project that I am leading is below:

Denominator Logic

individual characteristicbirth date

>= 18 years starts before start of measure period

and

individual characteristicbirth date

<= 85 years starts before start of measure period

and

diagnosis condition problemessential hypertension

<= 6 months starts after start of measure period

diagnosis condition problemessential hypertension

starts before start of measure period

and

encounteroffice visit

during measure period

encounterface-to-face interaction

during measure period

encounterpreventive care services - established office visit, 18 and up

during measure period

encounterpreventive care services-initial office visit, 18 and up

during measure period

encounterhome healthcare services

during measure period

encounterannual wellness visit

during measure period

Numerator Logic

physical examdiastolic blood pressure < 90 mm Hg

duringrecent of

encounteroffice visit

during measure period

encounteroutpatient consultation

during measure period

encounterpreventive care services-initial office visit, 18 and up

during measure period

encounterpreventive care services - established office visit, 18 and up

during measure period

encounterface-to-face interaction

during measure period

encounterhome healthcare services

during measure period

encounterannual wellness visit

during measure period

and

physical examsystolic blood pressure < 130 mm Hg

duringrecent of

encounteroffice visit

during measure period

encounteroutpatient consultation

during measure period

encounterpreventive care services-initial office visit, 18 and up

during measure period

encounterpreventive care services - established office visit, 18 and up

during measure period

encounterface-to-face interaction

during measure period

encounterhome healthcare services

during measure period

encounterannual wellness visit

during measure period

Consider some realistic but minimal health data applied against that particular CQM and let's see what what a QRDA Category 1 XML file for me would look like. Assume I have the following notional clinical data assigned to me in an Electronic Health Record system:

First Name: John
Last Name: Doe
DoB: June 24, 1975
Address: 123 Main Street Gardner, MA 01440
Work phone: 781-271-7102
HL7 Gender: Male
Spoken Language: English
CDC Race: White
CDC Ethnicity: Not Hispanic or Latino
Conditions: Hypertension diagnosed on March 1st, 2012
Encounters: Office Visit on March 1st, 2012
Office Visit on July 1st, 2012
Blood Pressure Visit on November 1st, 2012
Systolic BP: 127 mmHg on March 1st, 2012
123 mmHg on November 1st, 2012
Diastolic BP: 79 mmHg on March 1st, 2012
81 mmHg on November 1st, 2012

Now, lets see how that clinical data for this patient should be expressed in the (very verbose) QRDA Category 1 XML format. As an FYI for how the QRDA Category 1 XML specification works, the data expressed in the QRDA Category 1 XML is in response to a CQM request.

Assume that the QRDA Category 1 XML below were generate for that particular CQM NQF 0018 "Controlling High Blood Pressure" for the Meaningful Use Stage 2 program. Also, assume a reporting period ending on December 31st, 2012 23:59. I am highlighting in yellow within the XML below where the clinical data that I enumerated for our notional patient is expressed in the QRDA Category 1 XML:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="cda.xsl"?>
<ClinicalDocument xmlns="urn:hl7-org:v3"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:voc="urn:hl7-org:v3/voc"
xmlns:sdtc="urn:hl7-org:sdtc">
<realmCode code="US"/>

<templateId root="2.16.840.1.113883.10.20.22.1.1"/>
<templateId root="2.16.840.1.113883.10.20.24.1.1"/>
<templateId root="2.16.840.1.113883.10.20.24.1.2"/>
<id root="5b010313-eff2-432c-9909-6193d8416fac"/>
<code code="55182-0"
codeSystem="2.16.840.1.113883.6.1"
codeSystemName="LOINC"
displayName="Quality Measure Report"/>
<title>QRDA Report for John Doe</title>
<effectiveTime value="20130427145038"/>
<confidentialityCode code="N"
codeSystem="2.16.840.1.113883.5.25"/>
<languageCode code="eng"/>
<recordTarget>
<patientRole>
<id extension="12345" root="2.16.840.1.113883.4.572"/>
<addr use="HP">
<streetAddressLine>123 Main Street</streetAddressLine>
<city>Gardner</city>
<state>MA</state>
<postalCode>01440</postalCode>
<country>US</country>
</addr>
<telecom use="WP" value="tel:+1-781-271-7102"/>
<patient>
<name>
<given>John</given>
<family>Doe</family>
</name>
<administrativeGenderCode code="M"
codeSystem="2.16.840.1.113883.5.1"
codeSystemName="HL7 AdministrativeGender"/>
<birthTime value="19750624120000"/>
<raceCode code="2106-3"
displayName="White"
codeSystemName="CDC Race and Ethnicity"
codeSystem="2.16.840.1.113883.6.238"/>
<ethnicGroupCode code="2186-5"
displayName="Not Hispanic or Latino"
codeSystemName="CDC Race and Ethnicity"
codeSystem="2.16.840.1.113883.6.238"/>
<languageCommunication>
<templateId root="2.16.840.1.113883.3.88.11.83.2"
assigningAuthorityName="HITSP/C83"/>
<templateId root="1.3.6.1.4.1.19376.1.5.3.1.2.1"
assigningAuthorityName="IHE/PCC"/>
<languageCode code="eng"/>
</languageCommunication>
</patient>
</patientRole>
</recordTarget>
<author>
<time value="20130427145038"/>
<assignedAuthor>
<id extension="FakeNPI" root="2.16.840.1.113883.4.6"/>
<addr>
<streetAddressLine>234 Main Street</streetAddressLine>
<city>Gardner</city>
<state>MA</state>
<postalCode>01440</postalCode>
<country>US</country>
</addr>
<telecom use="WP" value="tel:(781)271-7102"/>
<assignedAuthoringDevice>
<manufacturerModelName>AcmeEHR</manufacturerModelName>
<softwareName>AcmeEHR</softwareName>
</assignedAuthoringDevice>
</assignedAuthor>
</author>
<custodian>
<assignedCustodian>
<representedCustodianOrganization>
<id root="2.16.840.1.113883.19.5"/>
<name>Fake Custodian</name>
<telecom use="WP" value="tel:(781)555-5555"/>
<addr>
<streetAddressLine>345 Main Street</streetAddressLine>
<city>Gardner</city>
<state>MA</state>
<postalCode>01440</postalCode>
<country>US</country>
</addr>
</representedCustodianOrganization>
</assignedCustodian>
</custodian>
<legalAuthenticator>
<time value="20130427145038"/>
<signatureCode code="S"/>
<assignedEntity>
<id root="bc01a5d1-3a34-4286-82cc-43eb04c972a7"/>
<addr>
<streetAddressLine>567 Main Street</streetAddressLine>
<city>Gardner</city>
<state>MA</state>
<postalCode>01440</postalCode>
<country>US</country>
</addr>
<telecom use="WP" value="tel:(781)271-3000"/>
<assignedPerson>
<name>
<given>Mike</given>
<family>Doe</family>
</name>
</assignedPerson>
<representedOrganization>
<id root="2.16.840.1.113883.19.5"/>
<name>AcmeEHR</name>
</representedOrganization>
</assignedEntity>
</legalAuthenticator>
<documentationOf typeCode="DOC">
<serviceEvent classCode="PCPR">
<effectiveTime>
<low value="20100601"/>
<high value="20100915"/>
</effectiveTime>
<performer typeCode="PRF">
<time>
<low value="20020716"/>
<high value="20070915"/>
</time>
<assignedEntity>
<id root="2.16.840.1.113883.4.6" extension="111111111"/>
<representedOrganization>
<id root="2.16.840.1.113883.4.2" extension="1234567"/>
<id root="2.16.840.1.113883.4.336" extension="54321"/>
</representedOrganization>
</assignedEntity>
</performer>
</serviceEvent>
</documentationOf>
<component>
<structuredBody>
<component>
<section>
<templateId root="2.16.840.1.113883.10.20.24.2.2"/>
<templateId root="2.16.840.1.113883.10.20.24.2.3"/>
<code code="55186-1" codeSystem="2.16.840.1.113883.6.1"/>
<title>Measure Section</title>
<text>
<table border="1" width="100%">
<thead>
<tr>
<th>eMeasure Title</th>
<th>Version neutral identifier</th>
<th>eMeasure Version Number</th>
<th>NQF eMeasure Number</th>
<th>Version specific identifier</th>
</tr>
</thead>
<tbody>
<tr>
<td>Controlling High Blood Pressure</td>
<td>ABDC37CC-BAC6-4156-9B91-D1BE2C8B7268</td>
<td>1</td>
<td>5177f5798538a2f952caf324</td>
<td>8A4D92B2-397A-48D2-0139-C6208B875109</td>
<td/>
</tr>
</tbody>
</table>
</text>
<entry>
<organizer classCode="CLUSTER" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.24.3.98"/>

<templateId root="2.16.840.1.113883.10.20.24.3.97"/>
<statusCode code="completed"/>
<reference typeCode="REFR">
<externalDocument classCode="DOC" moodCode="EVN">
<id root="8A4D92B2-397A-48D2-0139-C6208B875109"/>
<text>Controlling High Blood Pressure</text>
<setId root="ABDC37CC-BAC6-4156-9B91-D1BE2C8B7268"/>
<versionNumber value="1"/>
</externalDocument>
</reference>
</organizer>
</entry>
</section>
</component>
<component>
<section>
<templateId root="2.16.840.1.113883.10.20.17.2.1"/>
<code code="55187-9" codeSystem="2.16.840.1.113883.6.1"/>
<title>Reporting Parameters</title>
<text>
<list>
<item>Reporting period: January 1st, 2012 -
December 31st, 2012</item>
</list>
</text>
<entry typeCode="DRIV">
<act classCode="ACT" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.17.3.8"/>
<code code="252116004"
codeSystem="2.16.840.1.113883.6.96"
displayName="Observation Parameters"/>
<effectiveTime>
<low value="20120101000000"/>
<high value="20121231235900"/>
</effectiveTime>
</act>
</entry>
</section>
</component>
<component>
<section>
<templateId root="2.16.840.1.113883.10.20.17.2.4"/>
<templateId root="2.16.840.1.113883.10.20.24.2.1"/>
<code code="55188-7" codeSystem="2.16.840.1.113883.6.1"/>
<title>Patient Data</title>
<text/>
<entry>
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.22.4.2"/>
<templateId root="2.16.840.1.113883.10.20.24.3.57"/>
<id root="1.3.6.1.4.1.115" extension="5177f5807938a7ce61000287"/>
<code code="8462-4"
codeSystem="2.16.840.1.113883.6.1"
sdtc:valueSet="2.16.840.1.113883.3.526.3.1033">
<originalText>Physical Exam, Finding:
Diastolic BP</originalText>
</code>
<statusCode code="completed"/>
<effectiveTime>
<low value="20120301120000"/>
<high value="20120301120000"/>
</effectiveTime>
<value xsi:type="PQ" value="79" unit="mmHg"/>
</observation>
</entry>
<entry>
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.22.4.2"/>
<templateId root="2.16.840.1.113883.10.20.24.3.57"/>
<id root="1.3.6.1.4.1.115" extension="5177f5807938a7ce6100028d"/>
<code code="8462-4"
codeSystem="2.16.840.1.113883.6.1"
sdtc:valueSet="2.16.840.1.113883.3.526.3.1033">
<originalText>Physical Exam, Finding:
Diastolic BP</originalText>
</code>
<statusCode code="completed"/>
<effectiveTime>
<low value="20121101120000"/>
<high value="20121101120000"/>
</effectiveTime>
<value xsi:type="PQ" value="81" unit="mmHg"/>
</observation>
</entry>
<entry>
<encounter classCode="ENC" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.22.4.49"/>
<templateId root="2.16.840.1.113883.10.20.24.3.23"/>
<id root="1.3.6.1.4.1.115" extension="5177f5807938a7ce6100027f"/>
<code code="99201"
codeSystem="2.16.840.1.113883.6.12"
sdtc:valueSet="2.16.840.1.113883.3.464.1003.101.12.1001">
<originalText>Encounter, Performed:
Office Visit</originalText>
</code>
<text>Encounter, Performed:
Office Visit</text>
<statusCode code="completed"/>
<effectiveTime>
<low value="20120301120000"/>
<high value="20120301130000"/>
</effectiveTime>
</encounter>
</entry>
<entry>
<encounter classCode="ENC" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.22.4.49"/>
<templateId root="2.16.840.1.113883.10.20.24.3.23"/>
<id root="1.3.6.1.4.1.115" extension="5177f5807938a7ce61000280"/>
<code code="99201"
codeSystem="2.16.840.1.113883.6.12"
sdtc:valueSet="2.16.840.1.113883.3.464.1003.101.12.1001">
<originalText>Encounter, Performed:
Office Visit</originalText>
</code>
<text>Encounter, Performed:
Office Visit</text>
<statusCode code="completed"/>
<effectiveTime>
<low value="20120701120000"/>
<high value="20120701130000"/>
</effectiveTime>
</encounter>
</entry>
<entry>
<encounter classCode="ENC" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.22.4.49" />
<templateId root="2.16.840.1.113883.10.20.24.3.23" />
<id root="1.3.6.1.4.1.115" extension="5177f5807938a7ce61000281"/>
<code code="185349003"
codeSystem="2.16.840.1.113883.6.96"
sdtc:valueSet="2.16.840.1.113883.3.464.1003.101.12.1001">
<originalText>Encounter, Performed:
Blood Pressure Visit</originalText>
<translation code="99202" codeSystem="2.16.840.1.113883.6.12"/>
</code>
<text>Encounter, Performed:
Blood Pressure Visit</text>
<statusCode code="completed"/>
<effectiveTime>
<low value="20121101120000"/>
<high value="20121101130000"/>
</effectiveTime>
</encounter>
</entry>
<entry>
<encounter classCode="ENC" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.22.4.49" />
<templateId root="2.16.840.1.113883.10.20.24.3.23" />
<id root="1.3.6.1.4.1.115" extension="5177f5807938a7ce61000281" />
<code code="185349003"
codeSystem="2.16.840.1.113883.6.96"
sdtc:valueSet="2.16.840.1.113883.3.464.1003.101.12.1048">
<originalText>Encounter, Performed:
Blood Pressure Visit</originalText>
<translation code="99202"
codeSystem="2.16.840.1.113883.6.12"/>
</code>
<text>Encounter, Performed:
Blood Pressure Visit</text>
<statusCode code="completed" />
<effectiveTime>
<low value="20121101120000" />
<high value="20121101130000" />
</effectiveTime>
</encounter>
</entry>
<entry>
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.22.4.2" />
<templateId root="2.16.840.1.113883.10.20.24.3.57" />
<id root="1.3.6.1.4.1.115" extension="5177f5807938a7ce61000285" />
<code code="8480-6"
codeSystem="2.16.840.1.113883.6.1"
sdtc:valueSet="2.16.840.1.113883.3.526.3.1032">
<originalText>Physical Exam, Finding:
Systolic Blood Pressure</originalText>
</code>
<statusCode code="completed"/>
<effectiveTime>
<low value="20120301120500"/>
<high value="20120301120500"/>
</effectiveTime>
<value xsi:type="PQ" value="127" unit="mmHg"/>
</observation>
</entry>
<entry>
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.22.4.2" />
<templateId root="2.16.840.1.113883.10.20.24.3.57" />
<id root="1.3.6.1.4.1.115" extension="5177f5807938a7ce6100028b" />
<code code="8480-6"
codeSystem="2.16.840.1.113883.6.1"
sdtc:valueSet="2.16.840.1.113883.3.526.3.1032">
<originalText>Physical Exam, Finding:
Systolic Blood Pressure</originalText>
</code>
<statusCode code="completed"/>
<effectiveTime>
<low value="20121101120000"/>
<high value="20121101120000"/>
</effectiveTime>
<value xsi:type="PQ" value="123" unit="mmHg"/>
</observation>
</entry>
<entry>
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.22.4.4" />
<templateId root="2.16.840.1.113883.10.20.24.3.11" />
<id root="1.3.6.1.4.1.115"
extension="5177f5807938a7ce6100027e"/>
<code code="282291009"
displayName="diagnosis"
codeSystem="2.16.840.1.113883.6.96"
codeSystemName="SNOMED-CT"/>
<text>Diagnosis, Active: Hypertension</text>
<statusCode code="completed"/>
<effectiveTime>
<low value="20120301123000"/>
<high nullFlavor="UNK"/>
</effectiveTime>
<value code="10725009"
codeSystem="2.16.840.1.113883.6.96"
xsi:type="CD"
sdtc:valueSet="2.16.840.1.113883.3.464.1003.104.12.1011">
<originalText>Diagnosis, Active: Hypertension</originalText>
<translation code="401.1"
codeSystem="2.16.840.1.113883.6.103"/>
</value>
<entryRelationship typeCode="REFR">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.22.4.6"/>
<templateId root="2.16.840.1.113883.10.20.24.3.94"/>
<id root="da6b50c0-9177-0130-01b7-12313d02bdec" />
<code code="33999-4"
codeSystem="2.16.840.1.113883.6.1"
codeSystemName="LOINC" displayName="status" />
<statusCode code="completed"/>
<value xsi:type="CD"
code="55561003"
displayName="active"
codeSystem="2.16.840.1.113883.6.96"
codeSystemName="SNOMED CT"/>
</observation>
</entryRelationship>
</observation>
</entry>
</section>
</component>
</structuredBody>
</component>
</ClinicalDocument>

If your first impression that this is bloated XML... you are not alone.

The primary cause of this "bloat" really traces its routes back to the HL7 Clinical Document Architecture and the HL7 RIM for expressing effectively anything (from individual patient records to Clinical Quality Measure procedural logic!) in XML. However, as much as I hate HL7 XML-based documents, there is a little bit of goodness with respect to the QRDA Category 1 XML for expressing patient-level data as inputs to Clinical Quality Measures.

Several HL7 standards have proven to demonstrate failures as inputs to Clinical Quality Measures; the HL7 Continuity of Care Document (CCD), the HITSP C32, or the Consolidated CDA. These are all general XML standards meant for expressing patient-level data for continuity of care from one provider to another via an XML format.

The silver lining on the QRDA Category 1 cloud is that once the clinical data that is needed for a particular CQM has been identified in an EHR system, the way to express that clinical data on a patient-by-patient basis is clear(er) and more tractable for systems that will need to parse and interoperate with the structured data.

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. © Rob McCready, 2013.