Why did OpenIZ use the HL7 RIM?

One of the questions you might be asking yourself is: Why on earth, would the designers of OpenIZ use the HL7 RIM (Reference Information Model) as the basis for the platform.

It is true, there are alternatives to using the RIM as an information model including HL7 FHIR, HL7 v2, OpenEHR, custom model, etc. So, I thought since it is Friday, it would be a good time to do some explaining of why the OpenIZ data model is the way it is.

So, why the RIM?

Good question, at a high level:

• The RIM is very expressive, it allows us to represent a variety of use cases outside of immunizations. Often, countries will try to leverage investments in one programme area for another purpose, and Immunization is no different. When you think about it, Immunizations are just a part of child care, and child care is really a part of maternal and child care, and maternal care is part of patient care. The key here is we wanted OpenIZ to be patient centric rather than programme centric .
• The RIM saved us time (that might sound like an weird statement given the common complaints about HL7v3). By leveraging the RIM, it already gave us a logical construct to work within, there are literally thousands of pages of documentation on the RIM, and this really saved us having to invent our own way of doing things.
• There are a ton (probably a metric tonne if we printed it out and weighed it) of documentation surrounding the RIM, and there are lots of training materials for the RIM. These training materials can be adapted for OpenIZ relatively easily.
• We probably would've come up with something not as good or similar anyways. Given the fact that we wanted a patient centric record for immunization, and the fact that there are probably millions of person-hours of effort put into developing the RIM, we felt that this analysis wasn't worth reproducing.
• We felt like we could simplify the RIM, since we have extensive expertise in HL7v3 we felt that the pain points of the RIM could be optimized and made less painful. Also the advent of better tooling and better wire level formats would assist in this.

Things we took out:
In order to make the RIM a little more bearable, we had to take some things out, this is a high level..

• Roles - This is perhaps the biggest change we made to the RIM. OpenIZ's data model is based on Entities Participating in Acts, whereas the RIM is Entities playing Roles Participating in Acts. Why did we take out roles? Well, after some careful discussion in the team we determined that there was really no need given the use cases to differentiate between Bob the Doctor and Bob the Patient, we just create two entities (even though they are logically the same entity, the benefit of this added join just added complexity).
• Procedures - One of the major classifications of Acts missing in OpenIZ is Procedures. The reason for not including these was simply a matter of resourcing, we didn't have sufficient resources to put into developing this Act type given the other pressing concerns. Procedures are on the roadmap for OpenIZ in the future, as we definitely want to allow people to record procedures done to the patient.

Things we added:

Not everything was an exercise in removal. We've adapted the RIM to include some concepts from FHIR as well.

• We added versioning to Acts and Entities which means that instead of using Replaces relationships, we just version the entity and  act independently of the entity or act relationships. We still have entity relationship of replaces but that is now used for merging.
• We added the concept of Extensions and Tags. These are taken from FHIR. An extension defines a versioned piece of data about an entity or act, that is creating a new extension creates a new version of the entity or act. Tags on the other hand, allow for non-versioned tags to be attached to an object.
• We added the OpenMRS concept dictionary data model to the RIM. This gives the information model a little more flexibility in terms of using concepts in the context of the RIM. This is a huge shout-out to the flexibility of the OpenMRS concept dictionary information model which separates the logical concepts from wire-level reference terms.
• We added some proprietary schema tables around consent and permissions. This was borrowed from IHE XDS' view on confidentiality. Rather than tagging a code as in the RIM for privacy, we allow the associating of security policies against an object.