Adopting the NIEM for Health Information Exchange

A National Information Exchange Model (NIEM) Information Exchange Package Documentation (IEPD) for health information exchange is being considered by the U.S. Department of Health and Human Services Office of the National Coordinator (ONC). After years of work developing the HL7 CCD and HITSP C32, will a NIEM IEPD represent a step forward in health data exchange standards? Will the NIEM IEPD process work in the healthcare domain? In adopting the NIEM process, can we leverage the work that has been done so far by organizations such as HITSP, HL7, and the ASTM?

NIEM vs. RIM

Having previously used the NIEM standard in a project, my first reaction when I started to work with the HL7 CDA and the related Reference Information Model (RIM) refinement process was, "why not use the NIEM?". The NIEM approach is proven and has been successfully used in complex data exchange scenarios in criminal justice and other sensitive domains.

The HL7 RIM expressed as a set of UML class diagrams defines a foundation model for health care and clinical data. The HL7 Clinical Document Architecture (CDA) is derived from the HL7 RIM through a refinement process that generates a Refined Message Information Model (R-MIM) for the CDA. The HL7 Continuity of Care Document (CCD) and HITSP C32 specifications define additional constraints on the HL7 CDA. Although the HL7 CCD was in fact an original attempt to harmonize the HL7 CDA and the ASTM CCR, there is still a need to define a unified data model for health information exchange. The Meaningful Use Interim Final Rule (IFR) allows both the CCD and the CCR for data exchange.

Ease of Use

From a software development point of view, the HL7 CCD and HITSP C32 standards are complex to learn and use. Data exchange standards don't provide any value by themselves. They provide value when they are used to create software solutions that improve the quality and safety of care and reduce costs. Therefore, ease of use represents an important requirement for a health data exchange standard. How do you create an XML data exchange standard that developers can learn quickly and that is easy to use?

Something as simple as adopting a component naming convention that conveys the semantics of those components is a good start. For example, ISO 11179, Part 5 entitled "Naming and Identification Principles" defines the following convention for naming data components:

• Object-class qualifier terms (0 or more).
  
• An object class term (1).
  
• Property qualifier terms (0 or more).
  
• A property term (1).
  
• Representation qualifier terms (0 or more).
  
• A representation term (1).
  

An example of an element name that follows that recommendation is <PersonBirthLocation>. Not having a component naming convention or using cryptic names make it hard for developers to understand a new XML vocabulary. Disk space is cheap these days, so there is no reason to keep using those cryptic names.

Defining components is also important. ISO 11179, Part 4 entitled "Formulation of Data Definitions" provides the following recommendations for defining data components:

1. state the essential meaning of the concept
   
2. be precise and unambiguous
   
3. be concise
   
4. be able to stand alone
   
5. be expressed without embedding rationale, functional usage, or procedural information
   
6. avoid circular reasoning
   
7. use the same terminology and consistent logical structure for related definitions
   
8. be appropriate for the type of metadata item being defined
   

In general, consistency based on a predefined XML Schema Naming and Design Rules (NDRs) document which is itself based on recognized XML Schema design patterns can contribute to ease of use.

Developing Software

Key to adoption is the ability for an average software developer to use familiar tools including existing open source software to generate and process instances of the exchange XML schema. Examples of these tools include:

• XML databinding tools such as JAXB
  
• XML APIs such as JDOM or DOM4J
  
• Mapping and storing the data in existing relational databases (this is what the majority of developers know)
  
• Web Services Framework such as Apache CXF.
  

Reference Implementation and Testing Ease of Use

Creating a reference implementation with existing open source tools and testing ease of use should be part of releasing new health data exchange standards.

The reference implementation should support a complete SOA-based exchange scenario and provide artifacts that are typically generated in a real web services project. This includes designing a data model for storage, WSDLs, precompiling the XML schema with a databinding tool such as JAXB, and using an open source web services tool such as Apache CXF.

One way to determine ease of use is to ask average developers to process instances of the XML schema using familiar XML APIs and then measure how long it took them to write the code as well as the Cyclomatic Complexity (and other code quality metrics) of the written code.


Benefits of Adopting NIEM in the Healthcare Domain

I believe that NIEM is a good choice for moving healthcare interoperability forward for the following reasons:

• The NIEM is a proven data exchange standard that has been used in mission critical environments such as the justice and intelligence domains.
  
• The NIEM embodies recognized XML Schema design patterns in its Naming and Design Rules (NDR). For example, the NIEM component naming convention is based on ISO 11179 Parts 4 and 5. Per the NIEM NDR, all schema type definitions must be global to enable reuse. The NIEM provides a schematron-based tool to automatically validate XML schemas against the rules defined in the NDR.
  
• The NIEM provides core components that can be used or extended for the healthcare domain. Core NIEM data components such as <Person>, <Organization>, and <Address> are universal components that are needed in healthcare as well. NIEM also specifies an elegant solution for modeling roles, associations between entities, and code lists.
  
• The NIEM provides various tools to facilitate the IEPD process. These tools include the Schema Subset Generation Tool (SSGT), the NIEM Wayfarer, and conformance validation tools. The SSGT presents a shopping cart metaphor for assembling existing components into new exchange packages. The ONC anticipates the need for additional tools for the healthcare domain.
  
• A companion specification called the Logical Entity Exchange Specification (LEXS) can be used to define a messaging model for web services. LEXS has its own set of tools.
  

A NIEM Concept of Operations for the Healthcare Domain

The diagram below is extracted from a presentation made at the HIT Standards Committee meeting on June 30, 2010 and entitled: Standards & Interoperability Framework Concept of Operations (ConOps) Overview (click to enlarge).



NIEM Healthcare IEPD vs. NIEM Healthcare Domain

My personal recommendation is that the new harmonization structure (the successor to HITSP) should create a NIEM Healthcare domain as opposed to a NIEM IEPD for the healthcare domain. The healthcare domain is complex enough to warrant its own domain within the NIEM. A NIEM Healthcare domain should provide a data exchange standard for Electronic Health Records (EHRs) and leverage the work done by HITSP C32, C80, and C83 in defining required data elements and code lists (terminology) for various EHR content modules. Instead of mapping those data elements to the HL7 CCD XML schema as was done by HITSP, those elements will be mapped to existing, extended, or new NIEM components. Specific health data exchanges can then create IEPDs to satisfy their unique requirements by reusing data components from the NIEM.

It should be possible to map the CDA RMIM into the NIEM model using the NIEM Component Mapping Tool or CMT. It should also be possible to leverage at least some components from the HL7 CCD XML schema in building a NIEM Healthcare domain or IEPD. However, these components will have to be renamed and restructured to comply with the NIEM naming and design rules.