Should I use HL7 RIM or roll my own data model?

Question

My team has been assigned to build a e-health platform for a customer, and in the design process we have arrived at this dilemma:

We have two options for the data model, the HL7 RIM (reference information model) and another one that is yet to be designed.

Although the RIM has been documented extensively and seems very complete, I'm not sure if it is the best choice, given its complexity and apparent slowness.

I would like to design a more simple model which would take into account only the customer's requirements, aiming to be more easy to understand and maybe faster.

What do you think? Should I follow the HL7-RIM? Or should I think up a simpler model for the requirements of my customer?

In any case, the need for interchange of information would require an implementation of the HL7 messaging protocol, so we must develop that part independently of the underlying model.

Answer 1

The more flexibility you require in terms of healthcare data (the more of a "repository or data warehouse" your application is), the more the reason to implement the HL7 RIM. Search for "RIMBAA" (RIM Based Application Architecture) for additional information on this approach.

The more your application is oriented to support one particular set of well-defined workflows, the more reason to use a data model that's optimzed for that particular workflow. I agree with John Saunders: make sure your 'optimized data model' can be mapped to the RIM. That should help to 'future proof' your application and to make it easier to support HL7 interfaces.

Answer 2

The answer is to use your own model, specific to customer requirements, but with a functional requirement to always be able to interchange with HL7. Test that requirement throughout your development process.

Answer 3

I would recommend HL7 however you should be strategic about its use. I'm assuming you have a whole suite of software systems at your organization already. If that is the case, it's probably a good idea to have "HL7 interfaces" exposed on key services, but have the internal dialog in some canonical form specific to your organization.

The great thing about HL7 is it's inherently message based, so you can do all sort of cool things with Business Proccessor Manager (BPM) software where you are just letting your business people draw nice charts of how the flow of an HL7 message is governed.

One thing I might suggest is doing an investigation of the various "adapters" out there, for instance "iWay Intelligent Adapter for HL7", or IBM's WTX. These let you concentrate on the business code you'll need to write, instead of having to worry about HL7 messaging at the transport layer, etc...

Hope that helps.