Alix Goss

Bob Dieterle

Danielle Friend

Patrick Murta

Jason Walonoski

Ed Martin

Tim Young

Karl Davis

Alex Kontur

Diana Ciricean

One-pager Updates

• Commonwell (Tim), DirectTrust (Patrick), Availity (Patrick), Surescripts (Danielle) one-pagers should be available by next week
• Ed – can do one-pagers for Apple and AWS

Use Case Discussion

Patient information request – provider to plan

• Extensions – scenario 4 – “request an attributed patient roster”
  • Bob – response returned as a FHIR structured document. Content of request/response are items we should consider
• Extensions – scenario 5 – “request claims information for my panel”, “response back from the payer is an asynchronous FHIR structured document…”
  • Bob – “my panel” is a specific qualification, which may be decomposed to a request for information about a single patient. When a new patient is seen by a provider, the provider may want to see claims history and/or the payer’s record on that patient. Uses the FHIR bulk data access model
    • Jason – the bulk data specification doesn’t actually send FHIR responses (bundles), rather an NDJSON file. The check to see whether the response is complete are just JSON files, not a FHIR resource/bundle
    • Bob – should update the language in the use case
    • Murta – the use case identifies bundles because there is work between Humana/Epic to implement some of this using actual FHIR documents. Will double check language
    • Bob – when the response is complete, it returns a URL to where you can get the NDJSON files, correct?
      • Jason – it returns a JSON document including transaction time, request, and output (with URL to the appropriate NDJSON file)
      • Bob – security?
        • Jason – Oauth for authorization. May need to use a JWT access token to obtain the NDJSON files from the server
        • Murta – the word bundle is being used inappropriately here, was intended to mean a grouping of documents rather than a FHIR Bundle resource
    • Bob – Tiger Team implications: do you need a separate token/authorization for the results, does an endpoint have the ability to respond to a bulk data request
    • Murta – this was called out as an alternate flow because it’s specifically an asynchronous response, whereas other scenarios were mostly synchronous
      • Bob – (in the diagram) may need to add the clinical actor has to repeatedly query the payer to check the status of the response
• Frequency: 25 million per day
  • Murta – indicates a rough estimate of how this use case has to scale. Consider a payer w/5m covered lives. In a given day, that results in 1.5m transactions (includes administrative transactions, not just clinical transactions. Expect over time that administrative/clinical transactions will be roughly equivalent). Multiply that across all the scenarios (all request from providers to payers), account for a worst case scenario = potentially 25m transactions over a ten hour period
  • Bob – did you do any thinking about how many of those are bulk data vs. single requests?
    • Murta – We considered a single request for a single FHIR response would have the same weight as a bulk data request. Considered the activity between two endpoints, rather than the size/scope of the transaction

Patient information request – plan to provider

• In scope – all items
• Assumptions – “transactions will be explicitly declared…”, “endpoint discovery, security, versioning…”
  • Bob – same as comment on last use case…not really out of scope just not defined in the use case
• Supporting actors – payer systems, EHR, endpoint resolution capability
• Stakeholders & interests – payer/plan, provider
  • Bob - Payer/plan is receiving information, provider is providing information
• Pre-conditions – 2 “payer system has adequate information…”, 3 “the EHR or other clinical system has adopted the FHIR model…”, 4 “the payer/plan has adopted the FHIR model…”
  • Bob – on 2, it’s not really the “requesting endpoint”, should be “the endpoint for the request”
  • Bob – on 2, is the expectation that the responsibility resides with the payer system internally or requires an external resource?
    • Murta – may be interpreted either way. There is no requirement that anything external to a payer will resolve a provider to a member
    • Bob – payer is responsible for determining the relationship between the member and a provider
    • Bob – on 3, will need to determine the version that is supported. Also will need to determine the type of endpoint (e.g. an operations endpoint vs. a FHIR server)
• Post-conditions – 2 “received in a timely manner”, 3 “information is understandable”, 5 “in the event of an error, the information returned does not leave the clinician…”
  • Bob – 3 assumes the payload can be consumed. Is the assumption that the payload is a FHIR resource?
    • Murta – RESTful API to exchange information. FHIR resource as the base transaction structure, but liberal about payload
    • Bob – FHIR resources with CCD or PDF contained in or referenced by the resource