views:

367

answers:

3

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!

+5  A: 

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.

John Saunders
+3  A: 

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.

+2  A: 

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.

ThaDon
HL7 is so thoroughly customized by customers that "support HL7" is a meaningless requirement. It's necessary to say something like "support HL7 the way required by customer {x, y, z}". It's also necessary to test for that constantly, to make sure nothing gets broken.
John Saunders
You are correct at the Interaction/MT level, those are left up to the various country standards organizations that are governing HL7 adoption. It's up to the customer to "fill in the blanks" where the national standards organizational hasn't captured all of the customer's domain. But the concepts, methodologies and datatypes are going to be the same across domains/implementations. Essentially if you "know HL7" you should be able to go from customer to customer and jump in.
ThaDon