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
  • No labels