201801 IHE-on-FHIR

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:

• 201801 Care Plan
  • IHE Dynamic Care Planning Profile
• 201801 Medical Device and Implantables Tracking using UDI
  • IHE Point-of-Care Medical Device Tracking Profile
• 201801 Provider Directory
  • IHE Mobile Care Services Discovery (mCSD) Profile
• 201801 Patient Track
  • IHE Patient Demographics for Mobile (PDQm) Profile

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

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:

Domain	Profile	Name	Description
ITI	IUA	Internet User Authentication	provides user authorization for RESTful interfaces
ITI	mACM	Mobile Alert Communication Management	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.
ITI	MHD	Mobile access to Health Documents	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 enables simplified access by mobile devices to an XDS (or a similar) document management environment containing health information.
ITI	mXDE	Mobile Cross-Enterprise Document Data Element Extraction	provides the means to access data elements extracted from shared structured documents. This is intended to support data provenance.
ITI	NPFSm	Non-patient File Sharing	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.)
PCC	CMAP	Clinical Mapping	translates codes from one terminology to another for exchange of information between systems.
PCC	RECON	Reconciliation of Clinical Content and Care Providers (RECON)	communicates lists of clinical data that were reconciled, who did the reconciliation and when.
PCC	RIPT	Routine Interfacility Patient Transport	supports interoperability between systems used on transport vehicles between healthcare facilities
PHARM	MMA	Mobile Medication Administration	connects EHRs with devices such as smartphones and smart pill boxes using RESTful web services.
PHARM	UBC	Uniform Barcode Processing
QRPH	mRFD	Mobile Retrieve Form for Data Capture	describes the exchange of context data to allow a seamless form launch with supporting clinical context
QRPH	VRDR	Vital Records Death Reporting	defines a Retrieve Form for Data Capture (RFD) content profile that will specify derivation of source content from a medical summary document. by defining requirements for form filler content and form manager handling of the content.
RAD	SOLE	Standardized Operational Log of Events	stores and retrieves logs of operational events (patient arrives, scan complete, etc).

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

Alert Reporter

• The IHE Alert Reporter 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.

Document Recipient

• The IHE Document Recipient actor receives a set of documents. It is similar to a Document Repository but is only tasked with receiving documents. It will provide documents to other systems through transactions or operations using other interfaces.
• During the Connectathon, the Document Recipient will be expected to accept documents and metadata from a Document Source.

Document Responder

• The IHE Document Responder is a single actor that supports both the Document Registry and Document Repository functionality.
• During the Connectathon, the Document Responder will be expected to support search and retrieve operations from a Document Consumer. The Document Responder can use existing documents or perhaps accept new documents as grouped with a Document Recipient.

Document Source

• The IHE Document Source actor produces and publishes documents. In this context, it publishes documents with metadata by sending data to a Document Recipient.
• During the Connectathon, the Document Source will be required to submit documents for specified patients to a Document Recipient.

Document Consumer

• The IHE Document Consumer actor queries for document metadata meeting certain criteria, and may retrieve selected documents. In this context, it communicates with a Document Responder.

Patient Demographics Supplier

• The IHE Patient Demographics Supplier provides a searchable repository of patient demographic information.
• During the Connectathon, the Patient Demographics Supplier will be expected to host a set of patients with defined demographics (Patient resource) and to respond to search requests and retrieve requests. Searchable parameters are listed below.

Patient Demographics Consumer

• The IHE Patient Demographics Consumer searches for patients, retrieves demographic information and makes use of that information in some manner not defined by IHE.
• During the Connectathon, the Patient Demographics Consumer will be expected to exhibit patient searches using several different search criteria and to read individual Patient resources hosted by the Patient Demographics Supplier.

Patient Identifier Cross-reference Manager

• The IHE Patient Identifier Cross-reference Manager provides cross-referencing of patient identifiers across Patient Identifier Domains.
• During the Connectathon, the Patient Identifier Cross-reference Manager will be expected to host a set of patients with defined demographics (Patient resource) and to respond to Patient GET requests by a stated sourceIdentifier (not a FHIR resource).

Patient Identifier Cross-reference Consumer

• The IHE Patient Identifier Cross-reference Consumer has a patient identifier in one identifier domain (not a Patient resource identifier), retrieves an identifier from a different domain from the Cross-reference Manager, and makes use of that information in some manner not defined by IHE.
• During the Connectathon, the Patient Identifier Cross-reference Consumer will be expected to GET Patient resources for specific patients based on identifiers provided as test data. These are not traditional FHIR GET operations on a Patient resource.

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.

Scenario (MHD) Publication of New Documents

Action: Document Source publishes new documents by sending them to a Document Recipient

Precondition: Actors have agreed on patient identifier domains. A Patient resource exists somewhere that is referenced by the new documents. This Patient resource can live within the Document Source, the Document Recipient or in some other system.

Success Criteria: There are several ways to determine success. If the Document Recipient is coupled with a Document Responder, we have tools that can query the Document Responder and locate the documents. Also, a Document Consumer actor can directly discover and retrieve documents from a Document Responder. If nothing else, we will have to check log entries at the Document Recipient.

Bonus point: Integrate the document workflow with PDQm or PIXm scenarios to manage patient identities and demographics.

Scenario (MHD) Discovery and Retrieval of Existing Documents

Action: Document Consumer discovers documents and retrieves them from a Document Responder.

Precondition: Document Responder has pre-defined documents or is coupled with a Document Recipient and has received documents during the event. We will need to coordinate metadata values.

Success Criteria: Document Consumer will have to demonstrate that it was able to retrieve one or more documents for specified patients.

Bonus point: Integrate the document workflow with PDQm or PIXm scenarios to manage patient identities and demographics. Also integrate directly with submission of documents to a Document Recipient.

Scenario (mXDE) Reconstruct Patient History from a Trail of Documents

Action: Data Element Provenance Consumer discovers documents and retrieves them from a Data Element Extractor.

Precondition: Data Element Extractor implements a QEDm Clinical Data Source and has a patient history stored as a series of documents with provenance information..

Success Criteria: TBD

Bonus point: TBD.

Scenario (NPFSm)

A Healthcare Organization desires uniform rendering of XML Laboratory Reports produced within the organization, so it creates a stylesheet file. Mr. Black, a technician of the Healthcare Organization, creates the stylesheet. Then Mr. Black uses his File Source to publish the stylesheet file into a system that manages non-patient files (File Manager) using the Submit File [ITI-87] transaction. Now the stylesheet will be available to all the LIS involved in the organization.

A Laboratory Information System, according to the HIE policy, should be able to identify the stylesheet that can be used to render the CDA document.

Mrs. White uses the LIS to retrieve a CDA Lab Report from the HIE. The LIS also issues a query using the Search File [ITI-88] transaction, to search for a stylesheet published by the HIE Organization, in order to discover the resource URL of the stylesheet applicable to the Laboratory Reports. This URL is used to reference it as an XSL transformation of the CDA R2 Laboratory Reports produced.

Security and Privacy Considerations

unknown at this time