This wiki has undergone a migration to Confluence found Here

Difference between revisions of "201601 CDS Enablement Services"

From HL7Wiki
Jump to navigation Jump to search
(Blanked the page)
 
(10 intermediate revisions by the same user not shown)
Line 1: Line 1:
[http://wiki.hl7.org/index.php?title=Category:201601_FHIR_Connectathon_Track_Proposals Return to Jan 2016 Proposals]
 
[[Category:201601_FHIR_Connectathon_Track_Proposals|Jan 2016 Proposals]]
 
__NOTOC__
 
=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==
 
<!--Why is this an important track to include in the connectathon - include implementer need, impact on ballot, FMM readiness of the resources, etc. -->
 
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==
 
<!-- Name, email and Skype id of individual who will coordinate the track at the connectathon -->
 
Coordinator: [mailto:cnanjo@cognitivemedicine.com Claude Nanjo (Cognitive)]
 
 
==Expected participants==
 
<!-- List of the individuals and/or organizations that have indicated a desire to attend the connectathon and implement this track -->
 
The expected participants include:
 
 
 
==Roles==
 
<!-- Roles are sets of functionality (generally defined by a Conformance resource) that a single system can take on -->
 
===FHIR Client===
 
<!-- Provide a description of the capabilities this role will have within the connectathon -->
 
FHIR Client will....
 
 
===FHIR Server===
 
<!-- Provide a description of the capabilities this role will have within the connectathon -->
 
FHIR Server will....
 
 
==Scenarios==
 
<!-- What will be the actions performed by participants? -->
 
 
=== 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
 

Latest revision as of 19:44, 5 February 2016