Page tree

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

The following is a straw-man proposal to aid discussion with the group. This is a limited, happy-path scenario, including expression creation and querying. Many other operations could be performed using expressions.

Use Case

  • An orthopaedic clinician wants to record the procedure "Closed reduction of fracture of left radius"
    • We assume the EHR system supports searching precoordinated codes and, if necessary, creating postcoordinated codes
    • However, this EHR can only store codes up to 18 digits in length
    • The clinician selects the 87971000 |Closed reduction of fracture of radius (procedure)| with 272741003 |Laterality (attribute)| = 7771000 |Left (qualifier value)|

  • Then the orthopaedic department wants to report on the number of closed reduction vs. open reduction procedures.

Solution Overview

  • A CodeSystem supplement will be used to act as an expression library
  • A ConceptMap will be used to translate expressions to (and from) shorter codes for systems with restricted code lengths

Prerequisites

  • Create the CodeSystem supplement. This supplements a specific module and version of SNOMED CT
  • 1234005 is the identifier of the module that contains the postcoordination content

PUT /CodeSystem/1234005

{
    "resourceType": "CodeSystem",
    "url": "http://snomed.info/sct",
"version": "http://snomed.info/xsct/1234005", /* The supplement includes the unpublished content in this module */ "content": "supplement", "supplements": "http://snomed.info/sct|http://snomed.info/sct/900000000000207008/version/202020131 }

The PUT operation can be used to create a resource with a specific id. Using POST would generate an id.

  • Create ValueSet for expressions (can't use CodeSystem.valueSet because not a real code system)
  • Create CodeSystem for generated identifiers - specify CodeSystem.valueSet 
  • Create the ConceptMap to automatically translate expressions to generated short identifiers (only needed if EHR cannot store expressions) 
    • A SNOMED Namespace is required for identifier generation
      • The Implementation Support Team has ideas about how to simplify the process of namespace assignment for postcoordination

PUT /ConceptMap/example-pce-id

{
    "resourceType": "ConceptMap",
    "url": "http://example.org/snomed-pce-id-map",
    "source": {
       "sourceUri": "http://example.org/snomed-pce-library?fhir_vs"
},
"target": {
       "targetUri": "http://snomed.info/xsct/101101234112/pce-id-gen/1101234?fhir_vs"
} }

The target specifies that the target of the map will be generated SNOMED PCE identifiers. The targetUri includes the SNOMED Namespace to be used.

Feedback from group

  • ML
    • I would generate UUIDs for expressions rather than using SCTIDs
    • Type 5? UUID could take expression as the seed to create deterministic ids
  • KK - Maybe expression id generation should be implementation specific

Creating the Expression

The EHR system attempts to update the CodeSystem supplement with the expression, using either classifiable-form or close-to-user form depending on what is supported by the terminology server.
Example expression in close-to-user form: 87971000 |Closed reduction of fracture of radius (procedure)| : 272741003 |Laterality (attribute)| = 7771000 |Left (qualifier value)|

PATCH /CodeSystem/123005

{
   "concept": [{
      "code": "87971000:272741003=7771000"
  }]
}

The PATCH operation is used to update the existing CodeSystem supplement resource, adding an expression that combines existing codes.

Feedback:

  • ML
    • If short identifier could be generated within the EHR (Type 5 UUID) then this could be included as an alternate identifier when inserting the expression in the supplement.
    • Could then insert the short identifier into the ConceptMap as the target

The terminology server must perform MRCM domain-attribute and attribute-range validation. If close-to-user form is supported, then the expression should be transformed to classifiable form before MRCM validation. The terminology server may also classify the expression at this point to reduce the processing required during subsequent operations that use the hierarchy.


  • Create a map record from expression to generated code (only needed if EHR cannot store expressions)

PATCH /ConceptMap/1234005

{
   "group": [{
      "source": "http://snomed.info/sct",
"sourceVersion": "http://snomed.info/xsct/1234005",
      "target": "http://snomed.info/pce-id-gen/1101234",
"element": [
"code": "87971000:272741003=7771000"
]
   }]
}
.... if the id was autogenerated when the expression was created
{
   "group": [{
      "source": "http://snomed.info/sct",
"sourceVersion": "http://snomed.info/xsct/1234005",
      "target": "http://snomed.info/sct",
"targetVersion":"http://snomed.info/xsct/1234005/ids",
"element": [
"code": "87971000:272741003=7771000"
]
   }]
}
  • Lookup the generated code for storage in the EHR using translate (only needed if EHR cannot store expressions)

GET /ConceptMap/example-pce-id/$translate?target=http://snomed.info/pce-id-gen/1101234&code=87971000:272741003=7771000

{
    "resourceType": "Parameters",
    "parameter": [
        {
            "name": "result",
            "valueBoolean": true
        },
        {
            "name": "match",
            "part": [
                {
                    "name": "equivalence",
                    "valueCode": "equivalent"
                },
                {
                    "name": "concept",
                    "valueCoding": {
                        "system": "http://snomed.info/pce-id-gen/1101234",
                        "code": "1001101234160"
                    }
                },
                {
                    "name": "source",
                    "valueString": "http://example.org/snomed-pce-id-map"
                }
            ]
        }
    ]
}

The generated identifier "1001101234160" should be used as a whole. (It contains item identifier "100", namespace "1101234", partition identifier "16", and check digit "0".)

The generated identifier, from CodeSystem "http://snomed.info/pce-id-gen/1101234", can be stored in the EHR record. The code system is derivable from the code, within the bounds of SNOMED CT codes, because of the 16 partition identifier and the fact that the code contains the namespace.

Querying

The department would like to report on the number of closed reduction procedures performed. All codes representing this type of procedure must be fetched so that they can be matched against the EHR records.

  • Expand an intentional ValueSet using the expression library and ECL "< 86052008 |Closed reduction of fracture (procedure)|"
  1. GET /ValueSet/$expand?url=http://snomed.info/xsct/1234005?fhir_vs=ecl/<86052008
  2. GET /ValueSet/$expand?url=http://snomed.info/sct/900000000000207008#http://snomed.info/xsct/1234005?fhir_vs=ecl/<86052008

----------------------

  1. GET /ValueSet/$expand?url=http://snomed.info/xsct/1234005;module/98763002?fhir_vs=ecl/<86052008
  2. GET /ValueSet/$expand?url=http://snomed.info/sct/900000000000207008;module/98763002#http://snomed.info/xsct/1234005?fhir_vs=ecl/<86052008

---------------------


Feedback

  • ML - this syntax would not work today. Perhaps use a POST with a ValueSet def based on a SNOMED CT code system, including the code system supplement.. there is a ticket related to referencing supplements
    • The code system and supplement in the definition would need to match (inc version)

The terminology server will expand the ECL using the current version of the CodeSystem supplement and the precoordinated SNOMED CT Edition and the version that the supplement is dependent on. The results will contain a mixture of simple codes and expressions:

{
    "resourceType": "ValueSet",
  "url": "/ValueSet/$expand?http://example.org/snomed-pce-library?fhir_vs=ecl/<86052008",
...
  "expansion": {
        "id": "c770c558-57a3-4512-9099-a4c7e39bb618",
      "total": 23,
        "offset": 0,
        "parameter": [
            {
                "name": "version",
              "valueUri": "?"
          }
      ],
        "contains": [
            {
                "system": "http://snomed.info/sct",
                "code": "440143005",
                "display": "Closed reduction of closed nondisplaced rib fracture"
          },
            {
                "system": "http://snomed.info/sct",
                "code": "311446006",
                "display": "Closed reduction of fracture and traction"
            },
            {
                "system": "http://snomed.info/sct",
              "code": "87971000:272741003=7771000",
              "display": "Closed reduction of fracture of radius:Laterality=Left"
          }
....

The last code in the results is our expression. It includes a term generated using the expression.

Feedback

  • ML - In R5 the alternate id could be requested during expand

The EHR can use the precoordinated codes to identify closed reduction procedures within the EHR records. If the EHR can store expressions then the expressions can also be used as they are. If the EHR can not store expressions the following is needed:

  • Translate expressions to simple codes (only needed if EHR cannot store expressions)

GET /ConceptMap/example-pce-id/$translate?target=http://snomed.info/pce-id-gen/1101234&code=87971000:272741003=7771000

Same response as before.

Summary

  • Search existing precoordinated content
  • Create expression - CodeSystem supplement PATCH
    • Create map entry from expression to generated code - ConceptMap PATCH
    • Translate - ConceptMap Translate
  • Query - ValueSet Expand
    • Translate expression to code - ConceptMap Translate

Feedback

  • ML
    • the alternate identifier could be kept within the EHR, there may be no need to have that in FHIR.
      • POST to $expand could be used for translation of alternate id to expression



  • No labels