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

Introduction

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

Integration Mechnanisms

The 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 a cloud-based FHIR server with standards-compliant FHIR API for seamless data exchange.
HL7-based systems: A powerful messaging transformation service converts HL7v2 messages into structured FHIR resources, enabling interoperability between the platform and the legacy messaging format.

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

Subscription-based FHIR integration

Integration of RAYLYTIC platform with FHIR-based clinical systems occurs via a cloud-based FHIR server using a robust subscription mechanism.

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

Key Integration Scenarios & FHIR Resources

The integration platform 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	`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 the platform in real time.	A patient books a knee replacement surgery → The platform 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	The RAYLYTIC Platform monitors `Encounter` resources for status changes (e.g., `Encounter.status=discharged`).	Upon discharge, the FHIR server alerts The RAYLYTIC Platform, which evaluates the encounter type (e.g., inpatient, emergency visit).	A heart failure patient is discharged → The RAYLYTIC Platform 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	The RAYLYTIC Platform 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.		The RAYLYTIC Platform would store/use the FHIR `Patient.id` as its internal system identifier (e.g., `Patient/1234`) to track patients within platform-specific workflows (e.g., questionnaire responses, analytics). This ensures stable references even if external IDs change.
`Procedure`	Procedure Code - Identifier Procedure Code - Text	The RAYLYTIC Platform 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 The RAYLYTIC Platform.	A patient undergoes coronary artery bypass surgery → The RAYLYTIC Platform 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 RAYLYTIC Platform 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: The platform subscribes to relevant FHIR resources (e.g., Patient, Appointment). When a subscribed event occurs, the FHIR server sends a real-time notification to The RAYLYTIC Platform on-site integration component.
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 the RAYLYTIC Platform, allowing asynchronous processing.
Questionnaire Distribution: After the message is dequeued, the RAYLYTIC Platform 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

To integrate the RAYLYTIC Platform platform with HL7v2/v3 or CDA-based clinical systems, hospitals deploy the RAYLYTIC Platform Site Connect—an on-premises integration server that transforms legacy HL7 messages into FHIR-compatible resources. This ensures interoperability with the RAYLYTIC Platform’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, the RAYLYTIC Platform subscribes directly to FHIR resources
For HL7v2 systems, the RAYLYTIC Platform Site Connect (an on-premises VM) transforms messages to FHIR first

HL7v2 to FHIR transformation and message processing

the RAYLYTIC Platform Site Connect performs messaging transformation to convert HL7v2 messages to and from a FHIR-compatible format to facilitate communication of the RAYLYTIC Platform 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

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

Message Processing Pipeline
The Gateway service in the RAYLYTIC Platform 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 RAYLYTIC Platform platform.

Message Types and Segments: Detailed specifications

the RAYLYTIC Platform 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 the RAYLYTIC Platform 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 RAYLYTIC Platform Platform.

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

Updates, Maintainance and Issue Reporting

Release notes

Each software update affecting the RAYLYTIC Platform platform or the RAYLYTIC Platform 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

Before any update is deployed to production, the RAYLYTIC Platform on-site integration server 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 the RAYLYTIC Platform 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 RAYLYTIC Platform 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 RAYLYTIC Platform platform and the RAYLYTIC Platform On Site Connector integration server, and your input ensures that we focus on the areas most important to you.