T10.2: Implements Clinical Message Delivery

Overview

Clinical Message Delivery (CMD) is a UCR feature that enables the automatic notification of clinicians and systems when clinically significant events occur within the federation. When clinical data is submitted to the federation through Edge Gateways, the CMD system evaluates the data against configured filters and subscriptions to determine who or what should be notified.

How the Pipeline Works

The CMD pipeline operates in the following sequence: 1. Clinical event detection: A clinical data submission triggers the notification engine 2. Filter evaluation: The system evaluates topic filters and detail filters against the incoming data 3. Subscription matching: Subscriptions associated with matching filters are identified 4. Delivery determination: The delivery options associated with matched subscriptions determine how and where notifications are sent 5. Notification delivery: Notifications are delivered to clinicians (via their configured delivery channels) or to registered external systems

Types of Notifications

CMD supports two primary notification types:

• Clinician notifications: Sent to individual clinicians who have subscriptions matching the clinical event
• System notifications: Sent to registered external systems for automated processing

Use Cases

Common clinical message delivery scenarios:

• Notifying a primary care physician when their patient is admitted to a hospital
• Alerting a care coordinator when a lab result is abnormal
• Sending notifications to a disease registry when specific diagnoses are recorded
• Informing a specialist when a referral patient's data becomes available
• Triggering external workflow systems when clinical events meet specific criteria

---

Overview

Clinical Message Delivery is not enabled by default and requires explicit configuration to activate. The process involves enabling the CMD components in the Registry production and configuring Edge Gateways to participate in the notification system.

DoPush Setting

The DoPush setting is the master switch for CMD:

• When set to true, the CMD pipeline is active and processes clinical events
• When set to false, no notifications are generated regardless of other configuration
• This setting is configured at the Registry level
• Toggling DoPush provides a quick way to enable or disable all notifications

PushEvaluator Configuration

The PushEvaluator is the component responsible for evaluating incoming clinical data:

• Receives notification of clinical events from Edge Gateways
• Evaluates the event data against all configured topic filters and detail filters
• Identifies matching subscriptions based on filter results
• Passes matched subscriptions to the PushDeliveryMgr for delivery
• Configuration includes pool size settings for handling concurrent evaluations

PushDeliveryMgr Configuration

The PushDeliveryMgr handles the delivery of notifications:

• Receives matched subscriptions and notification data from the PushEvaluator
• Determines the delivery channel for each notification (clinician delivery, system delivery)
• Manages delivery retries for failed notifications
• Tracks delivery status and maintains delivery logs
• Configuration includes delivery retry settings and timeout values

Edge Gateway Configuration for CMD

Each Edge Gateway that should participate in CMD must be configured to:

• Send clinical event notifications to the Registry when new data is received
• Include appropriate metadata with notifications (patient identity, data type, facility)
• Handle acknowledgment responses from the Registry

---

Overview

Filters are the mechanism by which the CMD system identifies which clinical events should trigger notifications. Filters operate in a two-tier model: topic filters cast a broad net for event categories, and detail filters narrow down to specific criteria within those categories.

Topic Filters

Topic filters define broad categories of clinical events:

• ADT events: Admissions, discharges, and transfers
• Lab results: Laboratory test results
• Diagnoses: New or updated diagnoses
• Medications: New prescriptions or medication changes
• Procedures: Surgical or clinical procedures
• Documents: New clinical documents

Topic filters match based on the type of clinical data that triggered the event. A single topic filter can match many different specific events within its category.

Detail Filters

Detail filters refine the scope of a topic filter with specific criteria:

• Code-based: Match specific diagnosis codes (ICD-10), procedure codes (CPT), or medication codes (RxNorm)
• Value-based: Match specific lab result values (e.g., HbA1c > 9.0)
• Status-based: Match specific event statuses (e.g., only critical lab results)
• Facility-based: Match events from specific facilities

Regular Expression Support

Filters support regular expressions for flexible matching:

• Pattern matching on code values (e.g., "E11.*" to match all Type 2 diabetes codes)
• Text matching on clinical descriptions
• Wildcard patterns for broad or narrow matching
• Regular expression syntax follows standard patterns

Custom Operators

For complex filtering logic, custom operators can be used:

• Custom comparison functions for numerical values
• Complex logic combining multiple criteria
• Lookups against reference tables or value sets
• Time-based comparisons for event timing

Filter Design Best Practices

• Start with broad topic filters and refine with detail filters
• Test filters with representative clinical data before deploying to production
• Document the purpose and expected matches for each filter
• Review and update filters as clinical requirements change
• Monitor filter performance to ensure they do not create processing bottlenecks

---

Overview

Analytics filters extend the CMD filtering capability beyond simple event-based matching. They enable notifications based on analytics criteria such as patient cohort membership, risk scores, or calculated population health metrics. Analytics filters are applied to subscriptions to add a layer of intelligence to the notification pipeline.

How Analytics Filters Work

Analytics filters evaluate:

• Whether a patient belongs to a defined population or cohort
• Whether analytics metrics for a patient meet specified thresholds
• Whether aggregate data patterns trigger notification criteria
• Whether population health indicators warrant notification

Use Cases for Analytics Filters

• Notify care managers when a patient's risk score exceeds a threshold
• Alert population health teams when a cohort membership changes
• Trigger notifications when quality metrics fall below targets
• Send alerts when readmission risk is elevated for a specific patient

Configuration

Analytics filters are configured by:

• Defining the analytics criteria to evaluate
• Setting thresholds or conditions for triggering notifications
• Associating the analytics filter with a subscription
• Specifying how often analytics criteria are re-evaluated

Relationship to Other Filters

Analytics filters complement topic and detail filters:

• Topic filters identify the type of clinical event
• Detail filters narrow to specific criteria within the event
• Analytics filters add population health and analytics dimensions
• All filter types can be combined on a single subscription

---

Overview

Delivery options determine how notifications reach their intended recipients. UCR supports two primary delivery modes: direct delivery to clinicians and automated delivery to external systems. Each mode has its own configuration options and policies.

Direct Clinician Delivery

Notifications delivered directly to clinicians can use:

• Clinical Viewer alerts: In-application notifications visible when the clinician logs into the Clinical Viewer
• Email notifications: Email messages sent to the clinician's registered email address
• Other channels: Potentially other delivery mechanisms supported by the deployment

Clinician delivery is personalized based on:

• The clinician's subscription preferences
• The clinician's delivery policy settings
• The clinician's patient associations

System Delivery

System delivery sends notifications to registered external systems:

• Notifications are sent to configured endpoint URLs
• Message format follows defined standards (HL7, FHIR, custom)
• External systems process the notification and take appropriate action
• Delivery is automated without human intervention in the notification chain

System delivery is used for:

• Integration with care management platforms
• Feeding disease registries
• Triggering automated workflows in external systems
• Updating data warehouses or analytics platforms

Delivery Reliability

UCR includes mechanisms to ensure notification delivery:

• Automatic retry for failed deliveries with configurable retry intervals
• Dead-letter handling for notifications that repeatedly fail
• Delivery status tracking and logging
• Alert mechanisms when delivery failures exceed thresholds

---

Overview

Clinician delivery policies control how and when individual clinicians receive notifications. A default policy establishes baseline behavior for all clinicians, while individual policies allow customization per clinician.

Default Clinician Delivery Policy

The default policy applies to all clinicians who do not have individual overrides:

• Specifies the default delivery channel (Clinical Viewer alert, email, etc.)
• Sets default throttling parameters (maximum notifications per time period)
• Defines the default delivery schedule (immediate or batched)
• Establishes the default notification format and content

Individual Clinician Policies

Individual clinicians can have personalized delivery policies:

• Override the default delivery channel with their preferred channel
• Adjust throttling to receive more or fewer notifications
• Set custom delivery schedules based on their work patterns
• Choose notification detail level (summary vs full detail)

Throttling and Alert Fatigue Prevention

To prevent alert fatigue:

• Configure maximum notification frequency (e.g., no more than 10 per hour)
• Batch similar notifications into digest messages
• Prioritize notifications based on clinical urgency
• Allow clinicians to adjust their own throttling preferences

Delivery Schedule Options

• Immediate: Notifications delivered as soon as they are generated
• Batched: Notifications accumulated and delivered at scheduled intervals
• Scheduled: Notifications delivered only during specific time windows
• On-demand: Notifications stored and retrieved when the clinician requests them

---

Overview

Clinician-patient associations connect individual clinicians to the patients they care for. These associations are fundamental to the CMD system because they determine which clinicians should receive notifications about which patients.

Creating Associations

Clinician-patient associations can be established through:

• Manual entry: Administrators or clinicians create associations through the Management Portal
• Data feed import: Associations imported from EHR care team data via Edge Gateways
• Automated assignment: Rules-based automatic association based on clinical events (e.g., admitting physician is automatically associated)
• Bulk import: Loading association data from external sources

Association Types

Different types of associations reflect clinical roles:

• Primary Care Provider (PCP): The patient's main physician
• Specialist: Consulting physicians for specific conditions
• Care Coordinator: Responsible for coordinating the patient's care plan
• Nurse: Nursing staff assigned to the patient
• Custom roles: Organization-specific roles as needed

Association and Notification Targeting

When a clinical event triggers the CMD pipeline: 1. The system identifies the patient involved in the event 2. Looks up all clinicians associated with that patient 3. Evaluates each clinician's subscriptions against the event 4. Delivers notifications only to clinicians whose subscriptions match

This targeting ensures clinicians receive notifications only about their own patients, reducing noise and improving relevance.

Managing Associations Over Time

• Associations should be updated when care teams change
• Discharge or transfer events may trigger association updates
• Periodic review of associations ensures accuracy
• Stale associations can lead to missed or misdirected notifications

---

Overview

For system delivery (as opposed to clinician delivery), external receiving systems must be registered in the delivery registry. This registration provides the CMD system with the information needed to deliver notifications to the correct endpoints in the correct format.

Registering a Receiving System

For each receiving system, configure:

• System name: A descriptive identifier for the system
• Endpoint URL: The network address where notifications should be sent
• Protocol: The communication protocol (SOAP, REST, HL7 MLLP, etc.)
• Authentication: Credentials or certificates required to connect to the system
• Message format: The notification format the system expects (HL7v2, FHIR, CDA, custom)
• SSL/TLS: Security configuration for the connection

System Capabilities

When registering a system, specify its capabilities:

• Which types of notifications it can process
• Maximum throughput (messages per second)
• Supported message formats and versions
• Expected response behavior (synchronous acknowledgment, asynchronous processing)

Error Handling Configuration

For each receiving system:

• Configure retry policies (number of retries, retry interval)
• Define behavior when delivery fails permanently (dead-letter queue, alert)
• Set timeout values for connection and response
• Configure fallback behavior if the primary endpoint is unavailable

Testing and Validation

Before enabling production delivery to a receiving system:

• Test connectivity to the endpoint
• Send test notifications and verify processing
• Validate message format compliance
• Confirm authentication and security configuration
• Load test to verify throughput capacity

---

Overview

System delivery policies define the rules for automated distribution of notifications to external systems. These policies connect the CMD filter pipeline to the registered receiving systems, specifying what events trigger delivery and how notifications are formatted and delivered.

Creating a System Delivery Policy

A system delivery policy includes:

• Policy name: A descriptive identifier for the policy
• Source filters: Which topic and detail filters must match for this policy to apply
• Target systems: Which registered receiving systems receive the notifications
• Transformation rules: How notification data is transformed for the target system's format
• Delivery schedule: When notifications are delivered (immediate, batched, or scheduled)
• Priority: The urgency level of notifications under this policy

Policy-Filter Relationship

System delivery policies work with the CMD filter pipeline: 1. A clinical event is evaluated against topic and detail filters 2. Matching filters activate associated subscriptions 3. Subscriptions with system delivery policies trigger delivery to specified systems 4. The policy determines the format, timing, and target for the notification

Transformation Rules

Different receiving systems may require different message formats:

• Policies can specify transformation rules to convert notifications to the target format
• Common transformations include SDA to HL7v2, SDA to FHIR, and SDA to CDA
• Custom transformations can be developed for proprietary formats
• Transformation rules are evaluated at delivery time

Monitoring System Delivery

Administrators should monitor:

• Delivery success rates for each receiving system
• Queue depths for pending deliveries
• Error rates and common failure reasons
• Delivery latency between event occurrence and notification delivery

---

Overview

Subscription policies define the notification subscriptions that clinicians hold. A subscription connects a clinician to specific filters, determining which clinical events generate notifications for that clinician. Subscriptions can be based on the clinician's patient associations, facility memberships, or broader criteria.

Subscription Components

Each subscription policy includes:

• Subscriber: The clinician or clinician group that holds the subscription
• Filter bindings: Which topic filters, detail filters, and analytics filters are applied
• Patient scope: Whether the subscription covers all patients, only associated patients, or patients at specific facilities
• Delivery policy: How notifications are delivered (references the clinician's delivery policy)
• Active status: Whether the subscription is currently active

Subscription Basis

The subscription basis determines the patient scope:

• Patient association basis: Notifications only for patients the clinician is associated with
• Facility basis: Notifications for all patients at specified facilities
• Federation-wide basis: Notifications for all patients in the federation (typically for population health roles)
• Cohort basis: Notifications for patients in a specific cohort or population

Creating Subscriptions

Subscriptions can be created by:

• Administrators configuring subscriptions for clinicians
• Clinicians self-subscribing through available interfaces
• Automated subscription assignment based on clinician roles or facility memberships
• Bulk subscription creation for clinician groups

Subscription Lifecycle

• Subscriptions can be activated or deactivated without deletion
• Inactive subscriptions are preserved for potential reactivation
• Subscriptions should be reviewed and updated as clinical responsibilities change
• Expired or orphaned subscriptions should be cleaned up periodically

---

Overview

Filters are applied to subscriptions to define the criteria that determine when a clinician receives a notification. The combination of filters on a subscription creates a precise specification of which clinical events are relevant to the subscribing clinician.

Applying Topic Filters

When a topic filter is applied to a subscription:

• The subscription will match any clinical event that passes the topic filter
• Multiple topic filters can be applied to broaden the subscription's scope
• At least one topic filter must match for the subscription to trigger

Adding Detail Filters

Detail filters refine the subscription:

• Applied in addition to topic filters for more specific matching
• A subscription with a topic filter for "Lab Results" and a detail filter for "HbA1c > 9.0" will only trigger for elevated HbA1c results
• Multiple detail filters can be combined with AND or OR logic depending on configuration

Overlaying Analytics Filters

Analytics filters add intelligence-based criteria:

• Applied alongside topic and detail filters
• The analytics criteria must also be satisfied for the subscription to trigger
• Example: A subscription for lab results with an analytics filter for "high-risk diabetic cohort" only triggers for lab results of patients in the high-risk cohort

Filter Evaluation Process

When a clinical event occurs: 1. Topic filters are evaluated first to identify broadly matching subscriptions 2. Detail filters are evaluated next to narrow the matches 3. Analytics filters are evaluated last to apply population health criteria 4. Only subscriptions where all applicable filters match generate notifications

Configuration Best Practices

• Start with topic filters for broad coverage, then add detail filters for precision
• Use analytics filters sparingly, as they add computational overhead
• Test filter combinations with representative clinical events
• Monitor subscription match rates to identify filters that are too broad or too narrow
• Document the filter combinations on each subscription for troubleshooting

---

Overview

Cohort membership notifications extend the CMD system to support population health management. When patients are added to or removed from defined patient cohorts (populations), the CMD system can generate notifications to relevant clinicians or systems.

Cohort Definitions

Cohorts are defined populations of patients based on:

• Clinical criteria (e.g., all patients with diabetes, patients with heart failure)
• Risk scores (e.g., patients with readmission risk above a threshold)
• Demographics (e.g., patients in a specific age range or geographic area)
• Care program enrollment (e.g., patients enrolled in a chronic disease management program)

Cohort Entry Notifications

When a patient joins a cohort:

• The CMD system detects the cohort membership change
• Subscriptions with cohort-based filters are evaluated
• Notifications are generated for clinicians or systems subscribed to cohort entry events
• Use cases: alerting care coordinators that a new patient qualifies for a disease management program

Cohort Exit Notifications

When a patient leaves a cohort:

• The CMD system detects the removal from the cohort
• Exit notifications are generated for relevant subscriptions
• Use cases: notifying care teams that a patient's risk score has dropped below a threshold or that a patient has been discharged from a program

Configuration

Cohort membership notifications are configured by:

• Defining cohorts with appropriate clinical criteria
• Creating subscriptions that reference cohort membership as a filter criterion
• Specifying whether the subscription triggers on entry, exit, or both
• Associating delivery options for cohort-based notifications

Monitoring and Maintenance

• Monitor cohort membership calculations for accuracy
• Review cohort definitions periodically to ensure they reflect current clinical criteria
• Track notification volumes from cohort changes to identify unexpected patterns
• Audit cohort-based notifications for clinical relevance

---

Overview

The Clinical Message Delivery system operates as a pipeline with three main stages: filtering, subscription matching, and delivery. Understanding how these stages connect and interact is essential for configuring CMD correctly and for troubleshooting notification issues.

Stage 1: Event Filtering

When a clinical event enters the CMD pipeline:

• The PushEvaluator receives the event data
• Topic filters are evaluated to categorize the event
• Detail filters are applied to refine the match
• Analytics filters add population health criteria
• The result is a set of matched filters

Stage 2: Subscription Matching

Matched filters activate associated subscriptions:

• Each filter may be referenced by multiple subscriptions
• Each subscription may reference multiple filters
• The patient scope of the subscription is checked (does this event involve a patient the clinician cares about?)
• Clinician-patient associations are evaluated for patient-scoped subscriptions
• The result is a set of activated subscriptions

Stage 3: Delivery Execution

Activated subscriptions trigger the delivery process:

• The PushDeliveryMgr receives the activated subscriptions
• For clinician subscriptions: the clinician's delivery policy determines the delivery channel and timing
• For system subscriptions: the system delivery policy determines the endpoint and format
• Notifications are formatted and delivered to the specified recipients
• Delivery status is tracked and logged

Pipeline Troubleshooting

When notifications are not being delivered as expected: 1. Check filters: Are the topic and detail filters matching the expected events? 2. Check subscriptions: Is a subscription with the correct filters associated with the expected recipient? 3. Check patient scope: Does the subscription's patient scope include the affected patient? 4. Check delivery policy: Is the delivery policy correctly configured for the recipient? 5. Check delivery status: Are notifications being generated but failing during delivery?

Design Principles

When designing a CMD configuration:

• Keep filters modular and reusable (one filter can serve many subscriptions)
• Design subscriptions around clinical roles and responsibilities
• Match delivery options to recipient needs and preferences
• Test the full pipeline end-to-end with representative clinical events
• Document the relationships between filters, subscriptions, and delivery options

---