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