Logica Reference Messaging

Owned by Travis Cummings
Last updated: Nov 06, 2019 by Preston Lee
2 min read

Introduction


The Logica Reference Messaging system is designed to support FHIR Subscription resources and show how such patterns can be part of an enterprise content-based routing solution.

Reference Messaging System

The messaging system exists to support context-based routing of messages. The FHIR use case is to support the FHIR subscription resource. When a subscription is submitted to the API server (created, updated, deleted), the subscription is registered with the messaging system as a Drools rule based on the subscription criteria. When non-subscription resource (Observation, Patient, etc.) is submitted to the API server (created, updated, deleted), the resource is submitted to the messaging system for routing. If the resource matches (using Drools rules) the resource is routed according to the channel definitions of the subscription.

Alternatively, a back-end service could use a polling strategy to determine when any changes have occurred to the FHIR resources (for example, from an external data feed). This back-end service would then submit the resource to the messaging system for routing.

Bilirubin Monitor Application Usage of the Reference Messaging System

The Bilirubin Monitor application is a backend service application that is deployed external to the EHR, that is pre-authorized with the EHR according to the SMART on FHIR specification and OAuth 2.0/OpenID Connect technologies. The Bilirubin Monitor is send message from the reference messaging system according to subscription resources that have been registered with the messaging system. A message send from the EHR to the Bilirubin Monitor should not include full resource information. Instead the Bilirubin Monitor should query any resource information to comply with the SMART on FHIR security protocols.

The Bilirubin Monitor is interested in two scenarios. In the first scenario, the monitor wants to send an alert if a newborn baby has not been checked for Bilirubin levels within the first 12 hours after birth. The monitor is first sent a message when a patient resource is submitted. The monitor queries the full patient resource so the monitor can perform additional criteria analysis. If the patient is determine to be a newborn, the monitor creates a future task (to be run when the patient is 12 hours old) that will create an alert if there are no Bilirubin observations for the baby.

The second scenario the Bilirubin Monitor is interested in is creating alerts when Bilirubin observations are submitted that exceed dangerous thresholds. In this scenario, the monitor is sent every Bilirubin observation that is received by the EHR. The monitor then queries the full Bilirubin resource to determine if the value has exceeded the threshold, then creates an alert.



Enterprise Integration Patterns

Conceptually, we are doing Publish-Subscribe using the FHIR Subscription model. However, internally we are using various Enterprise Integration Patterns, and technologies of including Drools for dynamic content based routing and (future) Apache Camel for light-weight routing. Alternatives to Camel include Spring Integration and Mule ESB.


Using a light-weight routing solution allows an enterprise to easily provide additional behavior. For example, the EHR FHIR interceptor can publish to a service bus.