![](/wiki/rest/documentConversion/latest/conversion/thumbnail/71404994/1)
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