Implementation guide - embed only

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.

Our full covers all of our integration features. This document is a shorter version, including only the information needed to set up the Way to Health embedded view.



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

Use Cases, features, and required setup

Our app listings specify the broadest set of APIs and interfaces we use, but each connected health program will only use a subset. Our full contains a table summarizing all of our integration features are available to support workflow needs, and the setup required. Since this document focuses on the Epic Embed only, only that feature is shown.

Use Case


Required Setup

Use Case


Required Setup

Enrolling patients

Monitoring patients (data, messaging, and more)


  • 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


Implementation process

Build and testing for a connected health program


Setup and testing for Epic integration


Information to send to Way to Health

(reference: Send Specific Information to Your App Vendor)





Patient ID Type

MRN, HUP MRN, MR, etc.

Interconnect Base URLs

  • Prod OAuth

  • Non-prod OAuth

Network configuration

If needed to access Interconnect


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

Once we can access Interconnect, we have tools that can extract this PEM file

Program changes and shutdown

Once a program is live, all program changes (including shutdown requests) should be submitted through our help desk located at

Setup Notes: 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:

Reference: Configure the Integration Record for SMART on FHIR

Client ID





Integration type


Authentication Method


Launch URL



Launch Context








%EPTID;;; ; ;nnnn;NONE;%

Instead of nnnn, use the ID type that w2h will use. See the launch token library for details.



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