Stream: implementers
Topic: FHIR Mapping Language Question
Gino Canessa (Mar 01 2022 at 21:58):
Hi all, I received a question on FHIR Mapping Language + Validation and was hoping for confirmation. Starting from the (unfortunately named =) Transforms between DSTU 3 and STU 4, I am looking at (for example) Observation.
When mapping into extensions (e.g., v3.related where type=interfered-by), the extension extension URL is: http://hl7.org/fhir/3.0/StructureDefinition/Observation.interferedBy, which is different from the cross-version extension URL: http://hl7.org/fhir/3.0/StructureDefinition/extension-Observation.related.
The extensions used in the mapping language are not actually defined, which unfortunately means they fail validation. Is the intention just that they are used in the context of transformations and should ignore the validation warnings, or are the mapping files out of date and the 'correct' way is to use the cross-version extensions? Thanks!
Lloyd McKenzie (Mar 01 2022 at 23:06):
I think the mappings are out of date.
John Silva (Mar 01 2022 at 23:47):
I've found another example of where the DSTU2 to STU3 FHIR mappings are out of sync with 'reality'; I forget the specific example but when I posted about it I was told that it's not likely that the mapping would be updated.
Lloyd McKenzie (Mar 02 2022 at 04:09):
In principle, they could be fixed in R4B, but we'd need a FHIR mapping language volunteer to do it who isn't Grahame - and we'd need the work done in the next week or so.
Gino Canessa (Mar 02 2022 at 04:20):
Thanks for the info! I doubt that timeframe is realistic to spin up on the work that needs to be done though. I will check to see if anything can be done post-R4B release though.
René Spronk (Mar 02 2022 at 07:26):
AFAIK the only mappings that are well maintained are the ones for the conformance resources. For any other resource types there's no guarantee that they exist, nor that they're up to date. Obviously it would be nice if they were to exist, but then we'd need a (new) volunteer to maintain them.
Josh Mandel (Mar 02 2022 at 15:13):
Mappings also exist in 2 repos:
- https://github.com/HL7/fhir/blob/master/implementations/r3maps/R3toR4/
- https://github.com/FHIR/interversion/tree/master/r4/R3toR4
Is one of these "official," and how do we intend to keep these in sync?
Gino Canessa (Mar 02 2022 at 15:45):
Hmm.. I wonder if this is something that could be moved into core editing somehow. E.g., if you modify a resource, you also modify some map information to keep it up to date. Probably not worth cycles thinking about right now though.
John Silva (Mar 02 2022 at 19:32):
I found one of the tickets, FHIR-35797, I submitted for ClinicalImpression.finding.cause mapping is missing in DSTU2 to STU3 version map. The fix, assuming it's one line of missing FML, should be easy.
I think this line is just a typo:
"ClinicalImpression.finding-reason" : for src.reason make tgt.basis
should be:
"ClinicalImpression.finding-cause" : for src.reason make tgt.basis
There is no ClinicalImpression.finding[].reason property in STU3.
Lloyd McKenzie (Mar 03 2022 at 03:30):
@Gino Canessa the set of people who know how to use the mapping language is significantly smaller than the set of people who know how to maintain resources. (And that set isn't huge.)
Gino Canessa (Mar 03 2022 at 04:39):
Yep, idle theorizing. Mostly pinning in the back of my head to think about.
Declan Kieran (Mar 03 2022 at 10:15):
@Gino Canessa @Lloyd McKenzie
In testing 3to4 transforms using the validator_cli, I wrote a script to do a level of validation on the transforms. What it does is described here
https://github.com/declankieran-nhsd/hapi-fhir-3to4-demo/tree/main/scripts
The script is
https://github.com/declankieran-nhsd/hapi-fhir-3to4-demo/blob/main/scripts/generate_comparison.py
basically, it uses the source and target StructureDefinitions to work out if the transform is correct based on what is contained in the input and what ends up in the transform. I had in the back of my head when I was writing it, the notion that it might a good test harness for updating the maps. They're actually quite complete from what it 's show so far though.
It will identify
- Definitely lost data
- Data that is invalid (i.e. shouldn't be in the input)
- Data that might be lost or renamed either in the source or target (because a mapping isn't referenced).
in a generated report
https://github.com/declankieran-nhsd/hapi-fhir-3to4-demo/tree/main/examples
It currently has the limitation of not looking at data, it just looks at the keys and only so far as is defined in the StructureDefinition snapshot elements, and its only for STU3 to R4. More details on limitations here
It might be useful for what you're talking about as it should indicate potential issues with transforms assuming you have a good set of input data to test. I still need to write some unit tests for code, but I'm pretty sure where a transform has no issues, then it can be considered correct (well in terms of keys, to the level as defined...). I think it should be straightforward as well to extend it to look at the data, and even reference maps, but I haven't got round to that yet...
One other thing, is I needed to make a modification to the xver package as there is an issue with the code finding the STU3 definitions if the target is not a versioned URL in the StructureMaps.
There is a github pipeline that shows how it is ran on a linux machine
As for using this to get all maps fully correct by next week, even just for 3 to 4, I think that might be ambitious!
Vadim Peretokin (Mar 04 2022 at 09:51):
Gino Canessa said:
Hi all, I received a question on FHIR Mapping Language + Validation and was hoping for confirmation. Starting from the (unfortunately named =) Transforms between DSTU 3 and STU 4, I am looking at (for example) Observation.
When mapping into extensions (e.g.,
v3.related where type=interfered-by), the extension extension URL is:http://hl7.org/fhir/3.0/StructureDefinition/Observation.interferedBy, which is different from the cross-version extension URL:http://hl7.org/fhir/3.0/StructureDefinition/extension-Observation.related.The extensions used in the mapping language are not actually defined, which unfortunately means they fail validation. Is the intention just that they are used in the context of transformations and should ignore the validation warnings, or are the mapping files out of date and the 'correct' way is to use the cross-version extensions? Thanks!
I think it was just a mistake that they're not aligned. The format for the extensions and the first use of extensions was both in 2018 a few months apart.
It looks like a relatively simple change - if that's all there is to it, does not seem like a problem to fix. I'll look into it this weekend. No promises it'll fix all your validation issues, I haven't looked at the mappings in a while so we might discover other gremlins.
Which branch is tracking the R4B release on github? Is it master?
Lloyd McKenzie (Mar 04 2022 at 14:49):
R4B
Gino Canessa (Mar 04 2022 at 15:40):
Thanks Vadim!
Vadim Peretokin (Mar 08 2022 at 06:55):
https://github.com/HL7/fhir/pull/1758, have a look to see if that solves the problem!
Josh Mandel (Mar 08 2022 at 19:05):
Awesome! I added a quick correction here. Once merged is there a process for propagating these changes to keep these two in sync:
- https://github.com/HL7/fhir/blob/master/implementations/r3maps/R3toR4/
- https://github.com/FHIR/interversion/tree/master/r4/R3toR4
Last updated: Apr 12 2022 at 19:14 UTC
