#FHIR and mapping approaches

Dec 10, 2015

Across the board, many FHIR implementers have the same challenge: mapping between some other format, and a set of FHIR resources. The other format might be a CIMI model, an openEHR model, a CCDA document, or a series of other things. At the HL7 Orlando meeting in the second week of January 2016, we’ll be holding a BOF (Birds of a Feather) on Tuesday evening. In this meeting, we’ll be: * seeing some mapping tool demos

  • considering how to flesh out an interoperable format for mappings, and create an eco-system around that
  • gathering a set of requirements to drive the format./eco-system
  • identifying significant applications where exchanging mappings will be useful (e.g. CCDA…)

One problem when it comes to mappings is that there’s a wide variety of things that are called ‘mappings’. I find it useful to classify mappings into 4 categories:

  • Skeletal. There is just enough information to indicate to readers where the different models align structurally. Anything else is left to the reader’s imagination
  • Notional. The mappings are done at the class and attribute level (or equivalent), and indicate that the definitions of the elements establish that these are about the same thing. However the types of the attributes might not match up, and there might be all sorts of special conditions and assumptions that need to be true for the mappings to be valid
  • Conceptual. The mappings are done at the class and attribute level, down to the level of primitive data types. However not all the value domains of all attributes are fully mapped, and there may be special cases not accounted for
  • Executional. The mappings account for the full value domain of all the source attributes, and all the special cases are handled. The mapping notation is precise enough that all the construction issues such as when to create new instances of repeating elements is fully described. These mappings can be fed into conversion engines that are then capable of transforming instances correctly from one format to another

The mapping notations become more complex as you move through this classification; and it becomes less easy to read their intent. In fact, the full executable mapping cases is proper 3GL code, and it’s not unusual for implementers to maintain both executional mappings in code, and notional (usually) mappings as documentation of the code. But fully executional mappings are the most useful for real world use

FHIR’s existing mappings (on the mappings tab throughout the specification) are mostly Notional or Conceptual, though there’s a smattering of skeletal and executional ones as well. We’re going to ramp that up in the FHIR specification itself, and in a raft of implementation guides of various forms. As we work through our use cases, I suspect we’ll find a need for a mix of these levels of mappings, and we need to keep this classification in mind - unless someone comes up with (or knows) a better one.