An AI Mission for Healthcare: Medical Records Retrieval

Finding a medical record has been a solved problem for years. Establishing that a particular requester, for a particular purpose, may receive a particular slice of it — and no more — is the part that was never automated, and it is the part that decides whether the disclosure was safe.

The release-of-information desk in a mid-sized health system is a strange place to watch, because almost nothing that happens there resembles the problem it appears to be solving. Requests arrive all morning across channels that have accumulated like sediment: a fax from a specialist clinic asking for prior imaging ahead of a referral, a portal message from a person asking for their own chart, a structured query arriving over an interoperability feed from another organisation's system, an insurer asking for documentation attached to a claim, a law firm asking for a defined window of the record with an authorisation form attached, an internal analytics team asking for a cohort. The staff working that queue are not searching for anything. Every one of those records can be located in seconds by a system that has known where it lives since the day it was created. What consumes the hours — and what carries every ounce of the risk — is the question that comes after locating it, which is whether this particular thing may leave the building, in this particular form, into this particular pair of hands.

That distinction sounds pedantic until you watch what it costs. The person working the request has to establish who is actually asking, which is rarely as simple as reading the letterhead, because the entity named on the request and the entity that will receive the file are often not the same. They have to determine what instrument gives that requester standing — a patient's own right of access, an authorisation the patient signed, a treatment relationship, a payment or operational purpose. They have to figure out what purpose was stated and whether the scope being requested is proportionate to it, because a request for "the complete chart" attached to a narrow purpose is one of the most common failure modes in the whole workflow. They have to notice whether the record contains categories that carry heightened protection, or notes that reference a third party who never consented to anything, or a segment the patient specifically restricted. And they have to do all of that under a general obligation that runs through every privacy regime in the world in one form or another: disclose the minimum necessary to accomplish the stated purpose, and nothing beyond it.

Retrieval is an entitlement question wearing a search question's clothes

The reason this work has resisted automation for so long is that the industry framed it wrong from the beginning. Records retrieval was treated as an information-access problem, and information-access problems are exactly what enterprise software has spent forty years getting good at. Index the documents, federate the repositories, expose an API, build a portal, wire an exchange network between organisations. All of that was worth building, and all of it addressed the half of the problem that was already easy. What none of it addressed is that the record is not a single object with a single owner. It is a layered set of custodial claims — the patient's, the treating clinician's, the organisation's, sometimes another person's whose information ended up in a note — and a disclosure is a transfer of custody across an organisational boundary, not a read operation.

Once you see it that way, the shape of the real work becomes clear, and so does why it is so hard to systematise. Entitlement is a function of at least four variables that almost never live in the same system: the verified identity of the requester, the authorisation instrument that gives them standing, the purpose asserted for the disclosure, and the scope that purpose can justify. The identity might be checkable against a provider directory or a payer roster. The authorisation exists as a document, often a scanned one, whose validity depends on its dates, its named parties, its stated scope, and whether it has been revoked. The purpose is a sentence written by the requester, in free text, which someone has to interpret against a policy. And the scope is the hardest of all, because it is not stated anywhere — it has to be derived by reasoning from the purpose to the set of documents, encounters, and data elements that the purpose actually requires. There is no field in any system that contains the answer. There is only judgement, applied one request at a time, by people whose queue does not stop growing.

Reviewing a disclosure after it happens is a receipt, not a control

The way most organisations have managed this risk is to log everything and audit some of it, and the logic is understandable: if you cannot inspect every disclosure before it goes out, at least you can reconstruct what happened afterwards. But an audit log is a record of a transfer that has already completed. Nothing about it constrains the transfer. A file that left with more in it than the purpose justified cannot be recalled, and the fact that a sampling review might catch it in three weeks does not change what the recipient already has. This is a door with a very good camera and no lock, and the organisations relying on it are relying on deterrence and remediation to do a job that only prevention can do.

The volume makes it worse rather than better. Requests scale with the size of the patient population, the number of exchange partners, the number of payer relationships, and the growing appetite of every downstream system for structured clinical data — while the number of people qualified to make an entitlement judgement scales with the hiring plan, which is to say barely. The predictable result is that the careful, scope-limiting reasoning gets applied thoroughly to the requests that look unusual and thinly to the ones that look routine, and over-disclosure concentrates precisely in the high-volume, unremarkable traffic that nobody has time to scrutinise. The failure mode is not a dramatic breach. It is the quiet, systematic habit of sending the whole chart because trimming it correctly would have taken twenty minutes nobody had.

This is also why so much of the current wave of AI enthusiasm lands badly here. Gartner has predicted that over forty percent of agentic AI projects will be canceled by the end of 2027, naming inadequate risk controls among the reasons, alongside what the firm calls "agent washing." A system that retrieves records faster without carrying the entitlement logic is not an improvement in this domain — it is an accelerant, because the constraint that was already being applied unevenly by tired humans has now been removed from the path entirely. Speed is only a virtue downstream of correctness, and in disclosure the correctness question is the whole question.

Minimum-necessary has to be a property of the retrieval itself

What changes the picture is treating scope determination as something the retrieval system performs rather than something a reviewer applies to the retrieval's output. Concretely, that means an AI Mission that begins where the request arrives rather than where the record lives: parsing the incoming request off whichever channel carried it, verifying the requester against the directories and rosters that establish identity, reading the attached authorisation and checking its parties, dates, and stated limits, interpreting the asserted purpose, and only then reasoning from that purpose to the specific set of documents and data elements that the purpose supports. The record retrieval is the last step, not the first, and what it returns is already bounded — the entitled slice, assembled to fit the authorisation, with everything outside it never having been assembled at all. The provenance of every decision travels with the package, so the audit trail becomes an explanation of a constraint that was enforced rather than a reconstruction of one that was not.

It matters enormously what such a system is and is not permitted to decide. It makes no clinical judgement of any kind — it does not interpret findings, assess a patient's condition, or influence care, and it should be architected so that it structurally cannot. Its authority is confined to disclosure scope, and even there it belongs under an explicit human-in-the-loop boundary: a privacy officer or records professional owns the policy, sets what the system may release without review, and receives every request where the authorisation is ambiguous, the purpose is unclear, the scope is contested, the requester cannot be verified, or the record contains a category the organisation has chosen to route to a person by default. On the platform side this is where the plumbing earns its keep — specialist agents handling verification, authorisation interpretation, and scope derivation as distinct competencies; Model Context Protocol connections into the source systems so retrieval happens through governed, permissioned interfaces rather than bulk extracts; Enterprise Knowledge holding the organisation's own disclosure policy so scope reasoning reflects that organisation's standards; and Enterprise Deployment keeping the whole thing inside the boundary where the data already sits. This is the pattern that shows up wherever the autonomous enterprise starts governing regulated work rather than just accelerating it, and it is the thesis behind how a platform like StudioX frames missions in regulated domains generally: the human owns the policy, the agents execute inside it, and the constraint is enforced at the moment of action instead of inspected afterwards.

The mental model worth carrying out of this is that a medical record is not a file. It is a bundle of overlapping custodial claims, and every request is a proposal to transfer one of them across a boundary. A search engine answers "where is it," which was never the difficult question and stopped being an interesting one a long time ago. The question that actually governs this work is "how much of it does this person, for this reason, get to hold" — and an organisation that can answer that question at the speed requests arrive has not merely made its records operation faster. It has made minimum-necessary disclosure something its systems do by construction, rather than something its staff try to remember to do while the queue keeps filling.