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

Scenario (mRFD)

mRFD Use Case 1: Research Enrollment This use case encompasses a researcher within an EMR that wishes to transfer some clinical data about their subject to the RMS for use in an open research study.

A clinical user in North Carolina is using their tablet for mobile EMR access while interacting with patients. While doing so, the clinician identifies that the patient fits both the requirements and interest level to be enrolled in a specific study within the RMS.

Note: Study criteria may be managed with other QRPH profiles like Research Matching (RM).

The clinician uses their tablet to request a form from the RMS. This form returns and is displayed to the clinician partially populated with data from the EMR.

It also includes prompts for additional fields required by this particular study that were not available in the EMR population data or via the query to the EMR. This information may be data that is not captured in the EMR but is necessary for the study, or it may be data that is simply not included in the query content. The clinician completes the form on their tablet to flesh out the initial registration of the patient in the study.

Note: Enrollment may be managed with other QRPH profiles like Clinical Research Process Content (CRPC).

mRFD Case #2: Public Health Enrollment

This use case encompasses a provider within an EMR that wishes to transfer some clinical data about their patient to a Public Health information portal in line with jurisdictional requirements.

A public health provider in Vietnam is in a remote location where they see patients. They are using a web browser on their phone to access a view of EMR data. While doing so, they recognize that the patient they are working with has measles. This necessitates a notification to Public Health.

The provider uses their phone to request a form from Public Health using mRFD. This form returns and is displayed to the provider partially populated with:

• Data populated from the EMR
• Data populated from the Vaccination Registry in Vietnam with respect to this patient’s measles vaccination history.

It also includes prompts for additional fields required by this particular case report form that were not available in the EMR population data or via the query to the EMR. This information may be data that is not captured in the EMR but is necessary for the report, or it may be data that is simply not included in the query content. The provider completes the form on their phone to flesh out the initial registration of the Public Health incident.

Scenario (VRDR)

In the Death Certificate COD Guidance use case, a SMART-on-FHIR® app is available to the provider that uses EHR death reporting related information as input to an analytical engine that recommends probable sequences of events leading to the death based on the decedent’s health history; and allows the physician to complete the relevant portions of the death certificate. The completed death reporting information is sent to the EDRS where the jurisdiction completes the processing of the information with the national statistics agency.

When the provider is ready to document the decedent’s death, the Death Certificate COD Guidance SMART-on-FHIR app queries the EHR using VRDRQuery (QRPH-47) to retrieve death reporting related information. This information is used by an analytical engine that recommends probable sequences of events leading to the death based on the decedent’s health history; and allows the physician to complete the relevant portions of the death certificate.

Once the decedent’s death reporting information is documented using the app, the system, creates an HL7 VRDR message or a VRDR CDA document and sends the message to the EDRS directly. The EDRS communicates jurisdiction information to the national statistic agency where the standard coded cause of death is determined and returned to the jurisdiction.

Scenario (SOLE)

SOLE Use Case #2: Analyze Events

An analyst can use SOLE event reports to study the workflow and operations of a facility. The events have already taken place and are archived in the repository. The analyst selects the appropriate time span to be studied and determines the event reporters that may be reporting relevant information. An analysis workstation acts as an Event Consumer and requests all the data from those data sources during that time period. This will include the SOLE event reports and may include a variety of other event reports.

The analyst might use data import tools to ingest the event reports into an appropriate database or analysis system. For example, this might be a free text indexing database, or it could be an object database designed to hold SOLE event reports.

The analyst uses this information to generate the analyses and reports of the workflow based on the event reports and other information.

SOLE Use Case #4: Dashboard

A clinic maintains operational awareness for their staff by maintaining a "dashboard" that displays the current status of equipment, waiting room queues, processing queues, reporting queues, etc. This display is regularly updated to reflect the current situation as patients arrive, are imaged, and depart.

This dashboard receives SOLE event reports from the Event Repository as they are received by the Event Repository. The Event Repository is configured to filter the event reports that it receives to eliminate reports that should not be displayed, e.g., user login reports and security audit reports, and to eliminate SOLE reports from sources that should not be displayed.

The dashboard system uses the SOLE event reports to maintain and update the internal status description used generate the graphics of the dashboard.

Security and Privacy Considerations

unknown at this time