One of the big takeaways for me from this January HL7 meeting is a much better realization how the organization sees clinical documents and messages, and how they relate to distributed services. What I did not realize was how the terms “message” and “document” have a very special meaning in HL7. Specifically, messages and documents in HL7 are expected to establish the context of the exchange, based on the data and metadata found in the message or document wrappers.
In the past, I have made the mistake of talking about simplified content for hData at the leaf resources (“Section Documents” in hData lingo), and reference to this content using terms like “document” or “document parts”. This prompted strong opposition from CDA supporters, who claimed that “document parts” would be inherently unsafe, since they might leave out critically necessary context information. As such, any document or message moderated health IT exchange cannot simplify its content model without performing a “no-harm” analysis.
This is not true for a service-based exchange: the service contract and deployment parameters are the overriding functions that establish the context for any given client-service interaction. A very good example for illustrating this is sending textual information to your political representative: To get information to Senator Alice, you can do this by sending a RFC 822 compliant string of characters (i.e. “To: senator.alice@example.com …”), but for Senator Bob you can use a web application that offers a textbox for sending your letter. The former approach is akin to a V3 message, the latter is more like RLUS/hData services.
It now gets interesting when you take the RFC 822 formatted message to Senator Alice and paste it into Senator Bob’s textbox, i.e. you use the service to transport the message. The message will – obviously – not be sent to Senator Alice, but instead end up on Senator Bob’s desk. While this simplified analogy leaves out some details, it shows how metadata for one exchange mechanism are not necessary for another. Any different assumption may lead to unexpected (and most often undesired) results.
As a result, service are -other than messages or documents- able to exchange partial clinical model graphs without needing to include wrappers provided by standards like HL7 V3 or CDA. With proper documentation in the service contract, the wirelevel serializations of these graphs can be made relatively simple, so that standard code development tools (including things like SimpleXML) do not get tripped by the complexity of the format.
I’ve really fallen behind now. The only part of this post I understand are Maxwell’s equations!
Good man. It’s the general solution to the Maxwell equations in exterior calculus. Much, much more elegant and simple that traditional nabla notation. My point is that complex models can be simplified my proper notation.