Difference between revisions of "HL7"

From Clinfowiki
Jump to: navigation, search
(2012 HL7 Initiatives)
(Update v3 section)
 
(10 intermediate revisions by 4 users not shown)
Line 1: Line 1:
'''Health Level Seven (HL7)''' provides standards for [[interoperability]] that reduce ambiguity and enhance data transfer among providers, government agencies, and [[EMR|electronic medical records]]. [http://www.hl7.org/about/FAQs/index.cfm]
+
HL7 is a standards development organization which has developed a number of standards relating to interoperability in healthcare informatics. Informally, the term often refers to version 2 of the HL7 messaging standard. "HL7 interfaces" using the HL7 v2 messaging standard power much of the connectivity between various systems such as EHRs, ancillary, laboratory, and billing.
  
== Mission statement ==
+
== HL7, the organization ==
 +
'''Health Level Seven International (HL7)''' is a non-profit, standards development organization which develops and promulgates standards for [[interoperability]] in clinical practice. The organization has more than 1,600 members from around the world, including corporate members representing healthcare providers, government stakeholders, payers, and various commercial interests. <ref>http://www.hl7.org/about/index.cfm</ref>
  
HL7 provides standards for interoperability that improve care delivery, optimize workflow, reduce ambiguity and enhance knowledge transfer among all of our stakeholders, including healthcare providers, government agencies, the vendor community, fellow SDOs and patients. In all of our processes we exhibit timeliness, scientific rigor and technical expertise without compromising transparency, accountability, practicality, or our willingness to put the needs of our stakeholders first.
+
HL7 is accreditated by ANSI (the American National Standards Institute), an umbrella organization for Standards Development Organizations in the US.
  
"Level Seven" refers to the seventh level of the International Organization for Standardization (ISO) seven-layer communications model for Open Systems Interconnection (OSI) - the application level. The application level interfaces directly to and performs common application services for the application processes. Although other protocols have largely superseded it, the OSI model remains valuable as a place to begin the study of network architecture. [http://www.hl7.org/about/index.cfm]
+
The term "Level Seven" refers to the seventh level in the seven-layer [[wikipedia:OSI model|OSI model]] Open Systems Interconnection (OSI) communications model - the application level. The application level interfaces directly to and performs common application services for the application processes. HL7's protocols largely exist at the application layer, providing the infrastructure for various applications to interconnect seamlessly.
  
== History ==
+
== HL7 Messaging Standard Version 2 ==
  
Founded in 1987, the Health Level Seven (HL7) protocol and corporation behind it are a standard means for exchanging clinical data.  Currently in its third version, this standard describes a framework for the exchange of messages related to patient registrations, lab results, pharmaceutical orders, inventory, billing, et cetera between and within care-delivery systems and organizations.  “Health Level Seven” is an allusion to the Open Systems Interconnection (OSI) model’s “Level Seven”, the conceptual network layer at which data is exchanged between applications and the lower networking layers and infrastructure.  As such, the protocol accepts data from disparate applications, packages it into an appropriately formatted message type with various header and identifying information, and facilitates its transmission across TCP/IP connections between machines hosting these applications.
+
Currently the most common iteration of the HL7 standard is version 2.x.  Messages in this version rely on “triggers” to define the exchange of data.  Specific message types exist to signal Admissions, Discharges, and Transfers (ADTs), lab results (ORU), medication administration (RAS) events, and so onFor example, upon admission of a patient to a hospital, the registration system generates and populates an “ADT” message, of type “A01”.  This message is populated with demographic information, visit information, and diagnoses about the admitted patient, and is then sent to the various systems in a healthcare organization that need to know about the admission. The concept of event-based triggers is central to HL7 v2; other event types include ORU ("unsolicited observation message"), OMG ("General clinical Order Message"), OML ("Laboratory Order Message"), and scores of others. The HL7 standard specifies what content must (or may) be included in each of these message types.
 
+
== History of version 2 ==
+
 
+
Currently the most common iteration of the HL7 standard is version 2.x.  Messages in this version rely on “triggers” to define the exchange of data.  Specific message types exist to signal Admissions, Discharges, and Transfers (ADTs), lab results (ORU), medication administration (RAS) events, et ceteraUpon, e.g., admission of a patient to a hospital, the registration system generates and populates an “ADT” message, of type “A01”.  This message is populated with demographic information about the patient recently admitted, to include name and address, next-of-kin information, allergies, and related/relevant diagnoses.  Each of these bundles of information is relayed inside an ordered set of reusable “segment” of the message; e.g., Patient IDentifiers are placed inside a segmented component of the ADT message called a “PID segment”. Discrete pieces of information are separated by “delimiters”, which themselves are meaningful; e.g., “…|LastName^FirstName|…|DateOfBirth|Sex|…” might represent a portion of the PID segment, and is delimited using the ‘|’ character to set apart conceptual entities (e.g., name and date-of-birth), and the ‘^’ characer to set apart components of those entities (e.g., first and last name).  Some of these components and fields are allowed to repeat, such that a single lab result message may contain the results of several ordered labs for a given patient. The various segments which comprise the HL7 message are then prefixed with a MeSsage Header (MSH) segment, describing the message itself, (optionally) an EVeNt (EVN) segment, describing the event which “triggered” that message, and then transmitted through a TCP/IP connection to a receiving application’s interface server where the message is parsed into component values and consumed.
+
  
 +
An HL7 message is structured as a ordered set of reusable “segments”. For example, Patient Identifiers are placed in a segment beginning with PID. Within that segment, discrete pieces of information are separated by “delimiters” into fields, which is typically the | (pipe) character. The fields can be further divided into subfields. For example, the contents of the name field might be <code>DUCK^DONALD D</code> with the last name and first name separated into subfields. Some of these components and fields are allowed to repeat, such that a single lab result message may contain the results of several ordered labs for a given patient.  The various segments which comprise the HL7 message are then prefixed with a MeSsage Header (MSH) segment, describing the message itself, (optionally) an EVeNt (EVN) segment, describing the event which “triggered” that message, and then transmitted through a TCP/IP connection to a receiving application’s interface server where the message is parsed into component values and consumed.
  
 
==== Example ====
 
==== Example ====
Line 20: Line 18:
 
An example of an HL7 message follows.  Note how quickly you can guess the meanings of the fields and even segments within this message signaling the admission of a patient:
 
An example of an HL7 message follows.  Note how quickly you can guess the meanings of the fields and even segments within this message signaling the admission of a patient:
  
MSH|^~\&|||||200501100455||ADT^A01|ADT66561|P|2.3|||||||  
+
MSH|^~\&|||||200501100455||ADT^A01|ADT66561|P|2.3|||||||  
PID|||10006579||DUCK^DONALD D||19241010|M|||111^QUACK ST^^FOWL^CA^99999^^R||8885551212|||||40007716|123121234
+
PID|||10006579||DUCK^DONALD D||19241010|M|||111^QUACK ST^^FOWL^CA^99999^^R||8885551212|||||40007716|123121234
PV1||I|PREOP^101^1||||37^DISNEY^WALT|||||||||||I||||||||||||||||||||||||||200501100452  
+
PV1||I|PREOP^101^1||||37^DISNEY^WALT|||||||||||I||||||||||||||||||||||||||200501100452  
DG1|1|||OSTEOARTHROS NOS-L/LEG
+
DG1|1|||OSTEOARTHROS NOS-L/LEG
  
== Version 3 new additions ==
+
== HL7 v3 Reference Information Model==
 +
 
 +
Unlike HL7 v2 which is a messaging spec, HL7 v3 is fundamentally a data model. While HL7 v2 was a communication protocol which evolved over time to encompass more and more use cases, the HL7 v3 RIM was designed top-down as a data model to accomodate all the needs of healthcare data. In addition, while HL7 v2 allows a lot of flexibility in how it is used (especially in terms of the semantics of the data), v3 specifies a lot of semantic aspects of data encoding.
 +
 
 +
Unlike HL7 v2 which was adopted very widely across healthcare, HL7 v3 did not have similar levels of adoption. One aspect that did gain significant adoption was the [Clinical Document Architecture (CDA)]. CDA is an architecture for XML documents which can be viewed and exchanged across EHRs. A feature of the CDA is its ability to be viewed in a browser using a single style sheet, ensuring everyone can read the record. Structured information can also be recorded and be used in different systems. The information is recognizable by different systems through use of shared terminology, such as [[SNOMED]] and [[LOINC]].
 +
 
 +
 
 +
The HL7 [[Clinical Document Architecture (CDA)]] is an ANSI standard with release 2 being published early in 2005 [http://www.hl7.org]. Like other HL7 standards it is based on the reference information model (RIM) and is designed to capture information as a document and then be stored in EHR systems.
 +
 
 +
Version 3 also included other enhancements over v2:
  
 
#Top-down message development emphasizing reuse across multiple contexts
 
#Top-down message development emphasizing reuse across multiple contexts
Line 36: Line 43:
  
  
The HL7 Clinical Document Architecture is an ANSI standard with release 2 being published early in 2005 [http://www.hl7.org]. Like other HL7 standards it is based on the reference information model (RIM) and is designed to capture information as a document and then be stored in EHR systems.
+
==== CDA example ====
 +
The below 23 lines are excerpted and deidentified from a 784-line CDA document representing a single outpatient visit. In an HL7 v2 message, this information would all be represented as part of the PID segment. In this message (which is in XML) every single piece of data is explicit, including references to the vocabularies specifying each element. For example, one could look up the code system used for the race code at https://phinvads.cdc.gov/vads/ViewCodeSystem.action?id=2.16.840.1.113883.6.238 , which shows 966 coded options for race.
  
== Features ==
+
  <recordTarget>
 +
      <patientRole classCode="PAT">
 +
        <id root="2.16.840.1.113883.4.391.21502" extension="10150" assigningAuthorityName="eClinicalWorks" />
 +
        <addr>
 +
            <city>Kalamazoo</city>
 +
            <streetAddressLine>123 Main Street #2</streetAddressLine>
 +
            <state>MI</state>
 +
            <country>USA</country>
 +
            <postalCode>12345</postalCode>
 +
        </addr>
 +
        <telecom value="333-444-5555" />
 +
        <patient>
 +
            <name>
 +
              <family>Mouse</family>
 +
              <given>Mickey</given>
 +
            </name>
 +
            <administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1" />
 +
            <birthTime value="19720301" />
 +
            <raceCode code="2106-3" codeSystem="2.16.840.1.113883.6.238" displayName="White" />
 +
            <ethnicGroupCode code="2186-5" codeSystem="2.16.840.1.113883.6.238" displayName="Not Hispanic or Latino" />
 +
        </patient>
 +
      </patientRole>
 +
  </recordTarget>
  
A feature of the CDA is its ability to be viewed in a browser using a single style sheet, ensuring everyone can read the record. Structured information can also be recorded and be used in different systems. The information is recognizable by different systems through use of shared terminology, such as [[SNOMED]] and [[LOINC]].
 
 
== Inter nationality ==
 
 
The CDA standard holds great potential for sharing information and is being trialled in many countries including the Netherlands, Spain, Germany, Japan and Mexico to name a few.
 
 
== 2012 HL7 Initiatives ==
 
 
1  S T R A T E G I C I N I T I A T I V E S - S U M M A R Y
 
 
HL7 Recognition: Attain recognition as the lead developer and harmonizer of global
 
technical and functional health informatics standards
 
• Realm specifications have been advanced to international HL7 specifications
 
• International HL7 specifications have achieved ISO recognition
 
• Global adoption has increased
 
• HL7's role and value proposition in the overarching standards landscape has
 
been clarified
 
• Key stakeholder groups have been identified, with value propositions and action
 
plans for engaging each group
 
 
HL7 Internal Processes: Streamline the HL7 standards development process
 
• A globally applicable business model has been developed
 
• Working Group Meetings have been effective
 
• Product quality has improved
 
• End to end V3/CDA template and implementation guide infrastructure has been
 
developed
 
• Requirements traceability has been enabled
 
• Cross-artifact inconsistency is reduced
 
 
HL7 Implementation: Develop standards that are easier to implement and more
 
responsive to customer needs
 
• Industry responsiveness has been demonstrated through the timely development
 
and maintenance of key standards
 
• HL7 Standards implementation has gotten easier
 
• HL7 Education Plan has been developed
 
• Tooling strategy has been developed
 
 
2  S T R A T E G I C I N I T I A T I V E S - D E T A I L E D 
 
 
2.1 HL7 Recognition: Attain recognition as the lead developer and
 
harmonizer of global technical and functional health informatics
 
standards
 
o Description: Assume a leadership position in the development of global
 
technical and functional health informatics standards for electronic health
 
records, personal health records, health information exchange, and clinical and
 
operational data representation. 
 
 
2.1.1 Realm specifications have been advanced to international HL7
 
specifications
 
o Description: Standards that have been successfully deployed in a limited
 
number of realms are brought to ballot within HL7 as Universal Realm
 
specifications. 
 
 
2.1.2 International HL7 specifications have achieved ISO recognition
 
o Description: Universal Realm HL7 standards are advanced to ISO recognition,
 
so that barriers to adoption across the globe are resolved, their use becomes
 
ubiquitous, barriers to health information exchange across country boundaries
 
are lessened, and those implementing standards have an international market.
 
 
2.1.3 Global adoption has increased
 
o Description: "Adoption" is a decision to implement or use an HL7 standard. It
 
can refer to choosing HL7 standards, and/or incorporating HL7 standards into
 
the "outside world" (external to HL7) (e.g. RFPs, strategies, specifications,
 
software). 
 
 
2.1.4 HL7's role and value proposition in the overarching standards landscape
 
has been clarified
 
o Description: HL7 must work closely with national (for example, ONC, US TAG to
 
ISO, NHS, Infoway, NEHTA), international (for example, ISO JIC, IHE, IHTSDO),
 
and other complementary (such as. NQF, CIHI) stakeholder groups so as to
 
ensure a complete interoperability solution including implementation guides.
 
HL7's role, and HL7's relationship to these other organizations, needs to be
 
clear, so as to minimize duplication of effort and the cost of standards adoption.
 
 
2.1.5 Key stakeholder groups have been identified, with value propositions and
 
action plans for engaging each group
 
o Description: Groups that play a valuable role in the development of HL7
 
standards, whether through technical development, functional requirement or
 
identification have been defined. There is a written plan that describes how HL7
 
will seek to engage and involve each group in the standards development
 
process. 2.2 HL7 Internal Processes: Streamline the HL7 standards
 
development process
 
 
o Description: Optimize HL7 internal processes to more efficiently deliver global
 
and realm-specific standards.
 
 
2.2.1 A globally applicable business model has been developed 
 
o Description: An efficient HL7 standards development process relies on
 
engagement and contributions from across the globe. Components of a globally
 
applicable business model include, but are not limited to, policy for use and
 
redistribution of HL7 IP, membership and governance, and dues structure.
 
 
2.2.2 Working Group Meetings have been effective
 
o Description: Ensure that all WGMs have all strategic business areas
 
represented by healthy Work Groups as measured by the TSC with appropriate
 
cross section of expertise.
 
 
2.2.3 Product quality has improved
 
o Description: Product quality can be defined as "fitness for purpose". As part of
 
quality improvement, there is a need to clearly define the purpose for which a
 
standard is created, and to articulate the desired fitness criteria. 
 
 
2.2.4 End to end V3/CDA template and implementation guide infrastructure
 
has been developed
 
o Description: A template infrastructure supports requirements analysis,
 
development of templates that are consistent with domain models, and instance
 
validation. This infrastructure must align with other Strategic Initiatives (e.g.
 
must facilitate standards implementation), and must address the potential for
 
layered complexity, where one artifact constrains another, which constrains
 
another, and so on. 
 
 
Implementation guides further profile or characterize the use of an HL7
 
standard, and may describe how HL7 specifications operate within a broader
 
health information exchange ecosystem. Infrastructure supports publishing and
 
development of sample instances. The requirement is for infrastructure that
 
provides for the development of *consistent* implementation guides, with easy to
 
use human and machine readable representations. 
 
 
2.2.5 Requirements traceability has been enabled
 
o Description: Traceability refers to the ability to link back, from a specification to
 
the requirements that lead to its development, to the requirements that lead to
 
certain design decisions. 2.2.6 Cross-artifact inconsistency is reduced
 
o Description: This applies within a product "family" and between families (CDA,
 
messages, services). Once inconsistencies can be measured, and once we have a
 
plan for decreasing inconsistencies, we need to execute the plan and measure
 
the effects.
 
 
2.3 HL7 Implementation: Develop standards that are easier to
 
implement and more responsive to customer needs
 
o Description: Improve HL7 processes to enable clinicians, technical experts,
 
policy makers, SDOs and other stakeholder to collaborate in the development of
 
standards and related solutions that are easier to implement, and more
 
efficiently deliver global and realm-specific standards in response to new
 
"customer" requirements. 
 
 
2.3.1 Industry responsiveness has been demonstrated through the timely
 
development and maintenance of key standards
 
o Description: HL7 demonstrates its ability to assess and respond to key
 
interoperability challenges (e.g. a nationally prioritized interoperability use case)
 
and business needs through the timely development of relevant standards.
 
 
2.3.2 HL7 Standards implementation has gotten easier
 
o Description: "Implementation" refers to the use of HL7 material in the
 
development of software applications and messaging systems, for the exchange
 
of health information. 
 
 
2.3.3 HL7 Education Plan has been developed
 
o Description: An education plan lays the HL7 strategy for dramatically
 
increasing the number of folks with V3/CDA implementation-level knowledge.
 
HL7 should be supporting the delivery of training - both training developed and
 
provided by HL7, and that developed and provided by the market. Demand for
 
HL7 products can be stimulated by both direct and indirect users of HL7 (an
 
example of the former is implementers of HL7-based products and the latter is a
 
user of HL7-based products). 
 
 
2.3.4 Tooling strategy has been developed
 
o Description: Efficiency in HL7 implementation is supported by tools. Tools
 
developed for internal HL7 use are also of use externally. Components of a
 
tooling strategy include, but are not limited to, prioritization of new tool
 
development vs. ongoing support of existing tools, process for evaluating and
 
incorporating externally developed tools.
 
 
2.3.5 Product strategy has been developed
 
o Description: An HL7 product strategy and roadmap have been developed. 
 
Today, HL7 products are often organized to reflect how the product (standard) was developed.  The product strategy should address organizing and packaging
 
of products in ways that implementers of standards find useful.  The product
 
strategy should look at the products already held out as products and determine
 
those that have a position where they can exist independent of other products,
 
or as part of a formal product we have not yet recognized.
 
 
Submitted by Leah Lewis
 
 
[[Category:BMI512-FALL-2012]]
 
  
 
== References ==
 
== References ==
  
Dolin RH, Alschuler L, Boyer S, Beebe C, Behlen FM, Biron PV, Shabo A. [http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=Retrieve&db=pubmed&dopt=Abstract&list_uids=16221939&query_hl=1 HL7 Clinical Document Architecture, Release 2.] J Am Med Inform Assoc. 2005 Oct 12;
+
# Dolin RH, Alschuler L, Boyer S, Beebe C, Behlen FM, Biron PV, Shabo A. [http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?cmd=Retrieve&db=pubmed&dopt=Abstract&list_uids=16221939&query_hl=1 HL7 Clinical Document Architecture, Release 2.] J Am Med Inform Assoc. 2005 Oct 12;
 
+
# http://www.hl7.org/documentcenter/public_temp_4BF5D005-1C23-BA17-0CE1A58E38D45506/strategic/roadmap/HL7_2012_Strategic_Initiatives%20FINAL.pdf
http://www.hl7.org/documentcenter/public_temp_4BF5D005-1C23-BA17-0CE1A58E38D45506/strategic/roadmap/HL7_2012_Strategic_Initiatives%20FINAL.pdf
+
# Dolin RH, Alschuler L, Boyer S, Beebe C, Behlen FM, Biron PV, Shabo Shvo A. [http://www.ncbi.nlm.nih.gov/pubmed/16221939| HL7 Clinical Document Architecture, Release 2]. J Am Med Inform Assoc. 2006 Jan-Feb;13(1):30-9. Epub 2005 Oct 12.
 +
<references/>
  
 
[[Category:EHR standard]]
 
[[Category:EHR standard]]
 
[[Category:Definition]]
 
[[Category:Definition]]
 +
[[Category:Terminology and Coding]]
 +
[[Category:Interoperability]]
  
 +
Submitted by Leah Lewis
 +
[[Category:BMI512-FALL-12]]
  
== References ==
+
Updated by Michael Kopinsky
 
+
[[Category:BMI512-Spring-17]]
# Dolin RH, Alschuler L, Boyer S, Beebe C, Behlen FM, Biron PV, Shabo Shvo A. [http://www.ncbi.nlm.nih.gov/pubmed/16221939| HL7 Clinical Document Architecture, Release 2]. J Am Med Inform Assoc. 2006 Jan-Feb;13(1):30-9. Epub 2005 Oct 12.
+

Latest revision as of 14:16, 1 May 2017

HL7 is a standards development organization which has developed a number of standards relating to interoperability in healthcare informatics. Informally, the term often refers to version 2 of the HL7 messaging standard. "HL7 interfaces" using the HL7 v2 messaging standard power much of the connectivity between various systems such as EHRs, ancillary, laboratory, and billing.

HL7, the organization

Health Level Seven International (HL7) is a non-profit, standards development organization which develops and promulgates standards for interoperability in clinical practice. The organization has more than 1,600 members from around the world, including corporate members representing healthcare providers, government stakeholders, payers, and various commercial interests. [1]

HL7 is accreditated by ANSI (the American National Standards Institute), an umbrella organization for Standards Development Organizations in the US.

The term "Level Seven" refers to the seventh level in the seven-layer OSI model Open Systems Interconnection (OSI) communications model - the application level. The application level interfaces directly to and performs common application services for the application processes. HL7's protocols largely exist at the application layer, providing the infrastructure for various applications to interconnect seamlessly.

HL7 Messaging Standard Version 2

Currently the most common iteration of the HL7 standard is version 2.x. Messages in this version rely on “triggers” to define the exchange of data. Specific message types exist to signal Admissions, Discharges, and Transfers (ADTs), lab results (ORU), medication administration (RAS) events, and so on. For example, upon admission of a patient to a hospital, the registration system generates and populates an “ADT” message, of type “A01”. This message is populated with demographic information, visit information, and diagnoses about the admitted patient, and is then sent to the various systems in a healthcare organization that need to know about the admission. The concept of event-based triggers is central to HL7 v2; other event types include ORU ("unsolicited observation message"), OMG ("General clinical Order Message"), OML ("Laboratory Order Message"), and scores of others. The HL7 standard specifies what content must (or may) be included in each of these message types.

An HL7 message is structured as a ordered set of reusable “segments”. For example, Patient Identifiers are placed in a segment beginning with PID. Within that segment, discrete pieces of information are separated by “delimiters” into fields, which is typically the | (pipe) character. The fields can be further divided into subfields. For example, the contents of the name field might be DUCK^DONALD D with the last name and first name separated into subfields. Some of these components and fields are allowed to repeat, such that a single lab result message may contain the results of several ordered labs for a given patient. The various segments which comprise the HL7 message are then prefixed with a MeSsage Header (MSH) segment, describing the message itself, (optionally) an EVeNt (EVN) segment, describing the event which “triggered” that message, and then transmitted through a TCP/IP connection to a receiving application’s interface server where the message is parsed into component values and consumed.

Example

An example of an HL7 message follows. Note how quickly you can guess the meanings of the fields and even segments within this message signaling the admission of a patient:

MSH|^~\&|||||200501100455||ADT^A01|ADT66561|P|2.3||||||| 
PID|||10006579||DUCK^DONALD D||19241010|M|||111^QUACK ST^^FOWL^CA^99999^^R||8885551212|||||40007716|123121234
PV1||I|PREOP^101^1||||37^DISNEY^WALT|||||||||||I||||||||||||||||||||||||||200501100452 
DG1|1|||OSTEOARTHROS NOS-L/LEG

HL7 v3 Reference Information Model

Unlike HL7 v2 which is a messaging spec, HL7 v3 is fundamentally a data model. While HL7 v2 was a communication protocol which evolved over time to encompass more and more use cases, the HL7 v3 RIM was designed top-down as a data model to accomodate all the needs of healthcare data. In addition, while HL7 v2 allows a lot of flexibility in how it is used (especially in terms of the semantics of the data), v3 specifies a lot of semantic aspects of data encoding.

Unlike HL7 v2 which was adopted very widely across healthcare, HL7 v3 did not have similar levels of adoption. One aspect that did gain significant adoption was the [Clinical Document Architecture (CDA)]. CDA is an architecture for XML documents which can be viewed and exchanged across EHRs. A feature of the CDA is its ability to be viewed in a browser using a single style sheet, ensuring everyone can read the record. Structured information can also be recorded and be used in different systems. The information is recognizable by different systems through use of shared terminology, such as SNOMED and LOINC.


The HL7 Clinical Document Architecture (CDA) is an ANSI standard with release 2 being published early in 2005 [1]. Like other HL7 standards it is based on the reference information model (RIM) and is designed to capture information as a document and then be stored in EHR systems.

Version 3 also included other enhancements over v2:

  1. Top-down message development emphasizing reuse across multiple contexts
  2. Representation of complex temporal and non-temporal relationships
  3. Formalisms for vocabulary support
  4. Support for large scale integration
  5. Solving the identifiers problem
  6. Solving re-use and interoperability across multiple domain contexts
  7. Expanded scope to include community medicine, epidemiology, veterinary medicine, clinical #genomics, security, etc.


CDA example

The below 23 lines are excerpted and deidentified from a 784-line CDA document representing a single outpatient visit. In an HL7 v2 message, this information would all be represented as part of the PID segment. In this message (which is in XML) every single piece of data is explicit, including references to the vocabularies specifying each element. For example, one could look up the code system used for the race code at https://phinvads.cdc.gov/vads/ViewCodeSystem.action?id=2.16.840.1.113883.6.238 , which shows 966 coded options for race.

  <recordTarget>
     <patientRole classCode="PAT">
        <id root="2.16.840.1.113883.4.391.21502" extension="10150" assigningAuthorityName="eClinicalWorks" />
        <addr>
           <city>Kalamazoo</city>
           <streetAddressLine>123 Main Street #2</streetAddressLine>
           <state>MI</state>
           <country>USA</country>
           <postalCode>12345</postalCode>
        </addr>
        <telecom value="333-444-5555" />
        <patient>
           <name>
              <family>Mouse</family>
              <given>Mickey</given>
           </name>
           <administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1" />
           <birthTime value="19720301" />
           <raceCode code="2106-3" codeSystem="2.16.840.1.113883.6.238" displayName="White" />
           <ethnicGroupCode code="2186-5" codeSystem="2.16.840.1.113883.6.238" displayName="Not Hispanic or Latino" />
        </patient>
     </patientRole>
  </recordTarget>


References

  1. Dolin RH, Alschuler L, Boyer S, Beebe C, Behlen FM, Biron PV, Shabo A. HL7 Clinical Document Architecture, Release 2. J Am Med Inform Assoc. 2005 Oct 12;
  2. http://www.hl7.org/documentcenter/public_temp_4BF5D005-1C23-BA17-0CE1A58E38D45506/strategic/roadmap/HL7_2012_Strategic_Initiatives%20FINAL.pdf
  3. Dolin RH, Alschuler L, Boyer S, Beebe C, Behlen FM, Biron PV, Shabo Shvo A. HL7 Clinical Document Architecture, Release 2. J Am Med Inform Assoc. 2006 Jan-Feb;13(1):30-9. Epub 2005 Oct 12.
  1. http://www.hl7.org/about/index.cfm

Submitted by Leah Lewis

Updated by Michael Kopinsky