Business Continuity & Disaster Recovery

Healthcare interoperability is time-sensitive. When ConnectHL7 routes messages between systems, the reliable delivery of that data can support patient care. We design, back up, and test our platform with that responsibility in mind.

This page describes our approach to continuity and recovery at a high level.

---

Business continuity

Our goal is to keep the platform — and the business that operates it — running through disruption:

• The platform is built on redundant, multi–Availability Zone AWS infrastructure, so routine failures are absorbed automatically (see Infrastructure & Architecture).
• ConnectHL7 operates cloud-only, with no dependence on a single physical office or on-premise systems. Our team can operate securely from any approved location, which keeps critical functions running during localized disruptions.
• We maintain internal business continuity and disaster recovery plans that define critical functions, responsibilities, and recovery priorities, and we keep clear ownership for coordinating a response.

---

Disaster recovery planning

We maintain a documented disaster recovery plan for major disruptions such as a large-scale cloud service or regional event:

• Because our infrastructure is defined as Infrastructure as Code, we can rebuild our environment reliably rather than reconstructing it manually.
• Critical data is backed up and, for resilience, copied to a secondary AWS region.
• We have a defined process for declaring a disaster, coordinating recovery, and communicating with affected customers.

---

Backup strategy

Customer data is protected by automated, encrypted backups:

• Automated backups run on a defined schedule for our primary datastores.
• Point-in-time recovery is available for our relational databases, limiting potential data loss.
• All backups are encrypted at rest and in transit.
• Backups are retained according to defined schedules aligned to operational needs and customer commitments.
• Critical backups are copied across AWS regions to protect against a regional event.

For how encryption is applied, see Encryption & Data Protection.

---

Recovery objectives

We maintain internal Recovery Point Objectives (RPO) and Recovery Time Objectives (RTO) that reflect the criticality of each part of the platform, with the most aggressive targets applied to core healthcare message processing and the primary data store. These objectives guide our architecture, backup frequency, and recovery procedures.

Specific recovery objectives can be shared with enterprise customers under NDA as part of a security review.

---

Regular testing

A recovery capability is only real if it is tested:

• We test data restoration on a recurring basis to confirm that backups are complete and usable — a backup that has never been restored is not treated as reliable.
• We exercise our disaster recovery and business continuity plans on a regular schedule, validating both the technical recovery steps and our communication and coordination process.
• Findings from tests feed back into improvements.

---

Operational resilience

Resilience is a product of design, not luck. The same choices that make our platform secure also make it durable: managed, redundant AWS services; multi–Availability Zone deployment; infrastructure defined as code; automated deployments that reduce human error; and continuous monitoring that surfaces problems early. Together these reduce both the likelihood and the impact of disruption.

---

Related: Infrastructure & Architecture · Encryption & Data Protection · Security Overview · Security FAQ

Last updated: 1 July 2026