Standard AI Model Catalog for Health Systems: How to Approve a Model Once for Every Department

What a catalog entry has to contain

In many health systems the same model is reviewed separately by clinical, revenue cycle, research, and administrative teams. Each review produces its own assessment, its own conditions of use, and its own view of how PHI may be handled. The approval is then stored as a document, and nothing ties it to what the model can do when someone calls it.

A standard catalog entry replaces those parallel reviews with one structured record. The fields below are a working design, not a regulatory template. No regulation prescribes a catalog format. What matters is that each field can be evaluated by a machine at the moment of use, not only read by a reviewer.

The first four fields carry the approval itself. The last two make the approval defensible and keep it current.

• Approved use cases: The specific tasks the model may perform, such as summarizing a clinical note or drafting a prior authorization letter. Anything outside the list is not approved.
• Data classes: Which data the model may receive and return, with PHI treated as its own class and a stated handling rule for each class.
• Permitted tools: The tools, agents, and MCP servers the model may call, and the actions each may take.
• Escalation conditions: The situations that require human approval before an action proceeds, such as a write to a record system.
• Evaluation and monitoring requirements: How accuracy, bias, and ongoing performance are checked for this model.
• Owner and risk analysis reference: The accountable owner and the HIPAA risk analysis that supports the approved conditions.

Build the approval workflow around a central inventory

Start with an inventory of the models in use and the departmental uses of each. Federal AI strategy guidance emphasizes comprehensive inventories of AI use cases and clear roles, and the same logic applies inside a health system. You cannot approve once for every department if you do not know which departments are already using the model.

Assign three roles explicitly: a catalog owner who maintains the entry format, an approver or review body that decides, and an exception path for departments that need conditions the standard entry does not allow. Keep the exception path narrow. If every department negotiates its own conditions, the catalog reverts to duplicate reviews under a different name.

Make evaluation and monitoring a required field, not an optional one. A federal data brief on hospital use of predictive AI reports that most hospitals evaluated their models for accuracy and bias and monitored them after implementation, but fewer did so for all or most of their models. A required field closes that gap by making the absence of an evaluation visible at approval time.

Finally, define review triggers. A new model version, a new tool permission, or a new data class should reopen the entry. HHS proposed in January 2025 to require review and testing of technical controls at least every 12 months, or sooner on environmental or operational change. As of November 2026, that remains a proposal, not current law. Building the triggers now is still sound practice.

One policy, scoped by department

Approving once does not mean every department gets identical access. It means the base approval is shared and the differences are explicit. Billing may be approved to use a model on claims text but not on clinical notes. Research may be allowed a narrower tool set and a stricter PHI rule. Clinical use may require human approval before any tool call that changes a record.

Express this as one policy with scoping attributes: department, user role, data class, and tool access. The base policy states what the model may do for the health system. Each scope narrows it. A scope can restrict the base approval but should not widen it. Widening is an exception and goes through the exception path.

This design is consistent with the HIPAA access control standard at 45 CFR 164.312(a)(1), which requires technical policies and procedures that allow access to electronic information systems maintaining ePHI only to persons or software programs that have been granted access rights. The text refers to software programs as well as people. A reasonable reading is that agents and tool integrations need defined access rights too. That is an interpretation, not AI-specific regulatory language, so confirm it with your privacy and compliance counsel.

The benefit for architects is a single source of truth. When the approval changes, one policy changes, and every department's scope inherits it.

Evidence for HIPAA 164.312(b) and NIST

The HIPAA audit controls standard at 45 CFR 164.312(b) requires a covered entity or business associate to implement hardware, software, and procedural mechanisms that record and examine activity in information systems that contain or use ePHI. It is technology-neutral. It does not prescribe log fields for AI prompts, responses, or tool calls, so deciding what to record for AI interactions is a design decision grounded in your risk analysis.

For a model approved across departments, an auditor will want to see that actual use matched the approved conditions. That calls for records showing which scope applied, which data class was involved, which tool was called, what the policy decided, and whether a person approved an escalation. Because enforcement happens in the execution path, those records come from the decision itself. Evidence is a by-product of enforcement, not something reconstructed from application logs later.

Trussed produces this evidence continuously and maps it to HIPAA and NIST, among other frameworks. It can be self-managed in the customer cloud, with configurable retention and data residency, which matters when evidence itself contains sensitive context.

The January 2025 HHS proposal states that OCR enforcement experience suggests compliance with the audit controls standard could improve with more specificity. As of November 2026, it is a proposal. Even so, it signals where examination of audit controls may go, and entries that already reference the supporting risk analysis are better placed.