V2/V3/CDA Issue Resolution Task Force

Suggested Actions: Tactical and Strategic

Introduction The task force has identified serious challenges facing HL7, arising from the multiple standards it promotes (V2, V3 and CDA), from the complexity of V3 and the RIM, and from market responses to these standards.

I am encouraged that HL7 is acknowledging these problems head-on and is prepared to contemplate revolutionary, as well as evolutionary, responses. This note proposes tactical and evolutionary actions which could pave the way to a revolutionary response (if one is needed), without throwing away the good work of recent years. The intent is to allow HL7 to move beyond the era of competing healthcare standards – both within HL7, and between HL7 and other SDOs.

These proposals are based on two assumptions:

1. The core mission of HL7 is semantic interoperability of healthcare systems, which has huge and proven potential to improve healthcare effectiveness

2. There will always be multiple overlapping representations of healthcare data; no single semantic model or data representation will ever emerge as the winner.

Point (2) may already be regarded as a lesson of history. Some of the reasons for it are blindingly obvious: (a) the massive diversity and semantic complexity of the medical domain, which continues to grow; (b) the number of different stakeholders with differing interests and business requirements; (c) the very high costs for any stakeholder of abandoning ‘legacy’ investments which work; and (d) the preference for local small-scale solutions tightly linked to specific domains.

The task force has addressed a manifestation of (2) within HL7 itself; that HL7 simultaneously promotes V2, V3 and CDA, and so itself is contributing to the diversity of message structures and lack of interoperability of healthcare systems. The diversity of offerings is a weakness for HL7 in the market. A related concern has been the market failure of Version 3, the semantic ‘jewel in the crown’ compared to Version 2, CDA, or to other external standards with little or no semantic foundation.

Semantic Mappings The proposed way to address these problems involves executable semantic mappings as a part of the way forward; so these must be explained.

There can only be a semantic mapping between two formalisms A and B if at least one of them (say B) is a semantic model – a model of meaning in the healthcare domain, typically in UML. Then A can be either another model (model-to-model mapping) or a data structure (structure-to-model mapping). A semantic mapping from A to B states precisely how an instance of A represents an instance of B. It defines the semantics of A, as precisely as it can be defined, in terms of model B. For example, if A is the V2 structure for the OMP^009 message, and B is a V3 Pharmacy RMIM, the mapping from A to B defines what an OMP^009 message means, in terms of the RIM-based Pharmacy model. If the mappings are executable, they can be used directly to translate instances in either direction, without further coding. Executable mappings are supported by the mapping tools on the HL7 Homebase, and by some model-to- model mapping tools (developed in the Eclipse community, and used by current HL7 tooling work in NHS and IBM/VA).

Executable semantic mappings have four main uses:

1. They precisely define the semantic relationship between two formalisms – as a basis for defining and testing semantic interoperability between systems

2. By providing runtime data translations, they support the reliable implementation of interfaces between systems

3. By allowing systems to send and receive messages in several mapped formats, they support an incremental migration path from one formalism to another – removing the need for ‘big-bang’ cutovers

4. Through open sharing and review of mappings, the whole community can share and build its knowledge of interoperability problems and solutions – rather than having different suppliers duplicating effort and making different mistakes behind closed doors.

Executable semantic mappings are not yet widely used, so these benefits are not commonly gained. They could be.

Proposed Evolutionary Steps The proposed tactical/evolutionary steps are to:

 Develop and publish executable semantic mappings between V2, V3 and CDA

 In collaboration with other SDOs (such as CEN, NCPDP, CDISC, and ASTM), publish semantic mappings of their standards onto RIM-based HL7 models.

These steps are evolutionary in that they do not move away from or abandon anything that has been developed by HL7, or by any other SDO. They move towards a common semantic base for all healthcare IT standards, in line with HL7’s mission of semantic interoperability. They contribute directly to HL7’s strategic initiative 4, to ‘define an overarching and internally consistent interoperability framework’ – with mappings to RIM-based semantics providing the internal consistency between V2, V3 and CDA. All the practical benefits of the uses (1)-(4) above will start to accrue, wherever the mappings can be defined.

In terms of the public perception of HL7, the semantic mapping activity could justify and underpin a statement along the following lines: “HL7 promotes three different stables of healthcare data format, for good historic and pragmatic reasons. But we provide a common semantic underpinning for all three, in RIM-based semantics. Through published mappings, we provide practical means for users to interoperate between the different standards – testing interfaces, implementing them, and migrating from one standard to another. We do not compete with other SDOs, we work with them to provide a sound basis for semantic interoperability.”

Binding Local Models to Interoperability Models HL7 working groups have spent a great deal of effort over the years developing DMIMs and RMIMs to support semantic interoperability in their domains. These RIM-based models are carefully constructed to provide adequate semantic coverage and to remove the ambiguities which can give rise to interoperability problems and errors.

However, the resulting collection of RMIMs is very large. Experience has shown repeatedly that rather than select appropriate RMIMs and constrain them to specific interoperability use cases, HL7 members and others prefer to work with simpler local models, which they can see match their specific requirements – or fit their legacy investments. The perceived complexity of the RMIM-based models, and the XML derived from them through the ITS, is just too large.

The preference for local models can be seen in the low takeup of HL7 V3, and in other developments in and around HL7:

 The much greater takeup of CDA compared to V3 – where a templated CDA section typically has a much simpler structure than the corresponding V3 RMIMs

 The development of more clinician-friendly representations such as archetypes and DCMs

 The continued interest in simpler XML representations such as the µ-ITS and Green CDA

 The growth of RIMBAA systems – where developers build their own RIM-based models, which can be simpler than RMIMs

So a strong preference for local, problem-specific models may also be regarded as a lesson of history. The problems then arise from the proliferation of local models, and because their relation to the interoperability model is not always fully defined. For instance, while a template CDA section and a V3 RMIM are both RIM-based, it is often not clear what is the precise semantic relation between them.

Charlie McCay has related this to the wider IT industry interest in Domain-Specific Languages (DSLs), and suggested that we might make fuller use of the emerging tooling for DSLs – such as model-to-model mappings and transformation. HL7 needs to be able to support and encourage local models – with their own notations and DSLs – while not compromising its commitment to semantic interoperability based on the RIM-based models it has carefully built. To do so, HL7 should provide methods and tools to define local models and languages, while always clearly defining their semantics in terms of the interoperability model. Semantic mappings to the interoperability model should be built as the local models are built – not as an afterthought.

If these semantic mappings are executable in both directions, then any local model can be continually tested, as it is built, against interoperability requirements as well as the local business and domain requirements.

In this way, the ‘public face’ of HL7 could be the local models, expressed in DSLs congenial to domain experts and software engineers, while semantic mappings would give a precise and executable bridge from the DSLs to the RIM-based interoperable forms.

Enabled Strategic Steps The task force has expressed concern that V3 RIM-based models are highly complex, as well as other concerns about the RIM. This raises the possibility that HL7 may need some revolutionary solution – which one might call HL7 V4. However, this route could create further confusion in the market and damage the takeup of the current standards, over some long period while a new standard is gestating.

Once HL7 has established the practice of making semantic mappings between its different standards, that practice can greatly reduce the risk that any new standard would undermine the current standards. As each part of the new standard was developed, precise semantic mappings to HL7 V3 would be developed and tested at every stage. In this respect the new ‘HL7 V4’ would be treated just as other standards from HL7 or from other SDOs. Users could continue to build V2, V3 and CDA interfaces – knowing that those interfaces could interoperate with V4 interfaces, or could migrate incrementally towards V4, using the semantic mappings to define, test, and implement the required translations.

Executable semantic mappings would make the introduction of a new core HL7 standard feasible without confusing the market or abandoning current investments. Whether or not such a new core standard is necessary is outside the scope of this note.

Conclusion This note has proposed that executable semantic mappings can do much to meet the challenges recognised by the task force, and to enable HL7 to meet its strategic goal of semantic interoperability.

The key is to recognize that a plurality of healthcare standards and data representations is a fact of life – and not to struggle against that fact, but to learn how to achieve semantic interoperability in the face of it. There can be many healthcare standards and many data models – provided there are well-defined and executable semantic mappings between them. These mappings both enable the day-to-day implementation of interoperability, and also make clear the limits to interoperability. Mapping one model onto another is the fastest way to discover their core incompatibilities and ambiguities, before you have written reams of code and installed systems. To achieve this vision of semantic interoperability in the face of diversity, HL7 will need to alter the balance of its deliverables. In the past it has delivered semantic models, implementation technology specifications (ITS), and implementation guidance. To these three must be added a fourth component – executable semantic mappings – which are developed hand in hand with the models and ITS, not as an afterthought. Experiment and piloting will be needed to discover what are the best tools, processes and governance to deliver these mappings as a core part of HL7’s role.