No Data at Rest: Designing a Healthcare Transaction Layer That Leaves No PHI Behind

Healthcare organizations need their data to move — not to accumulate. Every time a claim, eligibility feed, HL7 event, or FHIR bundle is copied into staging tables, message queues, logs, or backups on its way somewhere else, the organization inherits a new PHI asset to secure, monitor, retain, and eventually destroy. Brandywine Consulting Partners' Transaction Layer Integration service is engineered on the opposite premise: process the transaction, deliver it, and keep none of the client payload at rest.

At a glance

• ▸A single healthcare integration commonly spawns 4–7 additional persistent copies of PHI before it reaches its destination.
• ▸BCP's Transaction Layer Integration retains zero client payload in BCP-controlled infrastructure — only synthetic correlation metadata.
• ▸Supports X12, EDI, HL7 v2, FHIR, JSON, XML, flat-file, and proprietary formats between legacy and modern systems.

Healthcare organizations need their data to move.

Eligibility records must reach care-management platforms. Claims must be transformed for payers, clearinghouses, analytics platforms, and regulatory systems. Clinical events must move between electronic health records, health information exchanges, laboratories, applications, and downstream vendors. Prior-authorization requests increasingly must cross between modern FHIR APIs and systems still dependent on X12, HL7, flat files, or proprietary formats.

The problem is that traditional healthcare integration architecture often creates another data repository in the process.

An incoming file is written to an SFTP landing directory. It is copied into a staging database. A transformation engine creates an intermediate version. A message broker stores another copy. Application logs capture part of the payload. A backup service preserves the staging environment. An observability platform records a failed request body.

A single transaction may consequently produce multiple additional copies of protected health information before it reaches its destination.

Each copy expands the healthcare organization's data footprint. It also introduces another asset that must be identified, secured, monitored, retained, backed up, restored, governed, and eventually destroyed.

At Brandywine Consulting Partners, we believe many healthcare integration workflows do not need to create that additional data estate.

Our Transaction Layer Integration service is designed as a zero-retention transactional bridge between client-controlled data sources and authorized downstream systems. BCP receives the transaction, processes it in volatile runtime memory and controlled transient buffers, performs the required validation and transformation, forwards the result to the designated destination, and immediately discards the client payload.

BCP does not retain the client's source data, transformed data, PHI, PII, or transaction artifacts at rest within BCP-controlled infrastructure.

The transaction passes through BCP. It does not take up residence there.

Encryption is an essential security control. It is not, however, the same as eliminating unnecessary persistence.

An encrypted database still contains the data. An encrypted backup still contains the data. An encrypted message queue still contains the data. Each requires identity and access controls, cryptographic key management, retention policies, backup controls, disaster-recovery procedures, monitoring, testing, and incident-response planning.

The data remains part of the organization's attack surface and governance scope.

A zero-retention architecture addresses the problem differently. Instead of asking only how another stored copy should be protected, it first asks whether that copy needs to exist.

This is a data-minimization decision expressed through architecture.

The HIPAA Security Rule applies to electronic protected health information that an organization creates, receives, maintains, or transmits. Transient processing does not remove an organization's responsibility to protect the information while it is being handled. It can, however, reduce the number of places in which the information is maintained after processing has concluded.

Similarly, the HIPAA minimum necessary standard is based on limiting unnecessary or inappropriate access to and disclosure of protected health information. Although its application depends on the specific use and disclosure, the underlying principle supports deliberate limitation of the data used to perform a defined function.

BCP applies that philosophy to integration:

Process only what the transaction requires, keep it only for the duration of the transaction, and retain only the non-sensitive operational evidence needed to prove that the transaction occurred.

Regulatory anchors at a glance

For Brandywine's Transaction Layer Integration service, zero retention means that client payloads and client data artifacts are not persistently stored in BCP-controlled infrastructure.

The standard processing profile is designed around the following requirements:

• ▸Client payloads remain only in volatile runtime memory and approved transient processing buffers during active execution.
• ▸Source files are not copied into a permanent BCP staging directory.
• ▸Transformed output is not retained in a BCP database, data lake, file share, or object-storage account.
• ▸Message content is not placed in a persistent BCP-controlled replay queue.
• ▸PHI and PII are excluded from application, audit, diagnostic, and operational logs.
• ▸Request and response bodies are excluded from application-performance monitoring.
• ▸Failed payloads are not written to debug files, exception traces, crash dumps, or dead-letter repositories.
• ▸Successfully delivered payloads are released from memory immediately after the destination disposition is confirmed.
• ▸Operational visibility is maintained through summary-level metadata rather than copies of the underlying healthcare data.

Zero retention does not mean that the transaction is not controlled, monitored, validated, or auditable.

It means that BCP separates the evidence about the transaction from the sensitive content within the transaction.

A zero-retention integration requires more than deleting a temporary file after the process completes. Persistence must be prevented throughout the transaction lifecycle.

BCP's transactional pattern consists of the following stages.

1. Authenticate the source and establish the connection

The transaction is accepted only from an authorized source through an approved transport mechanism. Depending on the client and destination architecture, connectivity may include mutual TLS, secure APIs, SFTP, PGP-encrypted file exchange, private endpoints, site-to-site VPN connections, zero-trust network access, client-managed secure file locations, and controlled vendor endpoints.

Authentication and authorization are evaluated independently of network location. This aligns with zero-trust architecture principles, under which no implicit trust is granted solely because a user, workload, or system is located inside a particular network boundary.

2. Validate the transaction envelope

Before the payload is transformed, BCP validates the transaction's technical envelope. This may include file naming conventions, sender and receiver identifiers, file and content type, control numbers, transaction-set identifiers, schema versions, character encoding, required headers, expected segment structure, digital signatures, encryption status, payload size limits, and duplicate transaction indicators.

Invalid or unauthorized transactions fail closed. They are not passed into the transformation process merely because they reached the integration endpoint.

3. Load the payload into an isolated runtime context

The payload is loaded into an isolated execution context using volatile memory and tightly controlled processing buffers.

The runtime is configured to prevent common sources of unintended persistence, including default temporary-file creation, framework-level request-body caching, message-body tracing, automatic diagnostic capture, operating-system crash dumps, application heap dumps, uncontrolled page-file or swap usage, antivirus quarantine of payload artifacts, development-level debug output, automatic platform snapshots, and backup of processing workspaces.

This point is critical. An architecture cannot credibly claim zero retention while allowing its integration framework, operating system, monitoring agent, or cloud service to persist copies outside the primary application workflow.

Zero retention must be validated across the entire runtime stack.

4. Normalize and transform the data

BCP applies the required mapping and transformation logic while the transaction remains in the isolated runtime context.

Supported transformation patterns include:

• ▸X12 ↔ X12, JSON, XML, or FHIR
• ▸FHIR ↔ legacy healthcare formats
• ▸HL7 v2 ↔ JSON or FHIR
• ▸JSON ↔ proprietary vendor formats
• ▸CSV / spreadsheet data ↔ X12 transactions
• ▸Proprietary source files ↔ canonical healthcare structures
• ▸API payloads ↔ batch files

Examples can include eligibility, claims, remittance, clinical-event, laboratory, care-management, utilization-management, and prior-authorization transactions.

FHIR has become a widely used API-focused standard for representing and exchanging healthcare information, but healthcare organizations continue to operate environments containing X12, HL7 v2, EDI, flat-file, and proprietary interfaces. BCP's Transaction Layer Integration service is designed to operate between those environments without requiring the client to replace every source or destination system first.

5. Apply validation and business rules

Transformation is not complete simply because an output file or API message can be generated. The transformed transaction must also be evaluated for structural and business validity.

Depending on the use case, BCP validation can include required-field validation, code-set validation, data-type and format validation, segment and loop validation, date-sequence validation, claim balancing, header and trailer balancing, member and subscriber relationship checks, provider identifier validation, control-number reconciliation, record-count reconciliation, duplicate detection, source-to-target completeness, client-specific business rules, and vendor-specific implementation requirements.

The objective is to prevent structurally valid but operationally unusable transactions from reaching the downstream system.

6. Transmit the transformed transaction

Once the transaction passes validation, it is transmitted directly to the authorized downstream endpoint via synchronous API request, asynchronous client-controlled endpoint, SFTP destination, vendor intake directory, secure integration API, private network connection, client-owned queue, healthcare clearinghouse, or destination payer, provider, EHR, laboratory, or analytics platform.

BCP does not use a persistent BCP-controlled data store as an intermediary system of record.

7. Confirm the destination disposition

Where the destination supports it, BCP captures the technical disposition of the delivery: HTTP status, API acknowledgment, X12 functional acknowledgment, file-transfer confirmation, vendor receipt confirmation, transaction acceptance or rejection, destination control number, completion timestamp, processing latency, and rejection category.

The disposition is associated with a synthetic correlation identifier that is not derived from a member identifier, patient identifier, claim number, Social Security number, or other sensitive data element.

8. Release and discard the payload

After the destination disposition has been evaluated, the processing context is terminated and the transaction payload is released.

BCP retains no source file, transformed file, message body, database record, API payload, clinical document, or client artifact from the completed transaction. Only approved operational metadata remains.

Healthcare organizations need evidence that integrations are operating correctly. They do not necessarily need a second copy of every transaction to produce that evidence.

The HIPAA Security Rule's audit-controls standard requires regulated entities to implement mechanisms that record and examine activity in information systems containing or using electronic protected health information. It does not mean that application logs should become an uncontrolled repository of PHI.

BCP maintains summary-level runtime logs designed to support monitoring, reconciliation, troubleshooting, and audit review without reproducing the transaction content.

Application logging must be intentionally designed because excessive or poorly configured logging can cause sensitive information to be captured unnecessarily. BCP therefore treats logging as part of the security architecture, not as an unrestricted troubleshooting convenience.

Retry handling is one of the most important architectural decisions in a zero-retention integration. Traditional platforms frequently retain a complete copy of a failed transaction so it can be replayed later. That approach is operationally convenient, but it creates another persistent PHI repository.

BCP's standard zero-retention pattern uses one of three controlled approaches.

Source-controlled resubmission. The source system remains the transaction system of record. If the destination is unavailable or the transaction fails before confirmed delivery, the source resubmits the transaction using the BCP correlation ID and status metadata.

Client-controlled queuing. When delayed delivery is required, the transaction remains in a queue, database, or storage environment controlled by the client. BCP processes the transaction only when delivery can be attempted.

Synchronous failure with metadata-only evidence. The transaction fails closed, the payload is discarded, and BCP records only the non-sensitive failure category and correlation information. The source receives a failure response and determines the appropriate resubmission action.

This model preserves zero retention within BCP while allowing the client to select the resilience strategy that fits its operational and regulatory requirements.

If a workflow cannot function without BCP persistently retaining the payload, it does not meet the standard Transaction Layer Integration zero-retention profile. Any exception would require a separately designed, explicitly approved, and contractually defined architecture.

BCP's Transaction Layer Integration service is particularly valuable when an organization needs data transformation but does not want to create another third-party data repository. Common scenarios include:

• ▸Payer-to-vendor transactions — a health plan providing eligibility, claims, care-management, utilization-management, or provider data to an authorized vendor that must not retain the data.
• ▸Provider-to-payer / clearinghouse exchange — bidirectional 837/835/270/271/276/277 exchange without provisioning an intermediary system of record.
• ▸FHIR ↔ legacy bridging — modern applications consuming FHIR while the source or destination still speaks X12, HL7 v2, or a proprietary format.
• ▸Sensitive automation workflows — replacing local staging folders, manual downloads, spreadsheet copies, email attachments, and operator-controlled file movement with a controlled, auditable, no-retention path.

Zero retention is powerful, but it should not be applied indiscriminately. A persistent client-controlled or separately governed data platform may still be required when the workflow depends on longitudinal patient or member history, cross-transaction state management, enterprise master-data management, multi-period reconciliation, regulatory records retention, manual clinical review, human exception remediation, historical analytics, model training, large-scale event replay, long-duration destination outages, or legal hold requirements.

In these situations, BCP can use a hybrid architecture in which persistent data remains in a client-controlled environment while BCP provides stateless transformation, orchestration, validation, and delivery services.

The objective is not to eliminate persistence where it is required. The objective is to prevent unnecessary persistence where it is not.

A conventional integration vendor may become an additional custodian of the client's data. BCP's Transaction Layer Integration service is designed to avoid that outcome.

BCP owns and operates the capabilities required to move the transaction — connectivity, transformation logic, mapping rules, validation, orchestration, security controls, runtime execution, destination delivery, operational monitoring, and summary-level audit evidence.

The client retains ownership and control of the data itself.

The client owns the data. BCP owns the secure movement and transformation of the transaction.

The result is an integration layer that connects systems without becoming another source of data duplication, retention risk, vendor lock-in, or uncontrolled PHI exposure.

A no-data-at-rest architecture should never be presented as a shortcut around healthcare security or compliance.

BCP still receives and processes sensitive information. The runtime environment, identities, network pathways, transformation logic, credentials, monitoring controls, and operational procedures must therefore be secured and governed appropriately.

Zero retention reduces one category of risk: unnecessary persistence. It does not eliminate the need for risk analysis, access control, authentication, encryption in transit, secure key and certificate management, network segmentation, vulnerability management, change control, secure software development, incident response, availability planning, vendor governance, business associate obligations, interface testing, or audit-control design.

The architecture supports a reduced data footprint. It does not, by itself, establish compliance for either BCP or the client. Compliance depends on the complete implementation, the nature of the transaction, the parties involved, contractual requirements, applicable regulations, and the organization's risk-management program.

Healthcare organizations should not have to choose between interoperability and control of their data. They should also not have to accept that every new interface requires another database, another file archive, another backup set, another repository of production payloads, and another location in which PHI can be exposed.

Brandywine Consulting Partners' Transaction Layer Integration service offers a different model. We connect the source to the destination. We validate the transaction. We transform X12, EDI, FHIR, HL7, JSON, XML, flat-file, and proprietary healthcare formats. We deliver the result to the authorized endpoint. We retain the operational evidence needed to manage the process.

We do not retain the client's data.

That is the purpose of a true transaction layer: enable the exchange without becoming another data owner.

Brandywine Consulting Partners helps healthcare organizations modernize interoperability while maintaining control over where their data resides. Our Transaction Layer Integration service provides a secure, zero-retention bridge across legacy and modern healthcare systems — X12, EDI, FHIR, HL7, JSON, XML, API, batch, and proprietary vendor formats.

Explore related capabilities: Integration Services · Cloud-Native Azure · FHIR / HL7 / EDI Expertise · HIPAA / HITECH / ONC.

Talk with BCP about designing a healthcare integration architecture that moves your data without creating another place to store it.