Mapping to ‘code’ datatype elements

So we’re providing a FHIR interface to our existing data repository. The repository is populated from v2 messages (among other sources).

One issue we’ve come across is when mapping to a code datatype with a fixed value set and you have a code that is not in the fixed set (Something I assume will be quite common). The ‘official’ way to manage this is to find the closest match from the fixed set and use that, and then create an extension to put the more specific code. The thinking is that anyone compliant with the specification will understand the fixed set value, and it shouldn’t matter if they don’t understand the more detailed one (you’d use modifierExtension if it did matter).

But what do you do when you can’t tell what the most appropriate mapping is? Suppose your system collects data from other sources and you don’t have control over what coding those sources use? (Now, I know you should, but this doesn’t always happen). And there are situations out there where only text is provided…

Take AllergyIntolerance.category for example.

In FHIR the list of options is food, medication, environment.

In v2 (AL1-2) there is Drug allergy, Food allergy, Miscellaneous allergy, Miscellaneous contraindication, Environmental Allergy, Animal Allergy, Plant Allergy, Pollen Allergy

So the food & drug allergy is fine – but what to do with ‘miscellaneous allergy’?

You could use ‘environment’ as the fallback I guess, but it would be really nice to have an ‘other’ option.

If the datatype were CodeableConcept, then life would be easier as we could use the text element to place the description.

The policy we’re proposing to follow when mapping to a fixed set code element is this:

• If at all possible to map from a fixed set, then do so.
• If it’s not possible to map then don’t include the element – though we’ll include the textual component in the resource narrative (or a comment field if that exists)
• If the field is required, and we can’t provide a mapping, then we’ll use a modifierExtension to put our value in.

If you can think of a better approach – feel free to comment!

So a plea to the resource designers. If you are creating an element with a fixed value set, please include an ‘other’ option, unless you really really want a specific set of values and no other (some of the ‘status’ elements may be appropriate).

And consider the use of codeableConcept rather than code if at all possible.