Toward An Enterprise Reference Architecture for the Meaningful Use Era

Meaningful Use is not just about financial incentives. In fact, the financial incentives provided under the HITECH Act will only cover a portion of the total costs associated with migrating the healthcare industry to health information technologies. Consider the following Meaningful Use criteria:

• Submit electronic data to immunization registries
  
• Incorporate clinical lab-test results into certified EHR technology as structured data
  
• Submit electronic syndromic surveillance data to public health agencies
  
• Generate and transmit permissible prescriptions electronically (eRx)
  
• Provide patients with an electronic copy of their health information
  
• Exchange key clinical information among providers of care and patient authorized entities electronically.
  

These criteria are clearly designed to bridge information silos within and across organizational boundaries in the healthcare industry. This integration is necessary to improve the coordination and quality of care, eliminate the costs associated with redundancies and other inefficiencies within the healthcare system, empower patients with their electronic health records, and enable effective public health surveillance. This integration requires a new health information network such as those provided by state and regional Health Information Exchanges (HIEs) and the Nationwide Health Information Network (NHIN) initiative. HIEs and NHIN Exchange are based on a decentralized, service-oriented architecture (SOA) whereby authorized health enterprises securely exchange health information.

Health CIOs who see Meaningful Use as part of a larger transformational effort will drive their organizations toward success. Creating a coherent and consistent Enterprise Architecture for tackling these new challenges should be a top priority. Not having a coherent Enterprise Architecture will lead to a chaotic environment with increased costs and complexity. The following are some steps that can be taken to create an Enterprise Reference Architecture that is aligned with with the organization's business context, goals, and drivers such as Meaningful Use:

1. Adopt a proven architecture development methodology such as TOGAF.
   
   
2. Create an inventory of existing systems such as pharmacy, laboratory, radiology, patient administration, electronic medical records (EMRs), order entry, clinical decision support, etc. This exercise is necessary to gain an understanding of current functions, redundancies, and gaps.
   
   
3. Create a target enterprise service inventory to eliminate functional redundancies and maximize service reuse and composability. These services can be layered into utility, entity, and task service layers. For example, Meaningful Use criteria such as "Reconcile Medication Lists", "Exchange Patient Summary Record", or "Submit Electronic Data to Immunization Registries" can be decomposed into two or more fine-grained services.
   
   
4. Task services based on the composition of other reusable services can support the orchestration of clinical workflows. The latter previously required clinicians to log into multiple systems and re-enter data, or relied on point-to-point integration via the use of interface engines. These task services can also invoke services across organizational boundaries from other providers participating in a HIE in order to compose a longitudinal electronic health record (EHR) of the patient. Other services such as clinical decision support services or terminology services can be shared by multiple healthcare organizations to reduce costs.
   
   
5. Consider wrapper services to encapsulate existing legacy applications.
   
   
6. The Enterprise Reference Architecture should support standards that have been mandated in the Meaningful Use Final Rule, but also those required by NHIN Exchange, NHIN Direct, and the HIE in which the organization participates. These standards are related to data exchange (HITSP C32, CCR, HL7 2.x), messaging (SOAP, WSDL, REST, SMTP, WS-I Basic), security and privacy (WS-I Security, SAML, XACML), IHE Profiles (XDS, PIX, and PDQ), and various NHIN Exchange and NHIN Direct Specifications. While standards are not always perfect, healthcare interoperability is simply not possible without them.
   
   
7. Select a SOA infrastructure (such as an Enterprise Service Bus or ESB) that supports the standards listed above. Consider both open source and commercial offerings.
   
   
8. Consider non-functional requirements such as performance, scalability, and availability.
   
   
9. The Enterprise Reference Architecture should also incorporate industry best practices in the areas of SOA, Security, Privacy, Data Modeling, and Usability. These best practices are captured in various specifications such as the HL7 EHR System Functional Model, the HL7 Service Aware Interoperability Framework (SAIF), and the HL7 Decision Support Service (DSS) specification.
   
   
10. Finally, create a Governance Framework to establish and enforce enterprise-wide technology standards, design patterns, Naming and Design Rules (NDRs), policies, service metadata and their versioning, quality assurance, and Service Level Agreements (SLAs) such as the NHIN Data Use and Reciprocal Support Agreement (DURSA).
    

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.

Patient Consent: State of the Union

The viability and sustainability of an electronic health information exchange (HIE) largely depends on the trust and desire of patients to participate in the exchange. What are the laws, regulations, standards, practices, and current directions in the field of patients' privacy consents?

State and Federal Laws

The Health Insurance Portability and Accountability Act of 1996 (HIPAA) does not require patient consent and authorization for the exchange of health information among healthcare providers for the purpose of medical care. The patient consent is implied by her general consent to be treated.

Some states have adopted heightened laws (higher than those imposed by HIPAA) that require explicit patient consent and authorization for specially-protected health information such as sexually transmitted diseases, human immunodeficiency virus tests, viral hepatitis, genetic information, substance abuse, mental health, and developmental disabilities.


Building Trust

The lack of patient trust can be a significant barrier to the implementation of a HIE. Therefore, a common practice in HIEs is to offer individual patients the opportunity to opt-out of exchanging their health information even if patient consent is not required by existing laws and regulations. Patients are notified and informed of their consent options through an outreach program.


Consent Requirements

The HHS Office of the National Coordinator (ONC) releases a Consumer Preferences Requirements Document in October 2009. The document describes consent stakeholders, functional needs, policy implications, scenarios, and processes including HIEs.


Consent Options

The ONC released a whitepaper in March 2010 entitled "Consumer Consent Options for Electronic Health Information Exchange: Policy Considerations and Analysis". The whitepaper identified the following consent options:

• No consent. Health information of patients is automatically included—patients cannot opt out;
  
  
• Opt-out. Default is for health information of patients to be included automatically, but the patient can opt out completely;
  
  
• Opt-out with exceptions. Default is for health information of patients to be included, but the patient can opt out completely or allow only select data to be included;
  
  
• Opt-in. Default is that no patient health information is included; patients must actively express consent to be included, but if they do so then their information must be all in or all out; and
  
  
• Opt-in with restrictions. Default is that no patient health information is made available, but the patient may allow a subset of select data to be included.
  

The granularity of patient consent preference can be based on the type of data, healthcare provider, time range, and intended use.


Standardization

The IHE Basic Patient Privacy Consents (BPPC) provides a mechanism to record and enforce patient consents. It complements the IHE Cross-Enterprise Document Sharing (XDS) standard by specifying how an XDS affinity domain can create privacy policies and enforce those policies through the access control mechanisms of an XDS Actor such as an EHR system. Patient consent is captured in an HL7 Clinical Document Architecture (CDA) document using a scanned document (wet signature on paper) or a digital signature.

HL7 is working on a set of specifications for the creation and use of privacy consent directives.

The Nationwide Health Information Network (NHIN) Access Consent Policies Specification is based on the eXtended Access Control Markup Language (XACML), an OASIS standard.


Health Record Banks (HRBs)

An emerging pattern is to include a Health Record Bank (HRB) containing Personal Health Records (PHRs) as a participating node in the HIE. The HRB is accessible to patients via a web portal and allows patients to exercise fine-grained control over the exchange of their health records within the HIE through a consent configuration interface.

UPDATE: On Thursday, July 8, 2010, the Department of Health and Human Services (HHS) announced proposed modifications to the HIPAA Privacy & Security Rules.