Models and Messages: Insights from the HL7/OMG Services Specification Project

Recently I have been doing much of my standards work within a joint project between OMG and HL7, the HSSP Healthcare Services Specification Project that is using a combination of methods from OMG and HL7 to develop interoperability specifications for services (in the SOA Service Oriented Architecture sense) in and between healthcare information systems. These services concern, for example, managing identity of individuals and organizations; locating records; verifying terminology; and various kinds of clinical decision support.

This work is heavily model-driven, encompassing the model-based methodology of OMG, and the model-based messaging philosophy of HL7 v3. Interoperability can be based primarily on XML data exchange, or primarily on shared models. Proponents of both tend to regard the other as "platform-dependent"; in truth, good interoperability depends on getting a balance between these two viewpoints.

This paper provides a view of this work for XML 2005 attendees, including an update on the HSSP, and discussion of the role of XML in the context of service-oriented standardization in a heavily model-driven environment involving two different standards organizations.

This section presents two motivating examples, based on scenarios developed in US and UK contexts respectively.

A few years down the road, the way we manage our health information could change. Imagine that you have a family history of heart disease and personally have many risk factors for developing the condition. You want to learn more about ways of preventing the condition, so you visit your networked personal health portal, a website that maintains your electronic medical information in a personal health record (PHR) and provides information about a variety of health concerns

After reading up on the condition, you decide to begin a self-imposed regimen of low-dose aspirin. You navigate to a screen within your PHR where you enter information about over-the-counter medicines you are taking and record your intention to start low-dose aspirin.

After entering your information, you receive a drug interaction alert from the system telling you to avoid aspirin and to consult with your doctor. You had forgotten that you had experienced a bad reaction to aspirin as a child. Thankfully, the system is tied into a network that includes your provider’s EHR system, where your medical history is stored, preventing a potentially adverse reaction.

Your provider’s EHR systems have access to your electronically available medical history and can instantly give alerts on drug interactions because in the year 2006, the US took action spurring the healthcare industry to rally around a set of commercial open standards. These standards allow their software to interoperate, performing functions such as identifying you, locating your information and retrieving it with your consent. This interoperability is the backbone of the electronic personal health record.

This scenario was developed by US-based members of the HSSP.

A child is causing concern across several agencies, including health, social services and education. The incidents that have given rise to this concern are spread across several different London boroughs, since the child in question lives in one borough, attends school in another, and was recently admitted to A&E following an incident at a leisure centre in yet another borough. This child is the subject of information sharing between agencies as illustrated below, in accordance with an existing Information Sharing Protocol (a legally-defined framework for controlled sharing of sensitive information).

The key features of this scenario are:

In order to support these requirements, a technical architecture has been developed based on the concept of a "trusted information broker" that integrates local line-of-business systems and forms a node in a scalable network of secure information interchange. This architecture is expected to be realized using interoperable services, and the standards emerging from the HSSP are strong candidates for adoption for this purpose.

This scenario was developed by the FAME Framework for Multi Agency Environments project. In-depth business level discussion of this scenario, together with other examples, may be found on the FAME website, http://www.fame-uk.org. FAME offers advice and guidance on establishing successful multi-agency information sharing. It recommends a holistic approach covering both the technical and non-technical requirements, stressing the importance of arrangements which reinforce trust and strategic procurements of infrastructure to enable present and future inter-operability of systems.

Health Level Seven (HL7) Inc., one of the world’s most prolific healthcare standards developers, and the IT specifications consortium Object Management Group (OMG) are collaborating to build a set of healthcare-domain software components and services interface standards to promote interoperability across health provider organizations and health related software products. Conceived to support healthcare IT as part of national initiatives such as the U.S. Department of Health and Human Services’ National Health Information Infrastructure and similar initiatives throughout the world, the cooperative effort builds on the complementary strengths of the two organizations. The initial focus of the effort is to address the need for standards directly supportive of electronic health record interoperability and information exchange.

As set out in the project charter, the two organizations will jointly identify and prioritize candidate services for standardization. HL7 will elaborate the business functional needs, allocate functions to services, and provide information modeling and content. OMG will then develop these business domain requirements into specifications for software architecture and components using its foundation technologies – the Unified Modeling Language™ (UML®) and Model Driven Architecture® (MDA®). Strengthened by the support of companies holding membership in both organizations, the cooperative effort is on track to produce its initial deliverables by the end of 2005.

XML plays a key role in these stanardized services, since service instances conforming to these standards will be relying heavily on XML based standards for realizing service interfaces and for interoperability of data interchange. However, it is important for the XML community to understand that despite this, XML is just one possible platform for implementation. It may even come as a shock to some that XML can be viewed (legitimately) as a candidate platform for implementation, rather than as some kind of magic guarantee of platform-independence in its own right.

In fact, there are two complemetary points of view at work here. From the point of view of a pure model-based standard, XML is (just) a platform, even if using XML is the only sensible option. From the point of view of a pure XML-based data interchange standard, a non-XML model used at the endpoint of an XML data transfer is probably a platform, from which the XML is in principle independent.

In practice, a pure model-based view tends to lead to autogeneration of XML from non-XML models, often accompanied by the opinion that not even developers should have to deal directly with XML. A pure XML-based view tends to run into problems when the information to be exchanged is inherently complex, or when simple data exchanges are providing information that has a complex implied context.

These limitations are also reflected in implementation experience with standards. For example, XML data that is automatically generated from an instance of a pure model-based standard is often difficult to use except to regenerate a model of the same kind. In practice, such standards usually expect very similar technology at each end of the "wire", such as Java objects or UML. Conversely, a pure XML-based standard can lead to problems with semantic interoperability, that is, data being exchanged without enough context to ensure it is well understood. Recent years have seen a number of semantic frameworks such as ebXML emerging in the XML world to mitigate this problem.

The HSSP is aiming to steer clear of both these traps, by recognizing this apparent dichotomy as a key design trade-off in the development of interoperability standards.

Acknowledgements

Biography