Bridge is a data platform to build software applications for healthcare. It provides a web-oriented SDK and tools to enable real-time access to a normalized clinical data model.


Clinical data enters the enterprise messaging bus in its original format, as a message containing source, content, and destination information. The "brains" of the platform, the data-manager, runs these messaging queues and sends messages to various extraction-transformation scripts which eventually re-inject a modified message back into the bus. When the message reaches it's final/normalized stage, data-manager inserts or updates the appropriate rows in the database, as well as pushing these changes out to the messaging bus. The Java/Hibernate-based SDK provides access to the database, as well as providing role-based authentication and authorization and a HIPAA audit logging service. A client-side JavaScript library provides an interface to the message bus for real time data updates in the browser, as well as tabular and graphing helpers. Web applications are currently compiled into a WAR container for deployment to an application server, so clinicians can simply use a web browser for access to the applications.

Enterprise Message Bus

The RabbitMQ AMQP server is used for the enterprise messaging bus.

Data Store

The database of clinical and application information is PostgreSQL. The data-model published by AI and used by the SDK contains all the clinical and configurationd data in the system. Applications can have their own schema as well, allowing for stored references to clinical data and application configuration.

Business Logic and ETL

The data-manager is the core business logic engine: an Erlang-based service that handles messages processing, audit logging, etc.

Application Server

The application server for the platform is GlassFish and it handles JDBC connection pooling, site-specific resource configuration, and hosts the application bundles.

Data Sources


Mirth Connect is used to listen for inbound HL7 messages and inject them into RabbitMQ as an AMQP payload. No business logic lives in Mirth, it is simply a transformer from HL7 to AMQP.

HL7 messages are parsed and transformed using a Clojure wrapper around the open-source HAPI library. Subsequent transformations, post-parse, are handled by various scripts written in Ruby and Python.

Flat Files

Flat files (CSV, TSV, Excel, etc.) can be ingested as well with custom scripts, provided the data source is RFC 4180 compliant.

Triggered Events

The message bus architecture naturally lends itself to trigger-based data ingestion as well. For example, an "end exam" status HL7 message can trigger a DICOM query against a PACS archive server to find out information about image count, etc.


AI recommends applications be built in the Ruby on Rails framework, as this is the current process we are documenting, but anything that runs in the JVM will also work (e.g. we have had a developer build a proof-of-concept application in Python with the Django framework).


The SDK is distributed as a JAR file that acts as an extension of Hibernate, the Java ORM which it is based on. The SDK provides access to clinical data, as well as facilities for authorization and HIPAA audit logging.

Real Time Data

One of the tools available for application developers on the platform is a JavaScript library that allows applications to jack into the enterprise messaging bus and get real-time updates on specific types on information. This presents the paradigm of using the SDK to get existing state from the database, and merging that data in the application with real time data from the JavaScript side.

SSO Integration

The platform integrates with existing directory services such as Active Directory, eDirectory, and many others using OpenAM. User logins are mapped to clinical roles, allowing for role-based authentication, meaning an application knows who is logged in and can present different views and interfaces for different types of users.

HIPAA Logging

All applications built using the SDK and following the developer guidelines log all views of PHI back to the database. These logs are viewable and exportable from the Service Tools management and configuration application.