Alix Goss

Bob Dieterle

Karl Davis

Ed Martin

Danielle Friend

Alex Kontur

 

Slack Overview (Ed Martin)

  • Message channels show history of all conversations, which are searchable
  • Users should set their profiles: click name and select profile/account
  • List of names on the left hand screen indicate people who are online with a green dot
  • Types of messages:
    • Channels - # indicates a public channel, private channels have a lock symbol
      • Threaded replies help cut down on the number of messages in a channel
    • Direct message – enable private conversations, can be with one or more people
    • Can use @ to notify specific people or an entire channel to pay attention to a message
  • Auto-preview for specific links (e.g. for google docs)
  • Post function enables fancier document creation within Slack (i.e. not just a plain message)
  • Can upload files
  • Can change notification settings under preferences
  • 3 ways to access slack: browser, desktop app, mobile app
  • Suggest that we use Slack to post questions/comments for feedback between meetings
  • Value: cuts down on email, keeps information organized in one place
  • Can add capabilities like polling
  • The random channel is useful for off-topic conversations, can help cut down on clutter in other channels

 

Use Cases

  • [Bob walked through the same use case we reviewed on the last call – patient information request, provider to plan]
  • Use Cases Tiger Team has started process of combining use cases based on commonalities
    • Also developing use cases for core functionalities, e.g. endpoint discovery, authentication/authorization
  • Use cases aren’t focused on functionality (e.g. the content of a message/transaction), rather they are focused on ecosystem requirements
  • Use cases include:
    • Brief introduction/background about the use cases/P2 FHIR task force
    • Use case approach: barrier use cases (core functions), generic use cases, and use cases from/related to Da Vinci
    • Variations/Extensions describe the set of scenarios covered by the use case document
    • In scope/out of scope – set the boundaries of the use case. Mostly taken from Da Vinci use case in this example
    • Assumptions about the use case
    • Primary/supporting actors
    • Stakeholders/interests – frames background, e.g. providers, payer/plan, patient, caregiver, federal/state agencies, etc.
    • Preconditions – Assumptions/preconditions set requirements
    • Post conditions – also express certain requirements (i.e. the end state that the use case expresses)
      • We may have to expand on these and consider the details in our work on this Tiger Team
    • Trigger – what starts the use case
    • Requirements and main scenario – articulates a set of common requirements across the use case’s scenarios, often references core capabilities
  • Karl Davis - CMS recently released an RFP for a project to build a payer-to-ACO API to share claims data on attributed beneficiaries. Contract has been awarded. [this comment should not be construed as a CMS commitment]
  • Alix – how set is this use case, how much could it change?
    • Bob – still in development, not necessarily set yet, but probably close. This is an example of how they are thinking about use cases at the moment
  • Karl Davis – this use case is about a provider asking a payer for data they hold directly?
    • Bob – correct. Commercial plans may hold clinical records (e.g. lab reports, information to support value-based care contracts, etc.)
  • Bob – we will need to look at all of the requirements in each use case (i.e. the pre/post conditions, assumptions, requirements/scenarios, etc.) to see which ones apply to our Tiger Team
    • E.g. the requirement to send a request for data to a payer’s endpoint may involve the use of a trust framework to ensure trusted/secure authentication/authorization
  • Ed – will we have a chance to review use cases?
    • Bob – yes, as soon as the Use Case Tiger Team release it
  • Karl – are these use cases envisioned with some sort of timeframe in mind? (i.e. when they should be adopted by the industry)
    • Bob – part of our work will be defining when/how any standards we develop will be presented (e.g. balloting, recommending for regulation, best practice, etc). Testing through piloting to help define approach.
    • Karl – concerned about how we manage alignment with other initiatives (e.g. the CMS effort described earlier)
    • Bob – part of the reason we convened a broad group like the P2 FHIR Task Force is to help w/alignment of efforts
  • No labels