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.

Updates, Maintainance and Issue Reporting

Release notes

Each software update affecting the UNITY platform or UNITY On Site Connector integration server will include comprehensive release notes, which serve to inform clients and stakeholders about changes, enhancements, and necessary actions. The release notes will be structured as follows:

Version Identification:
- The release notes will include a unique version number to identify each update (e.g., Version 2.1.0). This number helps track the history of changes and allows for easy reference.
Summary of Changes:
- A high-level overview of the key updates, including new features, improvements, bug fixes, and any changes to existing functionality. This section will provide a quick snapshot of what has been updated or added in the release.
Client Information and Recommended Actions:
- A section dedicated to explaining how the update impacts clients with a list of clear, actionable steps to follow after the update.

Testing of UNITY On Site Connector & UNITY Cloud Connector

Before any update is deployed to production, UNITY On Site Connector & UNITY Cloud Connector undergoes rigorous pre-release testing to ensure seamless functionality, backward compatibility, and minimal disruption to client operations.

Pre-Release Testing Procedure

The testing process includes the following key phases:

Unit & Integration Testing

Code-Level Validation: Individual components are tested in isolation to verify correct behavior.
API & Endpoint Checks: All integration endpoints (REST, SOAP, etc.) are validated for request/response accuracy, error handling, and performance.
Third-Party Service Compatibility: Ensures compatibility with connected external systems (e.g., databases, APIs, middleware).

Regression Testing

Automated and manual tests confirm that existing functionalities remain unaffected by the new update.
Critical workflows (e.g., data synchronization, authentication, logging) are revalidated.

End-to-End (E2E) Scenario Testing

Simulates real-world client workflows to validate:
- Data integrity across integrations.
- Error recovery and rollback mechanisms.
- Performance under expected load.

Security & Compliance Testing

Audit Logs & Compliance: Ensures logging meets regulatory standards (e.g., GDPR, HIPAA if applicable).

Client-Specific Validation (UAT)

Staging Environment Deployment: Clients may opt to test pre-release versions in a sandbox environment.
Feedback Integration: Client-reported issues are prioritized for fixes before production rollout.

Rollback & Disaster Recovery Testing

Validates the ability to revert to the previous version if critical failures occur post-deployment.

Final Sign-Off

Internal QA, DevOps, and security teams approve the release.
Release notes are finalized to reflect tested changes, known issues, and client actions.

Post-Testing Steps

Release Notes Drafting: Documentation of all changes, fixes, and client-impacting updates.
Client Communication: Notifies stakeholders of upgrade schedules, expected downtime, and action items.

This structured approach minimizes risks and ensures UNITY On Site Connector remains stable, secure, and aligned with client needs.

Issue Reporting and Client Feedback

We value client feedback as an essential part of ensuring the UNITY On Site Connector integration server meets your needs and continues to improve. To facilitate the collection of feedback and the reporting of any post-update issues, we provide the following structured process:

Reporting Post-Update Issues

In the event of any issues encountered after applying an update, please follow these steps to report the issue:

Issue Tracking System: Access the https://raylytic.atlassian.net/servicedesk/customer/portal/1/group/1/create/6 page to log and track your issue. Please provide detailed information such as error messages, screenshots, and logs, so we can best identify and resolve the issue.

Submitting Feedback

Clients are encouraged to share feedback on new features, updates, and overall performance. You can submit your feedback through the following feedback portal: https://raylytic.atlassian.net/servicedesk/customer/portal/1/group/1/create/7

Client feedback is carefully reviewed and plays a significant role in shaping future updates. Key insights from reported issues, suggestions for new features, and overall satisfaction are all considered during the development and planning of subsequent releases.

We are committed to continuously improving the UNITY platform and UNITY On Site Connector integration server, and your input ensures that we focus on the areas most important to you.