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:

  1. Available for any user, with appropriate identity and authentication
    1. Alex – add authorization?
    2. 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

  1. Standard or easily discoverable endpoint for the “directory” itself
    1. 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)
    2. 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).

  1. Any complexity behind the directory model is hidden to the requestor
    1. 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

  1. 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

  1. 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
  2. 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
    1. 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
  3. 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.)
    1. 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

  1. 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)
  2. Implementation guidelines (e.g. covering testing/certification, authorization, authentication, acknowledgement responses, etc.)
  • No labels