Difference between revisions of "201601 CDS Enablement Services"
(Creation of new CDS Connectathon 11 Track) |
|||
| Line 29: | Line 29: | ||
===FHIR Client=== | ===FHIR Client=== | ||
<!-- Provide a description of the capabilities this role will have within the connectathon --> | <!-- Provide a description of the capabilities this role will have within the connectathon --> | ||
| − | + | FHIR Client will.... | |
===FHIR Server=== | ===FHIR Server=== | ||
<!-- Provide a description of the capabilities this role will have within the connectathon --> | <!-- Provide a description of the capabilities this role will have within the connectathon --> | ||
| − | + | FHIR Server will.... | |
| − | |||
| − | |||
| − | |||
| − | |||
==Scenarios== | ==Scenarios== | ||
Revision as of 19:27, 5 February 2016
DAF Patient, DAF Condition, DAF MedicationStatement and DAF Allergies
If creating a client, this track should require minimal work in advance of the connectathon, though at least a bit of preparation/reading on FHIR is recommended. If creating a server, advanced preparation will be required, but this scenario should somewhat limit the effort involved.
Pre-requisites: none
Submitting WG/Project/Implementer Group
Clinical Decision Support (CDS) with support from Service-oriented Architecture (SOA)
Justification
In order to provide effective and timely clinical decision support, a number of enabling infrastructure capabilities are necessary. This track explores and exploits capabilities available within the FHIR spec, and will illustrate how SOA services can complement these core capabilities as part of enablement of CDS.
Proposed Track Lead
Coordinator: Claude Nanjo (Cognitive)
Expected participants
The expected participants include:
Roles
FHIR Client
FHIR Client will....
FHIR Server
FHIR Server will....
Scenarios
Publish & Subscribe Use Cases:
1. Register a new publisher
Precondition: EPS service is running Action: Publisher registers as a credentialed and identified publisher Success Criteria: Publisher successfully registered Publish against a topic Precondition: Successful registration of publisher Action: An event is published to designated topic Success Criteria: Publisher successfully populates broker topic Bonus Point: Broker implements ability for a published event to be moderated - i.e. held until approved
2. Subscribe to a specific topic
Precondition: Desired topic identified Action: Query available topics associated with the broker Subscribe to one of the specific topics Success Criteria: Successfully establish a pull subscription Bonus Point: Successfully subscribe to a topic and receive push subscriptions
3. Receive a published event
Precondition: Successful subscription Action: Server receives a request to publish an event on a topic Server processes request and publishes the event to the topic Success Criteria: Successfully receive events from a pull subscription Bonus Point: Successfully receive events from a push subscription
4. Create a new topic
Precondition: Successful registration, common topic tree, agreement on topic body Action: Review topic tree Add new topic at the right point in the hierarchy Success Criteria: New topic appears on the topic tree Bonus Point: Support deferred topic create until topic parent owner approves insertion
Notify Care Team Use Cases:
1. Notify the primary care provider using EMR alert
Precondition: A clinical process necessitates alerting a provider Action: Determine the notification payload to be sent Determine addressing of recipient Submit alert message to recipient Success Criteria: Primary care provider receives alert in "EMR" inbox Bonus Point: Use decision support to determine notification message
2. Select recipient based upon clinical role
Reroute (failover) message to provider along a different modality (e.g., eMail or SMS) Precondition: Original alert message sent to provider is not acknowledged in a timely manner. Action: Determine that message rerouting is required Determine recipient addressing for a new communication channel Submit message to recipient using alternative communication channel Success Criteria: Recipient receives message on the right device Bonus Point(s): Select alternative payload based on new communication channel and its HIPAA compliance Select preferred modality based on recipient’s preference profile
3. Escalate message to next-in-charge via alert
Precondition: Original alert message sent to provider is not acknowledged in a timely manner. There is a named alternate (next-in-charge or surrogate) specified. Action: Determine that message escalation is required Determine new recipient addressing for the alert Submit message to proper recipient Success Criteria: Next-in-charge receives alert Bonus Point: Select escalation recipient based upon clinical role Escalate to recipient using alternative communication channels
