The AI inventory and product registry
The mapping
| Framework | Where this control sits |
|---|---|
| Joint Commission RUAIH | Focus area 1 — Governance |
| CHAI governance playbooks | Playbook 4 — Responsible AI lifecycle management |
| NIST AI RMF | MAP |
| HTI-1 | Predictive DSIs must be identifiable to satisfy source-attribute disclosure |
The artifact: AI use case registry
Who signs it: The accountable executive for AI, usually the CMIO or CDO
What an assessor actually asks for
The register itself, and the method by which it was compiled. The second question is the harder one, because it tests whether the register is complete or merely populated.
Why the mapping is not obvious
This is the control everything else depends on and the one most commonly wrong. You cannot risk-tier, validate, monitor or train against an inventory you do not have. It sits under CHAI’s lifecycle playbook rather than its structure playbook, which is why organisations working from CHAI alone often build it late.
The most common failure
The register is incomplete in a predictable direction: it lists what was procured and misses what arrived inside something already procured — the model in an EHR module, the scoring in the population-health tool, the triage logic in the patient portal. Build it from the EHR vendor’s own feature list and two years of contracts, not from what people volunteer.
Where this sits in the whole map
This is one control in the RUAIH ↔ CHAI ↔ NIST crosswalk. The artifact itself is specified at AI use case registry.
Written and reviewed by Neel Chauhan, MD MBA, physician-executive and founder of the Healthcare AI Institute. Last reviewed 2026-07-30.
Generated from data/crosswalk.yaml, where the mapping and the commentary for each control are authored individually. Reviewed on each framework revision.
The Institute accepts no vendor sponsorship, holds no vendor equity and takes no referral fees.