Wednesday, September 06, 2006

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!


Addendum:
Steve Hart has posted on this subject as well at http://www.hartsteve.com/2006/09/11/hl73-xml-msg-receipt-handling/


Tags: , , , ,


5 Comments:

At 10:25 AM, Anonymous Glen said...

Hi Simon,

I saw this post a while ago and thought it was cool that someone was working on similar stuff as me. I'd love a follow up on your approach of generating the object model from the HL7 schemas ...

Please do make more posts along these lines and you can even make them more technical in nature. I believe there's an audience out there for it.

Regards

 
At 12:56 AM, Blogger Abhi said...

Hi Simon,

I also working on this topic. I need lot of research and good knowledge of HL7. I am just a beginner in HL7.

 
At 4:46 AM, Anonymous Anonymous said...

Hi Simon,

The blog is quite interesting. Really helpful to people like me who is working on the same v3.0 related stuff. But when we look at the HL7 v3.0 Normative Edition XSD set, many of them are incomplete or invalid when you validate them. I am just wondering how these xsds can be fixed. I appreciate your help if you can provide me some tip.

 
At 7:38 AM, Blogger Bugs! said...

Hi Simon,
I am working on the same Hl7 v3.0 message handling. I plan to have all the classes in place using xsd.exe from Visual Studio .NET, and then just use the xsd's from the Normative edition to validate the message xml and then deseriliaze it to the respective class depending upon the Message Type.

Can this be a good solution?

-Regards,
Vaibhav Gaikwad

 
At 10:34 AM, Blogger Ren´┐Ż said...

The blogpost is 4 years old when I write this, but for those that read the post it may be relevant: see the HL7 Wiki for information on schema based code generation: http://wiki.hl7.org/index.php?title=Schema_based_code_generation and http://wiki.hl7.org/index.php?title=MIF_based_code_generation

The RIMBAA Working group within the HL7 organization focuses on the implementation of HL7 version3 using techniques such as code generation.

 

Post a Comment

<< Home