Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Thursday, August 22, 2013

Information Modeling vs. Implementation Representations

I was thinking last night about how HL7 modeling works going back to the RIM, and how the methodology provides a lot of knowledge relevant to the information model, but that knowledge hardly changes in the communications. Then I was contrasting that rather detailed methodology to some simpler approaches.  FHIR for example, provides one or more mappings from a resource to HL7 V2, V3 or other specifications. Then I looked at the VMR Logical Model.

Through all of this I was trying to determine how an XML Implementation Technology Specification might work that would allow the generation of simpler XML for HL7 Version 3 specifications, and potentially tie FHIR resources more formally back to V3 models.  I don't really have a huge need for all this formalism by the way, but my brain likes to play these tricks on me while I'm trying to go to sleep.

I thought about the rules to generate XML from the VMR UML. That was pretty easy. I realized the missing piece was not actually the translation to XML, but rather the linkage back to the RIM.  And then what popped into my head was the idea that UML logical models such as the VMR map back to information models such as the Clinical Statement through a variety of applied patterns or templates that could be described through a (possibly parameterized) stereotype.  The stereotype and parameter values provide the information modeling knowledge that allows for semantic translation back to the HL7 RIM.  The UML model provides the structure that is used for developing the XML or other representation of the content.

You can apply these stereotypes to classes, relationships and attributes of a UML model.  The parameterized stereotype for a class might well establish how one sets an information context from which attributes and relationships of that class in a logical model access information via the reference information model.  For example, I can now take the class representing the FHIR Condition Resource and associate it with the RIM Condition Class via a UML Stereotype.  I can attach to the severity attribute a UML stereotype representing an "Annotation", with parameters indicating that the type of annotation is "Severity" (from an appropriate coding system).  That stereotype can be associated with a RIM model fragment where the content of the severity attribute in the UML model represents the value attribute of an observation class associated with the base observation by the subject of relationship.

Essentially what this allows is the creation of simplified, nearly arbitrary UML logical models, related back to the RIM and so providing full semantic information in the standard.  And while the models can be nearly arbitrary, there are some natural patterns that would appear because they become the easy way to group or relate things together.  One can readily generate XML or other representations from these logical models, for example, as FHIR already does to generate XML or JSON.  And you have full RIM semantics stored in the model, but not necessarily needing to be conveyed in the message because it's knowledge captured in the model.

I touched on this idea that the domain knowledge in the model need not be transmitted in every message briefly back in 2009 in Synthesis, and also a little bit in in A Triangle has Three Sides.  [One of the nice things about having a blog is being able to see where you wrote about similar issues].  We've been struggling with this idea of simplification in HL7 for quite some time.  I think this idea might provide the bridge between current V3, FHIR and CDS artifacts.


  1. The beauty of UML for platform independent models.

  2. The problem with this is that stereotypes, property values, and annotations are limited in their ability to express complex conditional mappings. And these are at the heart of any meaningful simplification of the RIM to workable models that make sense to everyday implementers. Some of the FHIR mappings are going to be very complicated indeed.

    1. I'd love to understand what you mean by "complex conditional mapping".

    2. Look at some of the RIM mappings for DiagnosticReport. Even something as straight-forward as "status" gets pretty complicated.