RTI MedTech Reference Architecture

The Medical Reference Architecture demonstrates RTI's best practices for building medical devices using RTI Connext®.

This repository contains documentation and module demo applications showcasing different capabilities of Connext in a Medical context. The goal is to provide a comprehensive guide to help developers leverage Connext for building robust, scalable, and interoperable medical systems.

Introduction

RTI Connext is a leading connectivity framework designed to facilitate real-time data distribution in distributed systems. In the medical field, it is crucial to have reliable and timely data exchange between various medical devices and systems. This project aims to illustrate how Connext can be used to build a robust Medical Reference Architecture that ensures data interoperability, scalability, and reliability.

By following the examples and best practices outlined in this documentation, architects and developers can find inspiration to create medical applications.

Here are some links that compliment this repository:

Quick Start

The steps below cover environment setup, dependencies, security artifacts, and building the project. To run anything, follow the module-specific README for the scenario you want to explore.

1. Prerequisites

You will need:

RTI Connext DDS 7.3 installed and NDDSHOME set, including the Python API .whl. See the Installation Guide and Python API setup.

If NDDSHOME is not already in your environment, source the platform setup script from your Connext installation: source <connext_dir>/resource/scripts/rtisetenv_<arch>.bash (Linux/macOS) or rtisetenv_<arch>.bat (Windows). This script sets NDDSHOME, CONNEXTDDS_ARCH, and related library paths required by both build.py and launch.py.
CMake ≥ 3.17 and a C++ compiler toolchain.
Python ≥ 3.9.

Install the system build dependencies for your platform:

Linux (Debian/Ubuntu)

sudo apt install \
    build-essential \
    cmake \
    pkg-config \
    libgtkmm-3.0-dev \
    python3-venv

python3-venv is required on Debian/Ubuntu to create virtual environments (python3 -m venv). It is a split package not included with the base python3 install.

macOS

xcode-select --install          # compiler toolchain (if not already installed)
brew install cmake pkg-config gtkmm3 python3

Homebrew's python3 includes pip and venv — no separate installs needed.

2. Clone the Repository

git clone https://github.com/rticommunity/rticonnextdds-medtech-reference-architecture.git
cd rticonnextdds-medtech-reference-architecture

3. Set Up a Python Virtual Environment

python3 -m venv .venv
source .venv/bin/activate          # Windows: .venv\Scripts\activate
pip install -r requirements.txt

# Install the RTI Connext Python API from your local Connext installation:
pip install rti.connext.activated -f $NDDSHOME/resource/python_api
# Alternatively, if the above path is not available, install from PyPI:
# pip install rti.connext==7.3.0

4. Build the C++ Modules

Build all modules:

python3 build.py

To build only the modules you intend to run:

python3 build.py --target module-01   # all C++ targets in Module 01
python3 build.py --target ArmController  # only the ArmController target

The compiled binaries are placed under build/<CONNEXTDDS_ARCH>/.

5. Generate Security Artifacts (optional — skip if not using `-s`)

The security flag (-s) requires PKI certificates, signed governance/permissions XML, and a WAN PSK seed file. Generate them once:

python3 system_arch/security/setup_security.py

Re-run with --force to regenerate existing artifacts. See the Security README for full details.

When setup is complete, use the module-specific READMEs below to choose a workflow. They explain what each demo launches and how to run it from the repository root with the project-level launch.py script.

Hands-On: Modules

The RTI MedTech Reference Architecture demonstrates use cases and capabilities of the provided system architecture.

Use the module-specific READMEs when you want to run a demo. They describe what each workflow launches, why it exists, and the exact launch.py commands to use from the repository root.

Module 01 : Digital Operating Room
Module 02 : RTI Recording Service & RTI Replay Service
Module 03 : Remote Teleoperation with RTI Real-Time WAN Transport
Module 04 : Security Threat Demonstration

Hands-On: Architecture

RTI System Designer allows you to graphically design, configure, examine, and share Connext system architectures.

RTI recommends using the provided RTI System Designer project file (RefArch.rtisdproj) to follow along with the next section, Architecture Overview.

Launch RTI System Designer.
- From RTI Launcher:
  1. Open RTI Launcher.
  2. Navigate to the Tools tab.
  3. Click the System Designer button.
- From a terminal:
  1. Launch the rtisystemdesigner[.bat] script found in the $NDDSHOME/bin folder. Where $NDDSHOME is the folder where Connext is installed.
Open the Project File.
1. Select Projects in the toolbar.
2. Click Open in the dropdown.
3. In the file browser popup, navigate to system_arch/RefArch.rtisdproj and open.

Please refer to Project Management documentation for more detailed instructions on working with RTI System Designer projects.

Architecture Overview

The Medical Reference Architecture is designed to support various use cases within the medical domain. This reference architecture ensures that data flows seamlessly from devices to applications, enabling real-time monitoring, decision-making, and reporting.

The RTI MedTech Reference Architecture consists of the following key components:

Data Types
Quality of Service (QoS)
Domains & Topics
DomainParticipants & DDS Entities
DDS Security

Through RTI XML-Based Application Creation, aspects of all 4 components are expressed in XML statically, separate from application code and choice of language. This allows for the extraction of a common system definition from the application logic and behavior - a must-have for designing integrated systems with multiple development teams.

Please find a diagram of the Digital OR module module below:

Data Types

DDS is a data-centric communication standard that understands user-defined Data Types. You can define a Data Type, its members, and annotations in IDL, XML, or XSD. Conversion between file formats and type-support code generation for (de)serialization can be done with RTI Code Generator.

This reference architecture defines the following Data Types in Types.xml:

Data Type	Intended Use
DeviceStatus	Describes a status (e.g. `ON`, `PAUSED`) for a unique device
DeviceHeartbeat	Asserts that a unique device is alive
MotorControl	Commands the direction of motion for an arm motor (e.g. `SHOULDER`, `ELBOW`)
DeviceCommand	Commands initiating a status (e.g. `START`, `SHUTDOWN`) to a unique device
Vitals	Describes data representative of a unique patient's collected vital signs

Quality of Service (QoS)

Quality of Service (QoS) in DDS characterizes a system's infrastructure and data flow. In a QoS Profile, you can define a set of QoS policy values for a DDS entity (e.g. DomainParticipant, DataWriter, DataReader).

The hierarchy of components configured in a QoS Profile are as follows:

QoS Profile
├── DomainParticipant QoS
├── Topic QoS
├── Publisher QoS
├── Subscriber QoS
├── DataWriter QoS
└── DataReader QoS

This reference architecture defines the following QoS Profiles in Qos.xml:

Qos Library	Qos Profile	Intended Use
System	DefaultParticipant	Common, or base, system configuration (e.g. transport, network interfaces, discovery, thread priorities, etc.)
DataFlow	Streaming	Periodic data that is published at a high frequency (i.e. frequencies <1 second)
DataFlow	Status	"Current status"-like data, sent once at the beginning of operation and again only upon change to the status
DataFlow	Command	Data that represents commands or trigger some action in the system
DataFlow	Heartbeat	Assert and detect the presence of system devices

Domains & Topics

A Domain represents a data space where data can be shared by means of reading and writing the same Topics, where each Topic has a corresponding Data Type. In a Domain, you can define Topics and associate Data Types.

The hierarchy of the components configured in a Domain are as follows:

Domain → Domain ID
├── Type Name → Data Type
└── Topic → Type Name
 
Legend:
 → references

This reference architecture defines the following Domains in DomainLibrary.xml:

Domain	Intended Use
OperationalDataDomain	Real-time operational medical device data

Note, this reference architecture defines just a single Domain. As a Connext system design scales over time, additional domains could be defined for monitoring, logging, etc. Those additional domains should not affect the performance of our operational data, and therefore should belong to a different domain.

This reference architecture defines the following Topics in DomainLibrary.xml:

Domain	Topic	Intended Use
OperationalDataDomain	`t/MotorControl`	Command the direction of motion for a motor kind (e.g. `SHOULDER`, `ELBOW`)
OperationalDataDomain	`t/DeviceStatus`	Status (e.g. `ON`, `PAUSED`) for a unique system component
OperationalDataDomain	`t/DeviceHeartbeat`	Assert that a unique system component is alive
OperationalDataDomain	`t/DeviceCommand`	Command initiating a status (e.g. `START`, `SHUTDOWN`) to a unique system component
OperationalDataDomain	`t/Vitals`	Data representative of a unique patient's collected vital signs

Note, this reference architecture defines a unique Topic for each Data Type defined. While a Topic may only reference a single Data Type, a multi-purpose Data Type can be associated with multiple Topics. It is a best practice to limit the number of defined Topics, but in doing so, it may be feasible to re-use a Data Type for several Topics.

DomainParticipants & DDS Entities

A DomainParticipant is a discoverable Domain actor. DomainParticipants own DDS entities such as DataWriters and DataReaders.

This is where the entire system architecture is tied together:

DomainParticipants are configured to operate on a defined Domain.
DomainParticipants are configured to use a defined QoS Profile.
DataWriters and DataReaders are contained within a defined DomainParticipant.
DataWriters and DataReaders are configured to operate on a defined Topic, which has been associated with a defined Data Type.
DataWriters and DataReaders are configured to use a defined QoS Profile.

The hierarchy of DDS entities and components configured in a DomainParticipant are as follows:

DomainParticipant → Domain
├── DomainParticipant QoS → QoS Profile
├── Publisher
|   ├── Publisher QoS → QoS Profile
│   └── DataWriter → Topic
|       └── DataWriter QoS → QoS Profile
└── Subscriber
    ├── Subscriber QoS → QoS Profile
    └── DataReader → Topic
        └── DataReader QoS → QoS Profile
        └── Content Filter
            ├── Expression
            └── Expression Parameters

Legend:
 → references

This reference architecture defines the following DomainParticipants in ParticipantLibrary.xml:

Domain	DomainParticipant	Subscriptions	Publications	Intended Use
OperationalDataDomain	Arm	`t/DeviceCommand`, `t/MotorControl`	`t/DeviceStatus`, `t/DeviceHeartbeat`	Operate a robotic surgery arm with 5 motors: Base, Shoulder, Elbow, Wrist, and Hand.
OperationalDataDomain	ArmController	`t/DeviceCommand`	`t/MotorControl`, `t/DeviceHeartbeat`	Administer commands to an Arm device to control its motors.
OperationalDataDomain	Orchestrator	`t/DeviceStatus`, `t/DeviceHeartbeat`	`t/DeviceCommand`	Administer device-level commands and monitor presence and status of all devices.
OperationalDataDomain	PatientSensor	`t/DeviceCommand`	`t/Vitals`, `t/DeviceStatus`, `t/DeviceHeartbeat`	Stream simulated patient vitals.
OperationalDataDomain	PatientMonitor	`t/DeviceCommand`, `t/Vitals`	`t/DeviceStatus`, `t/DeviceHeartbeat`	Process and display patient vitals.

Note, this reference architecture utilizes one DomainParticipant for each device application. It is a best practice to define one DomainParticipant per application. However, in more complex systems, an application may be required to operate on multiple Domains. This requires defining multiple DomainParticipants for those applications that run in parallel.

DDS Security

DDS Security defines authentication, access control, and encryption capabilities essential for medical device communications. Security is critical in medical systems to protect patient data, ensure device integrity, and maintain regulatory compliance.

DDS Security is meant to be a pluggable component to the system architecture. This reference architecture demonstrates the flexibility of the RTI Security Plugins, and how a system can be secured purely through configuration. It should be noted that enabling security does have an effect on performance - both at initialization due to authentication and in steady-state operation due to encryption. It is because of this, that a system's architecture should be designed with security in mind, even if application code has no dependency on the use of security.

The reference architecture configures security in SecureAppsQos.xml with:

Component	Security Features
LAN Communications	Domain 0 governance, participant-specific certificates and permissions
WAN Communications	Domain 1 governance for WAN connections
RTI Services	Dedicated security profiles for Recording/Replay Services and Routing Services

Security Artifacts Structure in security:

ca/ - Certificate Authority hierarchy (root CA → intermediate identity CA + intermediate permissions CA)
domain_scope/ - Per-domain governance and permissions XML documents with signed versions
identity/ - Per-participant identity certificates, private keys, and cert chains organized by module

See the Security README for generation instructions and full details.

Going Further

Want to dig deeper?

Check out the the system_arch folder, where the system architecture artifacts live and are covered in more depth!

Additional References

RTI XML-Based Application Creation
RTI System Designer
RTI Core Libraries Users Manual
RTI Security Plugins
RTI Connext Modern C++ API , used in Module 01: Digital Operating Room
RTI Connext Python API , used in Module 01: Digital Operating Room
RTI Recording Service & Replay Service , used in Module 02: RTI Recording Service & RTI Replay Service
Connext Real-Time WAN Transport , used in Module 03: Remote Teleoperation with RTI Real-Time WAN Transport
RTI Routing Service , used in Module 03: Remote Teleoperation with RTI Real-Time WAN Transport
RTI Cloud Discovery Service , used in Module 03: Remote Teleoperation with RTI Real-Time WAN Transport
RTI Security Plugins Users Manual , used in Module 04: Security Threat Demonstration
RTI Connext Third-Party Software

Name		Name	Last commit message	Last commit date
Latest commit History 51 Commits
docs/release		docs/release
modules		modules
resource		resource
system_arch		system_arch
.clang-format		.clang-format
.gitignore		.gitignore
.markdownlint.json		.markdownlint.json
CMakeLists.txt		CMakeLists.txt
LICENSE		LICENSE
README.md		README.md
build.py		build.py
launch.py		launch.py
requirements.txt		requirements.txt

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Repository files navigation

RTI MedTech Reference Architecture

Contents

Introduction

Quick Start

1. Prerequisites

2. Clone the Repository

3. Set Up a Python Virtual Environment

4. Build the C++ Modules

5. Generate Security Artifacts (optional — skip if not using `-s`)

Hands-On: Modules

Module 01 : Digital Operating Room

Module 02 : RTI Recording Service & RTI Replay Service

Module 03 : Remote Teleoperation with RTI Real-Time WAN Transport

Module 04 : Security Threat Demonstration

Hands-On: Architecture

Architecture Overview

Data Types

Quality of Service (QoS)

Domains & Topics

DomainParticipants & DDS Entities

DDS Security

Going Further

Want to dig deeper?

Additional References

About

Uh oh!

Releases 3

Packages

Uh oh!

Contributors

Uh oh!

Languages

Folders and files

Latest commit

History

Repository files navigation

RTI MedTech Reference Architecture

Contents

Introduction

Quick Start

1. Prerequisites

2. Clone the Repository

3. Set Up a Python Virtual Environment

4. Build the C++ Modules

5. Generate Security Artifacts (optional — skip if not using -s)

Hands-On: Modules

Module 01 : Digital Operating Room

Module 02 : RTI Recording Service & RTI Replay Service

Module 03 : Remote Teleoperation with RTI Real-Time WAN Transport

Module 04 : Security Threat Demonstration

Hands-On: Architecture

Architecture Overview

Data Types

Quality of Service (QoS)

Domains & Topics

DomainParticipants & DDS Entities

DDS Security

Going Further

Want to dig deeper?

Additional References

About

Resources

License

Uh oh!

Stars

Watchers

Forks

Releases 3

Packages 0

Uh oh!

Contributors

Uh oh!

Languages

5. Generate Security Artifacts (optional — skip if not using `-s`)

Packages