The Medical Reference Architecture demonstrates RTI's best practices for building medical devices using RTI Connext.
This repository contains documentation and 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
- Getting Started
- Cloning the Repository
- Hands-On: Demos
- Hands-On: Architecture
- Architecture Overview
- Going Further
- Additional references
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:
RTI strongly recommends proceeding in the following order:
- Setup: Clone the repository.
- Run: Run the demos.
- Learn: Understand the architecture.
To clone the repository you will need to run git clone as follows to download both the repository and its submodule dependencies:
git clone --recurse-submodule https://github.com/rticommunity/rticonnextdds-medtech-reference-architecture.gitIf you forget to clone the repository with --recurse-submodule, simply run
the following command to pull all the dependencies:
git submodule update --init --recursiveFor the specific demos and their prerequisites, refer to the README.md located in each demo folder.
The RTI MedTech Reference Architecture demos showcase usage and capabilities of the provided system architecture.
RTI recommends following along the demo-specific READMEs before returning here and learning more about the designed system 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:
- Open RTI Launcher.
- Navigate to the Tools tab.
- Click the System Designer button.
- From a terminal:
- Launch the
rtisystemdesigner[.bat]script found in the $NDDSHOME/bin folder. Where $NDDSHOME is the folder where Connext is installed.
- Launch the
- From RTI Launcher:
- Open the Project File.
- Select Projects in the toolbar.
- Click Open in the dropdown.
- 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.
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:
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 demo below:
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) 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 heirarchy 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 presense of system devices |
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 heirarchy 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.
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 heirarchy 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 presense 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.
Check out the the system_arch folder, where the system architecture artifacts live and are covered in more depth!
- RTI XML-Based Application Creation
- RTI System Designer
- RTI Core Libraries Users Manual
- RTI Connext Modern C++ API , used by demo applications
- RTI Connext Python API , used by demo applications
- RTI Recording Service & Replay Service , used in demo