This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "201605 CDS Enablement Services"

From HL7Wiki
Jump to navigation Jump to search
(Undo revision 114822 by Rgeimer (talk))
Line 27: Line 27:
 
==Roles==
 
==Roles==
 
<!-- Roles are sets of functionality (generally defined by a Conformance resource) that a single system can take on -->
 
<!-- Roles are sets of functionality (generally defined by a Conformance resource) that a single system can take on -->
===Document Creator===
+
===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 -->
creates a C-CDA on FHIR document (Bundle containing a Composition and supporting resources) using whatever means are appropriate, including manual creation, assembling documents from other resources, transforming C-CDA R2.1 XML documents (CDA -> FHIR transform), etc.  
+
FHIR Client will....
===Document Consumer===
+
 
 +
===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 -->
receives a C-CDA on FHIR document and does one or more of the following: a) validates the document against the C-CDA on FHIR profiles, b) displays the document in a browser using a supplied display stylesheet, and c) extracts discrete resources from the document for some other purpose.
+
FHIR Server will....
  
 
==Scenarios==
 
==Scenarios==

Revision as of 22:14, 5 February 2016

Return to May 2016 Proposals

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.


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

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