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:
- Clear definitions of issues we have discussed and defined*
- Concise summary of industry efforts*
- Define regulatory barriers and their impact*
- Define/propose standards & regulatory efforts, including timelines
- Define future state & technical solutions
- Evaluate recent regulatory efforts (ONC/CMS NPRMs)
- Present findings to FAST Steering Committee
- Identify solutions to issues for industry review
- E.g. create a single place for individuals to register their interest in obtaining health data, which may be shared across data sources
- 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?