FHIR Chat · References to unknown resources · implementers

Stream: implementers

Topic: References to unknown resources

Josh Haskins (Nov 21 2018 at 18:05):

Hi,
I am working with the Encounter resource, specifically in the indication property. I am trying to reference conditions and procedures, however I do not have a literal reference to the resource. I am trying to figure out how to do a logical reference for this resource. I have the SNOMED name and SNOMED code for this resource, however it appears as if SNOMED is not on on list of known identifier systems (https://www.hl7.org/fhir/identifier-registry.html). From looking at the various types of identifier systems, these identifiers are meant for person identifiers (like drivers licenses, healthcare numbers, etc.). Am I trying to reference this resource incorrectly, or..?
Thank you,
-Josh

Lloyd McKenzie (Nov 21 2018 at 18:10):

SNOMED is a code, not an identifier. If you don't have a Condition instance to point to, you can instead create a "contained" Condition resource that just includes the code and the patient. The Encounter.indication reference would then point to the contained Condition resource which you'd assign an internal id to.

Lloyd McKenzie (Nov 21 2018 at 18:12):

You could also submit a change request suggesting that the Reference to Condition or Procedure should also allow a CodeableConcept. (Observation would probably be appropriate to add to the list of resources too.)

Josh Haskins (Nov 21 2018 at 18:22):

Thanks Lloyd. Another question, could I use an custom extension of type valueCoding to achieve this?

"indication": [
{
"extension":[{
"url":"www.example.com/test1",
"valueCoding":{
"system":"http://snomed.info/sct",
"value":12345,
"display": "Severe burn of left ear"}
}]
}]

Yunwei Wang (Nov 21 2018 at 18:36):

What you add here is a diagnosis code. It is NOT a Condition.
And i don't see "indication" in Encounter resource

Lloyd McKenzie (Nov 21 2018 at 18:50):

Yes, it's not called indication, it's called diagnosis.

You certainly could use an extension, but given that there's a "standard" way to convey the codes you have only using core, that's probably an approach that will provide greater interoperability. Searching based on the condition code will work with the contained Condition, but it won't work with the extension unless you also use a custom search criteria

Yunwei Wang (Nov 21 2018 at 18:59):

@Josh H. I put a JSON sample code:

{
    "resourceType": "Encounter",
    "contained": [
        {
            "resourceType": "Condition",
            "id": "c1",
            "code": {
                "coding": [
                    {
                        "system": "http://snomed.info/sct",
                        "code": "39065001",
                        "display": "Burn of ear"
                    }
                ]
            },
            ...
        }
    ],
    "diagnosis": [
        {
            "condition": {
                "reference": "#c1"
            }
        }
    ],
    ...
}

Josh Haskins (Nov 21 2018 at 19:01):

Thanks @Yunwei Wang and @Lloyd McKenzie . My error on mixing up indication and diagnosis, I must have been looking at a different resource. I think I will go with the contained resource method.

Brian Postlethwaite (Dec 03 2018 at 11:09):

This has been restructured in R4, and there is now a mechanism to do the codableconcept in there too through the reasonCode property.

Yunwei Wang (Dec 03 2018 at 15:06):

Good catch. Forgot about that one.

Last updated: Apr 12 2022 at 19:14 UTC