Do not model your interfaces on HL7's structure
HL7 has a very non-orthogonal design. If you are unclear what I mean by orthogonal please read my article A,B,C’s, Kanji and Orthogonality which explains the concept with an everyday example. The way information is lumped together into ADT events is very arbitrary. It’s a reflection of the history of the protocol and what it replaced, namely a bunch of proprietary ad-hoc batch export data mechanisms. See my article on how the cultural legacy of level 7 impacts HL7 in a negative way. Really in an ideal world interfacing would be a lot simpler and more modular. There would be restful APIs that one could use to query for discrete small amounts of data like:
- Patient demographics
- Events pertaining to patients like registration, transfers, admits.
- Insurance provider information for a given patient.
- Drug orders for a patient.
etc. Blobbing all this data together in a big messages in ambiguous ways to arbitrary broadcast events like ADT^A01 Admit, ADT^A04 register etc., doesn’t make a lot of sense in todays world. It’s an historical legacy. Unfortunately it is the reality of the current landscape and will be for many years to come since the oldest most grungy systems are those which are updated the least often. Processing HL7 almost always means maintaining your own database which is effectively mirroring some subset of the information being sent to you by the other vendor system. However just because the HL7 protocol is structured this way doesn’t mean that your application has to inherit all the headaches for it’s own internal APIs. Whether you are using staging tables or if you have web service style APIs into your application you’ll be much more efficient at interfacing if you take the time to decompose your targets into discrete logical pieces rather than modelling your interfaces on the HL7 spec itself. It’s a very common mistake that I see with a lot of customers where they base their internal interfaces on HL7, that’s just increasing their costs per interface.