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.

Scenario (CMAP)

Scenario 1

This use case addresses the recording of vital signs monitoring data from an IHE PCD compliant device using IEEE 11073 nomenclature to the EMR in LOINC.

Providers can view patient data generated by patient care devices in an inpatient setting or outpatient encounter room, but when that same provider accesses his or her EMR application that data is not readily available. Getting semantically correct clinical data from patient care devices into clinical applications is generally not achieved today for a couple of reasons:

• The applicable nomenclature from medical devices, IEEE 11073-10101, is not one of the

clinically approved nomenclatures in most if not all countries, reducing the incentive to use IEEE 11073 data in clinical applications. The update under review, IEEE 11073- 10101a, is also not one of the approved clinical nomenclatures as well.

• There are no commonly accepted mappings of IEEE 11073-10101 to clinical

nomenclatures (LOINC and SNOMED-CT® primarily) for clinical measures although there are vendors who have done so as proprietary interfaces. The result is that there is no reliable way to translate data captured using IEEE terminology to LOINC for systems needing it.

As a result, much of this numeric data generated from medical applications is either not available in clinical or research systems or reentered at significant cost and risk of error. The missing link is a mapping service that can be accessed in a straightforward manner by clinical applications to transform IEEE clinical observations to LOINC nomenclature. Benefits that can be derived from applications utilizing these mappings include:

• Improved data collection and patient safety: Much of the clinical data would no longer

need to be reentered from the device to the clinical application, effectively reducing costs and eliminating risks of neglecting to record the data or making transcription errors.

• Improved patient care: Additional medical device observation data would be available

to clinicians. Increased observation data would be included in the patient’s chart as well as in near real time to the clinical application for clinical decision support.

The benefits would apply to a high volume of work including any scenario involving devices providing vital sign observations. This volume would increase as more clinical observations are added beyond vital signs.

This use case involves the monitoring of vital signs in an inpatient setting (e.g., an ICU, Step Down, Observation, or General / Surgical unit). Vital signs are generally available at the point of care visually from monitoring displays. What is not available and is addressed by this use case is the ability to view and analyze vital signs in time sequence retrospectively for patient care or study purposes.

Scenario 2

Healthcare payers often require the use of ICD-10 terminology for billing and reporting uses. However, other terminologies, such as SNOMED-CT are often used to capture problems in the EMR.

Preconditions:

A patient visits his or her doctor for a scheduled ambulatory encounter. During the course of the encounter, the doctor documents relevant clinical facts about the patient in the EMR system. When documenting the patient’s problems, the EMR system assists the doctor to code each problem with appropriate codes selected from SNOMED-CT.

Scenario (RECON)

Mr. Jonathan Allan is a 77 year old male ‘snowbird’. He lives in Michigan during the summer and in Florida the rest of the year. He has diabetes and has also undergone multiple open heart surgeries to correct irregular heartbeats and other ailments related to the heart. He is currently planning his return to Michigan. He makes an appointment with his Cardiologist in Michigan. His Cardiologist practice sets up an initial visit with the patient and obtains information about the patient from his care providers in Florida as well as from the Florida State HIE. The Cardiologist would like to reconcile pertinent clinical information and import it into his EHR so he can have updated information about his patient so he can effectively care for his patient.

Scenario (RIPT)

Hospital Discharge to Transport Using Information Query Process Flow Pre-conditions:

1. Hospital EMR has patient information in the system
2. Physician Clears Patient for discharge
3. Transport provider is contacted and minimum required patient data is shared with the transport provider (name, gender, date of birth, MRN)
4. The pickup time is arranged

Main Flow:

1. Transport teams arrives at the pick-up location and queries the patient information from the Hospital EMR to populate the patient care record system.
2. Transport team receives nurse report and transfer of care
3. Patient contact is made and transport is started

Security and Privacy Considerations

unknown at this time