Alix Goss
Bob Dieterle
Ed Martin
Jason Walonoski
Dan Chaput
Alex Kontur
Use Cases
Use cases cover multiple scenarios (variations)
Provider-Plan request for patient info use case (https://oncprojectracking.healthit.gov/wiki/download/attachments/46301216/P2_UC_ProviderRequestFromPlan_v1_11.pdf?api=v2)
- Includes variations for coverage requirements discovery, request for full clinical record, request for specific information/section of a clinical record, request for attributed roster, bulk claims data
Plan-provider request for patient info use case (https://oncprojectracking.healthit.gov/wiki/download/attachments/46301216/P2_UC_PlanRequestToProvider_v1_07.pdf?api=v2)
- Includes variations for request for full medical record/clinical data, request for bulk medical records/clinical data for multiple members/encounters
Recommend asking the Use Cases Tiger Team to mark the documents to indicate whether they are public, what their status is, etc.
Future State Discussion
Bob – created a document based on last week’s Tiger Team meeting and the summary document drafted by Alix Goss. Defines a vision for endpoint discovery and related directory services in the future
Directory:
- Available for any user, with appropriate identity and authentication
- Alex – add authorization?
- Jason – rereading TEFCA document…do we want to say anything about whether a user should have a relationship with TEFCA?
i. Bob – Think of the Common Agreement as the next phase of the DURSA. Just because we have a FHIR endpoint, doesn’t mean it needs to be related to a common framework for sharing PHI. Let’s note that we need to continue to address/resolve overlap with TEFCA
- Standard or easily discoverable endpoint for the “directory” itself
- Bob – assume we know where the directory is and how to access it. If there is more than one directory that complexity is hidden (see #3)
- Goss – What do you mean by the word “standard”
i. Bob – the URL is something national.directory.hhs.gov à one known place to look for it, and/or way to resolve different endpoints to it (may not be a single endpoint/address). There is a known way to get to the directory(ies).
- Any complexity behind the directory model is hidden to the requestor
- Bob – e.g. complexities associated with a federated directory are hidden to the user. The user doesn’t need to know the architecture behind it (e.g. like Google or Amazon)
i. Ed Martin – implementation complexity is hidden
- Goss – unsure if we always want to hide the complexity when patient care is at stake, e.g. importance of knowing the source of truth
i. Jason – some of those concerns may be resolved based on the endpoint metadata (see #5)
ii. Bob – comment about source of truth was related to whether providers may be in multiple directories, and/or have different endpoints in each directory
- Bob – comment about dispute resolution referred to whether anybody can post anything about anybody (e.g. somebody publicly accuses a competitor’s endpoint of always providing bad data), or there is a more private process
- Ability to discover a FHIR associated electronic endpoint using a standard directory endpoint query that supports search criteria that are reasonably known by the requestor
- Bob – Intent that there are a standard set of queries support, which may be based on common parameters such as name, organization, NPI, specialty, location. Need to have a relationship capability to help determine the relevance of the endpoint
- Endpoints have standard metadata that describe the endpoint (e.g. owner, FHIR version, type of exchange/service supported, support profiles/IGs, trust framework, status of endpoint, etc.)
- Bob – need to have a definition of what an endpoint is, does, and supports.
i. Intent for the FHIR Endpoint resource to support all of these elements at some point in the future
- Bob – support for mixed models – do I need to know if this endpoint is really the endpoint, or a proxy for an endpoint? (e.g. the endpoint for a clearinghouse that will route the request to the appropriate endpoint)
- Implementation guidelines (e.g. covering testing/certification, authorization, authentication, acknowledgement responses, etc.)