Secure Healthcare Data Exchange: Best Practices That Hold Up Past the Transport Layer

Most secure healthcare data exchange reviews happen after the integration is already live. A new system goes in, data starts moving between it and ESR or Spine or a clinical system, and a few months later an IG Lead asks the question that actually matters: who can see what, and can you prove it. In most Trusts, the honest answer is that the transport is encrypted. Everything past that point is a shrug.

That gap is the subject of this piece. Encryption in transit is table stakes. It is also where a lot of integration security thinking quietly stops, which is why it keeps failing the review it was supposed to pass. Secure healthcare data exchange is not a property of the connection. It is a property of the whole path a record takes, from the moment your platform requests it to the moment someone has to account for it.

This is written for the IT Lead, Digital Lead, or CTO who owns the integration estate and keeps being handed the "is this secure" question with no clean way to answer it.

On paper, secure exchange looks like a checklist: TLS, a firewall rule, a signed data sharing agreement, a green tick in the DSPT. In practice, none of those tell you whether a specific patient record was handled correctly on a specific Tuesday.

The useful way to think about it is by lifecycle rather than by connection. A record moving from PDS into a downstream system passes through at least five distinct stages: your platform authenticates and requests it, reads a set of fields, transforms them into the shape the destination expects, writes them, and logs (or fails to log) what just happened. Each of those stages is a separate security surface. Encryption protects one of them: the bit in flight. The other four are where the real questions live.

So when someone asks "is this integration secure", the precise version of the question is: is access scoped to the minimum, is data minimised before it moves, is every exchange provable at the record level, and can you cut access off cleanly if you need to. A platform that only has an answer for the transport layer is not secure. It is encrypted, which is a different and much smaller claim.

The weaknesses are consistent across estates, and they rarely show up in a normal health check because the happy path keeps working. They surface in a penetration test, an IG audit, or an incident.

The first is standing broad credentials. Many Trust integrations authenticate once with a service account that can read far more than the integration ever uses, and that credential never expires. If it leaks, or if the supplier relationship ends, the blast radius is the entire scope of that account, not the handful of fields the integration actually touches.

The second is moving more than the destination needs. A rostering integration that needs three demographic fields will often pull the whole record because that is what the source endpoint returns and nobody trimmed it. Every field that travels is a field you now have to secure, log, justify, and potentially breach.

The third is transformation blind spots. The HL7v2 to FHIR R4 transform, or the mapping into a normalised model, is where data is reshaped, and it is frequently where logging goes dark. You can often see that a message arrived and that a message left. What happened in between, and whether it was correct, is invisible.

The fourth is job-level logging. Most ESR and Spine integrations log at the job level: the run started, the run finished, this many rows moved. When IG asks why a particular record shows what it shows, or a data subject exercises a right, job-level logs cannot answer at the resolution the question demands.

The fifth is having no revocation story. Ask a Trust how it would cut off one integration's access, today, without taking down the rest of the estate. The pause before the answer is the finding.

These are the practices that survive a real security review rather than a self-assessment. They apply whether the exchange runs over MESH, a FHIR R4 API, or a direct system connector.

1. Make least privilege a field-level decision, not a system login. Scope each integration to the minimum resources and fields it needs, with its own service identity, not a shared master account. Where you are talking to FHIR R4 endpoints, use scoped access (SMART on FHIR scopes) rather than blanket read. The test is simple: if this integration's credential leaked tomorrow, how much could an attacker reach. That number should be small by design, not by luck.
2. Minimise at the transform, before the payload leaves you. Filter to the fields the receiving system actually consumes before anything crosses the boundary. Do not move a full PDS record when three fields will do. Data minimisation is a UK GDPR principle, but for an integration platform it is also an attack-surface decision: the data you never moved is the data you never have to defend.
3. Make every exchange provable at the record level. Log what was read, what it was transformed into, what was written, by which integration, and under which lawful basis, with before-and-after values on the fields that changed. This is the single thing that turns an IG or DSPT conversation from painful into short. Job-level logging cannot do it. Field-level logging is the difference between "we think so" and "here is the record."
4. Build revocation and rotation in from day one. Assume a credential will leak and a supplier will eventually be offboarded. Design so you can rotate secrets on a schedule and revoke a single integration's access without collateral damage to the rest of the estate. If revocation requires a change freeze and a war room, it is not a control, it is a hope.
5. Validate the payload, do not just move it. Schema validation, terminology checks against the transform, and reject-and-alert on malformed messages rather than silent pass-through. A corrupted or mismapped clinical message is not only an integrity problem, it is a clinical safety one, which is exactly what DCB 0129 and DCB 0160 exist to force you to think about. Secure exchange includes not delivering wrong data confidently.
6. Isolate by Trust and by environment. In any multi-tenant or multi-Trust setup, no shared secrets across tenants, and hard separation between environments. UAT should never touch live patient identifiable data. Most accidental exposures are not clever attacks, they are a test job pointed at the wrong endpoint because the environments were not truly isolated.

Two things are moving the baseline for secure healthcare data exchange, and both push in the same direction: prove it, do not just assert it.

The CAF-aligned Data Security and Protection Toolkit, now at version 8, has shifted assurance away from checklist compliance toward outcome-based, evidence-driven assessment against the NCSC Cyber Assessment Framework. The relevant point for integration owners is that "we encrypt in transit" is no longer a satisfying answer. Assessors are looking for demonstrable outcomes across access control, logging, monitoring, and incident readiness, which is precisely the field-level, revocable, observable design described above.

The Data (Use and Access) Act 2025 adds a second pressure specific to suppliers. Its extension of information standards to IT providers, not only to health and care organisations, means the systems that move NHS data will be expected to meet common standards for interoperability and secure sharing in their own right. For anyone building or buying an integration platform, "the Trust is compliant" stops being enough. The platform has to carry its own weight.

Neither of these rewards a platform that stops at the transport layer. Both reward the one that can produce a record-level account of what it did.

Secure healthcare data exchange is not the connection. It is whether you can scope access to the minimum, minimise what moves, prove what happened at the record level, and cut access off cleanly when you need to. Encryption in transit gets you one of those four, and it is the one everyone already has.

If you want a single place to start this week, pull one live integration and ask two questions of it: what could this credential reach if it leaked, and can we produce a field-level account of the last record it moved. Whatever the answers are, they will tell you exactly where your exposure sits, and the fix for one integration is the pattern you will reuse for the rest of the estate.

If you are working through how secure exchange should actually be architected across your Trust, that is a conversation WeHub's integration team is glad to have.