Monitoring Overview

The Direct project specification as outline by the applicability statement for secure health transport does not explicitly list requirements for message quality of service. However, section 3.0 indicates that Direct implementations may use additional notifications to indicate confirmation of receipt or message delivery. The Direct Project implementation guide for delivery notification describes specific notification messages and message sequences to validate (from the senders perspective) that a message was delivered to its final destination. In addition, the implementation guide provides eight possible use cases with accompanying diagrams that describe successful and failed message flows. Of the failure flows, some use cases outline scenarios where the receiving HISP goes “radio silent” on the sending HISP. In these scenarios, the sending HISP must be aware that the messages are in a pending notification state, and should only stay that way for a certain time period (hence timely delivery). This is where the role of monitoring becomes important; some entity in the sending HISP must be watching for the lack of notifications messages from the receiving HISP.

The monitoring service is responsible for tracking outgoing messages from a sending HISP and ensuring that all required ACK or NACK responses are received by the sending HISO in accordance to the implementation guide. If all the required notifications required to “complete” the delivery notification sequence are not received by the sending HISP within a certain time period, then the monitoring service places the original messages’s delivery status into a failed state and generates a failure message to be delivered to the original message’s edge client. The monitoring service is also responsible for ensuring that one and only one success or failure notification message is sent to the original message’s edge client in accordance to the implementation guide.

There are potentially several ways to solve the issue of notification messages not being sent back to the original sending HISP, however, the Java RI has chosen to use a monitoring component that tracks the notifications associated with a given outgoing message. Enterprise integration patterns and corresponding open source libraries exist that solve many of the problems associated with the scenario at hand. Utilization of these patterns simplify the implementation of an efficient monitoring solution.

How It Works

Any time a HISP successfully encrypts and sends an out bound message to another entity (in some cases, even to itself), a entry for the message is sent to the monitoring service containing all relevant information to track the message for notification delivery. When a HISP receives, decrypts, and validates trust for an appropriate incoming notification message, it again sends all relevant information to the monitoring service for tracking. The notification message is correlated back to the original message, and the state of the original message is updated to reflect that a notification message has been received.

Each time a notification message is received by the monitor, it checks to see if the message has received all required notifications. If all necessary notifications are received to “complete” the notification delivery sequence, the original message is then discarded by the monitoring service. The monitor also actively watches all messages that have not been completed. If all notification messages are not received within a given time period for a given message, the monitoring service generates a failure notification to be delivered to the original message’s edge client. At that point, the original message is then discarded from the monitor.

Because the implementation guide states that only one delivery notification message can be delivered to the edge client, the monitoring service also tracks all success or failure notifications sent to the original message’s sending edge client. Before the HISP delivers a notification message to the edge client, it checks first with the monitoring service to see if a notification message has already been delivered to the edge. In the case where a notification has already been delivered, the HISP suppresses the notification. If a notification has not already been delivered, then the notification is allowed to continue and be delivered to the edge client.