Per-encounter capability minting for clinical agents

A clinical agent asked to summarise an encounter is given a connector, and a connector is a system rather than a permission. From that moment two sets are in play: the records the agent can reach, which is a property of the credential, and the records it clinically needs, which is a property of the task. The companion teardown to this piece — The summarisation agent could reach the whole record because the connector could — walks the evidence that the first set is never enumerated and grows after approval without anybody re-approving it. I take that as established and design against it. The design has one idea in it: make the two sets the same object.

I will call the reference design @authority/broker throughout, purely so the modules below have a name to hang on. It is not a package you can install — I know of nothing published under that name, and the code here is a specification you would implement rather than a dependency you would add. It is written at the level a competent platform team could build from, which is also the level at which it can be shown to be wrong. I would rather it be checkable than persuasive.

The rule already asks for the triple

The argument for this primitive is usually made as an argument about good engineering practice, and it does not need to be. In US healthcare the shape of the object is already written down in binding text, and it has been for two decades. It is worth reading the words rather than the summaries, because the summaries have smoothed off exactly the granularity that matters.

The minimum necessary implementation specification at 45 CFR 164.514(d)(2)(i) requires a covered entity to identify "(A) Those persons or classes of persons, as appropriate, in its workforce who need access to protected health information to carry out their duties; and (B) For each such person or class of persons, the category or categories of protected health information to which access is needed and any conditions appropriate to such access." Read (B) slowly. It asks for two things per principal: the categories, and the conditions. It does not ask which system the principal has an account on. A grant recorded as the EHR connector answers a question the rule did not put; it names a system where the rule asked for a category and a condition.

The duty attaches to the call, not only to what was read. 45 CFR 164.502(b)(1) requires a covered entity or business associate, "[w]hen using or disclosing protected health information or when requesting protected health information from another covered entity or business associate," to "make reasonable efforts to limit protected health information to the minimum necessary to accomplish the intended purpose of the use, disclosure, or request." Both arms are load-bearing and they catch different calls: an agent querying its own organisation's server is making a use, not a request from another entity, and an agent calling a partner endpoint is making a request. In either case the obligation lands on the shape of the call, before the model has seen anything — which is precisely where a capability system operates and precisely where a post-hoc access log does not.

The same provision contains the constraint that makes generic least-privilege advice inapplicable here, and an argument ignoring it deserves to be dismissed by the first clinician who reads it. 164.502(b)(2) exempts "disclosures to or requests by a health care provider for treatment" from the minimum necessary standard. That is a clinical safety judgement rather than a loophole, and it is why clinical systems are provisioned broadly: a physician looking for the thing that explains this patient cannot declare in advance which categories will matter. The argument for narrowing therefore cannot be made at the bedside. It is made on the other paths — operations, payment, analytics, research, vendor tooling, quality reporting — where the exemption does not apply.

The Security Rule covers non-human principals explicitly, which is worth noting because agents are often assumed to fall into a gap. 45 CFR 164.312(a)(1) requires technical policies "to allow access only to those persons or software programs that have been granted access rights." Software programs, named in the standard. The corresponding administrative safeguard reaches a unit finer than a connector: 164.308(a)(4)(ii)(B) calls for policies for granting access to ePHI, "for example, through access to a workstation, transaction, program, process, or other mechanism," and (C) calls for policies that "establish, document, review, and modify a user's right of access to a workstation, transaction, program, or process." A transaction. A process. Two honest qualifications: (B) introduces that list as an example rather than as a closed set, and both specifications are addressable rather than required, so an entity may document an alternative it judges reasonable and appropriate. Neither changes what the example tells you about the unit the drafters had in mind, and it is finer than anything a connector-shaped grant can express.

In FDA-regulated life sciences the same point is made even more directly. 21 CFR 11.10(g) requires "use of authority checks to ensure that only authorized individuals can use the system, electronically sign a record, access the operation or computer system input or output device, alter a record, or perform the operation at hand." The operation at hand is the regulation's own name for per-task intent. A check performed once when a connector was bound, and never again, is not a check on the operation at hand; it is a check on the connector, and the operation at hand happened three thousand operations later.

All CFR text quoted here is from the GPO annual edition for 2025 — the official codification, which may lag amendments made after its revision date. eCFR blocked automated retrieval throughout the research for this piece, so spot-check by hand any provision you intend to rely on. Separately: the HIPAA Security Rule notice of proposed rulemaking at 90 FR 898 (6 January 2025) is cited below as a proposal, and for the Department's characterisation of the existing risk-analysis duty. Whether it has since been finalised could not be confirmed from a primary source, so nothing here depends on it.

Five premises

Everything below follows from five statements. I want them separated from the design so that a reader who rejects one can say which, rather than arguing with the consequences.

One: a capability is not a tool name. It is a triple. A verb, a resource set, and a constraint. Read, over the observations in encounter 41c9 with category laboratory, subject to expiring when that encounter closes and not being redisclosed outside this holder. A tool name is none of those things — it is an address. Handing an agent an address and calling it a permission is the category error the whole design exists to correct, and it is the error the regulation already declines to make when it asks for categories and conditions.

Two: grants must be intersected against intent, not unioned into a toolbelt. The dominant pattern today is additive. Each integration adds a tool; the agent's authority is the union of everything it has been given; and nothing anywhere computes what that union amounts to. The alternative is that every act draws from the intersection of two things — what this principal standingly holds, and what this task has declared it needs. Intersection has the property that adding an integration cannot widen what a given task can do, because the task's declared intent is the other operand.

Three: the intersection is computed at the moment of need and expires when the need does. A capability computed at deployment time is a configuration, and configurations outlive the reasons for them. A capability computed when the encounter opens and destroyed when it closes has a lifetime that matches the lifetime of the justification. This is the premise the sector's own vocabulary makes easy: an encounter is already a first-class object with a start, an end, a responsible clinician and an identifier. The boundary is not something the design has to invent — the clinical domain hands it over.

Four: the closure of a proposed grant is computed before execution, not reconstructed after an incident. A grant to one system is a grant to everything that system can reach, transitively, through every export, every integration, every notification path. That closure is a computable object if somebody computes it, and it is an unbounded liability if nobody does. Computing it before minting turns "how far does this reach?" from a forensic question into a precondition. HHS's own framing of the existing risk-analysis duty is that it "requires a regulated entity to perform an inventory of its technology assets, determine how ePHI moves through its information systems" — which is that computation, described in the Department's words as a present obligation rather than a proposed one.

Five: the record must be legible to a reader who was not there and may be adverse. This premise is where healthcare differs from every other sector this design has been written for, and it is the one that shapes the data model most. The reader is not a colleague reconstructing an outage. It is a patient exercising a statutory right, an auditor six years later, or opposing counsel. The record therefore has to carry the fields those readers are entitled to, in a form that does not require the person who built the system to be available to explain it.

The strongest objection to the whole programme lands on premises two and three together, and it lands hard, so let me put it before the design rather than after it.

You are proposing that a clinical agent declare in advance what it needs, in a domain whose defining feature is that you do not know what you need until you have looked. A summariser that cannot see the medication list because nobody predicted the note would reference it will produce a summary that is wrong in a way nobody catches. You have not removed risk; you have moved it from a privacy failure, which generates a letter, to a clinical failure, which generates a patient.

That objection is correct in its structure and I have no clean answer to it. I have three partial ones. First, it is an argument about the treatment path, which the rule itself exempts — so where the objection is strongest, the design's answer is to record rather than to narrow, and the broker below says so in code. Second, on the non-treatment paths the counterfactual is not a clinician's judgement but a vendor's default. Third, a capability that is too narrow fails loudly and leaves an artefact; an ambient credential that was too broad fails silently and leaves nothing. That is a preference rather than a proof, and the objection retains its force.

What the premises force

Take them in order and ask what each one rules out.

The triple rules out any grant model whose unit is a system, a connector, an integration, a service account or an API key. It also rules out the intermediate position most teams reach for, in which a tool is registered with a scope string that names a resource type — because a resource type is a category without a condition, and 164.514(d)(2)(i)(B) asks for both. The condition is the part that does the work and the part that gets dropped.

Intersection, not union rules out the ambient toolbelt in every form. It rules out a planner selecting tools from a registry at runtime, because selection is not narrowing. It rules out per-agent role assignment, because a role is standing authority — one operand of the intersection, not the answer. And it rules out asking the model to request only what it needs, because applying a constraint by asking the constrained party to apply it is not a control.

Minted at need, expiring with the need rules out long-lived credentials, agent-held refresh tokens, and the seductive shortcut of a short-lived token with a long-lived refresh — which has the lifetime of the refresh and the appearance of the token. The expiry that matters is the clinical one, and it must be carried as a caveat inside the capability rather than enforced by a scheduler outside it.

Closure before execution rules out every architecture in which the authorisation decision is local to one resource server. Whether a grant is safe is a property of the whole graph of systems, not of the system being granted. This is the expensive premise: it requires a model of what connects to what, which most organisations do not have and none have completely, and it means the broker must fail closed on an incomplete graph rather than optimistically on a partial one. It is where the design is weakest.

Legible to an adverse reader rules out the record format almost everyone builds first, which is a log line saying that a tool ran. The audit controls standard at 45 CFR 164.312(b) requires mechanisms "that record and examine activity in information systems that contain or use electronic protected health information," and 164.308(a)(1)(ii)(D) separately requires "procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports." A log that records the tool name rather than the rows touched cannot support the review the second duty requires — you can examine it all you like and learn only that something ran.

The certification layer already demands more than that, which is a useful fact because it means the recording infrastructure largely exists. The ONC/ASTP criterion at 45 CFR 170.315(d)(2) for auditable events and tamper-resistance requires recording actions related to electronic health information — additions, deletions, changes, queries, print and copy, per 45 CFR 170.210(e)(1) — plus changes to user privileges, to audit log status, and to the encryption status of locally stored information. It incorporates ASTM E2147-18 by reference, and the certifying body's own test method lists that standard's audit-entry elements as including user identification, patient identification, date and time, type of action, and the specific category of data content, such as demographics, pharmacy data or test results.

ASTM E2147-18 is paywalled, and the element list above is read from ONC/ASTP's own certification test method rather than from the standard's text. That is the certifying body publishing what it tests for, which is a primary source for the certification requirement and not a substitute for the standard. I am not quoting ASTM section numbers, and neither should anyone relying on this.

So a certified system can already record a category of data content per entry. What it cannot do is record a capability, because nothing upstream produced one. The gap is not in the recording layer. It is that there is no object to record.

Where the existing standards stop

Three specifications matter here, and reading them precisely does more for the argument than any amount of assertion. Two of them document the problem in their own words. The third supplies most of the solution and has not been taken up in this sector.

SMART App Launch describes the closure and its growth. HL7's SMART App Launch v2.2.0 (STU 2.2) defines scopes in the form compartment/ResourceType.[cruds], and of the wildcard form it says: "When a wildcard is requested for the FHIR resource, the client is asking for all data for all available FHIR resources, both now and in the future." That final clause is the closure growing after the approval was given. Nobody re-approves the boundary when a new resource type is added to the server, because the boundary was expressed as a wildcard rather than as a list.

The same specification supplies the narrower alternative, which matters because the design below is not asking the sector for a capability it does not have. SMART provides that "to apply these constraints, add a query string suffix to existing scopes, starting with ? and followed by a series of param=value items separated by &" — so a scope such as patient/Observation.rs?category=...|laboratory is expressible today. It also warns that the scopes "ultimately granted by the authorization server may differ from the scopes requested by the client." Both facts point the same way: the mechanism for a resource set with a condition on it already ships, and what is missing is anything that computes what the condition ought to be for this task.

Bulk export shows a single omitted parameter becoming a whole-population read. In the HL7 FHIR Bulk Data Access (Flat FHIR) Implementation Guide v2.0.0 (STU 2), the system-level operation is defined to "export data from a FHIR server, whether or not it is associated with a patient"; the patient-level form obtains resources "pertaining to all patients"; and when the client omits the _type parameter, the server will "return all supported resources within the scope of the client authorization." The default is the closure of the credential rather than the intent of the task, stated by the standards body itself. One absent parameter is the difference between a cohort and a population.

That is the sharpest available illustration of why the triple has to be an object rather than a convention. Where the resource set is supplied optionally, its absence resolves to everything; where it is a required field of the only constructor available, its absence resolves to nothing, because the capability does not exist.

RFC 9396 already standardises the triple, in an OAuth extension the sector has not adopted. OAuth 2.0 Rich Authorization Requests, Standards Track since May 2023, opens by saying exactly what is wrong with scope: it "is sufficient to implement static scenarios and coarse-grained authorization requests ... However, it is not sufficient to specify fine-grained authorization requirements, such as 'please let me transfer an amount of 45 Euros to Merchant A' or 'please give me read access to directory A and write access to file X.'" It then defines an authorization_details parameter carrying JSON objects whose fields include type, locations ("the location of the resource or RS"), actions ("the kinds of actions to be taken at the resource"), datatypes ("the kinds of data being requested from the resource"), identifier ("a specific resource available at the API") and privileges.

Actions, locations and datatypes is a verb, a resource set and a constraint, in a published standards-track RFC. The prescription in this piece is therefore not aspirational — it has an encoding, an IANA-registered parameter and an authorization-server story. What it does not have, as far as I can establish, is adoption in clinical authorisation servers, and that is a fact about deployment rather than about availability.

One thing I will not assert. There is no published measurement of the ratio between the resource set a clinical tool grant was intended to cover and the set it actually reaches. HL7 documents the mechanism; no regulator, standards body or vendor publishes a quantification of the result, and the multipliers that circulate are vendor derivations repeated onward from publishers who did not issue them. The honest statement is that the gap is unmeasured, and that being unmeasured is itself the finding — an organisation cannot bound something it has never computed.

The data model

A capability is the only thing that travels. It carries a set of verbs, a set of resource selectors, a set of caveats, a pointer to its parent, and a seal binding it to the chain above it. Three properties of the model are load-bearing and easy to lose.

1. The constructor computes a meet, never a join. mintForEncounter takes standing authority and a declared intent and returns the intersection. There is no exported function that produces a capability with more authority than its input. Widening is not refused; it does not exist as an operation, which is a stronger guarantee than a policy that forbids it.
2. The consent class is a dimension of the resource set, not a filter applied afterwards. A selector that does not name which consent classes it may touch does not select anything. This is what stops a grant crossing the invisible boundary into records governed by 42 CFR part 2, whose permitted onward uses are narrower than the rest of the table and are carried by consent metadata rather than by connectivity.
3. The purpose determines whether narrowing applies at all. Because 164.502(b)(2) exempts treatment requests, the broker treats a treatment-purpose intent differently: it records the full standing authority as the minted capability and marks the record accordingly, rather than pretending to narrow something the rule does not ask to be narrowed. A design that silently narrows the treatment path is a design that will be switched off by a clinician, correctly.

/** A verb in the resource server's namespace, e.g. "read", "append", "amend", "export".
 *  Compared for equality by this package and never interpreted by it. */
export type Verb = string;

/** The consent regime a record sits under. Part 2 records live in the same tables as
 *  everything else and carry narrower onward uses, so this is a dimension of the resource
 *  set rather than a filter applied to a result. */
export type ConsentClass =
  | "general"
  | "part2-substance-use"
  | "investigational"
  | "restricted-by-patient-request";

/** Why the access is happening. This is not decoration: 45 CFR 164.502(b)(2) exempts
 *  requests by a health care provider for treatment from the minimum necessary standard,
 *  so the broker's behaviour is genuinely different on that path. */
export type Purpose =
  | "treatment"
  | "payment"
  | "health-care-operations"
  | "research"
  | "quality-reporting"
  | "vendor-tooling";

/** A selector in the resource server's grammar. Opaque to this package: containment is
 *  supplied by the caller, because the grammar belongs to the estate, not to the broker. */
export interface ResourceSelector {
  /** Logical system identifier, e.g. "ehr.primary". */
  readonly system: string;
  /** Resource kind in that system's vocabulary, e.g. "Observation". */
  readonly kind: string;
  /** Compartment the selector is confined to, e.g. an encounter or patient id.
   *  null means unconfined, which the gate below treats as a refusal by default. */
  readonly compartment: string | null;
  /** Additional conditions, e.g. { category: "laboratory" }. This is 164.514(d)(2)(i)(B)'s
   *  "conditions appropriate to such access", carried as data. */
  readonly conditions: Readonly<Record<string, string>>;
  /** Which consent classes this selector may touch. Empty means it selects nothing. */
  readonly classes: readonly ConsentClass[];
}

export type Caveat =
  | { readonly kind: "expires-at"; readonly epochMillis: number }
  | { readonly kind: "bound-to-encounter"; readonly encounterId: string }
  | { readonly kind: "purpose"; readonly purpose: Purpose }
  | { readonly kind: "max-exercises"; readonly count: number }
  /** 42 CFR 2.33's redisclosure limit, carried on the credential rather than in a contract. */
  | { readonly kind: "no-onward-disclosure-beyond"; readonly holder: string };

export interface Capability {
  readonly id: string;
  /** null only for standing authority. A child's seal depends on its parent's, so a
   *  capability cannot claim an ancestry it does not have. */
  readonly parentId: string | null;
  /** The software principal that will exercise it. */
  readonly subject: string;
  /** The human or role whose authority it derives from. Required: an agent acting on
   *  nobody's authority is the failure this whole design exists to make impossible. */
  readonly onBehalfOf: string;
  readonly verbs: readonly Verb[];
  readonly resources: readonly ResourceSelector[];
  readonly caveats: readonly Caveat[];
  /** Terminal MAC of the chain, base64url. */
  readonly seal: string;
}

/** Selector containment in the estate's grammar. Injected, never parsed here. */
export type Covers = (parent: ResourceSelector, child: ResourceSelector) => boolean;

/** Safe default for callers with no grammar: exact structural match on system, kind and
 *  compartment, with the child's conditions a superset of the parent's. Narrower than most
 *  callers want, which is the right direction for a default to be wrong in. */
export const exactMatch: Covers = (parent, child) =>
  parent.system === child.system &&
  parent.kind === child.kind &&
  parent.compartment === child.compartment &&
  Object.entries(parent.conditions).every(([k, v]) => child.conditions[k] === v);

export interface Sealer {
  /** Keyed MAC. The parent's seal is the key for the child's — the macaroon construction,
   *  so a holder can extend the chain downward and cannot climb it. */
  readonly mac: (key: Uint8Array, message: Uint8Array) => Uint8Array;
  readonly rootKey: (subject: string) => Uint8Array;
  readonly encode: (mac: Uint8Array) => string;
}

export interface Deps {
  readonly now: () => number;
  readonly newId: () => string;
  readonly covers: Covers;
  readonly sealer: Sealer;
}

/** What the task says it needs. Written down before anything is minted — this is the
 *  artefact 45 CFR 164.502(b)(1) attaches its duty to, since it is the request. */
export interface Intent {
  readonly purpose: Purpose;
  readonly encounterId: string;
  /** Free text, kept because 164.528(b)(2) requires a brief statement of purpose that
   *  reasonably informs the individual. A code alone does not inform anybody. */
  readonly statedPurpose: string;
  readonly verbs: readonly Verb[];
  readonly resources: readonly ResourceSelector[];
  /** Absolute wall-clock end of the encounter. Not a token lifetime. */
  readonly encounterClosesAt: number;
  readonly maxExercises: number;
}

export type Refusal =
  | { readonly reason: "no-standing-verb"; readonly verbs: readonly Verb[] }
  | { readonly reason: "no-standing-resource"; readonly resources: readonly ResourceSelector[] }
  | { readonly reason: "unclassified-selector"; readonly index: number }
  | { readonly reason: "unconfined-selector"; readonly index: number }
  | { readonly reason: "encounter-already-closed" };

export type MintResult =
  | { readonly ok: true; readonly capability: Capability; readonly narrowed: boolean }
  | { readonly ok: false; readonly refusal: Refusal };

const canon = (value: unknown): Uint8Array =>
  new TextEncoder().encode(JSON.stringify(value));

/** The meet. Every verb the intent asks for that the parent also holds; every selector the
 *  intent asks for that some parent selector covers. Anything named that the parent did not
 *  hold simply falls out — it is not refused, it is absent. */
function meet(
  parent: Capability,
  intent: Intent,
  covers: Covers,
): { readonly verbs: readonly Verb[]; readonly resources: readonly ResourceSelector[] } {
  const verbs = intent.verbs.filter((v) => parent.verbs.includes(v));
  const resources = intent.resources.filter((child) =>
    parent.resources.some((p) => covers(p, child)),
  );
  return { verbs, resources };
}

export function issueStanding(
  deps: Deps,
  input: {
    readonly subject: string;
    readonly onBehalfOf: string;
    readonly verbs: readonly Verb[];
    readonly resources: readonly ResourceSelector[];
    readonly caveats?: readonly Caveat[];
  },
): Capability {
  const id = deps.newId();
  const body = { id, parentId: null, ...input, caveats: input.caveats ?? [] };
  const seal = deps.sealer.encode(
    deps.sealer.mac(deps.sealer.rootKey(input.subject), canon(body)),
  );
  return { ...body, parentId: null, caveats: input.caveats ?? [], seal };
}

/** The only path to a non-standing capability. There is no second one. */
export function mintForEncounter(
  deps: Deps,
  standing: Capability,
  intent: Intent,
  subject: string,
): MintResult {
  if (intent.encounterClosesAt <= deps.now()) {
    return { ok: false, refusal: { reason: "encounter-already-closed" } };
  }
  for (let i = 0; i < intent.resources.length; i += 1) {
    const selector = intent.resources[i];
    if (selector.classes.length === 0) {
      return { ok: false, refusal: { reason: "unclassified-selector", index: i } };
    }
    if (selector.compartment === null) {
      return { ok: false, refusal: { reason: "unconfined-selector", index: i } };
    }
  }

  // The treatment path. 164.502(b)(2) exempts provider requests for treatment from the
  // minimum necessary standard, so narrowing here would be the design overriding a clinical
  // safety judgement the rule already made. Carry the standing authority, mark the record,
  // and still bind the expiry and the encounter — the horizon obligations are not exempted.
  const isTreatment = intent.purpose === "treatment";
  const { verbs, resources } = isTreatment
    ? { verbs: standing.verbs, resources: standing.resources }
    : meet(standing, intent, deps.covers);

  if (verbs.length === 0) {
    return { ok: false, refusal: { reason: "no-standing-verb", verbs: intent.verbs } };
  }
  if (resources.length === 0) {
    return {
      ok: false,
      refusal: { reason: "no-standing-resource", resources: intent.resources },
    };
  }

  const caveats: readonly Caveat[] = [
    ...standing.caveats,
    { kind: "expires-at", epochMillis: intent.encounterClosesAt },
    { kind: "bound-to-encounter", encounterId: intent.encounterId },
    { kind: "purpose", purpose: intent.purpose },
    { kind: "max-exercises", count: intent.maxExercises },
  ];

  const id = deps.newId();
  const body = {
    id,
    parentId: standing.id,
    subject,
    onBehalfOf: standing.onBehalfOf,
    verbs,
    resources,
    caveats,
  };
  const seal = deps.sealer.encode(
    deps.sealer.mac(new TextEncoder().encode(standing.seal), canon(body)),
  );
  return {
    ok: true,
    capability: { ...body, seal },
    narrowed: !isTreatment,
  };
}

The control path

Seven layers, and the useful thing about laying them out is that six of them have a citation. This is not a new obligation being invented; it is an artefact that the existing obligations presuppose and that nothing currently produces.

1. The encounter opens. A clinician or a workflow states, in clinical language, what the agent is for. Nothing is minted yet and the agent holds nothing.
2. The intent is declared. Purpose, encounter identifier, verbs, resource selectors, the requested horizon and an exercise cap, written down as data. This is the request that 164.502(b)(1) attaches its duty to, and writing it down is what makes the duty checkable rather than aspirational.
3. The gate computes the closure. Seeds are the systems named in the selectors. The analyser walks the estate graph and returns the reachable set, the external sinks, the consent classes traversed, and — critically — whether any reachable node is one the organisation knows it has not mapped. Any of those three conditions refuses.
4. The broker computes the meet. Standing authority intersected with declared intent, except on the treatment path where the rule's own exemption means the honest behaviour is to carry the standing authority and mark the record as unnarrowed.
5. The capability is minted and sealed. Verbs, selectors, caveats including the encounter binding and the hard expiry, parent identifier, seal keyed by the parent's seal.
6. The resource server verifies and recomputes. It does not trust the capability's stated authority. It walks the chain from the root and recomputes the running intersection, so a capability whose claimed authority disagrees with what the chain permits is evaluated on the chain. Without this the invariant depends on every minting party being honest, and one of the minting parties is running inside a model's tool loop.
7. The record is written and retained. The capability, the intent, the closure report, every exercise with the identifiers actually touched, and the retirement timestamp that starts the documentation clock.

The refusal branch is not an error path. A refused grant is worth as much as a granted one and should be recorded with the same care — what was asked for, what the closure contained, which condition fired. An organisation running this for a quarter has, in its refusal log, an inventory of the places its estate graph is wrong, and that inventory is worth more than the enforcement.

The horizon, and who is reading

Every other sector this primitive has been written for treats the audit horizon as a storage question. Healthcare does not have that luxury, and the reason is worth spelling out, because it changes what the record has to be rather than merely how long it is kept.

Start with the documentation clock, because it behaves counter-intuitively. 45 CFR 164.316(b)(2)(i) requires an entity to "retain the documentation required by paragraph (b)(1) of this section for 6 years from the date of its creation or the date when it last was in effect, whichever is later," and (b)(1) covers the policies and procedures implemented to comply with the rule together with "a written (which may be electronic) record of the action, activity, or assessment" where documentation is required. The clock starts when the configuration is retired, not when it was made. A capability configuration in effect for three years must be defensible for nine — and that arithmetic is a constructed illustration of the rule's own wording, not a reported figure.

Then the accounting right, which is the sector's concrete instance of provable afterwards — and which is narrower than it is usually made to sound, so the bound goes first. 45 CFR 164.528(a)(1) gives an individual "a right to receive an accounting of disclosures of protected health information made by a covered entity in the six years prior to the date on which the accounting is requested," but it reaches disclosures rather than internal uses, and it excepts, among others, disclosures to carry out treatment, payment and health care operations, disclosures to the individual, incidental disclosures, disclosures made pursuant to an authorisation, and disclosures of a limited data set. Most of the non-treatment workloads this piece is addressed to — coding, quality measurement, prior authorisation — are operations, so their disclosures are not accountable under this section. The section still matters, for a reason that survives its own carve-outs: where it does apply, (b)(2) requires each entry to carry the date, the recipient's name and address if known, "a brief description of the protected health information disclosed," and "a brief statement of the purpose of the disclosure that reasonably informs the individual of the basis for the disclosure" — which is the only place in this body of rules where a regulator enumerates the fields of a per-access record. Those fields are a resource set, a recipient and a purpose. They are reconstructable from a per-task capability record and not from a connector name in a configuration file, which is why the record module above projects directly into them and emits an entry only where an exercise actually delivered information to another party.

Then the breach presumption, where a missing closure computation becomes a notification obligation. Under 45 CFR 164.402, an impermissible acquisition, access, use or disclosure "is presumed to be a breach unless the covered entity or business associate demonstrates that there is a low probability that the protected health information has been compromised based on a risk assessment of at least the following factors," among them "the nature and extent of the protected health information involved" and "whether the protected health information was actually acquired or viewed." An organisation that never computed a grant's closure cannot bound the nature and extent, and so cannot rebut the presumption. The notification follows from the missing analysis rather than from any proven harm.

Hospitals participating in Medicare carry a retention floor independent of HIPAA: 42 CFR 482.24(b)(1) requires that "medical records must be retained in their original or legally reproduced form for a period of at least 5 years," and 482.24(c) requires all entries to be "legible, complete, dated, timed, and authenticated in written or electronic form by the person responsible for providing or evaluating the service provided." That duty is per-entry and names a responsible person, which agent-written entries must satisfy on the same terms as human ones — and a capability naming onBehalfOf is the only structure that lets an entry written by software point at the person responsible for it.

In clinical research the terminus is not knowable when the access happens. 21 CFR 312.62(c) requires an investigator to retain records for two years after a marketing application is approved for the drug under investigation, or, where no application is filed or it is not approved, for two years after the investigation is discontinued and FDA is notified. Read with 21 CFR 11.10(e) — which requires "secure, computer-generated, time-stamped audit trails" recording the date and time of operator actions that create, modify or delete records, provides that "record changes shall not obscure previously recorded information," and pins audit-trail retention to the retention of the underlying records — the retention period for an agent's access log is a function of an event that may be years away.

And the outer horizon is set by fraud law rather than privacy law. 31 U.S.C. 3731(b) bars a False Claims Act civil action brought "more than 6 years after the date on which the violation of section 3729 is committed," or more than three years after the material facts were or should have been known to the responsible federal official, "but in no event more than 10 years after the date on which the violation is committed, whichever occurs last." Such actions are commonly brought by relators against providers, so the party reading an agent's access record years later is frequently a private litigant — and the tolling turns on when facts were knowable, which is a question about what the records show.

Two procedural rules complete the picture. Federal Rule of Civil Procedure 37(e), as amended in 2015, provides that where electronically stored information that should have been preserved is lost because a party "failed to take reasonable steps to preserve it," a court may on a finding of prejudice "order measures no greater than necessary to cure the prejudice" — and only on a finding "that the party acted with the intent to deprive another party of the information's use in the litigation" may it presume the information unfavourable or "dismiss the action or enter a default judgment." Federal Rule of Evidence 902(13), added in 2017, makes a record "generated by an electronic process or system that produces an accurate result" self-authenticating on "a certification of a qualified person."

Put those together and the design consequence is specific. A record that exists and is unflattering is far better than one that is absent, because the severest sanction requires intent to deprive. And a record generated by a process a qualified person can certify is admissible without dragging a witness to the system's design into a courtroom eight years after the engineer who built it left. That second point is an argument for determinism in the record layer that has nothing to do with security: a record produced by a deterministic projection from a sealed capability can be certified; a record assembled by joining four log sources with a script somebody wrote once cannot be, comfortably.

The two procedural rules and the False Claims Act limitation period are paraphrased above with the operative language quoted; they are cited to the rules and the statute rather than to any commentary on them. Nothing here is legal advice, and the reading of what a court would do with a particular record is exactly the kind of question that belongs with counsel rather than with an architect.

How this design fails

Eight ways, in rough order of how likely they are to bite. A design piece without this section is marketing.

One: the encounter is the wrong boundary for a great deal of real clinical work. Longitudinal care, chronic disease management, care coordination across settings, tumour boards, population health and most quality reporting are not encounters. They are cohorts, episodes or programmes, and an encounter-bound capability either does not fit them or fits by being minted so broadly that the binding is decorative. The answer is that the boundary object should be whatever the clinical domain already names — an episode, a care plan, a study arm — but encounter is the easy case, and I have chosen the easy case to argue in.

Two: a refusal produces a workaround, not a smaller blast radius. A clinician or an analyst blocked by a gate does not stop needing the answer. They export to a spreadsheet, ask a colleague with broader standing authority to run it, or use the reporting tool provisioned before any of this existed. The design has then moved the access outside the record it was built to produce — worse than the ambient credential it replaced, which at least generated a log line. Every deployment needs a fast, well-recorded escalation path, and the quality of that path decides the outcome more than the quality of the broker.

Three: the closure is only as good as the estate graph, and no estate graph is complete. The gate fails closed on a reachable unmapped node, which is correct and is also the behaviour most likely to get it disabled in month two. A large provider organisation has integrations nobody remembers, interfaces maintained by a vendor, and flat-file drops predating the current architecture team. The honest position is that the refusal log is the mapping exercise and the first quarter will be mostly refusals. Organisations that cannot tolerate that will run the gate in advisory mode — which is a different product with a different guarantee.

Four: consent class is metadata, and metadata is frequently wrong. The design treats a record's Part 2 status as a property carried by the selector. In practice that status is derived — from the treating department, a program identifier, a flag set at registration — and derivations are wrong at the edges. A record misclassified as general when it is Part 2 passes a gate it should not, and the system produces a clean, sealed, well-recorded artefact attesting to a wrong classification. That is worse than an unrecorded failure, because it looks like assurance.

Five: a narrower capability is not always a smaller consequence. Blast radius is measured in rows, and harm is not. A capability confined to one encounter's psychiatric notes is narrower than one covering a department's laboratory results and could do more damage. The design gives no account of sensitivity weighting, and the intuition it trains — narrower is safer — is wrong for exactly the categories where being wrong matters most.

Six: these are bearer credentials. A minted capability is honoured because it verifies, not because the presenter proved possession of a key. Anything that can read it can use it until it expires — which is the argument for encounter-length expiry doing real work, and is not an argument that the credential is safe to log, to trace, or to hand to a model as context. Possession binding is straightforward and is deliberately omitted above, because the piece nobody saw specified is the piece that gets skipped.

Seven: the record is discoverable. A complete, sealed, per-task authority record is an asset when the organisation is right and a liability when it is not. It will be produced in discovery, and it will show refusals somebody overrode, closures that reached further than anyone realised, and treatment-path capabilities carrying authority nobody narrowed. Under Rule 37(e) this is still the correct trade — but it is a trade, and it should be made consciously, with counsel in the room rather than discovered afterwards.

Eight: nothing here touches what the model does with what it read. This design constrains reach. It says nothing about inference, about a summary that discloses more than its inputs did in isolation, about a model memorising across encounters, or about an output routed somewhere the capability never reached. Reach is a necessary condition for those failures, not a sufficient one. Anyone selling this as a solution to the disclosure problem is overselling it: it solves the reachability problem, which is one input to that one.

What it costs

Three kinds of cost — on the request, on the operators, on the migration. I will be precise where I can be and explicit where I cannot.

On the request. Minting is one intersection over two small sets plus one MAC, and verification is one MAC per link — pure computation, no I/O on the path. That is a property of the algorithm and I am comfortable stating it. The gate is not: closure is a breadth-first walk over the estate graph, so its cost is a function of graph size and it touches a structure loaded from somewhere. I have measured neither under a representative clinical workload, and I will not publish a millisecond figure I did not obtain. The measurement I intend to run is p50 and p99 for mint-plus-gate against graphs of one hundred, one thousand and ten thousand nodes; the prediction under test is that the resident case is dominated by the closure walk rather than the crypto at every size in that range.

On the operators. This is the cost people underestimate. You are adding a per-tenant key with a rotation policy; an estate graph that somebody must own, keep current, and be accountable for when it is wrong; an append-only store whose retention is set by the longest legal clock rather than by a storage budget; a refusal queue with an escalation path a clinician will actually use at two in the morning; and a new class of incident — the gate refused something it should not have — with its own runbook and its own fail-open-versus-fail-closed decision that someone senior has to make on purpose and in writing. None of that is exotic. All of it is headcount.

On the migration. The hard part is not minting; it is that a capability is worthless until something verifies it, and in a provider estate you do not own most of the things that would. The order that works: run the gate in advisory mode against the grants that already exist, so you learn where your map is wrong; then mint and record while enforcing nothing, so you see the shape of the authority your workloads actually exercise; then enforce at one boundary you do own — your tool-calling surface, not the EHR — logging failures and allowing them; then flip it closed; then widen. Every step is reversible except the last, and the value arrives at step one, because a refusal log with no enforcement is already an inventory of unmapped integrations.

I would budget the advisory-gate step in weeks and the first failing-closed boundary in quarters, and I would expect the argument about failing closed to take longer than the implementation of it.

The regulatory text in this piece is US federal because that is where the primary sources could be verified to the publisher's own words. The primitive is not US-specific: the same shape — a purpose limitation, a minimum-necessary duty and a multi-year audit horizon — recurs wherever health data is regulated, including under India's data protection regime and the health-data frameworks of the Gulf states. I will not characterise those regimes' provisions here, because I have not read them to the same standard — and a design piece that cites regulations it has not opened is worth less than one that says which ones it opened.

If you had a week

Build three things; deliberately skip the rest.

1. The type, the constructor and the property tests. Capability, mintForEncounter, and the four tests in the last tab above. Two days, and it is the part that has to be right because everything else is downstream of the invariant actually holding. Write the treatment-path test first: it is the one that will be argued about, and having it in code moves the argument from opinion to specification.
2. The estate graph for one workflow, and the gate in advisory mode. Pick one non-treatment workflow — coding, prior authorisation, a quality measure — and map only the systems it touches and what flows onward from them. Run the gate against the grant that workflow already has. You are looking for two numbers you have never had: how many systems that grant transitively reaches, and how many of those nobody had mapped. The second is usually the one that changes the conversation.
3. The record, projected into the accounting fields. Take one week of that workflow's activity and produce, from the capability records, entries carrying a date, a recipient, a description of the information and a statement of purpose. Then take the same week and try to produce them from your existing audit log. The gap between those two outputs is the deliverable — it is the thing you show a compliance officer, and it is the thing that gets the work funded.

What not to build that week: revocation, possession binding, a caveat language, a policy DSL, a user interface, sensitivity weighting, graph compaction. Every one is real work a real deployment eventually needs, and every one is a way to spend a week without computing a closure. Compute the closure first. It reliably changes what people think they are building.

The last thing I would say to a team weighing this up is that the argument is not primarily a privacy argument. Narrowing caps exposure, and the failure section above should make clear how much and how little. The argument that carries is that an organisation which cannot state what a clinical agent could have reached cannot rebut a breach presumption, cannot answer an accounting request, cannot certify its own record to a court, and cannot improve the control except by guessing. The rule has been asking for persons, categories and conditions for two decades. What changed is that the principal is now software making thousands of requests a day — and the rule was written to cover software programs all along.