Alix Goss

Bob Dieterle

Jason Walonoski

Dan Chaput

Alex Kontur

 

[No additional comments on 4 recent use cases: identity management, alerts, quality, orders]

 

Defining Deliverables

Bob & FAST architects (Murta/Oates) spoke with ONC about FAST progress and priorities:

  • Obtain clarity about issues discussed in Tiger Teams
  • Identify regulatory barriers
  • Plans for addressing

 

Tiger Team identified nine items we need to accomplish:

  1. Clear definitions of issues we have discussed and defined*
  2. Concise summary of industry efforts*
  3. Define regulatory barriers and their impact*
  4. Define/propose standards & regulatory efforts, including timelines
  5. Define future state & technical solutions
  6. Evaluate recent regulatory efforts (ONC/CMS NPRMs)
  7. Present findings to FAST Steering Committee
  8. Identify solutions to issues for industry review
    1. E.g. create a single place for individuals to register their interest in obtaining health data, which may be shared across data sources
  9. Propose industry leaders to involve in reviewing solutions

 

* Items to address over next month

 

Bob – Tiger Teams can identify problems and pose solutions, but requires industry leaders and decision makers to review the problem/solution and commit to addressing the problem and/or implementing a solution

 

Jason – question whether we have the knowledge to appropriately assess regulatory barriers (i.e. do we need legal/policy expertise)

  • Bob – believe that members of the Tiger Team have the appropriate knowledge based on experience working with/for federal agencies

 

Defining Issues

Alix reviewed brainstorming document to identify outstanding issues:

 

Issue: Identifying FHIR Endpoints & Services – how can a stakeholder identify appropriate FHIR endpoints and the services supported by the endpoint?

  • Balancing efficiency and trust
    • point-to-point connections vs. brokered connections
    • Data quality re: URI identification, capability statements
    • Do entities need to pre-register to exchange between endpoints? (i.e. identity, authentication, authorization)
    • Availability/participation in trust frameworks
    • Trusted source for information and accepted ecosystem work products
  • Patient identification & reconciliation
    • Insured vs. self-pay dynamics
    • Adherence to federal/state privacy & consent laws
  • Scope and breadth of directory information
  • Ongoing maintenance of directory
  • Alignment w/Testing Tiger Team scope of work (e.g. related to certification/validation)
  • Unresolved questions:
    • Who has the right to know an endpoint exists
    • Who are authorized users of the directory
    • How is directory access granted/managed
    • What data elements does directory include
    • How is information population/maintained
    • What automation is needed for populating directory?
    • Is directory data verified?
    • Uptime for directory (e.g. SLAs)
    • Audit requirements

 

Bob – typically view patients as out of scope for directory, not planning on supporting a “patient directory”

  • Alix – can remove this section as out of scope
  • Jason – if you have client software accessing a directory [for the purpose of exchange], want to have some assurance that endpoints are referring to the same patient
    • Alix - more appropriate for the Identity Tiger Team to address
    • Bob – can be managed to some extent w/patient matching

 

Bob – how do I know the correct provider endpoint to find data about a particular patient? Complex problem, national networks are addressing it to some extent, unclear whether we can do it w/o a national patient ID.

  • Jason – not scalable to query every known endpoint to see if they have data about a given patient
  • Bob – short of proposing a national patient registry, there aren’t a lot of solutions to the issue

 

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

  • Guidelines for number of versions to be recognized/supported
  • Capacity to keep pace w/evolution of FHIR
  • Backwards compatibility
  • Appropriately accommodating different versions via capability statement

 

Issue: Scaling – How do we scale FHIR-based exchange nationally?

  • Appropriate architecture, e.g. spoke/hub vs. point-to-point vs. network of networks
  • Feasibility of real-time data validation
  • Performance requirements (e.g. uptime, response times)

 

Jason – do we need to consider the degree to which we need to scale? E.g. how many clients do we expect? Is every patient/app potentially a client? How many transactions do we expect? Can some components be more/less scaled?

  • No labels