Asserting Interoperability

There are an increasing number of activities today trying to address and/or measure interoperability. Organizations such as HITSP (in the US) are defining standards that will be the support structure for interoperability. Groups such as IHE are developing interoperability profiles to tighten areas of ambiguity en route to stronger interoperability. HL7's EHR group has produced materials to guide consumers through the myriad of infrastructure en route to interoperability.

As we have been progressing with the HSSP activities, our work of late has been drilling-down into interoperability, considering what is needed to interoperate. As I think about my earlier posts, and given that some time has passed since my last posting, I have come to appreciate the importance of the multitude of perspectives that must each be considered to be interoperable. Let's delve...

1) Semantics. "The Holy Grail.' At the point we are able to meaningfully exchange business-pertinent healthcare information, at one level we will have achieved success. The challenge is to maintain sufficient information richness and sufficient context for the information to be meaningful and useful to the consumer.

2) Computational Mechanism. If we have the richest business semantics and we are exchanging that information on paper and via fax, have we achieved the potential of EHR's and interoperability? Probably not. While a purist view only requires information exchange, the format matters. Anyone who has travelled and forgotten a power adapter appreciates the difference. How things plug together matters, and the better the infrastructure we put into place to allow systems to interoperate (such as SOA services), the more flexible our organizations are to adapt to changing needs and technologies.

3) Business and Context (credit to HL7 EHR). Maintaining contextual relevance is important to interoperability. Receiving information items such as systolic and diastolic values does not convey enough information for that data to be useful. The same is true with business context. Patient self-entered information may be less reliable than that entered by a healthcare professional. Maybe not. (For example, what if we're talking about a family history). Understanding metadata and contextual information has relevance as we seek to build interoperability bridges across organizations and enterprises.

So, what do we do?
Two very important pieces must converge to address these matters and be able to assert and test conformance. HSSP work already includes the notion of conformance profiles, which comprise many of the datapoints above. By making conformance assertions that address the semantics and the functions (e.g., the computational mechanism), we are taking a more comprehensive view of interoperability.

Alan Honey (Kaiser-Permanente) had a great realization on a teleconference today that I believe ties things together nicely. If we consider the idea of an implementation context, many of these issues come into focus. Including this concept into our perspective of conformance propels this notion forward. We can elect to have an implementation context bringing together the business perspective, policies, and relevant environmental context in play within an organization. We can do the same for a RHIO or National context.

Integrating the notion of a "domain" into comptuational specifications is well established. (This approach was taken in the OMG Person ID Service -- PIDS -- many years ago). Perhaps I'm just now realizing the potential of this very simple idea as it adds a dimension to conformance and interoperability assertions.

What about Localization?
Not everything needs to be standardized and interoperable. Frankly, that is one of the strengths of this approach. In our conformance profiles, we can make assertions about what information, what behaviors, and what contextual elements can interoperate. The "rest" comes along for the ride. So long as we can precisely describe what is and is not interoperable, we have the freedom to extend specifications to include what we need and still be useful.

Many criticize HL7 v2 messaging because of the lack of interoperability that resulted from ambiguity in "Z" segments. On the contrary, HL7 V2 was and remains wildly successful at allowing organizations to interchange information and interoperate. The problem is not in the wire protocol, it is in the conformance assertions.

We have an opportunity now to benefit from the lessons learned from the past, taking the utility and flexibility offered by "Z" segments and tempering them with strong enough conformance so as to give confidence to consumers that things will interoperate within an interoperability profile. The challenge is on us to ensure that the interoperable portion is sufficient.