Stream: implementers
Topic: mapping client codes to FHIR
Lital Inghel (Oct 14 2021 at 18:23):
we have under intent code in medication request a value of 'reported', which cannot be mapped to any FHIR value set code. this will end up in an error and resource will not be outputted. what is the expectation for this kind of problem? clients have many codes that are used for years and FHIR do not recognize all of them.
Vassil Peytchev (Oct 14 2021 at 18:27):
What is the meaning of having a value like reported in MerdicationRequest.intent?
Jean Duteau (Oct 14 2021 at 18:36):
that wouldn't map to the medicationRequest.intent but would map to MedicationRequest.reported boolean
Lital Inghel (Oct 14 2021 at 19:14):
actually it doesn't matter what it means, it is just one example out of many. client has codes that cannot be mapped to any FHIR code and this is an issue where there is a required field (1..) with a required value set. wasn't it raised before as an issue by EHRs?
Lloyd McKenzie (Oct 14 2021 at 19:19):
It does matter what it means. MedicationRequest.intent has a specific purpose - and you can only map things to it that represent actual "intents". 'reported' is not a level of 'intent'. It's orthogonal to intent. You could have reported plans, reported orders, reported proposals, etc.
Lloyd McKenzie (Oct 14 2021 at 19:21):
The required binding signifies that HL7 believes that all possible values for concepts that really correspond to MedicationRequest.intent can be mapped to one of the values in the value set. Obviously, it's possible we got that wrong for certain required value sets. (In fact, I know we have.), but feedback needs to first be based on an accurate mapping. We use required bindings where understanding the element is critical to understanding the resource or where we're convinced that international-scale mapping is both possible and worth the cost.
Daniel Venton (Oct 14 2021 at 19:41):
Just because somebody stored the value "reported" in a field in a database called "intent" doesn't mean that it has the same definition of the FHIR resource attribute named intent. Perhaps that value shouldn't have been stored in that column but was done so because it was easier than making a "reported" t/f column in the database. In which case you know to flip resource.reported = true, but now you are in a bind what is the actual intent? You'll have to research and know your definitions. Perhaps in your database the 'reported' value means "reported=true, intent=order" perhaps it's something else.
Perhaps if the use case is research you skip that instance. But for treatment, you bite the bullet and provide the data you know even though it doesn't meet conformance. Because due to history, you didn't keep two different attributes intent and reported like you should going forward. In every conformance test I've been through, it has always been can you be conformant going forward. Nobody has ever been expected to meet conformance with the entire historical record.
Last updated: Apr 12 2022 at 19:14 UTC
