Alix Goss

Bob Dieterle

Danielle Friend

Doug DeShazo

Tim Young

Rick Geimer

Jason Walonoski

Dan Chaput

Diana Ciricean

Alex Kontur


Technical Barriers

Versioning – multiple FHIR versions in production

  • Bob - Creates a need for trading partners to support the same version [updated to: “multiple versions”] of FHIR, and therefore creates a significant challenge for multiple trading partners that may individually support different versions of FHIR
    • Geimer – suggest saying “compatible versions” rather than “same version”.
    • Bob – Not able to have multiple versions within a single bundle
    • Geimer – have been able to successfully load R3 resources on an R4 server b/c those resources hadn’t changed much. Can indicate version using meta tags (may be a recommendation we make)
  • Danielle – optionality within regulations is a barrier. As a server, you can pick one version to certify to, which means clients have to support multiple versions to interact with all possible servers. Therefore, regulations should rely on a single version and not provide options
    • Geimer – Would a single named version establish both a floor and a ceiling?
    • Bob – regulation should name one version for certification, but allow the adoption of future versions as long as existing applications continue to be supported
  • Bob - Potential to support normative resources across multiple versions. Potential to support transformation between versions of resources where backward/forward compatibility isn’t compromised
  • Existing efforts:
    • Bob – moving to normative resources; regulatory support for requirements for backward compatibility of future versions
    • Geimer – FHIR community working on reliable transformation tools (however, significant breaking changes may impact ability to do transformations)

Versioning – continued evolution of FHIR standard

  • Bob – Continued evolution of the standard to support new functionality creates timing and adoption challenges. E.g. supporting a new use case may require adoption of new version of the standard [b/c it includes new/modified resources, extensions, etc.]
    • Geimer – e.g. creation of new operations
  • Existing efforts:
    • Bob – work to mature FHIR standard and establish normative content

Versioning – variable standards adoption

  • Geimer - different vendors will support different functions at different times, which requires lookup of endpoint capabilities every time they are used
    • Geimer – responsibility of organization managing capabilityStatement to keep it up to date, and responsibility of the client to check capabilityStatement
    • Bob – May have to check capabilityStatement every time, especially if I have multiple trading partners
    • Geimer – in general, server doesn’t remove capabilities. Rather, they may add new capabilities
  • Existing efforts:
    • Bob – not aware of any existing solutions
    • Geimer – could do something like creating a capabilities registry (i.e. cache capabilityStatements, when they are updated, etc.)

Versioning – multiple versions comprising a single patient’s record

  • Bob – makes it difficult to apply decision support across the patient’s record; also difficult to communicate the entire patient’s record to another entity
    • Geimer – many EHR vendors don’t store the data in FHIR format, therefore less of an issue. However, is more problematic for data aggregators that do store in FHIR format
  • Existing efforts:
    • Bob – not aware of any existing solutions

Versioning – complexities created by version-specific profiles/extensions

  • Bob – have to essentially recreate IGs, profiles, extensions, etc. for each version of FHIR (e.g. US Core on R3 vs R4)
    • Geimer – possible to have multiple versions within an IG…so possible to point back to a previous versions (if they haven’t changed). Profiles can indicate all applicable versions
  • No labels