All
Accepted answers
Russ Leftwich · Jul 27, 2022 go to post

Forwards compatibility of DSTU2 (draft standard for trial use) was never intended.  That is the short answer. 

There are breaking changes between DSTU2 and R4.  Even to the extent that some FHIR Resources in DSTU2 no longer exist and names were changed or collapsed into a single Resource (ProcedureRequest + ReferralRequest => ServiceRequest).  DSTU2 => SDA => R4 is a path, but at some point we stopped supporting DSTU2.  There would be need to analyze data loss and integrity of the R4 data if it is still possible. 

Russ Leftwich · Jul 29, 2022 go to post

The FHIR subscription architecture will change in FHIR R5.  The SubscriptionTopic Resource exists in FHIR R 5.0.0 snapshot but did not exist in R4.  Therefore it has maturity level 0.  Advancement of maturity level is a prescribed processs which requires use in connectathons as well as in production (once to level 3).  FHIR Subscription Resource is maturity level 2.  Maturity level does not relate so much to whether a Resource is implementable as it does to whether the Resource is likely to change.  

Russ Leftwich · Nov 8, 2023 go to post

FHIR Resources (upper case when referring to the specification) represent a flexible healthcare data model that can be applied to many different use cases when that data model is constrained by creating FHIR Profiles.  The interoperability is in the constrained FHIR Profiles, not in FHIR Resources.  It is true that the base FHIR standard is equivalent to HL7 v2.  The HL7 v2 is syntactic interoperability only, as is the base FHIR standard, and you cannot apply a "profile" to HL7 v2.  It is not possible. 
Semantic Interoperabillity is hard and it exists only if there is a shared semantic model = FHIR Profile used by the systems exchanging data.  The same profile, because it is possible to create different profiles for a use case that are reasonable models but are not the same. 
FHIR is neither the holy grail nor just another technology.  It does offer the potential to enable semantic interoperability.  And FHIR was created by the same people, the same organization that created HL7 V3.  Lessons learned in the failed HL7 V3 were part of what guided the development of FHIR. 

Russ Leftwich · Feb 7, 2024 go to post

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

Russ Leftwich · Feb 8, 2024 go to post

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.

Russ Leftwich · Feb 19, 2024 go to post

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.