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
The Way to Health platform powers a diverse range of programs with different workflows and integration needs. Our app listings specify the broadest set of APIs and interfaces we use, but each connected health program will only use a subset. In this document we’ll try to specify which features, which setup, and which apps are required for specific types of connected health programs.
Much of this setup is applicable to all Way to Health programs - once the Embed is set up for one program, no additional IT setup is required to launch a second (or third, or thirty-third) program. If a future program requires an additional integration point (such as an outbound ADT feed), subsequent programs will be able to use that with no additional IT setup. The only exception is flowsheet rows and inbasket pools, which typically are set up per-program or at least per-care team or per type of data.
Your 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 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.
...
Use Case
...
...
Setup
...
Enrolling patients
Messaging them manually
Viewing data
...
Embed
...
Webservices access (via OAuth)
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 flowsheets
...
Flowsheet - via webservices
...
Webservices access (via Backend user)
Flowsheet FLO, FLT (Details below)
“Way to Health - Backend” client ID
...
Inbound HL7 flowsheet feed
...
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 programs post-discharge
Silencing programs during admissions
...
Outbound HL7 ADT feed
...
Triggering pre-procedure programs
...
Outbound HL7 Optime Scheduling feed
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
...
Embed
...
https://vendorservices.epic.com/interconnect-amcurprd-oauth/
...
Interconnect Base URLs
Prod Basic Auth
Non-prod Basic Auth
...
Backend App (flowsheet, inbasket)
...
https://vendorservices.epic.com/interconnect-amcurprd-username/
...
Backend user EMP
Username
Password
...
Backend App (flowsheet, inbasket)
...
waytohealthuser / 15 char random string
...
Inbasket pool
Pool ID (HIP .1)
...
Each Inbasket where we’ll send escalations
...
14234
...
Flowsheet information
FLT .1
FLO .1
...
For each data point (e.g. systolic BP) that we’ll send via WebServices
...
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 uses TLS certificates that are self-signed or signed by a CA not in Mozilla’s trust store
...
PEM file such as yourhospital_root_ca.pem
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
...
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 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
...
Launch URL
...
https://app.waytohealth.org/epic/embed?encrypted=%CRYPTSTR%
...
parameters
...
EPICUSERID=%SYSLOGIN%PATID=%xxxx%USERFNAME=%xxxx%USERLNAME=%xxxx%
...
Method
...
AES
...
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
via WebServices
Sending data to flowsheets is part of the Premium Epic Integration package. It requires installing the Way to Health - Backend app from Connection Hub, and incurs an additional cost
We need the following information:
For each data point (e.g. systolic blood pressure), we need the flowsheet ID and flowsheet template ID. These correspond to the
You should name the flowsheet rows to be clear that this
via HL7
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.
Other optional setup
Smart forms?
Used at LGH. probably don’t want to recommend to the general public
Smart phrases?
Program changes and shutdown
...
once, use for multiple programs
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 In Basket messaging, which are typically configured for a specific program or care team and therefore require program-specific customization.
Use Cases 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 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 .