NHSDigital / fhir-transforms

Maps and example resources for use in FHIR version transformation
4 stars 1 forks source link

Add descriptionId examples #42

Closed artronics closed 2 years ago

artronics commented 2 years ago

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:

https://fhir.nhs.uk/STU3/StructureDefinition/Extension-CareConnect-GPC-MedicationRepeatInformation-1

https://fhir.nhs.uk/STU3/StructureDefinition/Extension-CareConnect-MedicationRepeatInformation-1

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.

RNatarajanNHS commented 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?
artronics commented 2 years ago

@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.

RNatarajanNHS commented 2 years ago

@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" }

declankieran-nhsd commented 2 years ago

@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

https://termbrowser.nhs.uk/?perspective=full&conceptId1=91936005&edition=uk-edition&release=v20220216&server=https://termbrowser.nhs.uk/sct-browser-api/snomed&langRefset=999001261000000100,999000691000001104

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.

declankieran-nhsd commented 2 years ago

Profiles for CareConnect and UKCore AllergyIntolerance

https://simplifier.net/hl7fhircareconnectbaselineforstu3/careconnect-allergyintolerance-1 https://simplifier.net/hl7fhirukcorer4/ukcoreallergyintolerance

declankieran-nhsd commented 2 years ago

@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

declankieran-nhsd commented 2 years ago

@RNatarajanNHS @artronics I've asked the IOPS team to take a look

RNatarajanNHS commented 2 years ago

@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.

declankieran-nhsd commented 2 years ago

One issue with the solution I've suggested is nowhere for the descriptionDisplay to go, which is defined here by GPConnect

https://developer.nhs.uk/apis/gpconnect-1-2-6/pages/accessrecord_structured/GuidanceOnCodeableConcept.pdf

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

RNatarajanNHS commented 2 years ago

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.

artronics commented 2 years ago

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:

  1. Current example with the exception that expected will contain a descriptionDisplay extension.
  2. A new input/expected case, showing a coding with existing discriptionDisplay will be moved across as it is.
declankieran-nhsd commented 2 years ago

@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.

declankieran-nhsd commented 2 years ago

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.

declankieran-nhsd commented 2 years ago

Identified two possible uri values for input, see https://github.com/NHSDigital/fhir-transforms/issues/43

declankieran-nhsd commented 2 years ago

Updated map to handle both URI's

artronics commented 2 years ago

@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.

declankieran-nhsd commented 2 years ago

@artronics Yes, descriptionDisplay is optional, i.e. cardinality of 0..1, so you should only transform if it exists