Different approaches for Flowsheet

There are several mechanisms we can use to file flowsheet data.

HL7 over HTTPS is strongly preferred as it reduces operational complexity, reduces clinician effort, and can avoid the need for a site-to-site VPN.

Mechanism	Content	Flowsheet row identifiers	Encounter	Receiving system	Requires VPN

Mechanism	Content	Flowsheet row identifiers	Encounter	Receiving system	Requires VPN
HL7 over HTTPS	HL7 message (`ORU^R01`)	`OBX-3` identifier	Can be created by interface	Interconnect	No
HL7 over TCP	HL7 message (`ORU^R01`)	`OBX-3` identifier	Can be created by interface	Bridges	Yes
`AddFlowsheetValue`	JSON	flowsheet ID (`FLO .1`) flowsheet template ID (`FLT .1`)	Must already exist, and encounter ID in w2h	Interconnect	No
`Observation.Create`	JSON	flowsheet ID (`FLO .1`)	Must already exist, and encounter ID in w2h	Interconnect	No

HL7 (Inbound Flowsheet)

This is our preferred approach for clinical workflow reasons, as the interface can create encounters for the flowsheet data to file to. The other approaches involve workflow challenges as someone needs to create encounters and get the CSNs into Way to Health.

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.
If the interface is operating over HTTPS:
- The Way to Health - Backend app must be installed, which gives
If the interface is operating over TCP:

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 an DIASTOLIC 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 in
We 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.

AddFlowsheetValue

Epic’s AddFlowsheetValue endpoint is the simplest for us to use, though it incurs additional cost. Details on what FLO/FLT values we need are in the implementation guide.