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.

4 Replies to “Is RIMBAA a Mistake?”

  1. One of the main assumptions of this post is that RIMBAA applications are based on message models. That is theoretically an option (see but in practice one sees that applications are based on the HL7 RIM (and not on message models derived/specialized from the RIM).

    The HL7 RIM has been stable for the past few years, just a couple of attributes have been added to it. Therefore the versioning argument against a RIMBAA approach doesn’t hold true.

    In those cases where people have opted to base their application on a message model (yes, it happens) they probably only support CDA (a v3 model for clinical documents which has been been stable for 5 years). I agree with Marc that versioning of an internal data model is undesirable – and this is something that current RIMBAA-style implementations try to avoid.

    The author doesn’t like the “tight coupling” between the application model and the messaging model – but it’s probably less tight than he thinks. The RIM is a relatively abstract model, so there is quite a bit of mapping involved to transform it into the structure of a HL7 v3 message.. or to HL7 v2, or to any other format. The message structure may be changed between v3 publications – such differences are however resolved in the mapping to the underlying base RIM structures.

    When it comes to RIMBAA it’s early days yet; therefore it is appropriate to ask the type of fundamental questions posed by this blog.

  2. @Rene:

    I agree that when RIM is the base model used in app development, versioning issues play much less a role. We also seem to agree that basing a RIMBAA app on a model close to the message model would be undesirable. I.e., using a native XML database and building an EHR consisting of HL7v3 payload data in XML format would introduce versioning problems.

    The RIM is pretty generic indeed. The cost is there is effort required in mapping the messages to the RIM-based data: but as I’ve argued, that is a good thing, since it decouples internal data from message data.

    Though still, a RIMBAA app using the RIM would probably use some more than just RIM classes: HL7v3 datatypes, OID’s for identification of artifacts, classCodes, other code values. So even basing an app on the RIM introduces plenty of coupling between application and messaging levels.

  3. Yes, a RIMBAA app must use datatypes, OIDS, and structural vocabulary. So the versioning issue is not moot, but certainly not as bad as it could be.

    The real problem with RIMBAA to me is that the RIM+DT+ontology is a model of interchange, not a model of management. It has a very observational view of the world (which does actually manifest in “everything is an observation” arguments, but this is the least important part of my intent here). It appropriately sweeps under the carpet all sorts of deep issues about how information should be stored to foster longitudinal management.

    Two instances off the top of my head:
    – developers of real clinical applications are accustomed to the fun and games around patient identification, merging, and error management that occur in a large distributed environment. The rim has very little to say with tracking the details of this. The RIM itself is probably adaptable to this purpose (it’s just a grammar, after all), but there is no support in the structural vocab – you’d have to invent appropriate terms. So simple EHR’s may prosper, where these issues can be swept under the carpet, but as you scale, this would be very difficult. Also, the RIM stores are very denormalised with regard to storing identifiers – they are distributed across the entities rather than gathered in specific domain structures. For instance, there’s not even a single table of identifier types.
    – the same applies to CD. CD is a very flat structure which is appropriate for interoperability. But for an actual working system, there’s no way I could imagine not normalising CD, and adding lots of extra information in order to make data entry and content management workable

    So I think that RIMBAA is very risky, both in terms of the design of what is already covered, and in terms of missing scope of the RIM. But with regard to the former, you could heavily normalise the persistence store while still following the sementics of the RIM. This would be a virtual RIMBAA, and is yet another axis of implementation choice to add to the RIMBAA map of the world (Rene’s diagram)

  4. Is there anyone who has implemented this RIMBAA in a functional EHR ?
    One missing factor in Hl7 as a whole is that they concntrate only making theoretical frameworks. These kind of stuff needs some practical evidence or atleast some samples to show the effectiveness.


Comments are closed.