Most of the setup process and instructions you can find Third-Party App Setup and Support Guide on Galaxy. This document serves as a supplement - it adds details specific to Way to Health, and points you to specific sections of the Galaxy document as not all portions of that document are necessary.
| Table of Contents | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
Overview
Way to Health (W2H) is a platform used to power a range of programs in the realms of connected health, remote patient monitoring, and patient engagement. Most of our clinical programs use text messaging, but we also use surveys, connected devices, and other data sources.
This document is intended as a high-level overview of W2H’s Epic integration features, aimed at clinical or IT decision makers. Epic’s Third-Party App Setup and Support Guide on Galaxy also has useful high-level information. For technical audiences, Epic Integration: Technical details for Epic analysts contains further in-depth information as well as the full Epic Implementation guide.
Different programs, different integration needs
Different Way to Health programs will have different workflows and integration needs. For example, Heart Safe Motherhood (a postpartum BP monitoring program) requires a way to enroll patients, start them in the program post-discharge, and send BPs received from the patient back to the medical record. Coloprep (a text program to improve colonoscopy prep) does not require manual enrollment, but instead uses an HL7 scheduling feed to enroll patients and trigger the text messages at the right time.
Your Way to Health W2H implementation lead will guide your clinical, operational, and IT teams in deciding which features are needed for the specific program(s) you are implementing.
Setup once, use for multiple programs
Way to Health’s W2H’s Epic integration requires a one-time setup before it can be used for any number of programs. For example, once the embed is available, health systems can begin enrolling and monitoring patients in as many W2H programs as they’d like with no additional IT setup. Similarly, once an outbound ADT feed is established, this can be used by any number of programs to start the intervention after discharge. This applies to all of the features described below except for flowsheets and InBasket In Basket messaging, which are typically configured for a specific program or care team and therefore require program-specific customization.
Use Cases
...
Our app listings specify the broadest set of APIs and interfaces we use, but each connected health program will only use a subset. This table summarizes which integration features are available to support workflow needs, and the setup required.
...
Use Case
...
Feature
...
Required Setup
...
Enrolling patients
Monitoring patients (data, messaging, and more)
...
Embed
...
Webservices access (via frontend OAuth2/SMART on FHIR)
Web App Integration Record (details below)
Web App Integration Launch Point (see Galaxy for details)
“Way to Health” client ID
...
Sending patient-entered data to the medical record via flowsheets
(Requires only one of these 3 approaches)
...
Inbound HL7 flowsheet via TCP/IP
...
VPN between your interface engine and ours
Flowsheet identifiers for use in OBX-3
...
Inbound HL7 flowsheet over HTTPS
...
“Way to Health - Backend” client ID
Flowsheet identifiers for use in OBX-3
...
Flowsheet - via Observation.Create
...
Webservices access (via Backend OAuth2)
Flowsheet identifiers (see details below)
“Way to Health - Backend” client ID
...
Alerting clinicians or care teams of patients needing attention
...
InBasket
...
Webservices access (via Backend user)
Inbasket pool/HIP (details below)
“Way to Health - Backend” client ID
...
Triggering text outreach programs post-discharge
Turning participant messaging on and off during readmissions
...
Outbound HL7 ADT feed
...
VPN between your interface engine and ours
Establishing outbound interface
...
Triggering text outreaches prior to a procedure
...
Outbound HL7 Optime Scheduling feed
...
VPN between your interface engine and ours
Establishing outbound interface
...
Triggering text outreaches prior to an appointment
...
Outbound HL7 Cadence Scheduling feed
...
VPN between your interface engine and ours
Establishing outbound interface
Implementation process
Build and testing for a connected health program
TODO
Setup and testing for Epic integration
TODO
Information to send to Way to Health
(reference: Send Specific Information to Your App Vendor)
...
When do we need this?
...
Example
...
Patient ID Type
...
Always
...
MRN, HUP MRN, MR, etc.
...
Interconnect Base URLs
Prod OAuth
Non-prod OAuth
...
Always
...
https://vendorservices.epic.com/interconnect-amcurprd-oauth/
...
Inbasket pool
Pool ID (HIP .1)
...
Each Inbasket where we’ll send escalations
...
14234
...
Flowsheet information
...
For each data point (e.g. systolic BP) that we’ll send via WebServices or HL7
...
Either
FLO .1 (e.g.
1320)AND Health-system-specific OID (e.g.
urn:oid:1.2.840.114350.1.13.0.1.7.2.707679)
OR
Flowsheet FHIR ID
...
Network configuration
...
If needed to access Interconnect
...
VPN info
To be worked out between your networking/security team and our sysadmin team
...
If we’re using a TCP-based HL7 feed (in either direction)
For inbound HL7 flowsheet, we can use the HL7v2 webservice instead
...
Root CA
...
If Interconnect’s TLS certificates are self-signed or issued by a private CA
...
PEM file such as yourhospital_root_ca.pem
Program changes and shutdown
Once a program is live, all program changes (including shutdown requests) should be submitted through our help desk located at http://support.waytohealth.org
Epic embed
Desktop Integration
The Galaxy document Create Integration Records for Active Guidelines describes how to create the embedded view. Here are the details you’ll need to supply as you complete that setup:
Recommended method, using SMART launch
reference: Configure the Integration Record for SMART on FHIR
...
Client ID
...
Prod:
...
3aa086b8-6dfb-4143-9100-b8e003ebe2a2
...
Non-prod:
...
3ced6ceb-0741-4cf1-83ba-99f3b34d600a
...
Integration type
...
SMART on FHIR
...
Authentication Method
...
SMART on FHIR
...
Launch URL
...
Prod:
...
https://app.waytohealth.org/epic/smartLaunch
...
Non-prod:
...
https://staging.waytohealth.org/epic/smartLaunch
...
Launch Context
...
epicUsername
...
%SYSLOGIN%
...
userFirstName
...
%USERFNAME%
...
userLastName
...
%USERLNAME%
...
mrn
...
%EPTID;;; ; ;nnnn;NONE;%
Instead of nnnn, use the (numeric) ID type that w2h will use. See the launch token library for details.
...
csn
...
%CSN%
In some contexts this value will be empty, but if the embed is launched in the context of an encounter, having the CSN is useful for some workflows
...
frameAncestor
...
%CLIENTHOSTSOURCE%
Legacy launch, using AES encryption
reference: Configure the Integration Record for HTTP GET
...
Type
...
1-PACS
...
Model
...
10-Web PACS
...
Patient ID Type
...
A value should be specified here, but will depend on your health system
...
CRYPTURL
...
Prod:
...
https://app.waytohealth.org/epic/embed?encrypted=%CRYPTSTR%
...
Non-prod:
...
https://staging.waytohealth.org/epic/embed?encrypted=%CRYPTSTR%
...
CRYPTALGO
...
AES128
...
CRYPTIVLENGTH
...
0
...
Launch Context
...
EPICUSERID
...
%SYSLOGIN%
...
USERFNAME
...
%USERFNAME%
...
USERLNAME
...
%USERLNAME%
...
PATID
...
%EPTID;;; ; ;nnnn;NONE;%
Instead of nnnn, use the ID type that w2h will use. See the launch token library for details.
...
CSN
...
%CSN%
In some contexts this value will be empty, but if the embed is launched in the context of an encounter, having the CSN is useful for some workflows
...
frameAncestor
...
%CLIENTHOSTSOURCE%
Flowsheet
We currently only support writing to Clinical Documentation Flowsheets - Patient Entered Flowsheets include workflow constraints that are not feasible for how our programs operate. (Either they require a MyChart account limiting patient access/equity, or they require an order to be placed by the provider to create the flowsheet.) We recommend creating new flowsheet rows and naming them to make clear to any users that the data is patient-entered.
We can send flowsheet data using any of the following three mechanisms:
...
Mechanism
...
Content
...
Flowsheet row identifiers
...
Encounter
...
Receiving system
...
Requires VPN
...
HL7 over TCP
...
HL7 message (ORU^R01)
...
OBX-3 identifier
...
Can be created by interface
...
Interface engine or Bridges
...
Yes
...
HL7 over HTTPS
...
Interconnect
...
No
...
Observation.Create
...
JSON
...
flowsheet ID (FLO .1)
...
Must already exist, and encounter ID in w2h
HL7
More information on setting up HL7v2 over HTTPS can be found in the Galaxy document Incoming HL7v2 Over HTTP or HTTPS Using Interconnect.
Setup required:
New interface setup:
Interface Kind: Incoming Clinical Documentation Flowsheet Data [97]
No custom setting or custom executable codes used. All standard settings.
We have found success with having Bridges create a new encounter for each new data point received. That can be done by setting Bridges Profile variable VISIT_MATCH_USE_DATE_RANGE [80604] to 0 - Use visit ID only (default 1 - Use visit ID, then search by date range).
Sample message:
| Code Block | ||
|---|---|---|
| ||
MSH|^~\&|WAYTOHEALTH|WAYTOHEALTH|YOUR_HOSPITAL|EPIC|20230614112200||ORU^R01^ORU_R01|12234|T|2.6
PID|1||0123456^^^^MR|876876^^^^WAYTOHEALTH|Doe^Jane||19600101
PV1|1||DEPT_A|
OBR|1||148745|29274-8^VITAL SIGNS MEASUREMENTS^LN|||20230614112132||||||||||||||||||F
OBX|1|NM|SYSTOLIC^INTRAVASCULAR SYSTOLIC^||126|^mmHg|||||F|||20230614112132
OBX|2|NM|DIASTOLIC^INTRAVASCULAR DIASTOLIC^||71|^mmHg|||||F|||20230614112132 |
Identifiers
The identifiers in OBX-3-1 (
SYSTOLICanDIASTOLICin the sample message above) can be modified if needed to match other flowsheet rows in your system.The dept ID (
DEPT_Ain the sample message) is used by Bridges to determine which dept to create an encounter inWe send MRN, First Name, Last Name, and Date of Birth in the PID segment. These are used for identity verification by Bridges. PID 4 contains the patient’s Way to Health ID, which isn’t used by Bridges but can be helpful for troubleshooting.
Observation.Create
Flowsheet identifiers
We can use two types of identifiers for flowsheet rows - either the FHIR ID or the FLO .1 ID coupled with an OID specific to your health system. FHIR flowsheet IDs can be generated in the Interface Programmer Menu in Text. (d ^AI -> Support Utilities -> Web Service Utilities -> Generate Encoded Flowsheet IDs. If you don’t know the health-system specific OID for flowsheet rows, your Epic TS can help. Reference SLG 4392308.
Inbasket
Base requirements:
Webservices access (see “User and Security Setup” above)
Requires installing backend app
Project setup
We need Pool ID (
HIP.1)We typically send messages as Staff Message (message id type = 1). Sending messages into other folders requires more complex setup - consult your Epic TS for details on which message types can receive messages via API.
...
and features
Epic embed
The primary way clinical users interact with most W2H programs is through our EHR-embedded view from within a patient chart.
Accessing the Embed
It’s up to you and your health system to determine which menus the W2H link appears in. At Penn Medicine, it is available to all users from the “additional activities” menu or from the search, and some users modify their workspace (the “wrench” tool) to put the “Way to Health link” in their tab bar on every patient chart. At another EHR we’ve integrated with, they chose instead to make the embed available only from within specific patient management workflows. You can choose whichever approach works better for you.
...
Once clicked, the link opens a W2H tab in a sidebar of the patient chart.
...
The first time someone loads the embedded view they are prompted to create an account or link their existing W2H account if they have one. (Any given user will only see this screen once.)
...
Program list
Once the user has access to W2H, they will see all W2H programs linked to your EHR.
The Programs tab shows a list of any programs the patient is currently enrolled in, plus any other W2H programs you have chosen to deploy. Each program can be configured with either enterprise-wide access (any EHR user can enroll patients) or team-restricted access (EHR users must be granted explicit access to the program to enroll patients).
...
Requesting Access sends an email to any Project Managers set up for the project requesting approval. Once access is approved (or denied) the user is sent an email at an address they specify.
...
Enrolling patients
The Enroll button opens a screen gathering whatever information a program needs to enroll the patient. The set of information to be gathered could vary by program. In the simpler enrollments, it could just be phone number and language as shown. In other cases, additional details such as appointment time, clinician name or similar variables could be captured. (The need to enter these additional fields could be eliminated via the HL7 and other integration channel set up. )
All information is pre-populated from the patient’s demographics data retrieved from the EHR. (In this instance, the patient did not have a textable phone number, so the field was blank.)
...
Monitoring patients
Once a patient is enrolled, the embed shows several types of information for monitoring patients' involvement in the program.
The Inbox section shows all text messages (both manual and automated) between Way to Health and the patient, and allows staff to directly text the patient as well. In some programs, staff can temporarily pause system-generated responses so that the staff can respond directly without the bot getting in the way.
...
For programs collecting blood pressures or other structured data, the Data Snapshot can be a useful way of viewing the BP data at a glance.
...
For some programs where staff enter additional data during enrollment or the intervention, there are also Enrollment and Data Collection tabs that show up as appropriate.
Flowsheet
For programs collecting discrete data such as blood pressures, we can send that data back to the EHR to be filed in a flowsheet. The Implementation Guide and Epic Integration: Technical details for Epic analysts include details on what type of flowsheets we can send data to, and the technical approaches and requirements.
Automated enrollment
For some programs, the ideal enrollment workflow is for clinicians to manually enroll a patient in a W2H program. This enrollment step can include consenting the patient, educating them on e.g. how to take and send in their blood pressures, and so on. For other programs, automation is critical - no one can possibly manually enroll 5000 patients in an outreach programs. Sometimes, the right approach is a hybrid - enroll the patient manually while they’re in the hospital, and have the automation start the program as soon as they go home.
We have a variety of automation tools at our disposal, and will work with you to set up whatever makes most sense for your clinical workflows and IT resources.
File transfer
Often, the simplest way to automate enrollment is with a daily transfer of a flat (CSV) file. Your IT teams will need to set up something to automatically generate this file and transfer it to a location where we can pick it up and process it.
HL7 ADT feed
The ADT (Admission, Discharge, Transfer) feed can be used to trigger initiation of a post-acute program after a patient is discharged.
HL7 scheduling feed (OpTime or Cadence)
The HL7 appointment scheduling feed can be used to trigger pre-appointment or post-appointment patient messaging
The HL7 surgical case scheduling feed can be used to trigger pre-procedure or post-procedure patient messaging, and can be used (together with the ADT feed) to trigger programs after discharge from a surgical hospitalization.
Silencing messaging during admissions
For long-term (chronic) programs, patients might receive months of messaging checking up on them, asking them to report pain scores or blood pressures, and so on. Sending these messages while a patient is readmitted makes no sense. The HL7 ADT feed can be used to inform W2H when a patient enters and leaves the hospital, and W2H can silence messaging during that time period. (Messages during that time period will be skipped - if those missed days are critical, the patient can be reenrolled in a program upon discharge rather than simply resuming.)
In Basket
Our primary recommended way of sending escalations is via In Basket message to a pool. While Epic supports sending In Basket messages to individuals or to pools, in our experience sending messages to a pool of users provides better provider experience and is better for patient safety. Some of our clinical teams will choose to use existing pools they use for communicating amongst themselves; others will create new pools specific to W2H programs.
Most W2H programs send messages using the Staff Message message type - this requires no additional EHR build. We can also send messages using a custom message type. The Implementation Guide contains instructions for setting that up if desired.
...
We can also send escalations to pagers, cell phones, or by email. (We do not include patient identifiers in escalation messages to pagers or cell phones unless an exception is approved by your privacy office.)
Escalations can also be monitored or managed in W2H’s Triage View.
SDEs
SmartDataElements can be a useful way to capture patient-level info in the EHR. They can be pulled into RWB reports, used to show flags at various places in the chart (e.g. the story board), used in analytics, and more. Unlike flowsheets (discussed above) which represent longitudinal data collected across various points in time and graphed to view trends, SDEs are patient-level variables which only make the current (i.e. latest) value available.
Out of the box, we can update an Epic SDE with a value showing the patient’s status in a W2H program. (The values we send are customizable - for example, we could send Pending when their enrollment is started, Active when they start receiving daily messages, and Finished when the program ends.
Additionally, we can set up custom automation to send other SDE values. For example, we have some programs where we send structured data into SDEs which are used to prepopulate a note.
Smart Forms and Smart Phrases
Some of our health system customers use Smart Forms to drive some of the enrollment or tracking process. Some programs have set up Smart Phrases to pull flowsheet data sent from Way to Health W2H into clinical notes. If you’re interested in using these tools, we can connect you with the IT staff or physician builders who set these up.
Implementation process
Build and testing for a connected health program
Your W2H Implementation Lead will work with you to gather requirements, build, and test a new connected health program. For multi-site programs (e.g. a program launching at Penn followed by other locations), the program typically will be tested at the first site and will require much less testing at the subsequent sites (mostly covering any site-specific tweaks that may have been made).
Testing for Epic integration
We will provide a test script for each Epic integration feature described above (embed, flowsheet, SDE, etc.). For the embed and In-Basket, the test script only needs to be run once for W2H. Flowsheet and SDE test scripts may differ slightly for each program.
These test scripts can also be used as part of testing for Epic upgrades when warranted (primarily when Nova release notes indicate that things are changing in the affected areas).
Support, program changes, and shutdown
During the EHR setup process as well as during the setup of any connected health programs, there will be an assigned technical and project management point person.
Once a program is live, any issues or program changes (including shutdown requests) should be submitted through our help desk located at http://support.waytohealth.org .