The RIMBAA Technology Matrix
The contents of this whitepaper are published under the Creative Commons Attribution-Share Alike license.
An increasing number of software implementations in healthcare use a HL7 version 3 RIM based application architecture (RIMBAA). The subject of this whitepaper, the RIMBAA Technology Matrix, was created in order to be able to identify the architectural choices used by the designers of these applications in a technology independent fashion. This in order to determine a set of generic approaches and best practices related to the use of HL7 version 3 RIM-based models for purposes other than messaging.
1. IntroductionThe focus of the HL7 standards, including the HL7 version 3 Reference Information Model (RIM), has traditionally been on the exchange of data. The internal architecture of software applications was regarded to be out of scope.
"The RIM model is too good to be limited to messaging” says Peter Hendler, one of the committee chairs of the HL7 RIM Based Application Architecture (RIMBAA) group. “If someone were to show a programmer the RIM data model - and not give them any pre-information that it was created by an organization called HL7, and that the scope of HL7 is messaging - if you just put the data model in front of a programmer or an architect and say: please look at this model, and you ask them: what do you think this model is for?. Probably they'd look at the model and they'd say this is a very comprehensive model which could be used for making healthcare applications and could probably even be used to make persistence layers and relational databases."
Other implementers have come to the same conclusion (mostly because of exposure to the HL7 RIM in the context of messaging) , and are using RIM-based models as the basis for the development of applications. The RIMBAA technology matrix described in this whitepaper allows for a comparison between the architectural approaches used by these applications.
1.1 Rationale for the matrixSeveral RIM-inspired real-world solutions related to the challenge of generating HL7 version 3 messages from persistent storage were presented during the April 2007 meeting of the Dutch HL7 version 3 Architecture SIG. Some applications use HL7 version 3 models to persist data, others at the application layer, and others as the basis for user interface generation. During the meeting one implementer presented an implementation that used the HL7 version 3 RIM throughout.
The solutions used different ways of persisting the data (e.g. a pre-existing database, or a newly developed fully RIM-based database) and totally different mapping technologies (e.g. .NET Serialization, SqlServer XML queries, JAXB generated Java code). This resulted in quite an extensive set of interesting approaches to achieve the same goal.
It was however quite hard to understand what technology was trying to solve which part of the overall problem. In order to determine a set of generic approaches and best practices a way had to be found to describe (and compare) the various approaches in a technology independent architectural fashion. Ewout Kramer, one of the members of the Dutch HL7v3 Architecture SIG, came up with the RIMBAA technology matrix, which allows us to do just that.
1.2 The RIMBAA technology matrixThe RIMBAA technology matrix contains all possible “roadmaps” to transition between the persistence layer and the serialized representation (e.g. XML messages) of the data.
Transitions between cells could be supported using one of several alternative approaches. The cell transitions won’t be the same for all applications - a partial overlap in paths is however likely, which means that the experiences and best practices associated with that path can be shared between implementers.
1.3 The third dimension of the matrixThe Technology Matrix has a third dimension: the middle column (the *O cells) is one and the same; it covers the ways how RIM-objects are related to the Processing Logic (PL) and the User Interface (UI).
On the assumption that one uses the RO cell (of the Technology Matrix) Procesing Logic could be done in multiple ways. The extremes are:
A few implementations are creating solutions related to the user-interface: the generation of dynamic user interfaces or forms. The goal is the semi-automatic generation of a UI (mostly based on a CIM), with controls that are suitable for the (flavoured) data types being used, with support for the appropriate binding of value sets, and validation of the data that is entered according to the appopriate templates and OCL statements.
When asked what one would 'normally' use to generated a user interface, Ewout responds with: "This is an area were I haven't seen a lot of experiences yet." and continues with "I'd say that we first transform it into an object model, and then from the object model you go into the user interface. I know that some people are doing translations directly from the message into a user interface. How one would do that - receiving data and validating it, is quite difficult. I think the object model plays an important role here."
UI's may be based on the RO, the CO or the AO cell as defined in the Technology Matrix. There are two (extreme) options:
An interview with Ewout Kramer about various aspects of the RIMBAA technology matrix can be seen here:
2. Conclusions and recommendationsThe technology matrix is all about a reference model driven approach to application architectures. In general, not just when discussing the HL7 RIM, it is beneficial to use one and the same semantic (reference) model for messaging, in-memory application objects as well as at the persistence layer. This ensures the lowest degree of semantic loss due to mappings between data models.
The OpenEHR architecture (which mainly focuses on the RO cell) regards the consistent use of one single reference model as an essential requirement for implementations: "The meaning of information must be preserved from this point down through layers of business logic to its representation in the persistence (data storage) layer. If this is not the case, information entered by a user will not safely reach the part of the system which allows it to be shared with other users or other systems, or even the same user at a later time.. The same page criticizes messaging standards for their limited focus on serialized messages (the CS cell) without specifying the details of the application stack (the RO cell).
The video below contains an interview with two software developers about RIMBAA and the Technology Matrix. Both work for large HIS vendors, and have to deal with legacy applications and legacy data.
The HL7 RIMBAA Working Group has created a Java based Reference Implementation. This can be used to gain experience with this type of architecture. Whilst it is too early to draw conclusions (we’re still in the process of gathering RIMBAA-technology-matrix based
descriptions of implementations), some observations can be made related to current HL7-RIMBAA implementations: