Interoperability, Supported Messaging Standards, and Integration: Connecting Clinical Systems with the UNITY Platform

Introduction

This document outlines the technical architecture and integration pathways for UNITY’s two core approaches: FHIR-based integration via a cloud-hosted FHIR server leveraging subscription-based event notifications and HL7v2-based integration using UNITY On Site Connector, an on-premises transformation gateway that maps HL7v2 messages to FHIR resources.

Integration Mechnanisms

The UNITY platform enables fully automated clinical data acquisition and distribution of PROMs, PREMs, and custom forms by integrating with clinical systems via modern clinical messaging formats.

Integration with your clinical IT landscape is possible through two primary methods based on modern interoperability standards:

HL7 Fast Healthcare Interoperability Resources (FHIR): Plug-and-play integration via UNITY Cloud Connect, a cloud-based FHIR server, with standards-compliant FHIR API for seamless data exchange.
HL7-based systems: A powerful messaging transformation service, UNITY Site Connect, converts HL7v2 messages into structured FHIR resources, enabling interoperability between the UNITY platform and the legacy messaging format.

Below, we will describe the integration process of the UNITY platform with FHIR- and HL7-based clinical information systems in greater detail.

Subscription-based FHIR integration

Integration of the UNITY platform with FHIR-based clinical systems occurs via UNITY Cloud Connect, a cloud-based FHIR server, using a robust subscription mechanism.

FHIR subscriptions allow the UNITY platform to subscribe and react to specific events or changes to resources on the hospital’s FHIR server.

Key Integration Scenarios & FHIR Resources

UNITY Cloud Connect leverages the well-established FHIR resources Appointment, Encounter, and Patient as the backbone for integration with real-time clinical workflows. However, deeper integration with additional FHIR resources is also possible, enabling advanced customization, granular event triggers, and tailored patient engagement.

FHIR Resource	Inferred FHIR Field(s)	Subscription	Workflow Trigger	Example Use Case
`Appointment`	ID: Appointment Appointment Last Update Date/Time Filler Appointment ID: Client specific Filler Status Code: Client specific	UNITY Cloud Connect subscribes to `Appointment` resource updates (e.g., `Appointment.status=booked` or `Appointment.start` time within a threshold).	When a new appointment is scheduled (e.g., surgery, clinic visit), the FHIR server notifies UNITY in real time.	A patient books a knee replacement surgery → UNITY sends a pre-op PROMIS Pain Questionnaire 2 weeks prior and a recovery progress survey 6 weeks post-op.
`Encounter`	Patient Visit: Appointment Admission Type Visit Number Assigned Patient Location Ambulatory Status	UNITY monitors `Encounter` resources for status changes (e.g., `Encounter.status=discharged`).	Upon discharge, the FHIR server alerts UNITY, which evaluates the encounter type (e.g., inpatient, emergency visit).	A heart failure patient is discharged → UNITY sends a KCCQ-12 (heart failure-specific PROM) at 7 and 30 days post-discharge to monitor recovery.
`Patient`	Date of Birth Primary Language County Code Nationality Sex Patient ID (Internal ID) Patient ID (External ID) Patient Death Date and Time	UNITY leverages the FHIR `Patient`resource for cross-system patient identity management (using both internal and external identifiers) and personalized communication (via telecom and language preferences) to enable targeted, patient-centric workflows.		UNITY would store/use the FHIR `Patient.id` as its internal system identifier (e.g., `Patient/1234`) to track patients within UNITY-specific workflows (e.g., questionnaire responses, analytics). This ensures stable references even if external IDs change.
`Procedure`	Procedure Code - Identifier Procedure Code - Text	UNITY subscribes to Procedure resource updates (e.g., when a new surgical or interventional procedure is recorded).	When a procedure is documented (e.g., completed status, specific CPT or SNOMED code), the FHIR server notifies UNITY.	A patient undergoes coronary artery bypass surgery → UNITY sends recovery tracking surveys at 1 week, 1 month, and 3 months to monitor functional outcomes and complications.

Data Flow Overview

The typical flow of clinical information between your clinical system (e.g., Electronic Health Record or scheduling software) and the UNITY platform in the FHIR-based subscription model occurs as follows:

Event Trigger: A clinical event (e.g., appointment booking, discharge) is recorded in the hospital’s FHIR server (e.g., as an Appointment or Encounter resource).
Subscription Notification: UNITY Cloud Connect (a cloud-based FHIR intermediary) subscribes to relevant FHIR resources (e.g., Patient, Appointment). When a subscribed event occurs, the FHIR server sends a real-time notification to UNITY Cloud Connect.
Bidirectional Message Queue Processing: Notifications are routed through a bidirectional buffered message queue to ensure no data loss during transmission delays or outages. The queue decouples the hospital’s FHIR server from UNITY, allowing asynchronous processing.
Questionnaire Distribution: After the message is dequeued, UNITY evaluates the event against distribution rules (e.g., "send PROM 3 months post-op"). Questionnaires are dispatched to patients or clinicians via an EHR Questionnaire Launch Window, email, SMS, or patient portals.

HL7v2-Based Integration via UNITY Site Connect

To integrate the UNITY platform with HL7v2/v3 or CDA-based clinical systems, hospitals deploy UNITY Site Connect—an on-premises integration server that transforms legacy HL7 messages into FHIR-compatible resources. This ensures interoperability with UNITY’s cloud platform while maintaining data sovereignty and compliance.

The integration follows the same core principle as our FHIR implementation: real-time event triggers automate questionnaire distribution based on clinical data. The key difference is the transformation layer:

For FHIR systems, UNITY Cloud Connect subscribes directly to FHIR resources
For HL7v2 systems, UNITY Site Connect (an on-premises VM) transforms messages to FHIR first

HL7v2 to FHIR transformation and message processing

UNITY Site Connect performs messaging transformation to convert HL7v2 messages to and from a FHIR-compatible format to facilitate communication of the UNITY platform with relevant clinical systems. The HL7v2 to FHIR transformation process involves mapping HL7v2 message segments (such as PID) to their equivalent FHIR resources (like Patient, Observation, and Order), ensuring that the data is correctly parsed, restructured, and converted.

On-Premises Deployment

UNITY Site Connect is installed within the hospital’s secure network, acting as a gateway between HL7-based systems (EHRs, schedulers) and the cloud-based UNITY platform. It operates as a lightweight service (e.g., Docker container or VM) to minimize infrastructure overhead and facilitate rapid deployment of the UNITY platform as part of your routine clinical workflows.

Message Processing Pipeline
The Gateway service in UNITY Site Connect receives HL7v2 messages from systems such as EHRs and scheduling software. Messages are validated for HL7v2 compliance and logged for traceability.

HL7 Message Reception: The Gateway service Receives HL7v2/v3 or CDA messages (e.g., ADT^A01 for admissions, SIU^S12 for scheduling) from hospital systems via MLLP (Min Lower Layer Protocol) or API.
Validation & Logging: Validates message structure for HL7 compliance and logs it for auditability (e.g., in a local database or SIEM system).
PID Handling: If required, Patient Identifiable Data (PID) are stripped and remain within the PID server, ensuring sensitive data remains within the hospital’s networks. Retains internal patient IDs (e.g., MRN) for linkage without exposing raw PID to the cloud.
HL7-to-FHIR Transformation: Maps HL7 segments to FHIR resources (e.g., PID → FHIR Patient, OBX → Observation) using customizable templates.
Buffered Transmission: Transforms messages are sent to a cloud-based message queue for asynchronous, fault-tolerant delivery to the UNITY platform.

Message Types and Segments: Detailed specifications

UNITY Site Connect (Virtual Machine 1) receives and processes incoming HL7v2 messages from hospital systems, converting them into FHIR resources.

The table below outlines the essential requirements for enabling general HL7v2 message transmission to UNITY Platform.

For a comprehensive description of the HL7v2 to FHIR mapping process, including specific segment-to-resource transformations and implementation details, please refer to the provided documentation or contact your RAYLYTIC customer service representative for further assistance.

Key Personal-Identifying Data (PID) Security Considerations

If required for privacy, the PID server (see graphic) can be configured to strip direct identifiers (e.g., name, address) from notifications, replacing them with pseudonymized tokens before transferring the message to the UNITY Platform.

The true PID remains solely within the hospital’s secure environment, while the UNITY platform processes only de-identified, pseudonymized data.