HL7 Object Model
So I can't believe its been a year since the normative standard of HL7 version 3 has been released. It seems years in the coming, and now here it is.
But that's obviously just the start. So we have the RIM. We have DMIMs. And we have schemas. In fact we have a lot of schemas. 1000's in fact. And many different data types. So the next big question is how do we use them?
Well that probably depends on what you are trying to achive. (As a side note that's one of the reasons why there are so many; controlled flexibility) Interested in a detailed healthcare data model around the Laboratory? Try the Lab Domain DMIM. Interested in allowing a doctor to request an appointment with a hospital for a patient? Look at the interactions for the Scheduling Domain. And that's were the benefit and pitfall of the Version 3 paradim lie. It can be used to describe just about anything in the healthcare space, so where do you start?
One area of interest is in the generation of class libraries that reprisent the data contained within the interaction messages. There are many reasons why you would want to do this, say simplifying development of software that would like to communicate in the HL7 v3.0 world. But again there are many situations where this is hardly ideal, say when you want to extract a single value from the message.
I have enough reasons to make it worthwhile. So. If you try and generate a series of class libraries directly using a tool you end up with an awful lot of classes. Not so helpful. With thousands of datatypes being represented by thousands of classes you might as well use xPath given the memory requirements. A more subtle approach may be required.
One area I am currently investigating is the generation of base libraries of data types. I think the best approach is to start with the core schemas in the HL7 schemas. Only data types that have actual implementations will be included (so if an element is cloned but never used it's out). Once these have been modelled its onto the CMETs. Then we can start looking at software factories, or tools to generate domain specific classes.
The trick here is going to be namespacing to prevent redevelopment or multiple reprisentations of the same data type. Once the basic platform is created tools will hopefully provide the way forward to creating specific and re-usable, but most of all fast classes for serializing/deserializing HL7 interactions. Beyond that? Auto generation of web service end points, databases and fully interactive class systems (i.e. the system should be aware of associated messages).
I'll let you know how it goes!
Steve Hart has posted on this subject as well at http://www.hartsteve.com/2006/09/11/hl73-xml-msg-receipt-handling/