I've had to think a lot about how interfaces are created and developed as I work on HL7 Version 2 to FHIR Conversion. The process of creating an interface that builds on the existence of one or more existing interfaces is a mapping process.
What you are mapping are concepts in one space (the source interface or interfaces) to concepts in a second space, the target interface. Each of these spaces is represents an information model. The concepts in these interface models are described in some syntax that has meaning in the respective model space. For example, one could use XPath syntax to represent concepts in an XML Model, FHIR Path in FHIR models, and for V2, something like HAPI V2's Terser location spec.
Declaratively, types in the source model map to one or more types in the destination model, and the way that they map depends in part on context. Sure, ST in V2 maps to String in FHIR, but so does ID in certain cases, except when it actual maps to Code.
So, if I've already narrowed my problem down to how to map from CWE to Coding, I really don't need to worry much about those cases where I'd want to map an ST to some sort of FHIR id type, because, well, it's just not part of my current scope or context.
Thinking about mapping this way makes it easier to make declarative mappings, which is extremely valuable. Declarations are the data that you need to get something done, rather than the process by which you actually do it, which means that you can have multiple implementation mechanism. Want to translate your mapping into FHIR Mapping Language? The declarations enable you to do that.
But first you have to have a model to operationalize the mappings. Here's the model I'm working with right now:
Prerequisites
- An object to transform (e.g., a message or document instance, or a portion thereof).
- A source model for that object that has a location syntax that can unique identify elements in the model, from any type in that model (in other words, some form of relative location syntax or path).
- A target model that you want to transform to.
- A location syntax for the target model.
- A set of mappings M (source -> target) which may for each mapping have dependencies (preconditions which must be true), and additional products of the mapping (other things that it can produce but which aren't the primary concepts of interest).
Dependencies
Dependencies let you do things like make a mapping conditional on some structure or substructure in the source model. For example, a problem I commonly encounter is that OBR is often missing relevant dates associated with a report (even though it should be present in an ORU_R01, the reality is that it often is not). My choices are to not map that message, or come up somehow with a value that is close enough to reality. So, when OBR-7 or OBR-8 is missing, my goto field is often MSH-7. So, how would I express this mapping?What I'd say in this case is that MSH-7 maps to DiagnosticReport.issued, when OBR-7 is missing and OBR-8 is missing. So, this mapping is dependent on values of OBR-7 and/or OBR-8.
Products
Products let you add information to the mapping that is either based on knowledge or configuration. HL7 V2 messages use a lot of tables, but the system URLs required by FHIR aren't contained anywhere at all in the message (even though they are going to be known beforehand). So, when I want to map OBR-24 (Diagnostic Service Section Identifier) to DiagnosticReport.category, I can supply the mapping by saying OBR-24 -> DiagnosticReport.category.coding.code and that it also produces DiagnosticReport.category.coding.system with a value of http://hl7.org/fhir/v2/0074.Mapping Process Model
So now that you understand those little details, how does mapping actually work? Well, you navigate through the source model by traversing the hierarchy in order. At each hierarchical level, you express your current location as a hierarchical path. Then you look at the path and see if you have any mapping rules that match it, starting first with the whole path, and then on to right subpaths.ALL matching rules are fired (unlike XSLT, which prioritizes matches via conflict resolution rules). I haven't found a case where I need to address conflict resolution yet, and if I do, I'd rather that the resolution be explicit (in fact, you can already do explicit resolution using dependencies).
If there's a match, then the right hand side of the rule says what concept should be produced. There can only be a match when the position in the source model matches the concept that you are mapping from, and there exists an equivalent target concept in the model that you are mapping to. In my particular example: Presuming that DiagnosticReport was already in context (possibly because I said to create it in the current context on seeing an ORU_R01 message type), then DiagnosticReport.category would be created.
At some point, you reach an atomic level with some very basic data types (string, date, and number) in both the source and target models. For this, there are some built-in rules that handle copying values.
Let's look at our OBR-24 example a bit deeper. OBR-24 is basically the ID type. So, moving down the hierarchy, you'll reach ID. In my own mappings, I have another mapping that says ID -> Coding.code.value. This rule would get triggered a lot, except that for it to be triggered, there needs to be Coding.code already in my mapping context. In this particular case, there is, because it was just created previously in the rule that handled OBR-24. But if there wasn't, this mapping rule wouldn't be triggered.
When I've finished travering OBR-24 and move on to OBR-25, I "pop" context, and now that coding is no longer relevant, and I can start dealing with DiagnosticReport.status.
The basic representation of the mappings are FHIR Concept maps (as I've mentioned in previous posts in this series).
Clarified bullet point one above thanks to Ed VanBaak.
No comments:
Post a Comment