Purpose of Go-Live Readiness

Go-live readiness ensures that:

• ADT messages can be securely received from the upstream source
• Patient enrollment is active and aligned with delivery expectations
• Routing and delivery paths are configured and validated
• Downstream systems are prepared to receive and process notifications

Confirming readiness before production activation reduces false escalations, avoids misinterpreting expected behavior as defects, and establishes a shared baseline for post–go-live support.

Readiness Scope and Boundaries

Go-live readiness applies to behavior within Health Gorilla platform boundaries. It does not validate or guarantee:

• Encounter generation at the source system
• Completeness of upstream HL7 v2 feeds
• Client-side system availability or processing behavior
• Encounter frequency or notification volume

Observed notification activity after go-live reflects real-world encounter patterns, enrollment timing, and upstream feed behavior.

Readiness Validation Areas

Go-live readiness is assessed across four primary areas:

Delivery Configuration

Delivery readiness confirms that ADT notifications can be routed and delivered to the intended destination.

This includes validating:

• The selected delivery method (API, VPN, SFTP, or UI access)
• Endpoint reachability and authentication
• Subscription or routing configuration
• Acknowledgment behavior for delivered messages

Patient Enrollment State

Enrollment readiness confirms that patients are eligible to generate ADT notifications when encounters occur.

This includes validating:

• Roster submission and processing outcomes
• Enrollment timing relative to expected encounters
• Correct handling of roster updates and superseding behavior

Message Flow and Processing

Message flow readiness confirms that HL7 v2 ADT messages can be ingested and processed once received.

This includes validating:

• Successful ingestion of test or sample messages
• Application of routing rules
• Delivery to the configured destination Message validation confirms technical readiness, not encounter completeness.

Client System Preparedness

Client readiness confirms that downstream systems are prepared to receive and interpret ADT notifications.

This includes validating:

• Endpoint availability
• Message parsing and acknowledgment handling
• Internal monitoring and alerting
• Ownership for post–go-live support

Go-Live Readiness Checklist

The following checklist is used to confirm readiness prior to production activation.

Delivery and Routing

• Delivery method is confirmed and documented
• Delivery endpoint is reachable and authenticated
• Routing and subscription rules are enabled
• Test notifications are successfully delivered

Enrollment

• Initial patient roster has been submitted
• Roster processing completed without blocking errors
• Enrollment timing has been reviewed and understood
• Ongoing roster update cadence is confirmed

Message Flow

• HL7 v2 ADT messages have been ingested successfully (when available)
• Routing rules apply as expected
• Delivery acknowledgments are received

Client Readiness

• Downstream system can receive and process notifications
• Monitoring and alerting are in place
• Internal ownership for ADT operations is identified
• Escalation and support paths are understood

Transition to Go-Live

Once readiness criteria are met:

• ADT Notifications are enabled for production delivery
• Implementation ownership transitions to steady-state operations
• Monitoring and troubleshooting workflows apply

Initial production activity may be low or intermittent depending on encounter volume and enrollment scope. This is expected behavior and should be evaluated in the context of readiness validation rather than volume expectations alone.