Difference between revisions of "201605 CDS Enablement Services"
| (13 intermediate revisions by 4 users not shown) | |||
| Line 15: | Line 15: | ||
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. | 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. | ||
| + | '''Note that there is another CDS related track at this connectathon''' [http://wiki.hl7.org/index.php?title=201605_CDS_Hooks_Connectathon_Track_Proposal] | ||
==Proposed Track Lead== | ==Proposed Track Lead== | ||
| Line 21: | Line 22: | ||
==Expected participants== | ==Expected participants== | ||
| − | |||
The expected participants include: | The expected participants include: | ||
| − | + | * Cognitive Medical System | |
| + | * Database Solutions | ||
| + | * Health Samurai | ||
| + | * Intermountain HealthCare | ||
| + | * OSIA Medical | ||
| + | * Partners Healthcare | ||
| + | * Regenstrief | ||
| + | * University of Utah | ||
==Roles== | ==Roles== | ||
| − | + | The CDS Enablement Service consists of four roles to support the proposed tracks: | |
| − | === | + | ===SOA Services=== |
<!-- 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 --> | ||
| − | + | * A Publish and Subscribe Service which exposes interfaces for the registration of users and the association of users as subscribers and publishers to topics and for the management of topics. | |
| + | * A Unified Communication Service allowing communications directed towards human recipients and which supports functionality such as sending messages to recipients across various channels and escalating messages to other recipient. | ||
| − | === | + | ===SOA Service Clients=== |
<!-- 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 --> | ||
| − | + | * Publish and Subscribe Clients for the relevant interfaces of the Event Publish and Subscribe Service Functional Model such as publishing, subscribing, topic management, etc... | |
| + | * A Unified Communication Client that supports sending messages to the UCS broker and can query the UCS broker. | ||
==Scenarios== | ==Scenarios== | ||
| Line 120: | Line 129: | ||
=== 1. Notify the primary care provider using EMR alert === | === 1. Notify the primary care provider using EMR alert === | ||
| − | Precondition: A clinical process necessitates alerting a provider | + | '''Precondition''': |
| − | Action: | + | |
| + | A clinical process necessitates alerting a provider | ||
| + | |||
| + | '''Action''': | ||
| + | |||
Determine the notification payload to be sent | Determine the notification payload to be sent | ||
| + | |||
Determine addressing of recipient | Determine addressing of recipient | ||
| + | |||
Submit alert message to recipient | Submit alert message to recipient | ||
| − | Success Criteria: Primary care provider receives alert in "EMR" inbox | + | |
| − | Bonus Point: | + | '''Success Criteria''': |
| + | |||
| + | Primary care provider receives alert in "EMR" inbox | ||
| + | |||
| + | '''Bonus Point:''' | ||
| + | |||
Use decision support to determine notification message | Use decision support to determine notification message | ||
=== 2. Select recipient based upon clinical role === | === 2. Select recipient based upon clinical role === | ||
Reroute (failover) message to provider along a different modality (e.g., eMail or SMS) | 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: | + | '''Precondition''': |
| + | |||
| + | Original alert message sent to provider is not acknowledged in a timely manner. | ||
| + | |||
| + | '''Action''': | ||
| + | |||
Determine that message rerouting is required | Determine that message rerouting is required | ||
| + | |||
Determine recipient addressing for a new communication channel | Determine recipient addressing for a new communication channel | ||
| + | |||
Submit message to recipient using alternative communication channel | Submit message to recipient using alternative communication channel | ||
| − | Success Criteria: Recipient receives message on the right device | + | |
| − | Bonus Point(s): | + | '''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 alternative payload based on new communication channel and its HIPAA compliance | ||
| + | |||
Select preferred modality based on recipient’s preference profile | Select preferred modality based on recipient’s preference profile | ||
=== 3. Escalate message to next-in-charge via alert === | === 3. Escalate message to next-in-charge via alert === | ||
| − | Precondition: Original alert message sent to provider is not acknowledged in a timely manner. | + | '''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. | There is a named alternate (next-in-charge or surrogate) specified. | ||
| − | Action: | + | |
| + | '''Action''': | ||
| + | |||
Determine that message escalation is required | Determine that message escalation is required | ||
| + | |||
Determine new recipient addressing for the alert | Determine new recipient addressing for the alert | ||
| + | |||
Submit message to proper recipient | Submit message to proper recipient | ||
| − | Success Criteria: Next-in-charge receives alert | + | |
| − | Bonus Point: | + | '''Success Criteria''': |
| + | |||
| + | Next-in-charge receives alert | ||
| + | |||
| + | '''Bonus Point:''' | ||
| + | |||
Select escalation recipient based upon clinical role | Select escalation recipient based upon clinical role | ||
| − | Escalate to recipient using alternative | + | |
| + | Escalate to recipient using alternative communication channels | ||
Latest revision as of 21:53, 6 April 2016
CDS Enablement Services
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.
Note that there is another CDS related track at this connectathon [1]
Proposed Track Lead
Coordinator: Claude Nanjo (Cognitive)
Expected participants
The expected participants include:
* Cognitive Medical System * Database Solutions * Health Samurai * Intermountain HealthCare * OSIA Medical * Partners Healthcare * Regenstrief * University of Utah
Roles
The CDS Enablement Service consists of four roles to support the proposed tracks:
SOA Services
- A Publish and Subscribe Service which exposes interfaces for the registration of users and the association of users as subscribers and publishers to topics and for the management of topics.
- A Unified Communication Service allowing communications directed towards human recipients and which supports functionality such as sending messages to recipients across various channels and escalating messages to other recipient.
SOA Service Clients
- Publish and Subscribe Clients for the relevant interfaces of the Event Publish and Subscribe Service Functional Model such as publishing, subscribing, topic management, etc...
- A Unified Communication Client that supports sending messages to the UCS broker and can query the UCS broker.
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
2. 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
3. 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
4. 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
5. 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
