Alix Goss

Bob Dieterle

Jason Walonoski

Rick Geimer

Patrick Murta

Karl Davis

Dan Chaput

Alex Kontur

Use Case Discussion

Patient information request – provider to plan

Issues:

• Goss – typo in the language under Da Vinci UC Base – says “Use Da Vinci uses cases...”, “busses”
• Bob – under stakeholders/interests, items 1 and 2 are reversed (payer has an interest in providing, provider has an interest in receiving)
  • Karl – recommend adding adjective “complete”…you can have accurate information which is incomplete

Things this Tiger Team needs to consider:

• In scope – all items are relevant
  • Bob – we have to look at all of these items to understand if their components are relevant to our Tiger Team, e.g. do we need to include something in the endpoint metadata to indicate that it supports each in scope item
  • Murta – on the payer side, distinction between complete longitudinal history and a decomposed patient record (e.g. only medications)
    • Murta – Humana has a care summary document. Originally thought of it as a complete summary document. Recognized that as the record grew, the clinician may only want portions of it
• Assumptions
  • Transactions will explicitly be declared as synchronous or asynchronous
    • Synchronous – RESTful methods, CDS Hooks
    • Asynchronous – responses that look more like email (e.g. Direct), bulk data, publish/subscribe
      • Murta – original conversation in Use Case/Architecture didn’t involve Direct. Focused on bulk data transfer and/or services w/asynchronous “hops”
      • Bob – if I subscribe to something, I don’t necessarily receive information synchronously
  • Endpoint discovery, Security, Versioning, and Patient Provider Identification are out of scope for this document
    • Bob – fact that they are declared out of scope means they are issues that we have to deal with
      • Murta – probably more accurate to say that these things aren’t described in detail in the use case, although the capabilities are necessary for the use case to be successful
• Supporting actors – EHRs, Payer Systems, endpoint resolution capabilities
• Pre-conditions – numbers 2, 3, 4
  • Bob – 2 - implication is that they will have information when they look up an endpoint
  • Bob – 3 & 4 - indicates that the endpoint supports FHIR model (including version & capabilities)
    • Murta – simple way of trying to say that the actor uses FHIR
    • Bob – may have to be more discrete and indicate knowledge of version/capabilities
• Post-conditions – 2, 3, 4, 5
  • Bob – 2 “Received in timely manner” – may have implications for service level agreements
  • Bob – 3 “Information is understandable” – means we have agreed on an exchange standard
  • Bob – 4 “Transaction did not cause undue burden…” – performance/service delivery issues
  • Bob – 5 - “in the event of an error…”
    • Davis – Directory has to provide certain information for usability, e.g. can’t just say “couldn’t connect”; would need to provide a reason
      • Bob – are you saying that the directory has to include information about errors?
      • Karl – At a minimum, the directory needs to state FHIR version it supports, authn/authz handshakes to talk to it. May post copy of endpoint metadata. Could support additional metadata
      • Goss – do we need to specify errors?
      • Karl – FHIR spec does a decent job of covering the main errors, we may have to define additional errors for specific issues that aren’t well described by the spec (e.g. for authn/authz)
      • Murta – means that the system can’t leave the user in a state of uncertainty or compromise
        • Bob – if I send a synchronous request to an endpoint and I don’t receive a response in a defined period of time…do we need a standard for how to manage that period of time (e.g. time-out behavior if it takes longer than 3 sec)
        • Murta – easiest to mandate rules, but may not be appropriate. We did not define in the use case, other than to say it has to be quick/usable. May need to update the use case based on further discussion in Tiger Team
        • Bob – may need to say an endpoint is expected to respond for synchronous transactions in less than x seconds…endpoint metadata would indicate those rules
        • Karl – suggest that we don’t set a mandate, because we don’t have the appropriate info to do so. First step is that we can mandate that everybody tell us what their SLA requires
  • Karl – I didn’t see anything listed about business models…is that something we are explicitly setting aside? (e.g. not stating that you have to pay for every request to a directory)
    • Murta – specifically avoided in the use case/architecture teams…focused on the functionalities
• Requirements – all of them
  • Murta – use case was written from the perspective of the provider (requester)…can consider rewriting to include expectations on the payer
    • Bob – either way, our Tiger Team needs to consider the payer’s perspective
  • Bob – 1 “securely determine endpoint/version of payer’s resource…”
  • Bob – 2 “send appropriate payload to the provider for processing…”
    • Murta – intent is to indicate that the request from provider to payer must have a proper payload
    • [need to revise the language to more clearly indicate that this is related to a provider request]
  • Bob – 3 “send the request for data to the payer’s endpoint in a trusted and secure way…”
  • Bob – 4 “some interactions to be synchronous and some to be asynchronous…”
  • Bob – 5 “payer’s system to respond in an agreed upon time frame…”
  • Bob – 6 “in the case of an error…”
• Extensions – scenario 1 – “response back from the payer and can be CARDS, text,…”
• Extensions – scenario 2 – “automatically requested or provide an option for the clinician to manually request”
  • Bob – these are different triggers (one requires human interaction, other doesn’t). Regardless of how it’s triggered, the interaction should support synchronous or asynchronous methods?
    • Murta – can’t necessarily think of a situation where you would receive an asynchronous response for this scenario
      • Goss – e.g. pre-encounter documentation
      • Geimer – e.g. subscription for any updates to clinical documents where subject is x patient
      • Bob – e.g. Direct messaging
• Extensions – scenario 3 – “ccda over FHIR, FHIR structured document,…”
  • Murta – this scenario should call out exchange modality (synchronous vs. asynchronous) for consistency
• Extensions – scenario 4 – “request an attributed patient roster”