Alix Goss

Bob Dieterle

Tim Young

Tony Little

Alex Kontur

Technical Barriers

Versioning – Complexities created by version-specific profiles & IGs

• Bob – creates a barrier to adoption of new versions of the FHIR standard, because old versions of profiles, IGs, etc. will need to migrate to the new version of FHIR
  • Tony – is there any effort to do that sort of migration already?
  • Bob – no, e.g. US Core has to be updated for each version of FHIR
  • Tony – may want to consider breaking these into separate issues, one each for profiles, extensions, and IGs
  • Bob – profiles, and IGs are version specific, which creates complexities when supporting multiple versions of FHIR, as well as migration from one version to the next
• Existing efforts:
  • Bob – issue will be minimized (if not eliminated) as resources become normative; work being done to use structureDefinition to support multiple versions, which may be leveraged for certain use cases

Versioning – Complexities created by extensions

• Alex – Extensions work differently than profiles and IGs…they aren’t version specific. Therefore they represent a separate issue
• Bob – new capabilities might require changes to extensions, e.g. might want a different value set when working in a different version of FHIR
  • Alex – difference is that complexity with extensions is based on use. “Old” extensions will still validate in new versions of FHIR, whereas “old” profiles/IGs may not. The need/use cases for extensions can change, but the code itself is still valid

Versioning – FHIR versioning of RESTful APIs may differ from general industry definitions

• Bob – because FHIR uses slightly different definitions (e.g. for versioning) than standard RESTful APIs, it creates complexities for organizations implementing & supporting both FHIR RESTful APIs and other RESTful APIs not based on FHIR
• Existing efforts:
  • Not aware of any

Directory services – endpoint identification

• Bob – no current standard or implementation provides a reproducible method for finding a FHIR endpoint and its associated characteristics (beyond those included in a capabilityStatement)
• Existing efforts:
  • Bob – numerous efforts to incorporate FHIR endpoint information into existing directory services (e.g. Sequoia, DirectTrust)
  • Alex – conditions/maintenance of certification requirement in the ONC NPRM for EHR vendors to publish “service base URL”

Directory services – endpoint characteristics

• Bob – there is currently no standard or implementation that specifies additional endpoint attributes, including but not limited to trust framework, authentication requirements, FHIR version, supported services, certification & testing
• Existing efforts:
  • Bob – FHIR endpoint resource supports some attribute information; specific directory implementations may define additional attributes
  • Alex – Endpoint resource is not normative and therefore can change to incorporate additional attributes

Directory services – currency/accuracy of directory endpoint information

• Bob – currently no standard process for keeping published endpoint information current or validating its accuracy. This creates uncertainty in using any directory of endpoints
• Existing efforts:
  • Bob – ONC NPRM may address this

Directory services – restricting access to endpoint information

• Bob – The DVS Tiger Team anticipates that certain endpoints will not be generally available (regardless of authentication), and any directory service may need to restrict discoverability for those specific endpoints. This may be necessary to minimize security threats by malicious third parties
• Existing efforts:
  • Not aware of any