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,
Enterprise Message Bus
The RabbitMQ AMQP server is used for the enterprise messaging bus.
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
data-manager is the core business logic engine: an Erlang-based service that handles messages processing, audit logging, etc.
The application server for the platform is GlassFish and it handles JDBC connection pooling, site-specific resource configuration, and hosts the application bundles.
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 (CSV, TSV, Excel, etc.) can be ingested as well with custom scripts, provided the data source is RFC 4180 compliant.
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
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.
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.