Is RIMBAA a Mistake?

HL7v3 is a framework for developing messages in healthcare. Unlike its predecessor, v2, HL7v3 has at its core an information model, the RIM (Reference Information Model). The RIM contains classes and relations. From the RIM actual healthcare messages are derived, usually as XML instances. This is what HL7v3 does in a nutshell, and its focus is clearly on messaging, nothing else.

Recently a new school of thought is gaining ground: RIMBAA (RIM-Based Application Architectures). RIMBAA seeks to use the RIM not solely as the basis for messages, but to use it as the basis for an entire EHR (Electronic Health Record) system. The RIM, after all, is quite rich, and if it is rich enough to describe messages which care providers exchange between them, why not use it to describe the data contained in an EHR itself? This also makes deriving messages from my EHR a piece of cake.

Here’s why not.

Suppose I build an EHR from a certain HL7v3 version X (there are plenty of versions, called “ballots”, to choose from) and I also exchange messages with my colleagues using version X. If we now decide to upgrade the messages to version Y, I’m forced to do a double update: I have to upgrade not only my messaging framework to version Y, I also have to upgrade my entire EHR to version Y.

RIMBAA thus leads to tightly coupled systems. In a loosely coupled architecture, systems are black boxes: each system just has to know the interface (messages) of another system to communicate. In loosely coupled systems, each system can be upgraded or changed independent of other systems, as long as the interfaces remain unchanged. Loose coupling is a core design principle of Internet-scale messaging, and RIMBAA violates it.

Moreover, if RIMBAA gains wide acceptance, a majority of EHR’s would become RIM-based, and thus EHR’s would be very alike. Good, not? Since they’re so alike, won’t it be easy to communicate? Nope. If all, or many, EHR’s follow the RIM, there will be less competition, which will stifle innovation. Having EHR’s which are not based on the RIM enables healthcare developers to adopt any wild, new, unthought-of innovation they wish, as long as they keep supporting the common messages. This difference allows the full creativity of healthcare providers to be expressed in their systems, and is good for innovation and competition, major drivers of human progress.

With RIMBAA, it’s either taking what the RIM offers, or leaving RIMBAA. The latter is probably the best choice: take some inspiration from the RIM where useful, develop your EHR, and forget there ever was a link. I’ve seen a lot of efforts to harmonize data models, and it seldom works on a large scale, not even in a single large company. Different needs are simply too different. For messaging, a common data model is a necessity. For application architectures, it is a commodity at best and a nuisance at worst.

RIMBAA (and similar initiatives), in short, will lead to systems which are hard to upgrade, will stifle innovation and will hinder progress. It is much better to follow HL7v3’s original course and keep standards for messaging separate from standards for EHR’s. RIMBAA violates the fundamental design pattern of loose coupling and is a mistake.

Implementing Healthcare Messaging with XML

Last week Monday I gave a presentation on XML 2007 titled “Implementing Healthcare Messaging with XML” for a very attentive and responsive audience, chaired by Tony Coates. David Orchard and Glen Daniels of multiple WS-standards were there, and I had an interesting chat with them afterwards on the layering problems of WSDL mentioned in my presentation. Jon Bosak inquired about ebXML – which we hadn’t used because it did not seem to get any traction from IBM and Microsoft at the time. With hindsight, looking at what ebXML (ebMS specifically) delivered years ago and the time the WS-* stack took, one wonders whether this was such a wise decision… Anyway, it was great to have such a responsive crowd.

Axioms of Versioning 2

I’ve written a new version of ‘Axioms of Versioning‘. I extended the formalization to get a grasp of the concept of ‘Semantic Backward Compatibility in HL7v3, which I believe is flawed (quote: “Objective of backward model compatibility is that a receiver expecting an ‘old’ version will not misinterpret content sent from a new version”). It seems to be the reverse of the position of the W3C TAG in ‘Extending and Versioning Languages: Terminology‘, and the position I would defend myself. Yet the interaction of new senders with old receivers was not sufficiently explored in my Axioms.

It turns out that exploration of this notion leads to quite natural definitions of ‘may ignore’ and ‘must understand’ semantics. The HL7v3 notion is probably best characterized by the concept of ‘partial semantical forward compatibility’ in my new Axioms. The concept is also close to, if not the same as, the TAG’s ‘Partial Understanding‘.

It really thrilled me to see how helpful my formalisms were in exploring the notions in HL7v3, and uncovering the – I think – hidden meaning in it.