Alix Goss

Bob Dieterle

Dan Chaput

Jason Walonoski

Rick Geimer

Tim Young

Patrick Murta

Tony Little

Alex Kontur

 

Logistics

 

General P2 FHIR workflow: Use case tiger team creates a set of requirements. Requirements are shared with the appropriate Tiger Team. Each Tiger Team turns their requirements into specifications. Specifications are passed to the Testing & Certification Tiger Team, which develops implementation guides for pilot testing.

  • Our Tiger Team will have two sources of input, the Use Cases Tiger Team and a general framework derived from Directory Tiger Team conversations

 

Directory Tiger Team Deliverables:

  1. Identify appropriate national standards for directory of FHIR endpoints and services
  2. Propose approach to dealing with multiple versions of FHIR artifacts
  3. Propose solutions to scaling FHIR

 

Brainstorming

Endpoints (How can a provider or payer identify the appropriate FHIR endpoints and the specific “services” they support for P-P exchanges?)

Vision

  • Bob – any stakeholder’s technology can go to one defined place and discover an endpoint for anyone that they need to communicate with, determine what that endpoint is capable of supporting, and have confidence that the endpoint can support those things
    • Information about endpoints includes the version of FHIR the endpoint/service supports
  • Tony – looking at ways to create a “utility feel” for how we access endpoints/services

Research

  • Jason – Commonwell doesn’t necessarily support FHIR, but it may be worth reviewing their specifications given their scale. They have one location where users can get a full list of endpoints; users can search to find which providers have records for a particular patient and then request their endpoints. Connections to endpoints may go through a broker service (as opposed to accessing the endpoint directly). The broker reduces need for point-to-point authentication/authorization.
    • Geimer - It may be worth trying to establish some understanding w/Commonwell to discuss their approaches and combine efforts. It may be a good partnership as Commonwell implements FHIR capabilities (per their roadmap)
    • Goss – We should consider reviewing approaches by other entities as well
      • Tony –HIEs
      • Geimer – DoD and VA
      • Bob – Sequoia (eHealth Exchange & Carequality), DirectTrust
      • Goss – How does this fit into TEFCA?
      • Jason – Apple must have a directory as well
      • Dan – requirement in Cures act for HHS to identify a place to collect endpoints

 

FHIR Versions (How do we manage multiple versions of FHIR endpoints and FHIR artifacts?)

Vision

  • Bob – Any version of FHIR is supported
    • Jason – may be impractical for every stakeholder to support every version. Should emphasize “major” versions
      • Geimer – “major” means published versions of FHIR. Grahame has put a lot of work into structure maps across versions, but not everything can be mapped completely
      • Jason – Client has to know how to make a request for the correct data, depending on the version of FHIR they are working with/endpoint they are connecting to
      • Geimer – FHIR endpoints today are typically tied to a specific version of FHIR. There are use cases where entities might store FHIR documents in another type of repository, which wouldn’t necessarily indicate the FHIR version. HL7 has done some work to include version information in the metadata of a resource to address this issue (will be included as part of R4)

Research

  • Goss – How do we keep pace with the evolution of FHIR?
  • Goss – to what extent can we say FHIR is backwards compatible?
    • Geimer – FHIR isn’t backwards compatible w/o normative content. Normative content should not have breaking changes in the future. R4 introduces first normative content. Data types, certain infrastructure components (e.g. value set/code system), and the API are going normative, but most of the content resources aren’t going normative yet. Will focus on pushing “most important” resources to normative first. We should identify key resources where we feel we should increase the maturity or bring them to normative status.
  • No labels