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.

Health Information Exchanges (HIEs): Emerging Architectural Patterns

The following are some emerging architectural patterns in the nascent field of HIEs:

• Decentralized and Hybrid Models utilizing a service-oriented architecture (SOA). A centralized registry stores metadata about the type and location of clinical data available in edge systems connected to the HIE. For privacy and security reasons, the clinical data itself is kept at its source as opposed to a centralized repository. Upon request, a Record Locator Service (RLS) finds the data in edge systems and securely routes the data to authorized requestors.
  
  
• A Data Use and Reciprocal Support Agreement (DURSA) provides the legal framework for participation in the HIE.
  
  
• Use of a master patient index (MPI) as a core infrastructure for patient matching. The MPI stores identifying information on all patients with records in participating systems.
  
  
• Use of Integrating the Health Enterprise (IHE) profiles such as Patient Identity Cross-Reference (PIX) and Cross Enterprise Document Exchange (XSD.b) to facilitate patient discovery and the query and retrieval of clinical documents.
  
  
• Health Information Event Messaging to provide the ability to subscribe to health information.
  
  
• Interoperability with NHIN Exchange to enable exchange of data with other state and federal agencies such as the Department of Veterans Affairs (VA) and the Department of Defense (DoD). This requires support for NHIN messaging standards such as the Web Services Interoperability (WS-I) Profiles WS-I Basic v 2.0 and WS-I Security v 1.1. WS-I Basic specifies the use of SOAP 1.2, WSDL 1.1, WS-Addressing 1.0, WS-Policy 1.5 , MTOM 1.0 , and UDDI v3.0.2 for the NHIN Web Services Registry. WS-I Security defines the security standards for NHIN Exchange including TLS, AES 128, X.509, XML D-Sig, and Attachment Security. NHIN has adopted an authentication and authorization framework based on SAML 2.0.
  
  
• Use of the HL7 Continuity of Care Documents (CCD) as the data exchange standards for clinical documents. Meaningful Use criteria allow the ASTM CCR specification as well.
  
  
• Health Record Banks (HRBs) containing Personal Health Records (PHRs) as participating nodes in the HIE. The HRBs allow patients to exercise control over their health records by granting permissions to specific providers to view those health records.
  
  
• Ability to connect to the HIE through a local EMR or a web-based portal (for example to allow access for physicians without an EMR).
  
  
• For simple and secure interoperability, the NHIN Direct draft proposal at the time of this writing is to use:
  
  
  
  
  • SMTP as a backbone protocol
    
  • S/MIME-signed and encrypted messages for security
    
  • IHE XDM for content and metadata packaging
    
  • IHE XDR, REST, and Email (POP/IMAP) as edge protocols
    
  • TLS (with a server certificate only) for on-the-wire security
    
  • XDR as the backbone for NHIN Exchange.
  
  

Putting XQuery to Work in Healthcare

The following are some of the challenges that healthcare organizations will be facing during the next few years:

• Conversion from HIPAA 4010 to 5010
  
• Conversion from ICD-9 to ICD-10
  
• Efficiently storing, querying, processing, and exchanging Electronic Health Records (EHRs)
  
• Mapping from HL7 2.x to HL7 v3 messages
  
• Assembling EHRs by aggregating data from multiple organizations participating in Health Information Exchanges (HIEs).
  

XQuery is not just a query language for XML data sources. It is also a very powerful declarative, strongly typed, and side-effect free programming language for processing and manipulating XML documents. XQuery is a natural solution for querying and aggregating data coming from heterogeneous sources such as relational databases, native XML databases, file systems, and legacy data formats such as EDI. Some developers will find XQuery easier to use than XSLT because XQuery has a SQL-like syntax.


Migration to HIPAA 5010 and ICD 10

Conversion from HIPAA 4010 to 5010 and ICD-9 to ICD-10 will be a priority on the agenda in the next three years (details on final compliance dates can be found on this HHS web page).

The XQuery and XQuery Update Facility specifications provide a simple and elegant solution to this conversion challenge.


Health Information Exchanges (HIEs) and the Virtual Health Record

In a HIE with multiple participating organizations, EHR data must be assembled either through a centralized, federated, or hybrid data model. The data needed to assemble a longitudinal EHR (a virtual health record) for a patient could be coming from several providers, payers, lab companies, and medical devices. XQuery was designed to handle that type of XML processing use case.


Storing, Updating, and Querying EHRs

The HL7 CCD and ASTM CCR have been retained as Meaningful Use XML data exchange standards for EHRs. Mapping between an XML HL7 CCD representation (which is derived from the HL7 UML-based Reference Information Model or RIM) and an existing relational database structure is not trivial. IBM has been granted a patent entitled "Conversion of hierarchically-structured HL7 specifications to relational databases". The HL7 RIMBAA project provides some best practices on mapping RIM objects to a relational database structure.

With the emergence of native XML databases such as Oracle XML DB and IBM pureXML, XML is no longer just a messaging format. It can be used as a format for storing and querying data as well.

This article shows a sample code of updating an EHR stored in HL7 CDA format in an IBM DB2 pureXML native XML database.


Mapping from HL7 2.x to HL7 v3 messages

In countries like Canada where HL7 v3 has been adopted, a frequent challenge is to map from legacy HL7 2.x messages to HL7 v3 messages for example for lab results. An XQuery-based transform can be used to map from an HL7 v2.x XML structure to an HL7 v3 XML structure.


An Alternative to GELLO?

In a previous post entitled "Clinical Decision Support: Crossing the Chasm", I argued that Clinical Decision Support Systems (CDSS) implementers should be free to use any programming language of their choice. GELLO is an HL7 standard which specifies an expression and query language for CDSS. The following are the requirements for a CDSS expression and query language as specified in the GELLO specification:

• vendor-independent
  
• platform-independent
  
• object-oriented and compatible with the vMR
  
• easy to read/write
  
• side-effect free
  
• flexible
  
• extensible
  

XQuery satisfies all these requirements except the third. XQuery is a functional programming language with no side effect as opposed to an object-oriented programming language. GELLO settled on the OMG Object Constraint Language (OCL). The following paragraph from the GELLO specification explains why XQuery (known as XQL at the time) wasn't selected:

XQL is a query language designed specifically for XML documents. XML documents are unordered, labeled trees, with nodes representing the document entity, elements, attributes, processing instructions and comments. The implied data model behind XML neither matches that of a relational data model nor that of an object-oriented data model. XQL is a query language for XML in the same sense as SQL is a query language for relational tables. Since the HL7 RIM data model and the vMR data model are both object-oriented, it is clear that XQL is not an appropriate approach for an object-oriented query and expression language.

That might have been true back in 2004 in an object-oriented world. Today, if the inputs to a CDSS are EHRs represented in HL7 CCD or ASTM CCR format, and those EHRs are stored in an XQuery compliant native XML database, then XQuery could be a strong candidate for an expression and query language for the CDSS.

Data Modeling for Electronic Health Records (EHR) Systems

Getting the data model right is of paramount importance for an Electronic Health Records (EHR) system. The factors that drive the data model include but are not limited to:

• Patient safety
  
• Support for clinical workflows
  
• Different uses of the data such as input to clinical decision support systems
  
• Reporting and analytics
  
• Regulatory requirements such as Meaningful Use criteria.
  

Model First

Proven methodologies like contract-first web service design and model driven development (MDD) put the emphasis on deriving application code from the data model and not the other way around. Thousands of line of code can be auto-generated from the model, so it's important to get the model right.


Requirements Gathering

The objective here is to determine the entities, their attributes, and the relationships between those entities. For example, what are the attributes that are necessary to describe a patient's condition and how do you express the fact that a condition is a manifestation of an allergy? The data modeler should work closely with clinicians to gather those requirements. Industry standards should be leveraged as well. For example, HITSP C32 defines the data elements for each EHR data module such as conditions, medications, allergies, and lab results. These data elements are then mapped to the HL7 Continuity of Care Document (CCD) XML schema.

The HL7 CCD is itself derived from the HL7 Reference Information Model (RIM). The latter is expressed as a set of UML class diagrams and is the foundation model for health care and clinical data. A simpler alternative to the CCD is the ASTM Continuity of Care Records (CCR). Both the CCD and CCR provide an XML schema for data exchange and are Meaningful Use criteria. Another relevant data model is the HL7 vMR (Virtual Medical Record) which aims to define a data model for the input and output of Clinical Decision Support Systems (CDSS).

These standards can be cumbersome to use as such from a software development perspective. Nonetheless, they can inform the design of the data model for an EHR system. Alignment with the CCD and CCR will facilitate data exchange with other providers and organizations. The following are Meaningful Use criteria for data exchange:

1. Electronically receive a patient summary record, from other providers and organizations including, at a minimum, diagnostic test results, problem list, medication list, medication allergy list, immunizations, and procedures and upon receipt of a patient summary record formatted in an alternative standard specified in Table 2A row 1, displaying it in human readable format.
   
   
2. Enable a user to electronically transmit a patient summary record to other providers and organizations including, at a minimum, diagnostic test results, problem list, medication list, medication allergy list, immunizations, and procedures in accordance with the standards specified in Table 2A row 1.
   

Applying Data Modeling Patterns

Applying data modeling patterns allows model consistency and quality. Relational data modeling is a well established discipline. My favorite resource for relational data modeling patterns is: The Data Model Resource Book, Vol. 3: Universal Patterns for Data Modeling.

Some XML Schema best practices can be found here.


Data Stores

Today, options for data store are no longer limited to relational databases. Alternatives include: native XML databases (e.g. DB2 pureXML), Entity-Attribute-Value with Classes and Relationships (EAV/CR), and Resource Description Framework (RDF) stores.

Native XML databases are more resilient to schema changes and do not require handling the impedance mismatch between XML documents, Java objects, and relational tables which can introduce design complexity, performance, and maintainability issues.

Storing EHRs in an RDF store can enable the inference of medical facts based on existing explicit medical facts. Such inferences can be driven by an ontology expressed in OWL or a set of rules expressed in a rule language such SWRL. Semantic Web technologies can also be helpful in checking the consistency of a model, data and knowledge integration across domains (e.g. the genomics and clinical domains), and for managing classification schemes like medical terminologies. RDF, OWL, and SWRL have been successfully implemented in Clinical Decision Support Systems (CDSS).

The data modeling notation used should be independent of the storage model or at least compatible with the latter. For example, if native XML storage is used, then a relational modeling notation might not be appropriate. In general, UML provides the right level of abstraction for implementation-agnostic modeling.


Due Diligence

When adopting a "noSQL" storage model, it is important to ensure that (a) the database can meet performance and scalability criteria and (b) the team has the skills to develop and maintain the database. Due diligence should be performed through benchmarking using a tool such as the IBM Transaction Processing over XML (TpoX). The team might need formal training in a new query language like XQuery or SPARQL.


A Longitudinal View of the Patient Health

Maintaining an up-to-date and truly longitudinal view of a patient's medical history requires merging and reconciling data from heterogeneous sources including providers' EMR systems, lab companies, medical devices, and payers' claim transaction repositories. The data model should facilitate the assembly of data from such diverse sources. XML tools based on XSLT, XQuery, or XQuery Update can be used to automate the merging.


The Importance of Data Validation

Data validation can be performed at the database layer, the application layer, and the UI layer. The data model should support the validation of the data. The following are examples of techniques that can be used for data validation:

• XML Schema for structural validation of XML documents
  
• ISO Schematron (based on XPath 2.0 and XSLT 2.0) for business rules validation of XML documents
  
• A business rules engine like Drools
  
• A data processing framework like Smooks
  
• The validation features of a UI framework such as JSF2
  
• The built-in validation features of the database.
  

The Future: Modeling with the NIEM IEPD

The HHS ONC issued an RFP for using the National Information Exchange Model (NIEM) Information Exchange Package Documentation (IEPD) process for healthcare data exchange. The ONC will release a NIEM Concept of Operations (ConOps). The NIEM IEPD process is explained here.

Architecting the Health Enterprise with TOGAF 9

Several factors are currently driving the increased complexity of health information technology (HIT). These factors include: a new regulatory framework, innovations in the practice of healthcare delivery, standardization, cross-enterprise integration, usability, mobility, security, privacy, and the imperative to improve care quality and reduce costs.

A methodology and governance framework is needed for creating a coherent and consistent enterprise architecture (EA). The latter should not be driven by vendors and their offerings. Instead, health enterprises should develop an EA that is aligned with their unique overarching business context, drivers, and vision. Developing an architecture capability that is based on a proven framework should be a top priority for health IT leaders.

TOGAF 9 is an Open Group standard that defines a methodology, standardized semantics, and processes that can be used by Enterprise Architects to align IT with the strategic goals of their organization. TOGAF 9 covers the following four architecture domains:

• Business Architecture
  
• Data Architecture
  
• Application Architecture
  
• Technology Architecture.
  

The diagram below from the TOGAF 9 documentation provides an overview (click on the image to enlarge).



The Architecture Development Method (ADM) is the core of TOGAF and describes a method for developing an enterprise architecture. TOGAF 9 includes specific guidance on how the ADM can be applied to service-oriented architecture (SOA) and enterprise security (two areas of interest in health IT). The different phases of the ADM are depicted on the following diagram (click on the image to enlarge).



The Architecture Capability Framework provides guidelines and resources for establishing an architecture capability within the enterprise. This capability operates the ADM. The Content Framework specifies the artifacts and deliverables for each Architecture Building Block (ABB). These artifacts are stored in a repository and classified according to the Enterprise Continuum.

The Open Group has been working on the adoption of an open EA modeling standard called ArchiMate. ArchiMate provides a higher level view of EA when compared to modeling standards such as BPMN and UML. It can be used to depict different layers of EA including business processes, applications, and technology in a way that can be consumed by non-technical business stakeholders. A sample of an ArchiMate enterprise view of a hospital can be found here.

HL7 has published the Services-Aware Interoperability Framework (SAIF), an architectural framework for facilitating interoperability between healthcare systems. SAIF includes the following four components: the Enterprise Conformance and Compliance Framework (ECCF), the Governance Framework (GF), the Behavioral Framework (BF), and the Information Framework (IF).

For guidance on using SOA in healthcare, the Healthcare Services Specification Project (HSSP) has published the Practical Guide for SOA in Healthcare based on the TOGAF Architecture Development Method (ADM) and the SAIF ECCF. The Practical Guide for SOA in Healthcare contains a sample Reference Enterprise Architecture. The Practical Guide for SOA in Healthcare Volume II describes an immunization case study.

Also noteworthy is the HL7 EHR System Functional Model (EHR-S FM) and the HSSP Electronic Health Record (EHR) System Design Reference Model (EHR SD RM).

Clinical Decision Support: Crossing The Chasm

Clinical Decision Support (CDS) is certainly a "meaningful use" of electronic health records (EHRs). Despite its potential to improve the quality of care, CDS is not widely used in health care delivery today. In tech marketing parlance, CDS has not crossed the chasm. There are several issues that need to be addressed including: physicians buy-in into the concept of automated execution of evidence-based clinical guidelines, seamless integration into clinical workflows, usability, standardization, and CDS software architecture and design.

When I first started to explore CDS systems, I was quite overwhelmed by the number of different competing formalisms, standards, and academic projects in the field. To move us past the current gridlock in CDS adoption, I propose an agile approach to the development of CDS software with an emphasis on:

• Working CDS software that delivers results for providers and their patients
  
• Close daily collaboration between clinicians and software developers during the development process
  
• The use of agile techniques such as automated acceptance testing to facilitate the involvement of clinicians in CDS software quality assurance.
  

Working CDS Software

Different formalisms, methodologies, and architectures have been proposed for representing the medical knowledge in clinical guidelines for their automated execution. Examples include, but are not limited to the following:

• The Arden Syntax
  
• GLIF (Guideline Interchange Format)
  
• GELLO (Guideline Expression Language Object-Oriented)
  
• GEM (Guidelines Element Model)
  
• PROforma
  
• EON
  
• PRODIGY
  
• Asbru
  
• GUIDE
  
• SAGE
  
• SEBASTIAN
  
• The HL7 Decision Support Service (DSS) Functional Model Specification.
  

Many academic papers have been written to explain and compare these different approaches. Each of these projects represents an important contribution to the CDS field and will inform the design of future CDS software. However, it is quite easy to fall into analysis paralysis when reviewing and debating which formalism or standard is better. At the end of the day, what really matters to the pragmatic developer is tested and working CDS software that delivers results for clinicians and their patients.

Using business rule engines is not the only way to develop CDS software. However, I believe that because they are written in languages and frameworks that are accessible to mainstream software developers, business rule engines can accelerate the development, deployment, and availability of CDS software. Furthermore, many viable open source business rule engines are available today and can be leveraged.


Getting CDS Done with a Business Rule Engine

ARRA interim certification criteria for electronic health record (EHR) technology include the following CDS-related requirements:

1. Implement automated, electronic clinical decision support rules (in addition to drug-drug and drug-allergy contraindication checking) according to speciality or clinical priorities that use demographic data, specific patient diagnoses, conditions, diagnostic test results and/or patient medication list.
   
2. Automatically and electronically generate and indicate (e.g., pop-up message or sound) in real time, alerts and care suggestions based upon clinical decision support rules and evidence grade.
   
3. Automatically and electronically track, record, and generate reports on the number of alerts responded to by a user.
   

These requirements can be satisfied with simple conditional statements in any programming language. However, it is recognized that clinical decision support rules (like other complex types of business rules) are better implemented with a business rule engine. This allows the developer to externalize the medical knowledge in the clinical guideline in the form of declarative rules as opposed to embedding that knowledge in procedural code. This approach has many benefits notably resilience to change, ease of maintenance, and enabling collaboration with business users (in this case clinicians).


Collaboration between Clinicians and Software Developers

One of the most challenging aspects of CDS has been the translation of the medical knowledge in clinical guidelines into executable code. There are not that many people who are expert in the both the medical and software development fields. The Agile prescription to this problem is close and daily collaboration between clinicians and software developers.

Business Rules engines like JBoss Drools provide features such as Excel-based decision tables or the ability to write rules in a DSL (domain specific language) to allow clinicians to actively participate in the development and maintenance of decision support rules.

Automated Acceptance Testing

The quality of CDS software is of paramount importance for care safety reasons. The Agile prescription here is test-driven development (TDD), particularly the automated integration and acceptance testing of the proper execution of clinical decision support rules. "FIT for Rules" is an example of an automated acceptance framework for rule engines like ILog and Drools. Such frameworks allow both the developer and the clinician to participate in the acceptance testing process.


Service-Oriented CDS

The complexity and cost of developing CDS software strongly argue in favor of a service-oriented approach whereby CDS software capabilities are exposed as a set of services that can be consumed by other client health IT systems such as EHR and Computerized Physician Order Entry (CPOE) systems. To reduce costs, these CDS software services can be shared by several health care providers.

In this regard, the HL7 Decision Support Service (DSS) Functional Model Specification represents one of the most important specifications for CDS implementers today.

Interchange Standard

The complexity and cost inherent in capturing the medical knowledge in clinical guidelines and translating that knowledge into executable code remains an impediment to the widespread adoption of CDS software. Therefore, there is still a need for a standard for the sharing and interchange of executable clinical guidelines. Several formalisms and standards have been proposed such as the Arden Syntax, GLIF, GELLO, and GEM. However, none of these standards has been widely adopted. Although there is a lot that can be learned from these standards, I believe that they are not widely used because they are complex and specific to the healthcare domain, and therefore not accessible to mainstream developers. There is also a lack of open source and even commercial implementations of some of these standards.

If business rule engines are the pragmatic path to CDS adoption, then I would argue that the Rule Interchange Format (RIF) specification might be a solution to the interchange problem. The RIF Production Rule Dialect (PRD) is designed as a common XML serialization for multiple rule languages to enable rule interchange between different business rule management systems (BRMS). RIF is currently a W3C candidate recommendation and is backed by several BRMS vendors.

UPDATE: The following is the Final Meaningful Use criteria for Clinical Decision Support (CDS):

1. Implement rules. Implement automated, electronic clinical decision support rules (in addition to drug-drug and drug-allergy contraindication checking) based on the data elements included in: problem list; medication list; demographics; and laboratory test results.
   
   
2. Notifications. Automatically and electronically generate and indicate in real-time, notifications and care suggestions based upon clinical decision support rules.
   

And here are the draft stage 2 requirements:

Use CDS to improve performance on high- priority health conditions.

Establish CDS attributes for purposes of certification:

1. Authenticated (source cited);
   
2. Credible, evidence-based;
   
3. Patient-context sensitive;
   
4. Invokes relevant knowledge;
   
5. Timely;
   
6. Efficient workflow;
   
7. Integrated with EHR;
   
8. Presented to the appropriate party who can take action
   

How Health Plans Can Help Jumpstart EHR Adoption

ARRA incentives will help physicians and hospitals adopt computerized medical records software in the next four years. The next big challenge will be how to obtain patients' electronic health records (EHRs) in order to make a "Meaningful Use" of these investments in health information technology (HIT). Most patients don't currently have an EHR. The goal is to ensure that within four years, all patients in the US have an EHR.

It will take some time before physicians and hospitals have comprehensive medical records for their patients in their newly acquired Electronic Medical Record (EMR) software. EMR systems that are already deployed by providers don't typically contain clinical data about the care delivered by other providers. In contrast to EMRs, EHRs contain a longitudinal view of a patient's medical history across providers and can be populated from other sources including lab companies, at-home medical devices, health plans, and patient self-reported data (for example, data about over-the-counter drug that could potentially generate an adverse drug reaction).

Discussions on Meaningful Use don't usually mention health plans since the incentives are only directed at eligible professionals and hospitals. However, health plans can play a very important role in jumpstarting EHR adoption by extracting health records from the vast amount of clinical data in claim transaction repositories and by making that data available to members and providers as well.


Quality and Care Coordination with Claim-Based Health Records

The following examples demonstrate how health records extracted from claim data, when made available to providers, can significantly improve the quality and coordination of care :

• Pharmacy claim data can enable medication reconciliation during transitions of care.
  
• Lab and radiology claim data help avoid redundant and potentially costly orders.
  
• Diagnosis codes in medical claims can provide a view of a patient's problem list for care coordination purposes.
  

When delivered in standard compliant data format, these claim-based data can be fed into clinical decision support systems for the automated execution of clinical guidelines and for generating alerts and reminders.


Data Integration and the Importance of Data Standards

Maintaining an up-to-date and truly longitudinal view of a patient's medical history requires merging and reconciling data from heterogeneous sources including providers' EMR systems, lab companies, medical devices, and payers' claim transaction repositories. This data integration will only be possible if all stakeholders adhere to common data exchange standards such as the ASTM Continuity of Care Records (CCR) and the HL7 Continuity of Care Documents (CCD) standards.

Both the CCR and the CCD specify an XML Schema for constraining and validating EHR data. Therefore XML tools based on XSLT or XQuery/XQuery Update can be used to automate the merging of data from multiple sources.

To ensure data portability when members switch jobs or health plans, the HL7 standard development organization published a Plan-to-Plan Personal Health Records Implementation Guide of the CCD specification with active participation by America's Health Insurance Plans (AHIP) and the Blue Cross and Blue Shield Association (BCBSA).


Health Plans and HIEs

Collaboration between all stakeholders in the healthcare industry requires an IT infrastructure to ensure effective data exchange orchestration and security. This infrastructure can take the form of a Health Information Exchange (HIE) network at the regional, state, or even federal level. A HIE provides capabilities such as a document registry and repository, an authorization policy engine, a consumer preferences manager, a HIPAA-compliant audit log, and a master patient index (MPI) to reliably aggregate patient's data across payers, providers, and other data sources. Such exchange networks can be built with open source software such as NHIN Connect and the emerging NHIN Direct.


The Value of Claim-Based Health Records for Health Plans

Claim-based health records can help providers meet health plans' pay-for-performance incentives and quality measures initiatives. Electronic Health records will also be an important component of health plans' Population Health Management programs.

Some Accountable Care Organizations (ACOs) will be led by health plans. Data integration will be essential to the success of those ACOs.


Health Plans vs. Google Health and Microsoft Health Vault

Health Plans have a huge competitive advantage compared to online personal health records (PHRs) services such as Google Health and Microsoft Health Vault: they can pre-populate the PHRs of their members with health records extracted from claim transactions and those PHRs are likely to be more useful and reliable to providers than patient self-reported data.

A Roadmap for Health Plans

Health plans can position themselves for their new role as enablers of EHR adoption by doing the following:

• Create an EHR view of the health records in claim transaction repositories
  
• Map the data to industry exchange standards such as the ASTM CCR or the HL7 CCD
  
• Make the data available to their members (through a web portal for example) and partners (subject to patient's consent)
  
• Get ready to contribute data to HIEs by adopting other necessary standards such as Integrating the Health Enterprise (IHE) profiles for cross-enterprise document exchange (XDS.b), security, and patient consent
  
• Embrace and participate in open source projects such as NwHIN Connect and Direct
  
• Actively participate in the health IT standards development process
  
• Prepare their infrastructure to send and receive health records from providers.
  

Green EHRs, Genomics, Decision Support, and Checklists

I am back in the blogosphere after a three month hiatus. As you may have noticed from my last post, my focus lately has been on health information technology and how to unleash its potential to improve the quality of care and reduce costs. Healthcare Reform has been signed into law in the US as I have predicted in my last post. I believe that the healthcare sector is going through what former Intel CEO Andy Grove calls a "Strategic Inflection Point" driven by a combination of the following:

• A new regulatory framework including Healthcare Reform, ARRA and the HITECH Act
  
• Technology: electronic health records, advances in Genomics, and leveraging the ubiquity and ease of use of Web 2.0/3.0 platforms
  
• Innovations in the practice of healthcare delivery such as personalized medicine, automated execution of clinical guidelines (evidence-based medicine and clinical decision support), and the growing awareness of the effectiveness of checklists in high-pressure clinical settings such as surgery and intensive care.
  

Developing robust and easy to use health IT standards is key, so I've joined the HL7 standard development organization to follow and hopefully contribute. Specifically, I am interested in the following HL7 working groups:

The HL7 Structured Document Working Group and the Greening of the CDA

This group develops structured document standards for healthcare such as the Clinical Document Architecture (CDA) and the Continuity of Care Document (CCD). I am particularly interested in the greenCDA effort to simplify the CDA. I believe that simplifying the CDA can greatly facilitate and accelerate adoption. A simpler version of the CDA will allow adopters to quickly learn it and use their familiar software development tools (such as XML databinding tools and IDEs) to write software applications. To achieve that objective, data components of the greenCDA will be based on data semantics as opposed to the CDA R-MIM (Refined Message Information Model) classes. The CDA R-MIM is a graphical representation of the CDA specification and a step in the HL7 V3 Reference Information Model (RIM) refinement process.

HITSP C32 took the right approach by first defining required data elements for various content modules such as conditions and medications and then mapping those data elements to the HL7 CCD XML Schema structure. However the latter is quite complex. Fortunately, it is possible to map those HITSP C32 data elements to a simpler XML Schema than what is defined by the HL7 CCD. That simpler XML Schema can take different forms. A National Information Exchange Model (NIEM) Information Exchange Package Documentation (IEPD) for healthcare data is an approach that is being considered by the ONC. The NIEM approach is proven and has been successfully used in complex data exchange scenarios in criminal justice and other sensitive domains. Another approach is to create a lighter version of the HITSP C32 specification like the L32 proposed by the MITRE corporation.

There are many new interesting features of the XML Schema 1.1 specification such as assertions and conditional type assignments that can be leveraged as well to consolidate both structural and business rules data constraints in a single schema.

While there are different approaches to simplifying the CDA, instances of any well-designed simplified version of the CDA/CCD should easily be mapped to the original plain vanilla CDA/CCD schemas for exchange.


The Clinical Decision Support Working Group

This group develops standards such as the Virtual Medical Record (vMR), GELLO (an expression and query language for computer-interpretable clinical guidelines), Infobutton (a context-aware information retrieval standard specification), and Clinical Decision Support Services (CDSS).

Clinical Decision Support systems had a limited adoption but are likely to get a boost from the new ARRA EHR certification requirements.

The Clinical Genomics Data Working Group

This group develops standards for clinical and personalized genomic data such as DNA sequence variations and gene expression levels. Combined with clinical decision support services, this work has the potential to revolutionize personalized medicine as we know it. For example, a medication dose can be adjusted based on a patient's genotype. Family history and genetic screening will play an important role in preventive medicine for diseases such as diabetes and cancer.

Procedures and Checklists in the Cockpit and Intensive Care Units

The Flight Operation Interests Group (FOIG) of the Air Transport Association (ATA) of which I am a member is developing a data model and XML Schema for flight deck procedures and checklists. Adherence to well designed flight deck procedures and checklists can contribute significantly to the improvement of flight safety. For example, several no-flap/no-slat takeoff crashes have been caused by a deviation from basic operating procedures.

Aircraft manufacturers have different philosophies and policies on the design of flight deck procedures that must be reconciled. Another challenge is the need to take human factors into consideration in any effort related to the design and execution of flight deck procedures.

While the idea of using checklists and standard operating procedures has been fully embraced and adopted by aviation professionals for the last 70 years, it is only now making inroads into the field of medicine particularly in intensive care units. The use of checklists in medicine has already shown the potential to save patients live and reduce human errors. However, the main challenge remains acceptance and full embrace of checklists by clinicians. If you are interested in learning more about checklists in medicine, I recommend the book "The Checklist Manifesto: How to Get Things Right" by Atul Gawande.

A checklist could take the form of a tasks list automatically generated as output of clinical decision support services that take as inputs electronic health records as well as patient genomic data for a more effective form of personalized medicine.

Unlocking the Potential of Health Information Technology (HIT)

Around the world, HIT is widely seen as a key factor in containing rising health care costs and improving the quality of patient care. President Obama, in a speech at George Mason University in January 2009, declared:

To improve the quality of our health care while lowering its cost, we will make the immediate investments necessary to ensure that, within five years, all of America's medical records are computerized.

Yet, recent studies have raised some concerns about the effectiveness of Electronic Health Records (EHRs). A recent survey of 4000 hospitals conducted by Dr. David Himmelstein and his team of researchers at Harvard Medical School and published in the American Journal of Medicine concluded that the adoption of EHRs have had little impact on administrative costs and quality of care.

Another study published in the Milbank Quaterly raised some questions about the effectiveness of EHRs (as compared to paper records) in primary clinical work.

In the US, the American Recovery and Reinvestment Act (ARRA) of 2009 (also known as the "economic stimulus package") contains a portion called the Health Information Technology for Economic and Clinical Health Act (HITECH Act) which provides $19.2 billions of incentives to physicians and hospitals for the adoption of EHRs. No matter where you stand in the political spectrum, ARRA, the HITECH Act, and Health Care Reform are now realities to contend with in the US health care sector.

What can be done to ensure that these massive investments in HIT and EHRs live up to their expectations? A research paper entitled "Use of Electronic Health Records in US Hospitals" and published in April 2009 in The New England Journal of Medicine reveals:

On the basis of responses from 63.1% of hospitals surveyed, only 1.5% of U.S. hospitals have a comprehensive electronic-records system (i.e., present in all clinical units), and an additional 7.6% have a basic system (i.e., present in at least one clinical unit). Computerized provider-order entry for medications has been implemented in only 17% of hospitals.

The EHR is the cornerstone of the emerging Nationwide Health Information Network (NHIN). Software developers can do all sorts of interesting things (in the spirit of "meaningful use") with patient health data once it becomes available in electronic form. In 2010, EHRs will be a top priority for providers because of the incentives available under the HITECH Act. The ECRI Institute puts EHRs on the number two spot on its list of Top 7 Technologies for Health Plans in 2010.

The following factors will be key to unlocking the full potential of HIT:

• Standardization
  
• Open Source
  
• Training the HIT Workforce
  

Standardization

Standards are important for the seamless exchange of data between the different stakeholders (hospitals, physicians, payers, lab companies, etc.) in the health care industry. Furthermore, due to the complexity of the health care domain, organizations adopting HIT cannot afford to reinvent the wheel when deciding on key issues such as:

• A data model for representing EHR data and quality measure reporting content.
  
• Coding systems for representing patient health information in a machine-processable format.
  
• A language for expressing clinical practice guidelines for their automated execution in clinical decision support systems (CDSS) as a "meaningful use" of EHRs.
  
• A protocol for cross-organization exchange of patient data.
  
• Technologies for privacy, security, audit trails, and patient consents.
  

Fortunately, some of these standards exist today and should be adopted. Organizations such as the Health Information Technology Standards Panel (HITSP) and Integrating the Health Enterprise (IHE) in the US and Canada's Health Infoway's Standards Collaborative are working on harmonizing standards for data exchange as well as security and privacy in the health care domain.

EHR Data and Quality Reporting

The HL7 Reference Information Model (RIM) expressed as a set of UML class diagrams is the foundation model for health care and clinical data. The HL7 Clinical Document Architecture (CDA) which is derived from the HL7 RIM has been widely adopted around the world for EHR implementation projects. The HL7 Continuity of Care Documents (CCD) is a constraint on the CDA driven by the requirements of the ATSM Continuity of Care Record (CCR) specification. The HITSP C32 specification which is a further constraint on the HL7 CCD is emerging as the standard for the exchange of EHR data in the US realm.

On the CCR vs. CCD debate, I have come to appreciate and respect the exhaustive metadata provided by the CCD which is important for medico-legal reasons, but also for building software applications such as clinical decision support systems (CDSS) that rely heavily on the availability of such metadata. However, I also realize that some patient-facing web applications for managing personal health records (PHRs) can benefit from the simplicity of the CCR.

For collecting and reporting performance measure data to improve the quality of care, the Physician Quality Reporting Initiative (PQRI) Registry XML Specification and the HL7 Quality Reporting Document Architecture (QRDA) are available.

Laboratory content can be exchanged in HL7 2.5.1 messages or HITSP CCD documents. Digital Images and Communications in Medecine (DICOM), DICOM Structured Reporting (SR), and Web Access to DICOM objects (WADO) are used for medical imaging.

Medical Terminologies

The HITSP C80 Clinical Document and Message Terminology Component specification defines the vocabularies and terminologies used by various HITSP specifications. HITSP C80 recommends Logical Observation Identifiers Names and Codes (LOINC) for laboratory observations, RxNorm for standard names of clinical drugs, Unique Ingredient Identifier (UNII) for allergies, SNOMED CT for Problem Lists, and Unified Code for Units of Measure (UCUM) for units of measure.

Integrating terminologies is a big challenge in Health IT. An example is the mapping from SNOMED-CT to ICD-10 or Current Procedural Terminology (CPT). Semantic web technologies such as RDF, OWL2, SWRL, SPARQL, and SWASDL have proven their usefulness in semantic mediation across coding systems as well as in building Clinical Decision Support Systems (CDSS).

Administrative Transactions and E-Prescribing

Relevant standards include X12 4010 and 5010 for administrative transactions, Council for Affordable Quality Healthcare (CAQH) Core for online patient eligibility and benefits inquiries, and NCPDP SCRIPT 10.6 for electronic prescriptions (e-prescribing). Conversion from 4010 to 5010 and ICD-9 to ICD-10 will be a priority on the agenda in the next three years (details on final compliance dates can be found on this HHS web page). XQuery, XQuery Update, and XSLT2 are likely to play an important role in that conversion effort.

An Expression and Query Language for Clinical Decision Support Systems (CDSS)

There is currently no consensus on a single standard for expressing clinical practice guidelines for their automated execution in CDSS. Existing specifications include the Arden Syntax, the Guideline Interchange Format (GLIF), and GELLO (roughly Guideline Expression Language Object-Oriented). Some wonder if a standard is needed in this space at all. My position is that a standard with an open source reference implementation with support for some publicly available and approved clinical guidelines can be useful in speeding up adoption.

In addition, since EHR data is one of the primary inputs into a CDSS, the CDSS expression language should at least share the same underlying data model with the EHR data input. That model is the HL7 Reference Information Model (RIM). The "virtual medical record" (or vMR) specified by GELLO is defined as a view of the HL7 RIM. It would be a great help if HITSP could step in and harmonize standards in the CDSS space.

Cross-Enterprise Document Sharing

The Integrating the Health Enterprise (IHE) Cross-Enterprise Document Sharing (XDS) Integration Profile specifies a protocol for the sharing and access to EHRs across health enterprises. XDS defines concepts such as an "Affinity Domain" (a group of collaborating health enterprises), the "Document Source", the "Document Repository", and the "Document Registry". It also specifies transactions such as "Provide and Register Document", "Query Document" and "Retrieve document".

Other relevant IHE Integration Profiles include the Cross Community Access profile (XCA), the Cross Enterprise Document Reliable Interchange (XDR), and the Cross Enterprise Document Media Interchange (XDM).

Privacy and Security

On the privacy and security front, the following publicly available standards can be used to comply with ARRA and HIPAA requirements:

• Transport Layer Security (TLS)
  
• Advanced Encryption Standard (AES)
  
• Secure Hash Algorithm (SHA)
  
• OASIS eXtensible Access Control Markup Language (XACML)
  
• OASIS Security Assertion Markup Language (SAML)
  
• OASIS WS-Security
  
• OASIS WS-Trust
  
• OASIS WS-Policy.
  

The following IHE Profiles provide specific security guidelines for health enterprises and Health Information Exchanges (HIEs):

• Audit Trail and Node Authentication (ATNA)
  
• Consistent Time (CT)
  
• Basic Patient Privacy Consents (BPPC)
  
• Enterprise User Authentication (EUA)
  
• Cross-Enterprise User Assertion (XUA)
  
• Patient Demographics Query (PDQ)
  
• Patient Identifier Cross-Referencing (PIX)
  
• Digital Signatures (DSG).
  

For the de-identification and re-identification of content which are important for privacy as well as public health research and epidemiology, the following specifications are available:

• 45 CFR Parts 160 and 164. Standards for Privacy of Individually Identifiable Health Information; Final Rule. August 14, 2002. Section 164.514(a-b) Deidentification of protected health information. (Deidentification)
  
• 46 CFR Parts 160 and 164. Standards for Privacy of Individually Identifiable Health Information; Final Rule. August 14, 2002. Section 164.514(c) Reidentification (Pseudonymization)
  
• ISO/TS 25237:2008 Health Informatics --Pseudonymisation, Unpublished Technical Specification (Pseudonymization).
  

Open Source

High costs, total failure, disappointing return on investment (ROI), and adverse impact on end-users productivity are always risk factors to deal with in any large scale software implementation project. HIT projects are no exception. Driving costs out of health care will be a top priority for all stakeholders in 2010. So, companies will look for viable alternatives to insane software licensing and maintenance fees.

Open source implementations of some of the HIT standards mentioned above can be leveraged to reduce such risks. In addition to lowering costs and risk, open source can provide the transparency that is needed to ensure that HIT software provides adequate privacy and security protections. Examples of these tools include:

• The Open eHealth Integration Platform which is based on Apache Camel and implements HIT standards such as HL7 2.x, HL7 CDA/CCD, and IHE XDS.
  
• The Open Health Tools Project provides tooling for developing HIT applications.
  
• The Connect Gateway allows health enterprises to easily connect their HIT systems to health information exchanges (HIE). It implements key components such as a Master Patient Index (MPI), XDS.b Document Registry and Repository, Authorization Policy Engine, Consumer Preferences Manager, and a HIPAA-compliant Audit Log.
  
• The WorldVistA EHR open source EHR system which is based on the U.S. Department of Veterans Affairs (VA) sponsored VistA software. Work is underway to add CCR and CCD support to WorldVistA.
  

Training the HIT workforce

Finally, the potential of HIT will not be fully realized without the availability of a fully trained and competent workforce. All stakeholders in the health care industry should commit the necessary investments to educating the future HIT workforce through college and university programs as well as corporate training.

Lastly, the usability of EHRs in clinical settings deserves more attention and additional research.

Relational, XML, or RDF?

During the last 15 years, I have had the opportunity to work with different data models and approaches to application development. I started with SGML in the aerospace content management space back in 1995, then saw the potential of XML and fully embraced it in 1998. Since that time, I have been continuously following the evolution of XML related specifications and have been able to leverage the bleeding edge including XForms, XQuery, XSLT2, XProc, ISO Schematron, and even XML Schema 1.1.

However, being a curious person, I decided to explore other approaches to data management and application development. I worked on systems using a relational database backend and application development frameworks like Spring, Hibernate, and JSF. I've been involved in SOAP-based web services projects where XML data (constrained and validated by an XML Schema) was unmarshalled into Java objects, and then persisted into a relational table with an Object-Relational Mapping (ORM) solution such as Hibernate.

I also had the opportunity to work with the Java Content Repository (JCR) model in magazine content publishing, and the Entity-Attribute-Value with Classes and Relationships (EAV/CR) model in the context of medical informatics. EAV/CR is suited for domains where entities can have thousands of frequently changing parameters.

Lately, I have been working on Semantic Web technologies including the RDF data model, OWL (the Web Ontology Language), and the SPARQL query language for RDF.

Clients often ask me which of these approaches is the best or which is the most appropriate for their project. Here is what I think:

• Different approaches should be part of the software architect's toolkit (not just one).
  
• To become more productive in an agile environment, every developer should become a "generalizing specialist".
  
• The software architect or developer should be open minded (no "not invented here syndrome" or "what's wrong with what we're doing now" attitude).
  
• The software architect or developer should be willing to learn new technologies outside of their comfort zone and IT leadership should encourage and reward that learning.
  
• Learning new technologies sometimes requires a new way of thinking about the problems at hand and "unlearning" old knowledge.
  
• It is important not to have a purist or religious approach to selecting any particular approach, since each has its own merits.
  
• Ultimately, the overall context of the project will dictate your choice. This includes but is not limited to: skills set, learning curve, application performance, cost, and time to market.
  

Based on my personal experience, here is what I have learned:

The XPath 2.0 and XQuery 1.0 Data Model (XDM)

The roots of SGML and XML are in content management applications in domains such as law, aerospace, defense, scientific, technical, medical, and scholarly publishing. The XPath 2.0 and XQuery Data Model (XDM) is particularly well suited for companies selling information products directly as a source of revenues (e.g. non-ad based publishers).

XSLT2 facilitates media-independent publishing (single sourcing) to multiple devices and platforms. XSLT2 is also a very powerful XML transformation language that allows these publishers to perform the series of complex transformations that are often required as the content is extracted from various data sources and assembled into a final information product.

With XQuery, sophisticated contextualized database-like queries can be performed. In addition, XQuery allows the dynamic assembly of content where new compound documents can be constructed on the fly from multiple documents and external data sources. This allows publishers to repurpose content into new information products as needed to satisfy new customer demands and market opportunities.

XInclude enables the chunking of content into reusable pieces. XProc is an XML pipeline language that essentially allows you to automate a complex publishing workflow which typically includes many steps such as content assembly, validation, transformation, and query.

The second category of application for which XML is a strong candidate is what is sometimes referred to as an "XML Workflow" application. The typical design pattern here is XRX (XForms, REST, and XQuery) where user inputs are captured with an XForm front end (itself potentially auto-generated from an XML schema) and data is RESTfully submitted to a native XML database, then queried and manipulated with XQuery. The advantages of this approach are:

• It is more resilient to schema changes. In fact the data can be stored without a schema.
  
• It does not require handling the impedance mismatch between XML documents, Java objects, and relational tables which can introduce design complexity, performance, and maintainability issues even when using code generation.
  

A typical example of an "XML Workflow" application would be a Human Resources (HR) form-based application that allows employees to fill and submit a form and also provides reporting capabilities.

The third and last category of application are Web Services (RESTful or SOAP-based) that consume XML data from various sources, store the data natively in an XML database directly (bypassing the XML databinding and ORM layers altogether), and perform all processing and queries on the data using a pure XML approach based on XSLT2 and XQuery. An example is a dashboard or mashup application that stores all of the submitted data in a native XML database. In this scenario, the data can be cached for faster response to web services requests. Again the benefits listed for "XML Workflow" applications apply here as well.


The Relational Model

The relational model is well established and well understood. It is usually an option for data-oriented and enterprise-centric applications that are based on a closed world assumption. In such a scenario, there is usually no need for handling the data in XML and a conventional approach based on JSF, Spring, Hibernate and a relational database backend is enough.

Newer Java EE frameworks like JBoss Seam and its seam-gen code generation tools are particularly well-suited for this kind of task. There is no running away from XML however, since these frameworks use XML for their configuration files. Unfortunately, there is currently a movement away from XML configuration files toward Java annotations due to some developers complaining about "XML Hell".

The relational model supports transactions and is scalable although a new movement called NoSQL is starting to challenge that last assumption. An article entitled "Is the Relational Database Doomed?" on readwriteweb.com describes this emerging trend.


The RDF Data Model

Semantic Web technologies like RDF (an incarnation of the EAV/CR model mentioned above), OWL, SKOS, SWRL, and SPARQL and Linked Data publishing principles have received a lot of attention lately. They are well suited for the following applications:

• Applications that need to infer new implicit facts based on existing explicit facts. Such inferences can be driven by an ontology expressed in OWL or a set of rules expressed in a rule language such SWRL.
  
• Applications that need to map concepts across domains such as a trading network where partners use different e-commerce XML vocabularies.
  
• Master Data Management (MDM) applications that provide an RDF view and reasoning capabilities in order to facilitate and enhance the process of defining, managing, and querying an organization's core business entities. A paper on IBM's Semantic Master Data Management (SMDM) project is available here.
  
• Applications that use a taxonomy, a thesaurus, or a similar concept scheme such as online news archives and medical terminologies. SKOS, recently approved as a W3C recommendation was designed for that purpose.
  
• Silo-busting applications that need to link data items to over data items on the web, in order to perform entity correlation or allow users to explore a topic further. The Linked Data design pattern is based on an open world assumption, uses dereferenceable HTTP URIs for identifying and accessing data items, RDF for describing metadada about those items, and semantic links to describe the relationships between those items. An example is an Open Government application that correlates campaign contributions, voting records, census, and location data. Another example is a semantic social application that combines an individual's profiles and social networks from multiple sites in order to support data portability and fully explore the individual's social graph.
  

Of course, these different approaches are not mutually exclusive. For example, it is possible to provide an RDF view or layer on top of existing XML and relational database applications.

Adding Semantics to SOA

What can Semantic Web technologies such as RDF, OWL, SKOS, SWRL, and SPARQL bring to Web Services. One of the most difficult challenges of SOA is data model transformation. This problem occurs when services don't share a canonical XML schema. XML transformation languages such as XSLT and XQuery are typically used for data mediation in such circumstances.

While it is relatively easy to write these mappings, the real difficulty lies in mapping concepts across domains. This is particularly important in B2B scenarios involving multiple trading partners. In addition to proprietary data models, it is not uncommon to have multiple competing XML standards in the same vertical. In general, these data interoperability issues can be syntactic, structural, or semantic in nature. Many SOA projects can trace their failure to those data integration issues.

This is where semantic web technologies can add significant value to SOA. The Semantic Annotations for WSDL and XML Schema (SAWSDL) is a W3C recommendation which defines the following extension attributes that can be added to WSDL and XML Schema components:

• The modelReference extension attribute associates a WSDL or XML Schema component to a concept in a semantic model such as OWL. The semantic representation is not restricted to OWL (for example it could be an SKOS concept). The modelReference extension attribute is used to annotate XML Schema type definitions, element and attribute declarations as well as WSDL interfaces, operations, and faults.
  
• The liftingSchemaMapping and loweringSchemaMapping extension attributes typically point to an XSLT or XQuery mapping file for transforming between XML instances and ontology instances.
  

A typical example of how SAWSDL might be used is in an electronic commerce network where trading partners use various standards such as EDI, UBL, ebXML, and RosettaNet. In this case, the modelReference extension attribute can be used to map a WSDL or XML Schema component to a concept in a common foundational ontology such as one based on the Suggested Upper Merged Ontology (SUMO). In addition, lifting and lowering XSLT transforms are attached to XML Schema components in the SAWSDL with liftingSchemaMapping and loweringSchemaMapping extension attributes respectively. Note that any number of those transforms can be associated with a given XML schema component.

Traditionally, when dealing with multiple services (often across organizational boundaries), an Enterprise Services Bus (ESB) provides mediation services such as business process orchestration, business rules processing, data format and data model transformation, message routing, and protocol bridging. Semantic mediation services can be added as a new type of ESB service. The SAWSDL4J API defines an object model that allows SOA developers to access and manipulate SAWSDL annotations.

Ontologies have been developed for some existing e-commerce standards such as EDI X12, RosettaNet, and ebXML. When required, ontology alignment can be achieved with OWL constructs such as subClassOf , equivalentClass , and equivalentProperty.

Semantic annotations provided by SAWSDL can also be leveraged in orchestrating business processes using the business process execution language (BPEL). To facilitate service discovery in SOA Registries and Repositories, interface definitions in WSDL documents can be associated with a service taxonomy defined in SKOS. In addition, once an XML message is lifted to an ontology instance, the data in the message becomes available to Semantic Web tools like OWL and SWRL reasoners and SPARQL query engines.

From Web 2.0 to the Semantic Web: Bridging the Gap in Newsmedia

In this presentation, I explain the Semantic Web value proposition for the newsmedia industry and propose some concrete steps to bridge the gap.

Welcome to the world of news in the Web 3.0 era.

From Web 2.0 to the Semantic Web: Bridging the Gap in the Newsmedia Industry

View more presentations from Joel Amoussou.

Semantic Social Computing

The Web 2.0 revolution has produced an explosion in social data that is fundamentally transforming business, politics, culture, and society in general. Using tools such as wikis, blogs, online forums, and social networking sites, users can now express their point of view, build relationships, and exchange ideas and multimedia content. Combined with portable electronic devices such as cameras and cell phones, these tools are enabling the citizen journalist who can report facts and events faster than traditional media outlets and government agencies.

One of the challenges posed by this explosion in social data is data portability between social networking sites. But the next biggest challenge will be the ability to harvest all that social data in order to extract actionable intelligence (e.g. a better understanding of consumer behavior or the events unfolding at a particular location). In addition, in a world where security has become the number one priority, various sensors from traffic cameras to satellite sensors are also collecting huge amounts of data. The integration of sensor data and social data offers new possibilities.

Those are the types of integration challenges that Semantic Web technologies are designed to solve. The SIOC (Semantically Interlinked Online Communities) Core ontology describes the structure and content of online community sites. A comprehensive list of SIOC tools is available at the SIOC Applications page. Using these tools, developers can export SIOC compliant RDF data from various data sources such as blogs, wikis, online forums, and social networking sites such as Twitter and Flickr. Once exported, the SIOC data can be crawled, aggregated, stored, indexed, browsed, and queried (using SPARQL) to answer interesting questions. Natural Language Processing (NLP) techniques can be used to facilitate entity extraction from user generated content.

SIOC leverages the FOAF ontology to describe the social graph on social networking sites. For example, this can offer deeper insights for marketers into how social recommendations affect consumer behavior.

One unique capability offered by Semantic Web technologies is the ability to infer new facts (inference) from explicit facts based on the use of an ontology (RDFS or OWL) or a set of rules expressed in a rule language such as the Semantic Web Rule Language (SWRL). Using constructs such as owl:sameAs or rdfs:seeAlso, it becomes easy to express the fact that two or more different web pages relate to the same resource (e.g. different profile pages of the same person on difference social networking sites). Linked Data principles can help in linking social data, therefore building bridges between the data islands that today's social networking sites represent.

SIOC compliant social data can be meshed up with other data sources such as sensor data to reveal very useful information about events related to logistics, public safety, or political unrest at a particular location for example. With the advent of GPS-enabled cameras and cell phones, temporal and spatial context can be added to better describe those events. The W3C Time OWL Ontology (OWL-Time) and the Basic Geo Vocabulary have been developed for that purpose.

Publishing Government Data to the Linked Open Data (LOD) Cloud

In a previous post, I outlined a roadmap for migrating news content to the Semantic Web and the Linked Open Data (LOD) cloud. The BBC has been doing some interesting work in that space by using Linked Data principles to connect BBC Programmes and BBC Music to MusicBrainz and DBpedia. SPARQL endpoints are now available for querying the BBC datasets.

It is clear that Europe is ahead of the US and Canada in terms of Semantic Web research and adoption. The Europeans are likely to further extend their lead with the announcement this week that Tim Berners-Lee (the visionary behind the World Wide Web, the Semantic Web, and the Linked Open Data movement) will be advising the UK Government on making government data more open and accessible.



In the US, data.gov is part of the Open Government Initiative of the Obama Administration. The following is an excerpt from data.gov:

A primary goal of Data.gov is to improve access to Federal data and expand creative use of those data beyond the walls of government by encouraging innovative ideas (e.g., web applications). Data.gov strives to make government more transparent and is committed to creating an unprecedented level of openness in Government. The openness derived from Data.gov will strengthen our Nation's democracy and promote efficiency and effectiveness in Government.

Governments around the world have taken notice and are now considering similar initiatives. It is clear that these initiatives are important for the proper functioning of democracy since they allow citizens to make informed decisions based on facts as opposed to the politicized views of special interests, lobbyists, and their spin doctors. These facts are related to important subjects such as health care, the environment, the criminal justice system, and education. There is an ongoing debate in the tech community about the best approach for publishing these datasets. There are several government data standards available such as the National Information Exchange Model (NIEM). In the Web 2.0 world, RESTful APIs with ATOM, XML, and JSON representation formats have become the norm.

I believe however that Semantic Web technologies and Linked Data principles offer unique capabilities in terms of bridging data silos, queries, reasoning, and visualization of the data. Again, the methodology for adopting Semantic Web technologies is the same:

1. Create an OWL ontology that is flexible enough to support the different types of data in the dataset including statistical data. This is certainly the most important and challenging part of the effort.
   
2. Convert the data from its source format to RDF. For example XSLT2 can be used to convert from CSV or TSV to RDF/XML and XHTML+RDFa. There are also RDFizers such as D2R for relational data sources.
   
3. Link the data to other data sources such as Geonames, Federal Election Commission (FEC), and US Census datasets.
   
4. Provide an RDF dump for Semantic Web Crawlers and a SPARQL endpoint for querying the datasets.
   

The following are some of the benefits of this approach:

• It allows users to ask sophisticated questions against the datasets using the SPARQL query language. These are the kind of questions that a journalist, a researcher, or a concerned citizen will have in mind. For example, which airport has the highest number of reported aircraft bird strikes? (read more here about why Transportation Secretary Ray LaHood rejected a proposal by the FAA to keep bird strikes data secret). Currently data.gov provides only full-text and category-based search.
  
• It bridges data silos by allowing users to make queries and connect data in meaningful ways across datasets. For example, a query that correlates health care, environment, and census data.
  
• It provides powerful visualizations of the data through Semantic Web meshups.
  

S1000D and SCORM Integration

This is a presentation I gave at the DocTrain Boston 07 conference on how to reduce product lifecycle costs by integrating the S1000D and SCORM specifications.

S1000D is the International Specification for Technical Publications utilizing a Common Source Database (CSDB). Based on open XML standards, the latest issue (4.0) has been developed by the AeroSpace and Defence Industries Association of Europe (ASD), the Aerospace Industries Association of America (AIA), and the Air Transport Association of America (ATA).

Sharable Content Object Reference Model (SCORM) is a specification for online learning content developed by the Advanced Distributed Learning (ADL) Initiative.

The presentation has been updated to reflect the addition of SCORM support in S1000D 4.0.

S1000D and SCORM Integration

View more OpenOffice presentations from Joel Amoussou.