# In-room AI and ambient sensing readiness evaluation (HospitalRoom.org)

License: CC BY 4.0 — attribute 'HospitalRoom.org' with a link back to
https://hospitalroom.org/frameworks/ai-sensing-readiness

A HospitalRoom.org working checklist, not a published standard. Evaluate one camera, microphone, ambient documentation tool, or AI model at a time, in the room where it runs, during a busy shift and at night. Record evidence and an owner for each condition. Do not score or rank vendors.

- Sensor or model evaluated:
- Unit and rooms:
- Date of evaluation:

## Defined purpose and intended use

Each sensor and model in the room has a written clinical purpose, the unit and patient population it is meant for, and a statement of what it is explicitly not for — a fall-risk camera is not a staffing substitute or a security recording. Whether the function is regulated device software is determined, not assumed.

Why it matters: Purpose is the boundary every other condition is measured against. Without it, retention, access, validation, and response cannot be judged, and a sensor installed for one reason drifts into others — staffing cover, incident evidence, staff performance review — that patients were never told about and the model was never checked for.

Question: Does each in-room sensor and model have a written purpose — unit, population, and what it must not be used for — and has someone determined whether it is regulated device software?

Questions to ask:

- [ ] Does each in-room sensor and model have a written purpose — unit, population, and what it must not be used for — and has someone determined whether it is regulated device software?
- [ ] Which unit, patient population, and clinical decision is this sensor or model for?
- [ ] What is it explicitly not for — staffing substitution, security recording, staff performance review?
- [ ] Has someone with the right regulatory expertise determined whether the function is device software, and is that determination written down?
- [ ] If the function is FDA-authorized, does local use stay within its authorized intended use?

Warning signs observed:

- [ ] The purpose statement is a vendor brochure or a line in a purchase order.
- [ ] Recordings are kept in case they are needed for incidents or complaints.
- [ ] Staffing plans count the camera as a replacement for in-person observation without a documented clinical decision.
- [ ] Nobody can say whether the function is regulated device software, or the only answer is the vendor's.

| Met | Partial | Not met | Evidence | Owner |
| --- | --- | --- | --- | --- |
| ☐ | ☐ | ☐ | | |

## Visible notice and consent

Notice and consent that patients and visitors can actually see: in-room signage and admission notice, a visible indicator whenever audio or video is live, a clear path to opt out or pause where clinically possible, and policy covering staff, visitors, and roommates. Patients with limited language access or limited decision-making capacity are considered explicitly.

Why it matters: Notice that exists only in a policy binder is not notice. People in a room behave differently when they know a camera or microphone is live, and trust depends on being able to tell at a glance whether it is. Shared rooms, visitors, and patients who cannot read the signage are where notice most often breaks.

Question: Can a patient, visitor, or staff member tell from inside the room whether audio or video is live right now, and do they know how to ask for a pause?

Questions to ask:

- [ ] Can a patient, visitor, or staff member tell from inside the room whether audio or video is live right now, and do they know how to ask for a pause?
- [ ] Is there signage at the door and in the room, and is the sensor described in admission materials?
- [ ] Is there a visible indicator — light, screen state, or physical shutter — whenever audio or video is live?
- [ ] Where clinically possible, how does a patient opt out or pause, and who records that choice?
- [ ] What does policy say about roommates, visitors, and staff who are captured but did not consent?
- [ ] How is notice given to patients with limited English proficiency, sensory impairment, or limited decision-making capacity, and who can speak for them?

Warning signs observed:

- [ ] Notice exists only inside the general admission consent form.
- [ ] There is no indicator when audio or video is live, or the indicator can be switched off while the stream continues.
- [ ] Opting out requires a ticket to IT, or nobody on the unit knows the process.
- [ ] Signage is in one language on a unit that serves several.
- [ ] Ambient listening starts without anyone telling the patient it is on.

| Met | Partial | Not met | Evidence | Owner |
| --- | --- | --- | --- | --- |
| ☐ | ☐ | ☐ | | |

## Privacy-preserving data handling

Data minimization — process at the edge where possible, and avoid storing raw video or audio unless a defined purpose needs it — with defined retention and deletion, access logging, and separation of AI-derived alerts from raw media. HIPAA applies to the hospital; state privacy and recording laws vary and must be checked locally.

Why it matters: Much of the privacy exposure of an in-room sensor is set by what it keeps, not only by what it sees. An event such as a patient sitting at the bed edge can be shared with far less exposure than the video it came from. Retention, access, and deletion rules defined before go-live are easier to enforce than rules negotiated after the first request for a recording.

Question: What raw audio or video is stored, for how long, and who can see it — is that access logged, and are AI-derived alerts kept separate from the media?

Questions to ask:

- [ ] What raw audio or video is stored, for how long, and who can see it — is that access logged, and are AI-derived alerts kept separate from the media?
- [ ] Is processing done at the edge, and what, if anything, leaves the room as raw media?
- [ ] What is the written retention period for raw media, transcripts, and derived outputs, and how is deletion verified?
- [ ] Who can access stored media, and is every access logged and reviewed?
- [ ] Are AI-derived alerts and events stored separately from the media they came from?
- [ ] Have state privacy and audio or video recording laws been reviewed for this use, in addition to HIPAA?
- [ ] Are the sensors and their network path inside the organization's IEC 80001-1 risk management?

Warning signs observed:

- [ ] Raw video or audio is retained by default, or with no stated limit.
- [ ] Media is reachable by roles with no clinical or operational need, or access is not logged.
- [ ] An alert can only be reviewed by opening the underlying recording.
- [ ] Data leaves the hospital for processing and nobody can describe the agreement that governs it.
- [ ] Legal review covered HIPAA but not state recording law.

| Met | Partial | Not met | Evidence | Owner |
| --- | --- | --- | --- | --- |
| ☐ | ☐ | ☐ | | |

## Local validation and ongoing monitoring

The model is checked on this hospital's patients, rooms, lighting, and workflows before go-live; performance is monitored over time for drift and for differences across patient groups; and there is a written plan for model updates. For device software, FDA's predetermined change control plan (PCCP) concept describes how planned modifications are specified and assessed in advance. Vendor claims are a starting point, not proof.

Why it matters: Vision and speech models are sensitive to things that vary between hospitals: room layout, lighting, camera position, bed type, accents, background noise, and documentation style. Published evidence on in-room computer-vision fall detection and virtual sitting is still mostly single-site and observational, and vendor-reported performance is not independent validation. Local checking is the only way to learn how a model behaves in these rooms.

Question: Has the model been checked on this unit's patients, rooms, and workflows before go-live, and who reviews its performance — including across patient groups — over time and after updates?

Questions to ask:

- [ ] Has the model been checked on this unit's patients, rooms, and workflows before go-live, and who reviews its performance — including across patient groups — over time and after updates?
- [ ] What local check was run before go-live, on which unit, for how long, and with what definition of a correct alert or an acceptable draft?
- [ ] Who reviews false alerts, missed events, and documentation errors, and how often?
- [ ] Where relevant to the model, is performance compared across patient groups — for example by age, skin tone, mobility aid, language, or speech pattern?
- [ ] How are model updates announced, tested, and approved before they reach the room, and does the manufacturer describe a PCCP for authorized device software?
- [ ] What finding would pause the model, and who can make that call?

Warning signs observed:

- [ ] The only performance evidence is the vendor's own figures.
- [ ] Go-live happened without a local baseline, so drift cannot be detected.
- [ ] Model updates arrive without notice or local review.
- [ ] Nobody reviews false or missed alerts once the pilot ends.
- [ ] Performance has never been examined for different patient groups.

| Met | Partial | Not met | Evidence | Owner |
| --- | --- | --- | --- | --- |
| ☐ | ☐ | ☐ | | |

## Accountable human response

Every AI alert or ambient output has a named human owner, a response expectation, a way to override or correct it, and a feedback path. Ambient documentation drafts are reviewed and signed by the clinician. AI alerts go through the same alarm-path and routing governance as other signals.

Why it matters: An AI output nobody owns becomes either noise or an unexamined decision. Alerts from cameras and models land on the same phones, badges, and stations as device alarms and nurse calls, so they inherit the same failure modes — wrong recipient, no escalation, no record. A draft note signed without review carries the model's errors into the legal record.

Question: For every AI alert or ambient output, who is the named owner, what response is expected, and how do they override, correct, and report it?

Questions to ask:

- [ ] For every AI alert or ambient output, who is the named owner, what response is expected, and how do they override, correct, and report it?
- [ ] Who receives each alert type, and what response is expected?
- [ ] Does the alert travel through the same routing, escalation, and logging as other alarms and calls?
- [ ] Can the responder dismiss, override, or correct the output, and is that recorded?
- [ ] Is every ambient documentation draft reviewed and signed by the clinician, and are edits sampled for quality?
- [ ] Where do corrections and complaints go, and who acts on them?

Warning signs observed:

- [ ] AI alerts arrive on a separate app or console outside the unit's alarm and call routing.
- [ ] No one is named as the owner of an alert type.
- [ ] Overrides are impossible, or are not recorded.
- [ ] Ambient drafts are accepted in bulk or signed without being read.
- [ ] Staff feedback has no route back to the people who configure the model.

| Met | Partial | Not met | Evidence | Owner |
| --- | --- | --- | --- | --- |
| ☐ | ☐ | ☐ | | |

## Working rule

Defined purpose and accountable human response must both be at least Partial before any in-room camera, microphone, or model goes live. A sensor without a written purpose is surveillance, and an AI alert without a named owner is noise. Vendor-reported performance alone never counts as Met for local validation.

## Evidence note

This is a working checklist, not a published standard. It draws on the NIST AI Risk Management Framework (AI RMF 1.0), ISO/IEC 42001:2023 on AI management systems, FDA's January 2025 draft guidance on AI-enabled device software functions, FDA's final guidance on predetermined change control plans for AI-enabled device software functions, FDA's public list of AI-enabled medical devices, and ONC's HTI-1 decision support intervention requirements for certified health IT. Published evidence on in-room computer-vision fall detection and virtual sitting is still mostly single-site and observational, and vendor-reported performance is not independent validation. ONC rules are subject to revision; check their current status.

## Sources

- NIST AI Risk Management Framework (AI RMF 1.0): https://www.nist.gov/itl/ai-risk-management-framework — A voluntary framework for managing risks of AI systems, organized around four functions: Govern, Map, Measure, and Manage. Not specific to healthcare or to patient rooms.
- ISO/IEC 42001:2023, Artificial intelligence — Management system: https://www.iso.org/standard/81230.html — An international standard specifying requirements for establishing, maintaining, and continually improving an organizational AI management system. It governs the organization, not a specific model or room.
- FDA draft guidance (January 2025): Artificial Intelligence-Enabled Device Software Functions: Lifecycle Management and Marketing Submission Recommendations: https://www.fda.gov/regulatory-information/search-fda-guidance-documents/artificial-intelligence-enabled-device-software-functions-lifecycle-management-and-marketing — Draft guidance, not final. Describes FDA's current thinking on lifecycle management and marketing submission content for AI-enabled device software functions. Applies to device software, not to every AI function in a room.
- FDA final guidance: Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions: https://www.fda.gov/regulatory-information/search-fda-guidance-documents/marketing-submission-recommendations-predetermined-change-control-plan-artificial-intelligence — Final guidance describing the predetermined change control plan (PCCP) concept: how a manufacturer can specify planned modifications to AI-enabled device software, and how they will be developed, validated, and assessed, in advance.
- FDA list of AI-enabled medical devices: https://www.fda.gov/medical-devices/software-medical-device-samd/artificial-intelligence-enabled-medical-devices — A public FDA list of AI-enabled devices authorized for marketing in the United States. Presence on the list reflects a marketing authorization for a stated intended use; it is not local validation.
- ONC HTI-1 Final Rule and the Health IT Certification Program: https://www.healthit.gov/topic/laws-regulation-and-policy/health-data-technology-and-interoperability-certification-program — HTI-1 includes decision support intervention (DSI) requirements, including source-attribute transparency, for certified health IT. It applies to certified health IT developers, not directly to in-room sensors. ONC rules are subject to revision; check current status.