Alix Goss

Bob Dieterle

Patrick Murta

Tim Young

Ed Martin

Tony Little

Rick Geimer

Jason Walonoski

Dan Chaput

Alex Kontur

 

Deliverable – Issue Statements

Bob – Alix/Bob reviewed work from the fall, attempted to recast as issues rather than observations, solutions, etc.

 

Issue: Versioning – how do we manage multiple versions of FHIR endpoints/artifacts?

  • Currently multiple versions of FHIR in production
  • Regulation supports adoption of new versions
  • FHIR will continue to evolve
  • A single organization may have information provided on one or more patients from different versions of FHIR
  • Breaking changes between versions restrict ability to translate between versions

 

Bob – are these good issue statements, do you agree with them, are we missing anything?

  • Geimer – good issue statements; missing the concept that increasing number of normative resources will reduce number of conflicts between versions over time
  • Tony – are there issues around extensions that we need to consider re: versioning
    • Geimer – don’t think that would be a big issues as long as extensions are validated/recognized. Any issues w/extensions are not unique to versioning
    • Jason – raises the issue of profiling & IGs…does that fall under the umbrella of versioning?
    • Geimer – may be worth adding an issue related to versioning within profiles/IGs
      • Bob – “version issues are not limited to releases to FHIR core artifacts, but include extensions, profiles, and IGs”
  • Ed – Any issues related to adhering to a standard, e.g. implementation differs across EHR vendors
    • Geimer – for example: Sequoia directory is based on a pre-release version of FHIR STU3 (not compatible with the published version of STU3); EHR vendors may require different things in their HTTP headers; routine errors in implementation
    • Bob – suggest that testing/validation is out of scope for our Tiger Team; “issues related to the implementation of versions should be considered by the Testing & Certification Tiger Team”
  • Patrick – concerned that the way we version deviates from standard RESTful patterns
    • Tony – as an implementer, what do I need to know the version of? Do I need to know the version of FHIR as well as the version of REST?
    • Geimer – FHIR provides a normative RESTful API. Implementers may have an issue dealing with older versions of FHIR (and therefore the RESTful API). Not much we can do about deviations from RESTful patterns
    • Murta – there is a certain versioning pattern that exists in the world re: RESTful APIs…e.g. people expect to see certain information (indicating the version) in the URI that FHIR implementations don’t necessarily use
    • Bob – FHIR versioning of RESTful APIs may differ from general industry definitions

 

Issue: Identifying FHIR Endpoints & Services

  • Bob – ability to identify a FHIR endpoint associated with a specific organization and supported services
    • Murta – what does endpoint mean?
    • Geimer – a FHIR server endpoint with an available capability statement that describes the rules associated with the endpoint
      • Bob – but an operational endpoint wouldn’t necessarily have that, and we have both
      • Geimer – “…identify a FHIR endpoint or other FHIR-enabled service endpoint…”
      • Final language: Ability to identify a FHIR endpoint (server w/capability statement) or other FHIR-enabled service endpoint associated with a specific organization and supported services
  • Bob – ability to identify trust framework(s) and/or authentication requirements associated with a FHIR endpoint
    • Bob – implicitly includes pre-registration requirements
  • Ability to identify the version(s) of FHIR supported at a specific FHIR endpoint
  • Bob – Ability to identify the services supported at a FHIR endpoint…not an issue because a FHIR endpoint has a capability statement?
    • Capability statement are not constrained enough to always provide all of the information necessary to understand services
    • Bob – Do we create a more constrained version of Capability Statement, or do we include the ability to more definitively understand an endpoint’s capabilities in the directory itself – “ability to clearly define and understand supported services”
      • Bob - Wouldn’t I want the directory to tell me which endpoint to hit, rather than hit each of multiple endpoints to figure out their capabilities?
      • Geimer – want the directory to provide that information, and then need to check the capability statement at the endpoint to confirm; directory should periodically pull capability statements to verify/build content
      • Bob – want each endpoint to clearly define its capabilities, and want the directory to include enough information to understand how a given endpoint can be used
      • Geimer – “Ability to keep directory information updated with actual endpoint capabilities”
  • Bob – Ability to represent testing and/or certification information
  • Bob – trusted source of information – e.g. medical school is the only trusted source for provider’s education. Good observation but probably not an issue we need to identify
  • Bob – patient identification/reconciliation is not an endpoint issue
  • Bob – ability to keep endpoint and service-related information current
  • Alix – scope/breadth of directory content is more of a future state item than an issue
  • Bob – Ability to manage authorization to access endpoint details
    • Tony – are there privacy issues we need to consider (participants in directory have to be reasonably sure that their information is protected)
    • Bob – rephrase: “ability to restrict access to endpoint details”

 

Final language of identifying FHIR endpoints/services issues:

  • Ability to identify a FHIR endpoint (server w/ capability statement) or other FHIR- enabled service endpoint associated with a specific organization
  • Ability to identify trust framework and/or authentication requirements associated with a FHIR endpoint
  • Ability to identify the version(s) of FHIR supported at a specific FHIR endpoint
  • Ability to clearly define and understand supported services
  • Ability to keep directory information up-to-date with actual endpoint capabilities
  • Ability to capture/represent testing/certification information
  • Ability to keep endpoint and service related information current
  • Ability to restrict access to endpoint details
  • No labels