How a Passthrough CDC Architecture Keeps Patient Data Off Vendor Infrastructure Entirely

Passthrough change data capture (CDC) replicates patient data in real time without writing a copy to the replication vendor’s storage. Its central advantage is structural rather than contractual, making the transport layer a conduit instead of another custodian of protected health information (PHI). For healthcare teams evaluating managed CDC, that distinction connects compliance exposure, data residency, and delivery latency to one architectural choice.

Why vendor infrastructure is the hidden PHI risk in healthcare data pipelines

Conventional healthcare data pipelines can turn the transport layer into an inadvertent PHI store. Ingestion, transformation, transport, and loading each serve distinct purposes, but conventional ETL platforms often receive data, stage it on vendor infrastructure, and then forward it. That intermediate copy creates another place where patient information must be protected. Encryption alone does not remove that custody. Even a buffer that holds PHI for a short time puts it on systems outside the customer-controlled source and destination.

A Business Associate Agreement (BAA) governs the vendor’s responsibilities for that information, but it does not remove the storage location or its attack surface. The architectural concern therefore precedes the contract. A replication service may need to read changes without keeping its own stored copy of what they contain. What would a pipeline look like if the transport layer held no copy of PHI at all?

What passthrough CDC architecture means structurally

Passthrough CDC reads changes from a source database’s transaction log and delivers them directly to a customer-controlled destination without buffering a copy on vendor servers. The replication layer reads, encrypts in transit, and delivers. It does not write PHI to vendor storage. Unlike conventional ETL staging, this model leaves stored patient data at the source and destination rather than adding an intermediate repository.

Field-level encryption with customer-managed keys adds another way to protect the data. Data is encrypted before it leaves the source network, and decryption needs keys the vendor does not have. Storage avoidance and key ownership address different exposures. Storage avoidance removes the intermediate copy, while key ownership limits how much of the data being sent the vendor can read. Together, these properties narrow the vendor-side custody addressed by the BAA toward agent credentials and the control plane.

How each database's replication mechanism works in a passthrough model

PostgreSQL uses logical decoding to read its write-ahead log (WAL) and stream row-level changes through a replication slot. Events arrive in commit order, and the mechanism captures deletes and old row values without an extra write on the source table. The operational constraint is retained log data. If the consumer falls behind, the WAL keeps data until the replication slot catches up, so it uses more disk space. Production healthcare pipelines thus need replication-slot lag monitoring even when the transport service stores no PHI itself.

MongoDB exposes change streams over its oplog, the journal already maintained for replica set replication. Reading that journal adds almost no source overhead. MongoDB 4.0 is the practical minimum for CDC use cases, while version 6.0 and above is the preferred baseline for before-and-after document images. Standalone instances do not support change streams, so a replica set or sharded cluster is required. Resume tokens let a consumer resume after a network failure, but MongoDB’s change-stream documentation specifies at-least-once semantics, leaving duplicate handling to the listening application.

DynamoDB exposes changes through managed streams. DynamoDB Streams has a firm 24-hour retention window. A consumer that falls behind that window loses events irretrievably, making rapid failure recovery a production requirement. The pipeline must also handle stream view configuration, shard iterators, correctly scoped IAM permissions, and shard splits. Across all three databases, native log or stream infrastructure makes passthrough possible, but the tool above it either passes events through or buffers them on vendor infrastructure.

What HIPAA's requirements actually demand from the transport layer

Under HIPAA’s Security Rule, the choice of how to transport electronic PHI must account for safeguards that include access controls, audit logs, and secure transmission. Encryption is a central protection, but HIPAA does not name a specific cipher as a universal requirement. Role-based access is a common recommended approach. It is not the only access-control method the rule permits. A signed BAA establishes the business associate’s direct responsibilities, including safeguarding obligations and breach notification.

When a vendor buffers PHI on its infrastructure, those responsibilities extend to the stored copy. Passthrough removes that particular repository from the compliance surface. The vendor still has responsibilities for its control plane, credential management, and handling of the transmission. The narrower scope follows from the absence of stored PHI, not from a general exemption for a service described as a conduit. This distinction helps covered entities judge the vendor’s responsibilities when they cannot check directly whether its systems cache, log, or keep patient information.

Proposed Security Rule updates would add requirements for multi-factor authentication, encryption, proactive vulnerability scanning and penetration testing, and annual verification of business associates’ technical safeguards. The proposed updates would also require notification within 24 hours of activating a contingency plan. Their direction nevertheless favors stronger accountability for the systems through which PHI moves. Cutting vendor custody that the pipeline does not need is a sound design choice even if the proposals never become final.

Why the BAA alone does not contain the vendor-custody risk

A well-drafted BAA allocates legal duties, but it cannot remove the infrastructure on which a breach could occur. Accountability and attack surface are separate problems. Security controls address the protection of a vendor-held copy, while passthrough questions whether that copy needs to exist. A reputable vendor can still introduce unnecessary custody if its platform stages patient data merely because that is how the tool was built.

The Change Healthcare incident illustrates the downstream consequences of dependence on a business associate. HHS and OCR confirmed that BAAs were in place, yet the compromise disrupted covered entities that relied on the vendor. The AMA’s survey found that practices lost revenue from unpaid claims and could not submit claims, with small practices hit hardest. Contracts did not prevent that operational disruption. For independent practices, a vendor failure could affect the services on which daily work depended.

Healthcare organizations also use many cloud services, so they must check how more vendors handle PHI. Each service that holds data adds another party with custody of it. Removing vendor-side storage from a pipeline reduces that exposure without claiming that contracts or security controls are unnecessary. The replication function should be assessed for its need to possess a stored copy.

The cross-border dimension that HIPAA alone does not cover

The Department of Justice’s rules under Executive Order 14117 took effect on April 8, 2025, and restrict transfers of bulk U.S. sensitive personal data to certain foreign countries and entities. These rules also cover de-identified and encrypted health data. Vendor processing infrastructure that spans international regions can create exposure under these restrictions even when patient information is not transferred in plaintext.

A customer-hosted data plane addresses that exposure at the deployment level. In a bring-your-own-cloud (BYOC) model, the vendor can operate the control plane while the data plane runs within the customer’s VPC. Operational management is separated from patient-data processing. When the data path remains inside the customer-controlled environment, it avoids foreign vendor infrastructure rather than relying on encryption to make that route acceptable. Passthrough describes whether the service stores a copy, while BYOC establishes where its data processing runs, so the two properties answer related but distinct questions.

This distinction makes data residency a first-class architectural requirement. A BAA alone cannot make a restricted international transfer comply with the rules. Healthcare teams must therefore evaluate the data plane’s location as well as its storage behavior, rather than treating HIPAA contracting as the complete regulatory boundary.

Schema evolution as the operational challenge passthrough CDC cannot defer

Removing the vendor-side buffer also takes away a place to handle schema changes before they reach the destination. A column addition, type change, or table rename reaches the replication path immediately. There is no staging layer to defer it. Because schema drift often breaks production pipelines, a passthrough service must detect those changes and make matching changes at the destination without manual intervention or pipeline downtime. In healthcare, an interruption can prevent PHI from reaching necessary systems and create a potential compliance gap when audit logs or clinical records are affected.

Teams must also plan for consistency, because data can reach the destination without leaving it in a correct state. With at-least-once delivery, events can replay after a failure. Exactly-once results in practice require idempotent writes at the sink, including MERGE operations keyed on primary keys so that reprocessing an event produces the same result as processing it once. A tool that avoids vendor storage but drops events or leaves duplicates at the destination has exchanged one problem for another.

Healthcare teams should assess automated schema evolution and destination idempotency as core capabilities. Failure recovery must restart the stream and keep the destination usable.

Why real-time replication and passthrough are mutually reinforcing in healthcare AI

Clinical decision support depends on information that is current when a care team acts. A batch refresh every several hours can leave an AI system answering from an outdated patient record. Freshness is therefore part of the operational requirement. CDC delivery within 60 seconds gives near-real-time feature stores, AI agents, patient risk scoring, and dashboards fresh data in place of an hours-old refresh. That target must be delivered by the pipeline.

Passthrough supports this goal because continuous delivery removes the vendor staging step that would otherwise add dwell time. The same property serves two purposes at once. Avoiding vendor-side buffering gives the vendor less custody of PHI and cuts the time it takes for changes to reach the destination. This aligns the compliance design with the latency requirement while leaving the database-specific constraints on lag, retention, and recovery in place.

The recommended clinical ingestion pattern combines streaming for near-real-time vitals and event-driven data with CDC from transactional databases. An AI agent operating on stale inputs can produce unreliable outputs, which makes freshness a patient-safety concern. The replication path is consequently part of the foundation on which the clinical system’s trustworthiness depends.

How do you evaluate managed CDC for HIPAA and SOC 2 environments?

For teams seeking managed CDC for HIPAA and SOC 2 environments, the architecture review should follow the data. First, establish whether the platform stores customer data on vendor infrastructure at any point. A second question concerns deployment location. Can the vendor provide a BYOC or customer-VPC data plane that keeps PHI inside the customer’s network perimeter? The BAA discussion should then identify the actual scope of data handling and distinguish control-plane and credential responsibilities from any custody of the data stream.

Operational questions make that architecture testable in production. Teams should ask how source schema changes reach the destination and whether manual intervention is required. Delivery guarantees need a concrete explanation of sink idempotency. The review should also establish the published CDC latency SLA and how failure recovery works within source retention limits. A managed passthrough service must meet these requirements together, because neither storage avoidance nor fast delivery compensates for missing or inconsistent records.

AWS DMS provides a factual reference point for this comparison. AWS documentation states that its replication instance runs on an Amazon EC2 instance in a customer VPC and reads changes through native database engine interfaces. That places replication processing on third-party cloud infrastructure within the customer VPC, a deployment fact that leaves passthrough behavior to be verified separately. AWS DMS documentation also states that CDC does not provide real-time replication and that there are no SLAs for CDC latency. Those properties should be assessed against the healthcare workload’s requirements without treating all managed deployment models as equivalent.

A managed passthrough service can instead package schema evolution, idempotent delivery, and failure recovery without requiring the healthcare team to operate its own log-capture infrastructure. A tool that takes more than an hour to deploy or requires a multi-month infrastructure build retains a substantial implementation burden. Healthcare data teams do not have two years to build CDC infrastructure, and managed services can implement the passthrough architecture today when their data path and operational guarantees meet these criteria.