Implement Clinical Alerts

Clinical Alerts is document-driven and asynchronous. Alerts are generated only when enrollment is active and qualifying document retrieval is processed within an active observation window. Delivery configuration controls transmission only and does not affect eligibility or alert timing.

Implementation requires activation, delivery configuration, enrollment setup, end-to-end validation, and ongoing monitoring.

Step 1: Confirm Prerequisites

Confirm activation and technical readiness before configuration.

• Clinical Alerts is enabled for your Health Gorilla tenant.
• The tenant or subtenant receiving alerts is clearly identified.
• Patients to be enrolled exist as Health Gorilla FHIR Patient resources.
• Your downstream system can receive, acknowledge, and process notifications in an idempotent manner.

Proceed only after these conditions are met.

Step 2: Configure Delivery

Configure delivery so alerts can be transmitted once generated. Only one delivery method may be active per tenant.

Option A: FHIR Subscription

Use this method to receive alerts via HTTPS POST requests.

1. Provide your HTTPS endpoint URL.
2. Confirm network allowlisting and TLS requirements, if applicable.
3. Ensure your system returns a 2xx status code to acknowledge receipt.
4. Enable inbound logging to capture stable identifiers such as Encounter.id and subject.reference.

After configuration:

• Confirm that your endpoint receives a Clinical Alerts notification.
• Confirm that your system acknowledges and parses the payload.
• Confirm that identifiers are stored for downstream deduplication and correlation.

Option B: Secure File Transfer Protocol (SFTP)

Use this method to receive alerts as files.

1. Provide the SFTP host, port, and authentication details.
2. Provide the target directory for file delivery.
3. Confirm network access and TLS configuration, if applicable.
4. Ensure your system monitors and ingests delivered files.

After configuration:

• Confirm that an alert file is delivered to the configured directory.
• Confirm that your system ingests and processes the file successfully.
• Confirm that identifiers such as MSH-10 and PID-3 are captured when applicable.

Delivery configuration controls transmission only. It does not influence eligibility or alert timing. Delivery failures do not prevent alert generation, and notification ordering is not guaranteed.

Step 3: Enroll Patients

Enrollment determines which patients are eligible for alert generation. Eligibility is enforced at processing time within an active observation window.

Limited Enrollment

Use this model to monitor a defined patient population.

1. Create a FHIR Group resource.
2. Add patients to the group.
3. Validate group membership.
4. Maintain membership as patient eligibility changes.

Enrollment changes apply prospectively.

All-Tenant Enrollment

Use this model to monitor all patients associated with your tenant.

• All patients linked to the tenant are automatically eligible.
• Individual patients cannot be selectively excluded while this model is active.
• Newly available patients are included automatically.

Enrollment does not initiate document retrieval and does not generate alerts independently.

Step 4: Validate End-to-End Behavior

Validate that enrollment, alert generation, delivery, and document retrieval function together as expected.

1. Confirm a patient is enrolled.
2. Confirm qualifying document-driven activity was processed.
3. Confirm an alert is received through the configured delivery method.
4. Confirm your system parses and stores stable identifiers.
5. Retrieve associated clinical documents through Patient360 when follow-up is required.

Validation requires observed qualifying activity. The absence of alerts does not necessarily indicate system failure, as alert generation depends on document availability and network participation.

Alerts provide notification context only and do not include clinical documents.

Step 5: Confirm Operational Readiness

Before go-live, confirm the following:

• Delivery and enrollment are active and validated.
• Your system acknowledges FHIR deliveries or ingests SFTP files successfully.
• Idempotent downstream handling is implemented.
• Monitoring is in place for delivery failures or delays.

Clinical Alerts is asynchronous. Alerts may be delivered hours or, in some cases, days after the underlying care event, and ordering relative to other events is not guaranteed.

Ongoing Monitoring

After go-live:

• Monitor webhook response codes or SFTP ingestion.
• Deduplicate alerts using stable identifiers.
• Expect alert volume to vary based on enrollment size, network participation, and document availability.

If alerts are not received as expected:

• Confirm patient enrollment.
• Confirm delivery health.
• Confirm qualifying document-driven activity was processed.
• Confirm enrollment was active at processing time within an observation window.