Channels ▼
RSS

Web Development

Healthcare Information Integration


Using HL7 to Encode Telehealth Data

The HL7 v3 CDA Release 2 [4] is the ideal vehicle for health-care data integration. It is an informatics standard based on years of industry expertise, it represents health-care documents in their purest form, ranging from a progress report, to a discharge summary, to capturing an MRI study as a standard image set. The HL7 CDA can scale easily from early to advanced stages of adoption: it can represent a container with basic summary information (such as basic patient demographics, ordering physician, and a facsimile of a lab result stored as an attachment), to a container with a longitudinal health record. The standard is both precise and adaptable, as demonstrated by the Continua xHR Implementation Guide [3], a variant of the CDA developed to define the Personal Health Monitoring Report (PHMR) [10].

The real ingenuity of the CDA is the overlay of a series of templates or constraints to the v3 RIM, to uniquely identify and encode sections of a clinical document in a standard and semantically meaningful way. The HL7 v3 Continuity of Care Document (CCD) [9] was one of the first broadly implemented set of constraints applied to the HL7 CDA Release 2 [4], and it was selected by HITSP as the basis of their implementation guides. There are now a whole complement of implementation guides based on either the umbrella CDA or on the further constrained CCD, all of which aim to deliver both human-readable and machine-consumable clinical information in a systematized fashion.

Assigned Author

The HL7 CDA supports the concept of the Assigned Author being either a human or a device, as depicted in Listing 1.


<!-- when the CDA is compiled/reviewed by a Clinician -->
<author>
	<assignedAuthor>
		<assignedPerson>
		…
		</assignedPerson>
	</assignedAuthor>
</author>
<!-- when the CDA is created by a system or device -->
<author>
	<assignedAuthor>
		<assignedAuthoringDevice>
		…
		</assignedAuthoringDevice>
	</assignedAuthor>
</author>

Listing 1: Machine-Computable XML: Assigned Author (Source: Intel Corporation, 2009)

In some cases, a summary report of RPM is generated along with clinical notes, as part of a transfer of care or a request for consultation, and the use of a human Assigned Author makes perfect sense. In other cases, information is automatically collected by RPM devices, compiled into an HL7 CDA, and forwarded to other health-care systems for subsequent clinical analysis. In this latter case, there is no human author who can be assigned, as the information has yet to be reviewed by any clinical personnel. Similarly, while some regions may require legal authentication of a clinical document, other regions may delegate legal authentication to a device or system, and still others may opt to release a clinical document prior to legal authentication. The HL7 PHMR does an excellent job of both considering and supporting each of these variations in usage models [10].

Medical Equipment

The HL7 PHMR [10] (based upon the work of the Continua Health Alliance [3]) does a thorough job of specifying required peripheral manufacturer information. Table 1 and Listing 2 show the Medical Equipment section from the HL7 PHMR [10], depicting both the XML-rendered table and a subset of the machine-computable section for a single device, respectively.

Table 1: XML-Rendered table: medical equipment (Source: Health Level Seven, 2009 [10])


<title>Medical Equipment</title>
 …
<!-- Note the use of the IEEE EUI-64 unique peripheral DeviceID, used to establish a link between Medical Equipment peripheral and reference measurements in the Vital Signs section -->
<id root="1.2.840.10004.1.1.1.0.0.1.0.0.1.2680" assigningAuthorityName="EUI-64" extension="1F-3E-46-78-9A-BC-DE-F1"/>
 …
<!-- standard device encoding via SNOMED CT -->
<playingDevice>
<code code="32033000" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Arterial pressure monitor">
<!-- translated device encoding via MDC -->
<translation code="MDC_DEV_SPEC_PROFILE_BPM" codeSystem="2.16.840.1.113883.6.24" codeSystemName="MDC" displayName="Blood Pressure Monitor"/>
</code>
<manufacturerModelName>…</manufacturerModelName>
</playingDevice>

Listing 2: Machine-computable XML: medical equipment (Source: Health Level Seven, 2009 [10])

Note the significance of the use of standard terminology in Code 2, which leverages both SNOMED CT and MDC code sets (refer to "code/code system…translation code/code system"). This semantic encoding is what makes the information machine-computable and enables interoperability. Systems can transform the terminology to other standard and proprietary formats, precisely because the standard is encoded in the first place, just like the Rosetta Stone. Semantic interoperability is essential to enable clinical research and to facilitate queries across a wide variety of data sources; however, semantic exchange is only possible if the terminology has been first normalized to one of a few dozen international health-care terminology standards.

Levels of Interoperability

Semantic interoperability is the highest form of data integration, such that receiving systems can readily and precisely consume information, encoded with standard terminologies and code sets, with no loss of meaning or context for abstract terms and concepts. This is the goal of the HL7 v3 Reference Information Model (RIM).

Syntactic interoperability, the next lower form of data integration, exchanges information by using agreed-upon syntax. A set of fields are specified along with their syntax, but nothing is specified as to the possible range of values or meaning. Prior messaging standards tended to stop short at syntax: they did not address the crucial last step of semantics, and therefore left an incomplete data standard wide open to conflicting interpretation and incompatible implementations. For example, the earlier versions of HL7 v2.x messages focused almost exclusively on syntax, and hence the expression "every v2.x interface is a new v2.x interface." Each implementation added proprietary interpretations and extensions over time.

Integration at the lower five levels of the OSI model focus on standardizing transport, protocol, and security, which is also the primary focus of such groups as W3C, Continua, IHE, and IEEE. Technology standards are optimal to address the exchange on the wire, while health-care domain expertise is optimal to address the syntax and semantics of the exchange.

Vital Signs

Table 2 shows a sample of the Vital Signs section of a PHMR, depicting the XML-rendered table, while Listing 3 depicts a subset of the machine-computable section for a single measurement. This example highlights the dual role of the CDA construct: to provide highly accessible information viewable by clinicians in a concise, easy-to-read format, along with a fully encoded, machine-consumable version of the same information, capable of supporting any degree of advanced analytics and clinical workflow. It is common in fact for information in the machine-consumable section to be richer than that depicted in the XML-rendered table. For example, the XML-rendered table might present only summary or trend information, whereas it is perfectly acceptable for the machine-consumable segment to include both raw and summary information.

Table 2: XML-rendered table: vital signs (Source: Intel Corporation, 2009)


<title>Vital Signs</title>
…
<!-- standard encoding for Systolic readings -->
<code code="271649006" codeSystem="2.16.840.1.113883.6.96" displayName="Systolic"/> 
…
<!-- actual Systolic measurement -->
<value xsi:type="PQ" value="137" unit="mm[Hg]"/> 
<!-- interpretation code indicates reading is Abnormal, based upon referenceRange cited below -->
<interpretationCode code="A" codeSystem="2.16.840.1.113883.5.83"/> 
…
<!-- Note the use of the IEEE EUI-64 unique peripheral DeviceID, used to establish reference between a measurement in Vital Signs to originating peripheral details in the Medical Equipment section -->
<participant typeCode="DEV"> 
	<participantRole>
<id root="1.2.840.10004.1.1.1.0.0.1.0.0.1.2680" assigningAuthorityName="EUI-64" extension="1F-3E-46-78-9A-BC-DE-F1"/>
	</participantRole>
</participant>
<!-- referenceRange cites the lower and upper measurement thresholds considered out-of-range or abnormal -->
<referenceRange>
	<observationRange>
		<value xsi:type="IVL_PQ">
		<low value="89" unit="mm[Hg]"/>
		<high value="130" unit="mm[Hg]"/>
		</value>
	</observationRange>
</referenceRange>

Listing 3: Machine-computable XML: vital signs (Source: Intel Corporation, 2009)

Note also the use of Observation/interpretationCode and Observation/referenceRange in Code 3, to indicate whether a particular reading is considered within or outside of the reference range for that measurement type. These data elements are optional, but are strongly encouraged as industry best practice (i.e., "SHOULD") by the HL7 PHMR [10]. Inclusion of this information is crucial to be able to quickly perform patient triage as well as trending analysis and population management.

Functional Status

Remote patient monitoring has a clear need for including questionnaire assessments as a part of Functional Status. Assessments can range from standard question-answer sets, recognized regionally as the authoritative protocol for a given disease condition, to proprietary question-answer sets, designed by particular institutions along with customized care plans. The standard assessments are routinely used by payers and providers alike to gauge individual patient functional status and assess overall population trending. The HITSP Long Term Care–Assessments AHIC Gap/Extension [13] lists several assessments applicable to the United States, including the Long-Term Care Minimum Data Set (MDS), the Continuity Assessment Record and Evaluation (CARE), the Outcome and Assessment Information Set (OASIS), and the Inpatient Rehabilitation Facility-Patient Assessment Instrument (IRF-PAI). There are widely recognized instruments worldwide for managing chronic disease conditions such as diabetes, congestive heart failure, asthma, or depression. Assessments can also be utilized as part of pre-qualification and patient recruitment for clinical trials.

AHIC and HITSP acknowledged the gap in the lack of specifications related to assessments, and worked with HL7 to develop the CDA Framework for Questionnaire Assessments DSTU [8]. Standardized information, templates, guidelines, schedules, and scoring mechanisms are all needed to fully comprehend assessments within the HL7 CDA. Currently, work is divided amongst several different teams, including HITSP Consultation and Transfer of Care; Quality; and Long Term Care Assessments: all are working in conjunction with the HL7 Patient Care Work Group, the HL7 Structured Documents Work Group, and a broad array of clinical and technology industry experts.

Some assessment instruments have the concept of weighted points associated with particular question responses, which can then be used to triage patients who require immediate intervention. An extension of this is the concept of a Scored Care Plan Report, with higher patient acuity associated with higher points assigned to more significant health indicators. For example, Congestive Heart Failure patients might score a 0 if they are coping well on a particular day, versus a 5 or 6 if they suddenly put on additional weight or notice swelling in their legs. The ability to encode this information by using standard CDA templates, constraints, and appropriate terminology would be extremely powerful to drive both analytics and clinical workflow.

The great news is that both the CDA and specializations such as the HL7 PHMR permit the addition of optional sections such as Functional Status to represent this type of information. However, for a system to accurately consume and mediate the information, it would still require extensions to the specification. The work to date from the CDA Framework for Questionnaire Assessments DSTU [8] is outstanding in this regard, in making such rapid progress in such a short period of time. The framework is very thorough and nuanced in its handling of diverse use cases, both enabling early adoption while parts of the specification are yet to be finalized, as well as demonstrated capability to instrument very complex assessments, as evidenced by the derivative work on the Minimum Data Set Version 3 (MDSV3) [8]. We urge the SDOs to continue to aggressively pursue work in this area, essential to all forms of RPM, long-term care, and other clinical settings.

In Table 3, we show an example of how we might render assessment responses in human-readable form.

Table 3: XML-rendered table: functional status (Source: Intel Corporation, 2009)

High priority should be placed on standardizing the templates to encode patient assessments, including terminology, along with the concept of assessment scales or scores where relevant.

Plan of Care

Multiple SDOs and HITSP working groups are planning to address Plan of Care as it relates to Consultations and Transfers of Care [5]. This is another example of the power and flexibility of the CDA architecture. While a traditional treatment plan might be best characterized by a set of multidisciplinary protocols and a follow-up planned upon hospital discharge, in RPM it takes on a different character altogether. Plan of Care includes functional and other nursing assessments (not to be confused with physician assessments of patient status, which are located in the CDA "Assessment and Plan" section).

A Plan of Care is used to capture "What did we ask the patient to do?" whereas the combination of daily assessments and vital sign collection is the answer to "What did the patient actually do?" Thus, the combination of Plan of Care, Functional Status, and Vital Signs can be used to gauge patient adherence to the agreed-upon treatment plan, and can be used as a basis for long-term outcomes analysis with respect to RPM. We would like to see the SDOs create Plan of Care section constraints that cover both definition and scheduling of standard assessments and vital signs collection. Such constraints would be machine-consumable by different systems and encoded, by the use of international terminology standards, to promote advanced analytics.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 
Dr. Dobb's TV