Monday, July 12, 2010

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.

16 comments:

Keith W. Boone said...

Joel, what you propose is interesting, but I think a bit much. I have an alterative suggestion here:
An Alternative Approach for how to use the NIEM

Joel Amoussou said...

I am not suggesting using NIEM for stage 1 of Meaningful Use. I agree with you that it will take time to switch to NIEM. The CCD and the CCR have been retained for Meaningful Use Stage 1 and I believe that's the right approach because of time constraints.

I believe the NIEM data model is a strong candidate for harmonizing standards for stage 2 (beginning 2013) or stage 2 (beginning 2015). And as I said the NIEM approach can leverage what has been done with HL7, HITSP, and CCR.

Joel Amoussou said...

I mean ...stage 3 (beginning 2015).

Anonymous said...

NIEM is indeed a well designed XML standard based on best practices and its design principles are universal and can be used in the healthcare domain as well. It took me at least 3 months to wrap my head around the HL7 RIM and CCD.

It's about time we start creating usable standards.

Jack said...

The fact that we now need to support both the CCR and C32 per Meaningful Use Final Rule tells me that the issue of standards harmonization has not been solved. As a HIT developer, I agree with Joel that we need a unified data model that is easy to use. I know that the HL7 is trying to simplify the CDA with their work on the GreenCDA, but we should also consider the NIEM as a proven approach.

Joel Amoussou said...

Webb Roberts, NIEM Lead Engineer reacts to my post here.

Anonymous said...

There are very good reasons why HL7 has adopted the RIM and its associated methodologies (and warts). Medical/clinical information is much, much more complex than what non-healthcare IT developers are used to working with. It is inherently highly-dimensional with inextricable complexity. XML languages short of OWL-DL are going to be a challenge to do it justice, and the HL7 RIM based models are testimony to that.

It is important to realize that the identity of any given element in an XML message/CDA from HL7 is NOT carried in the element name. For better or for worse, this is just a fact. Element names are created for human consumption and have no real meaning in HL7 messages. You have to use other attributes of a class, such as the templateId, code, classCode, typeCode, and (in the case of Acts, which inherit from two separate parent classes and thus require two separate defining type codes) moodCode.

NIEM is NOT a proven approach in healthcare. We saw the same naive arrogance when banking came to healthcare to provide "the solution". I.e. you have ATMs all over the world w/ your banking info, why does healthcare have to be so hard. Well, they all left, and left quickly, tails between their legs.

This is a very complex domain, and any representation of it must accept this very basic fact of life.

While there are efforts to simplify things in CDA, the clinical data, the actual domain of interest, only can withstand so much simplification with fidelity and safely.

Joel Amoussou said...

Why is it that after so many years developing the CDA and CCD, the HL7 is now working on the so called greenCDA?

Why is it that Google Health, Microsoft Health Vault, and Keas decided not to use the CDA/CCD/C32 and adopted the CCR or created their own model in the case of Microsoft Health Vault?

Why is it that we now have to support both the CCR and the CCD according to the Meaningful Use Final Rule? Wasn't the CCD supposed to be a harmonization of the CDA and the CCR?

Why is the MITRE Corporation proposing the L32 spec? By the way, MITRE developed the Laika open source C32 certification tool in partnership with the CCHIT. What have MITRE developers learned about using the C32 in the real world?

Why have so many organizations decided not to use the CCD or C32, although Meaningful Use now forces them to do so?

I submit a very simple answer: the CDA, CCD, and C32 are complex to use for the average Joe Developer out there. Now, saying that something is complex does not necessarily mean that it is bad or that the people who created it are stupid. So there is no reason for people who created the RIM and the CDA and CCD to be on the defensive. We all want every patient to have an Electronic Health Record (EHR), and we're not going to get there if we don't keep the average Joe Developer happy.

You mention OWL DL. I have personally promoted the use of Semantic Web technologies such as RDF, OWL, SKOS, SPARQL, and Linked Open Data (click on Semantic Web in the tag cloud on the right on this page to see my writings on this subject). The reality on the ground is that Semantic Web technologies have been confined to a tiny niche market and in academia. Again the fact is that it has not been embraced by the average Joe Developer. So I would submit that using OWL DL will not be a good choice for healthcare at this point. By the way, the Semantic Web has seen some limited success on the web recently because of RDFa which essentially consists in inserting semantic annotations into XHTML documents. So markup languages such as XML and XHTML are not going away anytime soon. I have worked with SGML before switching to XML. SGML was a huge spec and had very limited penetration. XML embraced the KISS (Keep It Simple and Stupid) principle and was only 26 pages long. It has been a phenomenal success and I think there are a lot of lessons to be learned from the XML standard development experience.

This post is about proposing a new path forward for EHR data standards. I submit that some NIEM design principles are universal and apply to many domains including healthcare. I mentioned the importance of having a Naming and Design Rules (NDRs). That's actually a basic SOA design pattern that I will recommend to anyone building enterprise SOA. In fact if you look at the newly proposed greenCDA, you will see that the component names look a lot like NIEM component names in the sense that the names make the semantic of the data clear and this is a good step forward. The NIEM also requires all complex type definitions to be declared globally. This is not the case in the latest version of greenCDA that I have seen. You're not going to achieve reuse with anonymous types (Read here https://jaxb.dev.java.net/tutorial/section_2_3_1-Hints-on-Writing-XML-Schemas.html#Don%27t%20Use%20Anonymous%20Types about why anonymous types should be avoided in XML Schema). The point is that there are lessons to be learned from the past and from others as well. To reiterate what I said, in order to be successful, we need to finally embrace the KISS principle, we need an NDR based on XML Best Practices, we need to test ease of use, and we need to create a reference implementation that shows how the new XML standard works with the tools that Average Joe Developer uses to create applications in the real world.

Keith W. Boone said...

<rant>
Joel, you engage in religious debate, although you might not be aware of it. I've found that religious debates are rarely productive.

HL7 has naming rules, and has had them for years. Do you know what they are? That could be part of the problem.

XML best practices? HL7 V3 RIM includes practices from some of the people who helped write some the XML standards.

You talk about why so many avoid C32, but how about the many that have adopted it as well?

Are you also aware of some of the limitations of XML? UML? Do you understand why the RIM is modeled on restriction instead of extension?

For each of your points, there is a counterpoint.

Don't get me wrong, NIEM as a process will be good. It will help us to understand ALL of the points that need to be made.

But existing NIEM norms for some of the practices you mention may go against other similarly well established norms.

Let's start with understanding the process and have a dialog through it, instead of a pair of rants.
</rant>

Joel Amoussou said...

Keith,

I like the lyrics in your post: "I wanna be an ePatient".

Ok, let's talk about naming conventions which I believe is important for the usability of an XML vocabulary.

Consider these complex type names from the C32 v2.5:

ED
CE
CV
CS
CO
CR
ADXP
PIVL_PPD_TS
SXCM_MO
PIVL_TS
SXCM_INT
SXCM_TS
HXIT_PQ
EIVL_TS
IVL_PQ

Now consider these NIEM type names:

PersonAgeMeasure
PersonBloodType
ActivityOrganizationAssociationType
InternationalTelephoneNumberType
LatitudeCoordinateType
MeasurePointValueType
MeasureRangeValueType
MedicalConditionType
NumericType
OrganizationType


Now, assume that I am a developer trying to learn and understand these new standards. Do you really think that those HL7 names are going to help me do my work? Can you explain to me why the C32 has to use those cryptic names?

Joel Amoussou said...

Recommended reading on the issues with e-health standards. Glad this conversation is taking place. HL7 should be an enabler of interoperability, not an empediment:

HL7 Watch

The crisis in e-health standards

Keith W. Boone said...

You are being deliberately antagonistic, as those aren't listed in the C32, but you do know where they come from. I won't rise the the bait this time. ;-)

Joel Amoussou said...

Are you suggesting that you don't know that those XML schema complex types are in the C32 v2.5 XML schema?

Keith W. Boone said...

No, I'm suggesting that you are being deliberately provocative, and inaccurately representing details. When you get back to a discussion that isn't intended to be inflammatory, I'll re-engage more fully.

Anonymous said...

Agree with Joel, NIEM is a well engineered spec. A good explanation of why HL7 v3 XML is such a mess can be found here.

DRRW said...

Joel, next release of the CAMeditor will have JAXB binding generation support. Plan is to have the next release early April.