A partner integration that was provisioned to look up a handful of patients runs Patient/$everything against forty thousand of them, a few hundred a night, for six weeks. Every call carries a valid token. Every call is scoped correctly. Every call is logged. By the time anyone counts, a population's records are sitting on infrastructure you do not control, and no control fired, because you built the interface to answer exactly those calls.
For two decades, making records move was the hard part. FHIR, the 21st Century Cures Act, the information-blocking rules, the health information networks: the whole stack was built to make records flow freely across organizational lines. It worked. Records move now. The security question changed underneath everyone, and most health-data teams are still answering the old one.
The old question was access control: who is allowed to read this record. That one is largely settled. APIs are authenticated, scopes are scoped, OAuth is wired, data-use agreements are signed. The question almost no tool asks is the new one: across all the access you granted on purpose, is the pattern of movement still normal?
Interoperability is movement by design
Every other security domain treats data leaving a system as an exception to investigate. Health-data exchange inverts that. Movement is the product. A FHIR API exists so records flow out of the EHR. A health information network exists so a record requested in one state arrives from a provider in another. A patient-facing app exists so the data lands on a phone you do not control.
So the sanctioned interface is the exfiltration path. Not metaphorically. The same authenticated Patient/$everything call that lets a new provider pull a full history is the call that, repeated against thousands of patients by a partner who was supposed to query a handful, drains a population.
This is the permitted-pattern blind spot, and health-data exchange is where it lives in its purest form. No credential is stolen. No rule is violated. Permitting the move is the entire reason the interface exists. The breach is the pattern across the moves, and that pattern is invisible to any tool that judges moves one at a time.
What the existing stack actually checks
Walk the controls a mature health-data platform runs, and notice what each one answers.
The API gateway checks the token: valid, unexpired, correctly scoped. It answers is this caller allowed to ask. It is good at that. It does not answer whether a caller who is allowed to ask is asking in a shape that no legitimate workflow produces.
The consent and data-use layer checks the agreement: this network may query for treatment, this app has the patient's authorization. It answers is this purpose permitted. It does not watch whether the volume and cadence behind that purpose match what treatment-driven access looks like.
Rate limiting checks throughput against a ceiling. A patient app that bulk-pulls just under the cap, steadily, off-hours, for weeks, never trips it. A ceiling tuned not to break legitimate integrations is a ceiling a patient exfiltration pattern slides beneath.
Audit logging records that the access happened. It answers the question after the disclosure letter is already being drafted. By design it is the forensic record, not the runtime signal.
None of these is wrong. Each does its job. Interoperability security was built to govern whether a move is allowed. The danger that remains is the pattern across moves that are all allowed. That gap is not negligence. It is the seam between two different questions, and almost nothing in the stack stands in it.
The Epic and Health Gorilla frame
When an EHR incumbent and a health information network publicly fight over the rules of exchange, the subtext is the same on both sides. Data crossing these interfaces is the most valuable, most regulated asset either party holds, and the interfaces are open by mandate. You cannot win that argument by closing the door. The door is the product.
Which is why the runtime question gets sharper as exchange expands. Every partner, network, and app you connect adds sanctioned movement, and adds places a permitted pattern can go wrong with no control firing. Wider interoperability, wider blind spot, in direct proportion. The answer is not to slow the exchange. It is to watch the movement while it happens.
Seeing the pattern at runtime
A permitted-pattern breach is catchable in one place: at runtime, on the movement itself. Not before, where predictive tools guess and flood the team with false positives. Not after, where the audit log confirms what already left.
Hilt watches data movement at the kernel, metadata only by default, off the path. One lightweight collector runs single-tenant inside your own cloud, on the order of 0.1% of one core and 4 to 8 MB of memory per host. It never sits inline, and it never blocks, drops, or alters traffic. It resolves each move to a probabilistic, source-dependent identity: which service account or partner integration, which job, which destination, and whether this fits what that identity normally does.
Note what that does not require. To see that a partner integration is pulling records in a shape no treatment workflow produces, Hilt does not have to read the records. The breach pattern shows in the metadata of the movement: the identity behind the call, the cadence, the volume, the destination, scored against months of how that integration actually behaves. Content-aware inspection is available when an investigation calls for it. It is never the price of admission. That matters more in health data than almost anywhere, because the data in question is the thing the regulation exists to protect.
So when a sanctioned interface starts behaving unlike itself, the deviation shows up across layers at once. The identity is querying outside its usual population. The access pattern is a sustained bulk read where the workflow implies lookups. The destination volume is unusual despite the approved channel. Any one signal alone is noise. Together they are a pattern, and a pattern is a case, not an alert: a written narrative of what moved, resolved to the job behind it, with the host isolated at the network from the control plane if it warrants it. Events never leave your account.
What this does and does not replace
This is a layer, not a teardown. Your API gateway still authenticates callers, and it should. Your consent engine still governs purpose, and it should. Your audit trail still satisfies the regulators who require it. Hilt does not replace any of them, and it does not stand in the path of a single record.
What it adds is the question none of them was built to ask: across every move you permitted on purpose, is the movement itself still normal, right now, while it is happening. When the whole architecture exists to let data leave, that question decides whether you find the pattern at runtime or read about it in a disclosure letter.
If your stack cannot answer "what did this partner integration's access actually do this month, resolved to the job behind it and scored against how it normally moves," that is the seam. It is worth thirty minutes, engineer to engineer, walking through where the collector sits and what it sees.