Stream: mapping-framework
Topic: Issue with conversion using validator_cli
Declan Kieran (Dec 17 2021 at 17:41):
I'm using tag 5.6.7, commit 2b4f3f3d1870624c00dcd9cd7f9a67206dbfec46
When using the validator_cli to covert from version 3.0 to version 4.0, i.e.
ValidatorCli ./source.json -version 3.0 -to-version 4.0 -output ./output.json
It is using the STU3 version (in my case) of MedicationRequest (the ResourceType I'm trying to convert).
At ValidatorCli.java:237
String definitions = VersionUtilities.packageForVersion(cliContext.getSv()) + "#" + VersionUtilities.getCurrentVersion(cliContext.getSv());
ValidationEngine validator = validationService.initializeValidator(cliContext, definitions, tt);
cliContext.getSv() returns 3.0, as per the cli argument `-version 3.0'. It uses this to initialise the ValidationEngine, and is grabbing the npm package hl7.fhir.r3.core#3.0.2 from the cache.
When it calls getTargetResourceFromStructureMap, it extracts the target URL from the map that is passed in, i.e.
if (component.getMode() == StructureMap.StructureMapModelMode.TARGET) {
targetTypeUrl = component.getUrl();
break;
}
The value of targetTypeUrl is "http://hl7.org/fhir/StructureDefinition/MedicationRequest", which when searching the STU3 npm package of course returns the STU3 MedicationRequest, it therefore doesn't recognise the encounter element in the target FML. Changing the value of targetTypeUrl at runtime to "http://hl7.org/fhir/StructureDefinition/MedicationRequest" resolves this. Function in question
private org.hl7.fhir.r5.elementmodel.Element getTargetResourceFromStructureMap(StructureMap map) {
String targetTypeUrl = null;
for (StructureMap.StructureMapStructureComponent component : map.getStructure()) {
if (component.getMode() == StructureMap.StructureMapModelMode.TARGET) {
targetTypeUrl = component.getUrl();
break;
}
}
if (targetTypeUrl == null) throw new FHIRException("Unable to determine resource URL for target type");
StructureDefinition structureDefinition = null;
for (StructureDefinition sd : this.context.getStructures()) {
if (sd.getUrl().equalsIgnoreCase(targetTypeUrl)) {
structureDefinition = sd;
break;
}
}
if (structureDefinition == null) throw new FHIRException("Unable to find StructureDefinition for target type ('" + targetTypeUrl + "')");
return Manager.build(getContext(), structureDefinition);
}
another fix for this is to change the URL of the target in ~/.fhir/packages/hl7.fhir.xver.r4#1.2.0/package/StructureMap-MedicationRequest3to4.json, so when the package is searched it finds the correct StructureDefinition.
i.e. change this
{
"url": "http://hl7.org/fhir/StructureDefinition/MedicationRequest",
"mode": "target",
"alias": "MedicationRequest"
}
to
{
"url": "http://hl7.org/fhir/4.0/StructureDefinition/MedicationRequest",
"mode": "target",
"alias": "MedicationRequest"
}
@Grahame Grieve I'm wondering what would be the best of course of action is to fix this. The options I'm thinking of are
-
Change the code to load in the r4 package to search, as opposed to searching the STU3 package
- Advantage - No need to change the StructureMap, and possibly cause side effects elsewhere...
- Disadvantage - Loading another package is a lot of overhead and maybe also is duplication?
-
Change the StructreMap
- Advantage / Disadvantage - reverse of previous
If the former, should I create a github issue for this? If the latter, is there a set of tests that could validate this didn't break a load of stuff, also where a issue/change request be made for that?
Declan Kieran (Dec 17 2021 at 18:22):
Minimal source snippet to repeat the issue
{
"resourceType": "MedicationRequest",
"context": {
"reference": "Encounter/f001",
"display": "encounter that leads to this prescription"
}
}
Declan Kieran (Feb 24 2022 at 12:26):
@Lloyd McKenzie @Grahame Grieve Just in case it's useful to anyone, I have created a repo that uses a modified xver package that will convert a load of STU3 examples in a pipeline and then test them against expected output (just previously ran successful transforms). I took the examples from the fhir-swagger project . I cleared out ones that wouldn't convert, like bundles and resources that had contained resources and was left with 794.
https://github.com/declankieran-nhsd/hapi-fhir-3to4-demo/
There is also a script to validate how accurate the transforms are based on examining the input and expected files referencing the source and target StructureDefintions. Details of the logic behind the script are on a readme here
https://github.com/declankieran-nhsd/hapi-fhir-3to4-demo/tree/main/scripts
It is only looking at keys, and only so far as defined with the StructureDefinitions. It doesn't look at data, and it doesn't reference any defined mappings. There is a report on the transform accuracy here
https://github.com/declankieran-nhsd/hapi-fhir-3to4-demo/tree/main/examples
It highlights
Keys that are invalid and shouldn't be in the input as per the source StructureDefintion
Keys that are definitely lost (Limitation here is invalid data causing a failure in the transform currently isn't implemented)
Keys possibly lost or renamed (This is due to not referencing a defined map, but that again could be implemented fairly easily I think)
The ones showing issues with the transform I think are mostly not issues, and I think these tests show the libraries and maps to be very robust.
There is also another repo that currently has some FML for specific extensions, again with some test automation. These include UK CareConnect extensions being converted to UKCore extensions.
https://github.com/NHSDigital/fhir-transforms/
Thanks again @Oliver Egger for the help with writing the FML for these.
Grahame Grieve (Feb 24 2022 at 12:29):
great stuff, thanks
Last updated: Apr 12 2022 at 19:14 UTC
