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?