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.
This document is intended as a high-level overview of Way to Health’s Epic integration features, aimed at clinical or IT decision makers. Epic’s Third-Party App Setup and Support Guide on Galaxy also has
For technical audiences we can provide a more detailed Implementation Guide on request.
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 and features
Epic embed: Enrolling and monitoring patients
<Screenshot: opening embed from More Link.> It’s up to you and your Epic analysts to figure out which menus it belongs in.
<Screenshot: list of programs - HSM sandbox, one other>
<Screenshot: enroll modal>
<Screenshot: inbox>
<Screenshot: BP snapshot>
Flowsheet
<Description. >
<Screenshot from a pt chart>
Automated enrollment
<File transfer - we can work with you to do daily CSV file transfer>
In Basket
<Our primary recommended way of sending escalations is via Inbasket to a pool>
<Screenshot of an inbasket message>
SDEs
<Available out of the box: program status>
<Also available: other SDE writes at various points in the intervention>
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 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 Way to Health Implementation Lead will work with you to gather requirements, build, and test a new connected health program. For multisite 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).
Setup and testing for Epic integration
<We’ll give you a test script for each feature>
Program changes and shutdown
<There will be an assigned technical and project management point person. In addition, …>
Once a program is live, all program changes (including shutdown requests) should be submitted through our help desk located at http://support.waytohealth.org
Technical details
Further details are included in the Implementation Guide, available on request.
Required setup for integration features
Use Cases | Feature | Required Setup |
---|---|---|
Enrolling patients Monitoring patients (data, messaging, and more) | Embed |
|
Sending patient-entered data to the medical record via flowsheets (Requires only one of these 3 approaches) | Inbound HL7 flowsheet via TCP/IP |
|
Inbound HL7 flowsheet over HTTPS |
| |
Flowsheet - via Observation.Create |
| |
SDE | ||
Alerting clinicians or care teams of patients needing attention | InBasket |
|
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 |
|
Different approaches for Flowsheet
There are several mechanisms we can use to file flowsheet data. Which approach we use is largely dictated by your health system’s preferences or resource constraints.
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
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 (
SYSTOLIC
anDIASTOLIC
in the sample message above) can be modified if needed to match other flowsheet rows in your system.The dept ID (
DEPT_A
in 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.