Closed artronics closed 2 years ago
@artronics please review the snomded description Id extension example for r4 . It has been wrongly rendered in your snippet. https://simplifier.net/hl7fhirukcorer4/extensionukcorecodingsctdescid.
I think the R4 UK Core example should be "extension": [ { "url": "https://fhir.hl7.org.uk/StructureDefinition/Extension-UKCore-CodingSCTDescId", "extension": [ { "url": "descriptionId", "valueIdentifier": { "system": "http://snomed.info/sct", "value": "372285017" } } ] } ]
@declankieran-nhsd can you confirm my view?
@RNatarajanNHS We have other examples mapping to this url. See for example this: https://github.com/NHSDigital/fhir-transforms/blob/develop/resources/careconnect-to-ukcore/medicationrequest/expected/MedicationRequestStatusReason-Extension-3to4_000.json#L24 Please let me know if this is wrong and we'll fix this and other examples.
@artronics I think they are wrong particularly w.r.t to descriptionId , it's a complex extension with value[x]. It contains valueIdentifier an array that can be used to populate system and value elements. In this case we harcode the system to SnomedCT URL and capture the descriptionId in the value element.
@declankieran-nhsd can you check the examples?
"valueIdentifier": { "system": "http://snomed.info/sct", "value": "372285017" }
@RNatarajanNHS @artronics
Yes this is a tricky one as the extension is not defined to be used in AllergyIntolerance.code in UKCore. It uses this value set
https://simplifier.net/hl7fhirukcorer4/ukcore-allergycode
Strangely I can't find any code that indicates an allergy to penicillin in this value set. If the snomed code 91936005 was in the value set, and could then be referenced / validated to be part of that valueset, I don't see the need for the description ID as this is linked to the SCTID
I think this probably needs a more in depth discussion on what needs done here. Although if this was to be maintained as is, this goes back to the question of maintaining data, in which case we may want to maintain the original version (uri) as well in an extension to hold it, to indicate that it is orphaned data...
Also, the pipeline will fail if you haven't written an FML map to do the conversion.
Profiles for CareConnect and UKCore AllergyIntolerance
https://simplifier.net/hl7fhircareconnectbaselineforstu3/careconnect-allergyintolerance-1 https://simplifier.net/hl7fhirukcorer4/ukcoreallergyintolerance
@RNatarajanNHS @artronics
The binding strength is extensible on AllergyIntolerance.code
definition:
To be conformant, the concept in this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated. If the value set does not cover the concept (based on human review), alternate codings (or, data type allowing, text) may be included instead.
So the code doesn't need to be in the valueset.
A solution to this is that the SCTID could just be moved to UKCore as a standard coding entry. The descriptionId could be mapped to this extension, which is a standard base extension
http://build.fhir.org/extension-coding-sctdescid.html
and only contains the descriptionId
This avoids any loss of data and no custom extensions
@RNatarajanNHS @artronics I've asked the IOPS team to take a look
@declankieran-nhsd , I remeber raising this in the mapping calls and Dave.B said we need to have IG for the SnomedCT descriptionId extension in UK Core R4 as where an how it can be used. Not sure what is happening to the same.
One issue with the solution I've suggested is nowhere for the descriptionDisplay to go, which is defined here by GPConnect
as
The text of the description id. Only populated if a descriptionId exists and there is no need to populate this field if the text is lexically identical to the text in coding.display
If this is an issue, then the standard extension http://build.fhir.org/extension-coding-sctdescid.html could still be used, but an extension would be needed for the descriptionDisplay, in which case the transformed JSON would be something like
"code": {
"coding": [
{
"extension": [
{
"url": "http://hl7.org/fhir/StructureDefinition/coding-sctdescid",
"valueId": "152307010"
},
{
"url": "https://fhir.nhs.uk/StructureDefinition/Extension-CodingSCTDescDisplay",
"valueString": "Allergy to penicillin (finding)"
}
],
"system": "http://snomed.info/sct",
"code": "91936005",
"display": "Allergy to penicillin"
}
],
"text": "Penicillin allergy"
}
(the extension https://fhir.hl7.org.uk/StructureDefinition/Extension-UKCore-CodingSCTDescriptionDisplay doesn't exist though)
Or the UKCore extension (https://simplifier.net/hl7fhirukcorer4/extensionukcorecodingsctdescid) can be used as Jalal has done in this branch, with correction from @urchy, so below with descriptionDisplay it would look like this
"code": {
"coding": [
{
"extension": [
{
"url": "https://fhir.hl7.org.uk/StructureDefinition/Extension-UKCore-CodingSCTDescId",
"extension": [
{
"url": "descriptionId",
"valueIdentifier": {
"system": "http://snomed.info/sct",
"value": "148720012"
}
},
{
"url": "descriptionDisplay",
"valueString": "Allergy to penicillin (finding)"
}
]
}
],
"system": "http://snomed.info/sct",
"code": "91936005",
"display": "Allergy to penicillin"
}
],
"text": "Penicillin allergy"
}
If descriptionDisplay is required, and I think its considered a clinical risk not to have it if the text differs in any way to the display on the SCTID, then I think it should really be specified in the profile (https://simplifier.net/hl7fhirukcorer4/ukcoreallergyintolerance) as there is a custom extension being used. Kevin S has put this as a priority to look at in DA and is on the agenda for next Tuesday.
Edited to reflect correction from @urchy, Edit: fix to extension array Edit: updated to reflect advice given here https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Extension.20coding-sctdescid/near/276639201
I can see a reason the need for descriptionDisplay which would capture the clinician selected term if its not the SnomedCT preferred term. We need to be sure to cater for wider range of consumers application who may lack the capacity to validate the terms using a CTS endpoint.
So my understanding is that if descriptionDisplay
exists we just move it across (like in statusReason
see this) but if descriptionDisplay
doesn't exists we need to create one extension as in @declankieran-nhsd example? If this is the case then, where the value is coming from? I can see the value is quite similar to the display
field but it's not identical i.e. that "(finding)" at the end.
Please let me know if this assumption is true and then I'll update this PR with following examples:
descriptionDisplay
extension. discriptionDisplay
will be moved across as it is. @artronics This is to be discussed with the IOPS team at the DA tomorrow afternoon. I think we need to wait on what comes out of that, then we can change the examples as needed. Regardless, the maps will need updated as the mapping isn't correct even if the UKCore extension (https://fhir.hl7.org.uk/StructureDefinition/Extension-UKCore-CodingSCTDescriptionDisplay) was to be used.
The Extension-UKCore-CodingSCTDescriptionDisplay extension has been raised as an issue in the HL7 ballot for UKCore. This is to be discussed in with a time line of a few months before decisions will be made. Comments can be found here
https://www.hl7.org.uk/2022/01/18/2279/
This extension may changed as mentioned previously, but for now, the extension Extension-UKCore-CodingSCTDescriptionDisplay should be consider to be the correct form to transform to.
An FML map has been added here and the examples update to reflect this. @artronics @urchy @RNatarajanNHS could you please review these changes.
Identified two possible uri values for input, see https://github.com/NHSDigital/fhir-transforms/issues/43
Updated map to handle both URI's
@declankieran-nhsd Based on mapping and pr changes I'm assuming we only transform descriptionDisplay
only if it exists. I'm saying this, because my understanding was that we need to create discriptionDisplay
even if the original one doesn't have it.
@artronics Yes, descriptionDisplay is optional, i.e. cardinality of 0..1, so you should only transform if it exists
I examined the examples that Peter sent. There are only two places that descriptionId can appear. One of them is inside MedicationRequest->statusReason(Extension) which we have already covered. The second place is the one that this PR is introducing. This extension appears inside
AllergyIntolerance.coding
.Note we noticed STU3 extensions can have two different urls. For example:
Question Is this the case with this extension as well? and if yes then, what would be the second url. The examples that Peter sent doesn't have it.