How to Track LLM Cost per Patient Encounter Without Putting PHI in Usage Records

Treat attribution as a data-modeling and privacy problem first

Healthcare teams running LLM workloads for documentation, coding, prior authorization, and claims review usually receive usage data at the API key, model, or account level. Finance and operations then cannot say what a single encounter or claim cost. Closing that gap requires an identifier on every request, and that is where the risk sits: an identifier placed in a prompt, a metadata field, or a usage record can turn a cost report into a store of PHI.

The pattern in this guide is deliberately narrow. Each interaction and each tool call carries a correlation key. Each call produces a record. Cost is computed from that record and summed by key. Nothing in this pattern reconstructs a business transaction or traces a workflow end to end across agents. It joins records that share a key. That boundary matters for how you describe the resulting numbers to finance and to auditors.

CMS guidance on production AI recommends tracking traces and key metrics. Per-call attribution records are one concrete way to produce the metrics side of that recommendation for cost.

Choose a correlation identifier that is not PHI

The key should be a surrogate: a random or system-issued value with no derivation from any patient identifier. HHS de-identification guidance shows why derivation is risky. A data set containing patient initials, or the last four digits of a Social Security number, would not meet the Safe Harbor method. A hash or truncation of a medical record number or encounter number carries the same problem in practice, because anyone holding the source value can recompute it.

Issue the surrogate in the system that already owns the encounter or claim, and keep the mapping from surrogate to encounter in that system, under existing PHI controls. The LLM path, the usage store, and the cost reports then only ever see the surrogate. Finance joins cost to the encounter by querying the mapping under normal access rules, not by reading identifiers out of usage data.

Be conservative about what the surrogate is. HHS notes that even de-identified data carries a re-identification risk that is very small but not zero. Whether a surrogate counts as PHI depends on the facts, including who can reach the mapping. Under the use and disclosure limits at 45 CFR 164.502(a), the safe design is to place any store holding the key, or the mapping, within your HIPAA control scope. HHS also advises documenting explicitly which features or values pertain to identifiers. Do that for every field in the usage record.

Tag at the point of execution and record one entry per call

Tag where the call is made, not afterward. If each application team attaches the key itself, coverage will be uneven and the totals will not be defensible. A single enforcement point in the execution path can attach the key to every interaction and tool call consistently, and reject or flag calls that arrive without one.

Each call should produce one evidence record. The following fields support both unit-cost calculation and audit review.

• Surrogate correlation key: The non-PHI identifier for the encounter or claim, and nothing derived from patient data.
• Caller identity: The unique user or service identity behind the call, consistent with the unique user identification specification in 45 CFR 164.312.
• Model and version: The model that served the call, so the correct price can be applied.
• Input and output token counts: Taken from the provider's reported usage for that call, kept separate because they are usually priced differently.
• Policy decision and redaction outcome: Whether the call was allowed, redacted, or blocked, and what was redacted by category, not by content.
• Timestamp: The time of the call, used for price lookup and for reconstructing activity during audit.

Calculate cost and decide how to count retries, tool calls, and shared context

Per-interaction cost is input tokens multiplied by the input price, plus output tokens multiplied by the output price, using the price in effect for that model at the time of the call. Store the price table with effective dates so any figure can be recomputed later. Reproducibility is what makes a per-encounter number defensible: given the same records and the same price table, anyone should get the same total.

The harder work is counting rules, and these are design decisions to settle and document before reporting begins.

Retries: decide whether a retried call is charged to the encounter that triggered it, or to a separate overhead bucket. Whichever you choose, record each attempt as its own entry so the choice can be applied or changed without losing data.

Tool calls: a tool call that invokes a model carries the same key as the interaction that triggered it. Tool calls that consume no tokens still belong in the record for audit purposes.

Shared context: system prompts, retrieved reference material, or cached context reused across encounters have no single owner. Choose an allocation rule, such as charging the encounter that made the call, and state it in the report definition.

The rule matters less than applying it consistently and writing it down.

Where enforcement in the execution path fits, and what the records must not contain

Enforcement in the execution path serves attribution in two ways. First, it is a single, consistent place to attach the key. Second, it can act on content before logging: allow the call, redact sensitive content, or block it. If PHI is redacted before the evidence record is written, the usage store does not inherit PHI from prompts, metadata, or tool arguments. Treat that ordering as a design requirement and test it with synthetic data containing identifiers.

The same decision data feeds audit review. Records that show who called, what was decided, and when give reviewers material to examine activity, which is the purpose of audit controls under 45 CFR 164.312(b). Retention periods and residency are your policy decisions, set with your compliance team. Trussed enforces policy in the execution path, runs self-managed in the customer's cloud, and supports configurable retention and data residency, so the evidence stays where your own controls apply.

On regulatory status, the Security Rule amendments published at 90 FR 925 in January 2025 are a proposal. As of October 2026, design against the current rule text and revisit if a final rule is issued.

Limits of the approach

Per-interaction tagging gives accurate cost for the calls it sees. It does not, by itself, tell you which calls belong to one unit of work when a workflow spans several agents, hands context between them, or runs asynchronously. If an upstream agent fails to pass the key to a downstream one, those calls are untagged or mis-tagged, and the encounter total is understated.

Aggregating cost across multi-step, multi-agent workflows needs additional systems: key propagation that your orchestration layer is responsible for, and a reconciliation job that compares tagged totals against account-level usage to expose untagged spend. Enforcement at the interaction and tool-call level supplies the per-call records those systems consume. It does not replace them.

Practical next steps: define the surrogate and where its mapping lives, write the retry and shared-context counting rules, add the key and the field list above to your enforcement point, and report an untagged-spend percentage alongside every per-encounter figure so readers know how much of the total is attributed.