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.
...
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 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.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.
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 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. In this document we’ll try to specify which features, which setup, and which apps are required for specific types of connected health programs.
Use Case | 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 |
| ||
Inbound HL7 flowsheet feed | 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 |
|
Information to send to Way to Health
...
When do we need this? | Example | ||||
|---|---|---|---|---|---|
Patient ID Type | Always | “MRN” | |||
Interconnect Base URLs
| EmbedAlways |
| Backend App (flowsheet, inbasket) |
| |
Backend user EMP
| Backend App (flowsheet, inbasket) |
| |||
Inbasket pool
| Each Inbasket where we’ll send escalations |
| |||
Flowsheet information FLT .1 | For each data point (e.g. systolic BP) that we’ll send via WebServices or HL7 | Either
OR
| |||
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 Interconnect’s TLS certificates that are self-signed or signed issued by a private CA not in Mozilla’s trust store | PEM file such as |
Implementation process
Program changes and shutdown
All program changes (including shutdown requests) should be submitted through our help desk located at http://support.waytohealth.org
Epic embed
Desktop Integration
...
Client ID | Prod: |
|
|---|---|---|
Non-prod: |
| |
Integration type | SMART on FHIR | |
Authentication Method | SMART on FHIR | |
Launch URL | Prod: |
|
Non-prod: |
| |
Launch Context |
|
|
|
| |
|
| |
|
Instead of | |
|
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 | |
|
| |
...
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: |
|
Non-prod: |
| |
CRYPTALGO | AES128 | |
CRYPTIVLENGTH | 0 | |
Launch Context |
|
|
|
| |
|
| |
|
Instead of | |
|
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 | |
|
| |
Flowsheet
There are a few different options for sending flowsheets, with pros and cons to each.
...
Method
...
Cons
...
Pros
...
Status
...
AddFlowsheetValue
...
Private API - requires Epic approval to use outside Penn
Requires CSN for open encounter
...
Already in use with working code
...
In use currently
...
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
...
Observation.Create (using patient access token)
...
Requires MyChart auth flowShows 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
...
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
...
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.
...
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
...
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.
...
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 XXXXXXWe 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:
...
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