Saturday, 30 June 2007

HL7 Standards and Message Mapping

For most of the last year I've been working on healthcare integration projects, involved in HL7 and related technologies. One of the biggest frustrations I've encountered is the HL7 standard itself, access to it (and related information) and the way the standard is published.

The HL7 (v2) standard was published as a body of Word documents, apparently without any machine-readable version. You might have expected that the standard would have originated as a database plus supporting commentary but it seems that the Word documents have always been the definitive standard.  You could of course write software to crawl over the documents and extract the standard but it looks to me as if this would be pretty painful; I haven't checked every document, but I'm not sure they are all consistently formatted.

Almost from the start I decide to write tools to help me with message profiles, mappings and transformations, but to do that effectively you really need to have the standard in a machine-readable form.

I did come across a German site which offered an Access DB version of the standard but this has now become an product (I believe it was originally unaffiliated but legal pressure was brought to bear...)

The fact that is a quasi-commercial entity irritates me: I don't mind special-interest bodies charging for 'value-added' things like books, papers and conferences, but making the standard itself proprietary and to restrict access to it just feels wrong.  Standards like this should be open to all.

What prompted this post was discovering this effort to capture HL7 segments, fields and tables in an Excel spreadsheet. Pity that the link to the file doesn't seem to work: Matthew, if you read this, please check the link in your post.

Thank goodness v3 is XML based. Presumably the specification will be driven from XSDs.  Reading the HL7 'statement of principles' (SOP) for v3 they appear to regard the v2 principle of starting from documents and deriving the technical artifacts as 'more direct', as 'one simply edits ... the appropriate word processing document'! Direct, certainly, but desirable?  The SOP indicates that a tool-chain will be used to derive documentation from 'computerized models' which sounds better. 

I was able to get access to the latest v3 standard draft, and part of this site contains the XSD but they're all linked separately, and as HTML! Why on Earth not provide a zip download of the whole thing?

No comments:

Post a Comment