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.

Overview

Way to Health 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.

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

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.

Way to Health’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 messaging, which are typically configured for a specific program or care team and therefore require program-specific customization.

Your Way to Health 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 Cases, Features, and Required Setup

Use Case	Feature	Required Setup
Enrolling patients Monitoring patients (data, messaging, and more)	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 the medical record via 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 text outreach programs post-discharge Turning participant messaging on and off during readmissions	Outbound HL7 ADT feed
Triggering text outreaches prior to a procedure	Outbound HL7 Optime Scheduling feed
Triggering text outreaches prior to an appointment	Outbound HL7 Cadence 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

reference: Configure the Integration Record for SMART on FHIR

Client ID	Prod:	`3aa086b8-6dfb-4143-9100-b8e003ebe2a2`
Client ID	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`
Launch URL	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

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%`
CRYPTURL	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

There are a few different options for sending flowsheets, with pros and cons to each.

	Method	Cons	Pros	Status
1	AddFlowsheetValue	Private API - requires Epic approval to use outside Penn Requires CSN for open encounter	Already in use with working code	In use currently
2	Observation.Create (as backend user)	Requires CSN for open encounter FHIR incurs cost for health system	Largely parallel to AddFlowsheetValue - should be a straightforward swap	Can consider switching
3	Observation.Create (using patient access token)	Requires MyChart auth flow Shows up in MyChart, can be modified by patient Needs an order to create the PEF FHIR incurs cost for health system	Shows up in MyChart, can be modified by patient	Non-starter
4	HL7 clinical flowsheet	Epic’s strong recommendation is to use patient-entered data structures instead. We and our customers should be aware of the differences in how the data would be stored and displayed and how that might affect end-user training to understand this as patient-sourced data. At Penn Medicine we use a separate flowsheet named to indicate that the data comes from w2h.	Can create encounters on the fly	In use at LGH, in progress at UPHS
5	HL7 Incoming Clinical Documentation Flowsheet Data – Patient Entered writes to Device-Entered flowsheets	Needs an order to create the episode and patient-entered flowsheet (and set parameters e.g. alert thresholds)	No MyChart account required Viewable in MyChart but not modifiable	The order is a significant obstacle - some clinical programs may be OK with that, but so far we haven’t gotten traction with this.
6	HL7 Incoming Clinical Documentation Flowsheet Data Interface writes to Clinical Flowsheets	Only allowed for FDA devices with no ability for patient to modify data Requires setup by customer to create encounters	No MyChart account required No order required	Not allowed since patients can modify data
7	HL7 over TCP/IP (for any of the 3 options above)	Requires VPN to outside sites		At Penn we don’t need a VPN, and any HL7 messages can go direct to Ensemble. We are requesting HL7v2 over HTTPS for outside health systems in case the HL7 methods above make sense there.
8	HL7 over HTTPS (for any of the 3 options above)	Requires Architectural Review Board locally Possibly requires net-new interface ($$)

via HL7

Mechanism can be either actual HL7 feed (in which case we need VPN) or HL7v2 interconnect (link to Galaxy doc for details)

Type of flowsheet can be:

via WebServices

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 XXXXXX

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

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 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.

Program changes and shutdown

All program changes (including shutdown requests) should be submitted through our help desk located at support.waytohealth.org

Implementation guide