Alix Goss

Bob Dieterle

Rick Geimer

Jason Walonoski

Patrick Murta

Dan Chaput

Alex Kontur

Use Case – plan-provider information request

• Requirements & primary scenario
  • 4 – “need some interactions to be synchronous and some to be asynchronous…”
    • Bob – does not necessarily need to be bulk data compliant (just because an interaction is asynchronous doesn’t mean we need bulk data, e.g. a request for a single patient’s care summary or progress note)
  • 5 – “need the provider’s system to respond in an agreed upon time frame”
    • Bob – as we think through things like scaling or put something in the “middle” like an intermediary, the solution can’t impact this requirement
  • 6 – “in the case of an error on the part of the mechanism or provider…”
• Extensions & variations
  • “the request will define the medical record, attached document….to send to payer systems”
  • “or EHR and the response can be a CARDS text (e.g. reminder)…links for docs, plugins, etc.”
    • Bob – typically the response back from an EHR wouldn’t be a plugin…a plugin only makes sense in the other direction where the payer may specify a SMART app for the provider to use
  • Bulk data – “multiple patients/members from a provider/provider group”
  • Bulk data – “request or provide an option…so the information can be retrieved at the appropriate time”
    • Bob – may want to clarify that this is a request for bulk data
  • Bulk data – “the flow for this scenario is exactly the same…labs, gaps in care, and etc. or a medical record”
    • Bob – this is incorrect, because the examples of responses back are not conformant to the bulk data spec
      • Jason – bulk data response can only be NDJSON
      • Geimer – can provide a Binary resource in response, which may include all of the other types
      • Jason – could return documentReference resources that contain base64 encoded documents

Use Case – versioning

• Assumptions/Primary Actors
  • Bob – the only primary actors are the requesting endpoint and a directory. However, one of the assumptions (“identification of the version of the individual FHIR…or any other FHIR construct”) refers to the content of information exchanged between two endpoints
    • Murta – use cases team wasn’t just thinking about interaction with a directory, rather interaction with a directory assuming second part of the transaction also occurs
    • Bob – then probably want to include the endpoint responder as an actor
  • Geimer – we approved a change to allow a server to support multiple versions of FHIR at a single endpoint. Individual resources can also identify a version in a metadata element
  • Bob – can we have mixed version bundles?
    • Geimer – probably wouldn’t pass validation, because all of the content in the resource must conform to the version of the resource
  • Bob – if you are saving FHIR resources as the resource, you will accumulate resources of different versions over time. If somebody asks for all data about [x], you would have to provide resources across multiple versions…either a bundle with resources from different versions, or convert all resources to a single version
    • Geimer – could potentially provide different bundles for each version, and combine them as a bulk data response if necessary
  • Murta – a single payer may support multiple versions at an endpoint
• Pre-conditions
  • 3 – “responder has a need to provide access…validation of the requestor”
    • Bob – likely not a part of an interaction between the requestor and a directory…a directory would only identify an endpoint not provide access to it
      • Jason – different interpretation: a FHIR directory itself may be a FHIR endpoint
      • Murta – intent was that after the directory has given an endpoint location, it is incumbent on the responder to authenticate/validate the request/requestor
        • Bob – shouldn’t that be a post-condition?
• Post-conditions
  • 2 – “requestor has established a secure connection…responder’s FHIR endpoint”
    • Bob – not a post-condition, should be a pre-condition. 2 authentication processes…one to the directory and one to the endpoint before requesting the server’s version