T1.2: Implements Clinical Message Delivery

Overview

Clinical Message Delivery (CMD) is a HealthShare UCR feature that automatically pushes clinical information to enrolled clinicians based on their subscriptions. Unlike the standard UCR model where clinicians search for patient data, CMD proactively delivers notifications and documents when relevant clinical events occur. This is essential for care coordination, enabling clinicians to stay informed about their patients without actively monitoring the system.

Architecture

CMD operates within the HealthShare Bus production:

• Event detection: The Bus monitors clinical data flowing through the federation for subscription-matching events
• Subscription evaluation: When new data arrives, the system evaluates it against all active subscriptions
• Message generation: For matching subscriptions, the system generates clinical messages
• Delivery: Messages are delivered to enrolled clinicians through their configured delivery channels
• Tracking: Delivery status is tracked and available for monitoring

Enabling Clinical Message Delivery

To enable CMD:

• Navigate to HealthShare > Registry Management > Clinical Message Delivery
• Enable CMD at the system level (this activates the CMD infrastructure)
• Configure the CMD business hosts in the Bus production
• Verify that the CMD service components are running
• Optionally enable CMD for specific facilities only

Disabling Clinical Message Delivery

CMD can be disabled without losing configuration:

• Disable at the system level to stop all message delivery
• Disable for specific facilities to stop delivery from those facilities only
• Existing subscriptions and enrollment data are preserved when CMD is disabled
• Re-enabling CMD resumes message delivery based on existing configurations

---

Delivery Filters

Delivery filters define the criteria that clinical events must meet to trigger message delivery. Filters act as gatekeepers, ensuring that clinicians receive only relevant information rather than being overwhelmed by all clinical activity.

Filter Types

UCR supports several categories of delivery filters:

• Patient-based filters: Trigger delivery only for specific patients or patient populations
• Event-based filters: Trigger based on clinical event types (admission, discharge, lab result, new diagnosis)
• Facility-based filters: Trigger only for events originating from specific facilities
• Data-type filters: Trigger based on the type of clinical data (medications, lab results, radiology reports)
• Composite filters: Combine multiple filter types with AND/OR logic for precise targeting

Creating Delivery Filters

To create a delivery filter:

• Navigate to Clinical Message Delivery > Delivery Filters
• Select the filter type (patient, event, facility, data-type, or composite)
• Define the filter conditions using the available criteria
• Set the logical operator for composite filters (AND, OR, NOT)
• Save the filter for use in subscriptions

Delivery Options

Delivery options control how messages are delivered:

• Format: Choose the message format (summary notification, full clinical document, structured data)
• Channel: Select the delivery channel (email, secure messaging, Direct protocol, FHIR endpoint)
• Timing: Configure immediate delivery, batched delivery (daily digest), or scheduled delivery
• Priority: Set message priority levels that affect delivery urgency
• Acknowledgment: Configure whether delivery acknowledgment is required

---

Delivery Relationships

Delivery relationships define the connections between clinicians and the patients or events they want to monitor. These relationships determine which clinicians are eligible to receive messages about specific patients or clinical events.

Relationship Types

UCR supports predefined and custom relationship types:

• Attending physician: The clinician currently responsible for the patient's care
• Primary care provider: The patient's designated primary care clinician
• Consulting physician: A specialist involved in the patient's care
• Care team member: Any clinician on the patient's care team
• Custom relationships: Organization-defined relationship types for specialized use cases

Output Transformations

Output transformations convert internal clinical data (SDA format) into the format required for delivery:

• CDA transformation: Produces CDA (Clinical Document Architecture) documents for structured clinical delivery
• HL7v2 transformation: Generates HL7 version 2 messages for systems that consume HL7v2
• Custom XML transformation: Creates organization-specific XML formats
• Plain text transformation: Produces human-readable text summaries for email delivery
• FHIR transformation: Generates FHIR resources for modern interoperability

Transformation Pipeline

The transformation pipeline processes data in stages: 1. SDA extraction: Retrieve the relevant clinical data from the patient's SDA container 2. Data filtering: Apply any CIT or consent restrictions to the extracted data 3. Transformation: Convert the filtered SDA data using the selected transformation class 4. Formatting: Apply output formatting (headers, metadata, presentation) 5. Packaging: Package the formatted output for delivery through the selected channel

---

Overview

Before clinicians can receive clinical messages through CMD, they must be enrolled in the system. Enrollment captures the clinician's identity, delivery preferences, and contact information for each delivery channel. Without enrollment, subscriptions cannot deliver messages to the clinician.

Enrollment Process

To enroll a clinician:

• Navigate to Clinical Message Delivery > Clinician Enrollment
• Search for the clinician in the clinician registry
• Create an enrollment record linking the clinician to CMD
• Configure the clinician's delivery preferences (channel, format, timing)
• Provide contact information for each delivery channel (email address, Direct address, etc.)
• Activate the enrollment

Delivery Preferences

Each enrolled clinician can configure:

• Preferred channel: The primary delivery channel (email, secure messaging, Direct, portal inbox)
• Backup channel: An alternative channel if the primary fails
• Message format: Preferred format for received messages (summary, full document, structured)
• Delivery timing: Immediate delivery, daily digest, or specific scheduled times
• Priority threshold: Minimum priority level for immediate delivery (lower-priority messages are batched)

Notification Channels

Supported delivery channels include:

• Email: Standard email delivery with clinical content (may require encryption for PHI)
• Secure messaging: Encrypted messaging through HealthShare's secure messaging infrastructure
• Direct protocol: Standards-based secure health messaging using Direct addresses
• Clinical portal inbox: Messages delivered to the clinician's inbox within the HealthShare Clinical Viewer
• FHIR endpoint: Delivery to an external FHIR-based system

---

Overview

Subscriptions are the core mechanism of CMD. A subscription connects a clinician (or group of clinicians) to a set of clinical events, defining what triggers message delivery and to whom. Subscriptions can be simple (one clinician, one patient) or complex (multiple clinicians, filtered event types, specific facilities).

Subscription Types

UCR supports several subscription types:

• Patient-based subscriptions: Monitor specific patients for any clinical events. The clinician subscribes to a patient and receives messages when new clinical data is recorded for that patient.
• Event-based subscriptions: Monitor for specific types of clinical events (e.g., all admissions, all critical lab results) regardless of which patient is involved. Useful for department heads or quality officers.
• Facility-based subscriptions: Monitor all clinical events from one or more specific facilities. Useful for care coordinators who oversee patients at particular facilities.

Creating Subscriptions

To create a subscription:

• Navigate to Clinical Message Delivery > Subscriptions
• Select the subscription type (patient-based, event-based, facility-based)
• Identify the subscribing clinician or clinician group
• Define the subscription criteria (patient list, event types, facilities)
• Associate delivery filters to refine which events trigger messages
• Associate delivery options to control message format and channel
• Activate the subscription

Subscription Lifecycle

Subscriptions follow a lifecycle: 1. Created: Subscription defined but not yet active 2. Active: Subscription is evaluating events and triggering delivery 3. Suspended: Subscription is temporarily paused (e.g., clinician on leave) 4. Modified: Subscription criteria updated while maintaining the subscription record 5. Deleted: Subscription permanently removed

---

Overview

The subscription basis determines what triggers a subscription to generate and deliver a clinical message. Understanding the different basis types is critical for configuring subscriptions that deliver the right information at the right time.

Basis Types

UCR supports several subscription basis types:

Data-Driven Basis:

• Subscriptions fire when new clinical data is recorded in the patient's SDA container
• Can be filtered by data type (new lab results, new medications, new diagnoses)
• Useful for clinicians who want to be notified of any new information about their patients
• The subscription evaluates incoming SDA streamlets against the basis criteria

Relationship-Driven Basis:

• Subscriptions fire based on the clinician's relationship to the patient
• When a relationship is established (e.g., clinician becomes attending physician), the subscription activates
• When a relationship ends, the subscription stops delivering for that patient
• Dynamically adjusts as clinician-patient relationships change

Event-Driven Basis:

• Subscriptions fire on specific clinical events identified by event codes
• Common events: ADT (admission/discharge/transfer), order placement, result availability
• Events are identified through HL7 message types or SDA event categories
• Useful for monitoring specific workflow milestones

Schedule-Driven Basis:

• Subscriptions fire on a schedule regardless of new data
• Useful for periodic summary reports (daily patient status, weekly care plan updates)
• Configured with cron-like scheduling parameters

Combining Basis Types

Subscriptions can combine multiple basis types:

• "Notify me of new lab results (data-driven) for patients I am attending (relationship-driven)"
• "Send daily summaries (schedule-driven) for patients admitted to my facility (event-driven)"
• Combinations use AND logic: all basis criteria must be satisfied for the subscription to fire

---

Overview

Cohorts enable subscriptions that target dynamic groups of patients rather than individually named patients. A cohort is a named group of patients who share common characteristics (e.g., all diabetic patients, all patients admitted in the last 24 hours). Cohort-based subscriptions deliver messages about any patient in the cohort, and cohort change subscriptions notify when the cohort membership changes.

Defining Cohorts

Cohorts are defined by criteria that identify qualifying patients:

• Diagnosis-based: Patients with specific diagnoses (e.g., diabetes, heart failure)
• Demographic-based: Patients matching demographic criteria (age range, location)
• Encounter-based: Patients with specific encounter types (inpatient, emergency)
• Custom criteria: Organization-defined criteria using clinical data queries

Cohort-Based Subscriptions

A cohort-based subscription monitors clinical events for all patients in a cohort:

• When a patient enters the cohort, the subscription begins monitoring their events
• When a patient leaves the cohort, the subscription stops monitoring their events
• The subscription delivers messages based on the configured filters and delivery options
• Useful for population health management and disease-specific care coordination

Cohort Change Subscriptions

Cohort change subscriptions fire specifically when cohort membership changes:

• Patient enters cohort: A notification is delivered when a patient newly qualifies for the cohort
• Patient leaves cohort: A notification is delivered when a patient no longer qualifies
• Useful for care managers who need to know when patients enter or exit their managed populations
• Can trigger enrollment workflows or care plan adjustments

---

Overview

Custom documents allow organizations to create tailored clinical documents assembled from patient data stored in the SDA container. These documents can be delivered through CMD subscriptions, providing clinicians with formatted, relevant clinical summaries rather than raw data notifications.

Document Templates

Custom documents are built using document templates:

• Templates define which SDA data elements to include in the document
• Templates specify the document structure (sections, headers, content organization)
• Multiple templates can be created for different use cases (discharge summary, care plan, referral)
• Templates are managed through the Management Portal or custom configuration

SDA-Based Content Assembly

Custom documents are assembled from the patient's SDA container:

• The system extracts specified SDA streamlets based on the template definition
• Data can be filtered by date range, category, source facility, or other criteria
• Multiple SDA streamlet types can be combined into a single document
• The assembled content reflects the patient's current clinical record

Document Formats

Custom documents can be produced in various formats:

• CDA: Clinical Document Architecture documents conforming to CDA R2 or C-CDA standards
• HTML: Human-readable HTML documents for web-based viewing
• PDF: Formatted PDF documents for printing or archival
• Plain text: Simple text summaries for email or messaging delivery
• Custom XML: Organization-specific XML formats for system integration

Creating Custom Document Definitions

To create a custom document definition:

• Navigate to Clinical Message Delivery > Custom Documents
• Create a new document definition with a name and description
• Select the SDA streamlet types to include (diagnoses, medications, lab results, etc.)
• Define the document structure and section ordering
• Choose the output format and transformation class
• Associate the document definition with subscriptions for automated delivery

Integration with Subscriptions and Advanced Features

Custom documents integrate with CMD subscriptions:

• A subscription can specify a custom document as the delivery payload
• When the subscription fires, the system assembles the document from current patient data
• Advanced features include conditional sections, data aggregation across encounters, cross-reference links to the Clinical Viewer, and automatic consent filtering to exclude restricted data

---