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

Difference between revisions of "201801 IHE-on-FHIR"

From HL7Wiki
Jump to navigation Jump to search
Line 60: Line 60:
 
<!-- What will be the actions performed by participants? -->
 
<!-- What will be the actions performed by participants? -->
  
===Scenario Step 1 Name===
+
===Scenario (mACM) Crisis Response===
 +
In response to a crisis or emergency situation, such as the 2014 and 2015 outbreaks of Ebola in western Africa, it is critical to communicate to health workers across organizational and national boundaries, and to verify receipt of such alerts. Such alerts are commonly issued in the OASIS Common Alerting Protocol (CAP) format. For this testing, the CAP format is a nice to have but not required.
 +
 
 
:Action: <!--Who does what?  (Use the role names listed above when referring to the participants -->
 
:Action: <!--Who does what?  (Use the role names listed above when referring to the participants -->
 +
The Alert Reporter submits an alert to the Alert Aggregator. The FHIR resource is CommunicationRequest.
 
:Precondition: <!-- What setup is required prior to executing this step? -->
 
:Precondition: <!-- What setup is required prior to executing this step? -->
:Success Criteria: <!-- How will the participants know if the test was successful? -->
+
:Success Criteria: <!-- How will the participants know if the test was successful? -->Alert Aggregator will have to demonstrate through logs or simulated alert being sent out the back end.
:Bonus point: <!-- Any additional complexity to make the scenario more challenging -->
+
:Bonus point: <!-- Any additional complexity to make the scenario more challenging -->Alert Reporter requests status information (Communication resource) from the Alert Aggregator.
  
 
<!-- Provide a description of each task -->
 
<!-- Provide a description of each task -->

Revision as of 17:37, 4 December 2017


IHE-on-FHIR

Submitting WG/Project/Implementer Group

Driven by IHE International in coordination with IHE-Connectathon

Justification

To support engagement at FHIR Connectathon on the IHE Profiles that leverage FHIR.

Shall not duplicate more focused and dedicate tracks. These other tracks are encouraged and every effort will be made to coordinate IHE engagement with them:

Also not intended to be testing non-FHIR based IHE profiles. Testing will leverage IHE-Connectathon tools, but will not be considered as comprehensive as IHE-Connectathon

Zulip thread for refinement

https://chat.fhir.org/#narrow/stream/ihe/topic/January.20Connectathon.20-.20IHE-on-FHIR

Proposed Track Lead

See Connectathon_Track_Lead_Responsibilities

  1. Steve Moore (MooreS@mir.wustl.edu)
  2. John Moehrke (JohnMoehrke@gmail.com) -- skype id = johnmoehrke

Expected participants

Roles

This track will be further refined based on the IHE Profiles that leverage FHIR, not including those more dedicated tracks, and the participation. The wiki reference above gives a full list of IHE profiles that leverage FHIR. This is a short list that excludes the tracks already proposed for January, 2018:

  • Mobile Alert Communication Management (mACM)
    • The Mobile Alert Communication Management (mACM) Profile provides the infrastructural components needed to send short, unstructured text alerts to human recipients and can record the outcomes of any human interactions upon receipt of the alert. The mACM Profile also allows for a feedback mechanism to determine the status of an alert through the use of alert statuses.
  • Mobile Access to Health Documents (MHD)
    • The Mobile access to Health Documents (MHD) Profile defines one standardized interface to health documents (a.k.a. an Application Programming Interface (API)) for use by mobile devices so that deployment of mobile applications is more consistent and reusable. MHD it enables simplified access by mobile devices to an XDS (or a similar) document management environment containing health information.
  • Mobile Cross-Enterprise Document Data Element Extraction (mXDE)
    • The Mobile Cross-Enterprise Document Data Element Extraction (mXDE) Profile provides the means to access data elements extracted from shared structured documents. This is intended to support data provenance.
  • Non-patient File Sharing (NPFSm)
    • The Non-patient File Sharing (NPFSm) Profile defines how to enable the sharing of non-patient files that are created, consumed and updated by many different systems involved in a wide variety of data sharing workflows (eg. domain policies sharing, stylesheets management, etc.)
  • Patient Demographics Query for Mobile
    • The Patient Demographics for Mobile (PDQm) Profile provides a transaction for mobile and lightweight browser based applications to query a patient demographics supplier for a list of patients based on user-defined search criteria and retrieve a patient’s demographic information.
  • Patient Identifier Cross-reference for Mobile
    • The Patient Identifier Cross-reference for Mobile (PIXm) Profile provides a transaction for mobile and lightweight browser based applications to query a Patient Identifier Cross-reference Manager for a list of patient identifiers based on the patient identifier in a different domain and retrieve a patient’s cross-domain identifiers information into the application.


IHE will provide experienced IHE-Connectathon staff with tooling used at IHE Connectation.

Alert Reporter

This actor originates the alert (an alarm, either physiological or technical, or an advisory). May also query the Alert Aggregator for the status of the alert. During the Connectathon, it will be required to submit alerts to the Alert Aggregator; the FHIR resource is CommunicationRequest. As an optional step, it can retrieve status information from the Alert Aggregator.

Alert Aggregator

This actor receives alerts from the Alert Reporter and collects status events related to the dissemination of the alert. During the Connectathon, the Alert Aggregator will receive alert requests from the Alert Reporter. It will have to simulate sending out actual alerts and creating status information for an Alert Aggregator to retrieve.

Scenarios

Scenario (mACM) Crisis Response

In response to a crisis or emergency situation, such as the 2014 and 2015 outbreaks of Ebola in western Africa, it is critical to communicate to health workers across organizational and national boundaries, and to verify receipt of such alerts. Such alerts are commonly issued in the OASIS Common Alerting Protocol (CAP) format. For this testing, the CAP format is a nice to have but not required.

Action:

The Alert Reporter submits an alert to the Alert Aggregator. The FHIR resource is CommunicationRequest.

Precondition:
Success Criteria: Alert Aggregator will have to demonstrate through logs or simulated alert being sent out the back end.
Bonus point: Alert Reporter requests status information (Communication resource) from the Alert Aggregator.


TestScript(s)

Security and Privacy Considerations

unknown at this time