Discussion
· Feb 6

FHIR interoperability

Hi everyone,

I was discussing the interoperability side of FHIR as part of a discussion about the best resource/s that should be used in order to represent Antibiotic resilience, and although we've reached an agreement, that got me thinking of two thing, and I'd love to know your thoughts on those matters.

1. How can you make sure that data from another organization is represented the same way it does on your side, I mean how do you get minimal transformation between organizations and minimal translations, for example I use Task in order to represent morbidity, while another organization uses Observation or Condition, how and who translates the resources?

2. Lets imagine everyone sticks to the same plan and there are no differences between the organizations, someone still needs to convert an incoming search bundle to a transformation bundle while replacing the keys in all the references like subject, location, organization, etc. how do you convert the incoming message to a request you can post / put?

I'm guessing most of you have already have those things figured out, and I'd like to hear from you and maybe have a better plan than the one we're currently conjuring.

Thanks,

Eyal

Discussion (4)5
Log in or sign up to continue

When using base FHIR, just as when using HL7 V2, the only way to assure interoperability is that agreement between the two organizations.   Semantic interoperability is not in base FHIR, it is created by FHIR profiles.  That FHIR profile for a use case is the agreement for how to represent the data.  That agreement, FHIR profile, can be shared across many organizations.  The FHIR profile is that "plan that everyone sticks to" as you describe it.  

But when the data source has not validated against a FHIR profile, say it is an HL7 V2 message, then the translation is indeed up to each individual developer.  And you wind up with different FHIR Resources and constraints for the same data.  

Your example of antibiotic resistance for a bacterial strain is interesting.  I have sent that question to the experts.  It is an observation but it is not an observation on the Patient.

Russ Leftwich

I reached out about the representation of antibiotic resistance in FHIR and received the response below:

here is some debate going on in zulip (www.chat.fhir.org) around that:stream:Orders+and+Observation+WG topic:Micro+/+Culture near:419845077

It is definitely an observation but how the organism and the susceptibilities are tied together is what the debate is about at this time.

OO says using observation.has member in the observation that has the organism name as observation.value and then have each susceptibility is it's own observation - see https://build.fhir.org/diagnostics-module.html#10.0.3.1.1

Jay and several other folks think we should use observation.value and then populate observation.component - one for each antibiotic susceptibility.

updating after response from FHIR community on how to represent bacterial resistance in FHIR.  There are SNOMED codes to represent the specific antibiotic resistance of an identified species of bacteria that would represent the "value" of a FHIR Observation resource. 

Creating a FHIR (Fast Healthcare Interoperability Resources) Observation resource for a blood culture that is positive for Vancomycin-resistant Escherichia coli (E. coli) involves specifying several components in the resource to accurately represent the clinical findings. Here’s an example of what such an Observation resource might look like in JSON format, which is commonly used in FHIR:

 

{

  "resourceType": "Observation",

  "id": "blood-culture-observation-12345",

  "status": "final",

  "code": {

    "coding": [

      {

        "system": "http://loinc.org",

        "code": "600-7",

        "display": "Bacteria identified in Blood by Culture"

      }

    ]

  },

  "subject": {

    "reference": "Patient/example"

  },

  "issued": "2024-02-13T08:03:00Z",

  "performer": [

    {

      "reference": "Practitioner/example"

    }

  ],

  "valueCodeableConcept": {

    "coding": [

      {

        "system": "http://snomed.info/sct",

        "code": "112283007",

        "display": "Escherichia coli"

      }

    ],

    "text": "Vancomycin-resistant Escherichia coli"

  },

  "interpretation": [

    {

      "coding": [

        {

          "system": "http://terminology.hl7.org/CodeSystem/v3-ObservationInterpretation",

          "code": "POS",

          "display": "Positive"

        }

      ],

      "text": "Positive for Vancomycin-resistant Escherichia coli"

    }

  ],

  "note": [

    {

      "text": "Blood culture positive for Vancomycin-resistant Escherichia coli (VRE)"

    }

  ]

}

 

Explanation of key elements in this resource:

 

      •     resourceType: Identifies the type of the resource, which is “Observation” in this case.

      •     id: A unique identifier for this particular observation.

      •     status: The status of the observation (e.g., “final”).

      •     code: Uses LOINC (Logical Observation Identifiers Names and Codes) to indicate the type of observation, here representing a blood culture.

      •     subject: Reference to the patient associated with this observation.

      •     issued: The date and time at which the observation was made available.

      •     performer: Reference to the practitioner or organization that performed the observation.

      •     valueCodeableConcept: Uses SNOMED CT to specify the finding, in this case, E. coli, with a note indicating it’s vancomycin-resistant.

      •     interpretation: Provides an interpretation of the observation, here indicating a positive result for vancomycin-resistant E. coli.

      •     note: Any additional notes or comments related to the observation.

 

This is a simplified example and in a real-world scenario, additional details like patient information, encounter data, and more specific coding might be included.