SKT

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)

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.

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.