descriptionId examples are missing

[artronics]

We have a ticket on our board to transform descriptionId however, there is no dedicated example(s) to cover this scenario. This extension only appears once in the StatusReason extension here.

Current behaviour

Currently, we only apply this transformation when descriptionId appears inside statusReason. It looks like however, descriptionId can apear else where.

Questions

1. I searched for this extension on simplifier and by looking at one of the definitions I can't tell where exactly we should expect this extension. The only useful information is the context field which, provides information about what resource may contain this extension.
2. Is it possible that this extension appears inside a field. For example Patient.given.extension.descriptionId

[declankieran-nhsd]

@artronics For question 1.

Looking at the StructureDefinitions for all three Resources (MedicationRequest, MedicationStatement and AllergyIntolerance) that are part of the PoC, I can see that the extension Extension-coding-sctdescid (the extension containing the descriptionId element) is defined in the following places

MedicationStatement.dosage.route.coding MedicationRequest.dosageInstruction.additionalInstruction.coding MedicationRequest.dosageInstruction.route.coding AllergyIntolerance.code.coding AllergyIntolerance.reaction.substance.coding AllergyIntolerance.reaction.manifestation.coding AllergyIntolerance.reaction.exposureRoute.coding

Based on the StructureDefinitions for the following profiles

https://simplifier.net/hl7fhircareconnectbaselineforstu3/careconnect-medicationrequest-1 https://simplifier.net/hl7fhircareconnectbaselineforstu3/careconnect-medicationstatement-1 https://simplifier.net/hl7fhircareconnectbaselineforstu3/careconnect-allergyintolerance-1

I mentioned before about maybe contrieving (manually creating) data for these, but there were questions around whether they are even being used, as a lot of the extensions (or parts of) are not being used, and UK Core has in turn deprecated these. I'll come back later with rationale from clinical and technical assurance, but I'm still reading through that.

Interestingly, the only example of the extension Extension-coding-sctdescid (the extension containing the descriptionId element) we found in the live test data was for the extension Extension-CareConnect-GPC-MedicationStatusReason-1, which actually doesn't explcitly defined the use of the Extension-coding-sctdescid within the statusReason CodeableConcept. Note, the examples are from GPConnect but they were based off the CareConnect profiles

See here for details

https://simplifier.net/gpconnect2/extension-careconnect-gpc-medicationstatusreason-1 https://simplifier.net/hl7fhircareconnectbaselineforstu3/extension-careconnect-medicationstatusreason-1

That GPConnect example is the only one currently provided within the repo here.

So my questions are

a. Do we need the above defined, i.e. should we manually create examples b. Are there any other unknowns like statusReason out there, which is probably only answered by c. Can we get a reasonably exhaustive set of test or sanitised live data that would provide a high degree of confidence that all possibilities have been accounted for.

@digitalhealthmartin @PeteSalis @RNatarajanNHS any thoughts?

For question 2.

I had a quick look at patient.given and I can't see it defined anywhere for CareConnect, as to whether it might appear in an implementation, that really goes back to getting implementation details / test data etc...

[RNatarajanNHS]

@declankieran-nhsd , I think the binding of descriptionId within the Snomed CT coding setup is well documented in STU3 so we need to reflect the same in UK Core R4. I think Dave.B has an action to do this as part of the mapping work we did for Allergy Intolerance.

[declankieran-nhsd]

@RNatarajanNHS Yes, good point, in UKCore for AllergyIntolerance, these are using bindings to ValueSets, so for the following in CareConnect

AllergyIntolerance.code.coding.snomedct.extension.snomedCTDescriptionID AllergyIntolerance.reaction.substance.coding.extension.snomedCTDescriptionID AllergyIntolerance.reaction.manifestation.coding.extension.snomedCTDescriptionID AllergyIntolerance.reaction.exposureRoute.coding.extension.snomedCTDescriptionID

The codings (i.e. FHIR element) are standard but bound to the following (included the canonical and simplifier links)

AllergyIntolerance.code (binding -> https://fhir.hl7.org.uk/StructureDefinition/UKCore-AllergyIntolerance, https://simplifier.net/hl7fhirukcorer4/ukcore-allergycode) AllergyIntolerance.reaction.substance (binding -> https://fhir.hl7.org.uk/ValueSet/UKCore-AllergySubstance, https://simplifier.net/hl7fhirukcorer4/ukcore-allergysubstance) AllergyIntolerance.reaction.manifestation (binding -> https://fhir.hl7.org.uk/ValueSet/UKCore-AllergyManifestation, https://simplifier.net/hl7fhirukcorer4/ukcore-allergymanifestation) AllergyIntolerance.reaction.exposureRoute (binding -> https://fhir.hl7.org.uk/ValueSet/UKCore-SubstanceOrProductAdministrationRoute, https://simplifier.net/hl7fhirukcorer4/ukcore-substanceorproductadministrationroute)

Does this mean that APIM does not need a mapping for these, and it will be more a case of validating that any code is in the bound valueset on conversion? i.e. there are no custom Structural differences to the base R4 when moving from CareConnect to UKCore.

cc: @artronics

[declankieran-nhsd]

Examples added for AllergyIntolerance.code in https://github.com/NHSDigital/fhir-transforms/pull/42