which approach do you recommend for data model in a e-health system

Question

We have been assigned to build a e-health platform for a customer, and in the design process we have arrived to this dilema:

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

Although the RIM has been documented extensively and it 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 take in account only the customer 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 in a simpler model for the requirements of my customer?

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

Any advice would be great!

Answer 1

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 2

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 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.