On this page
Published:
Key Takeaways
- Hospitals ask about AI data flows, outside AI services, model updates, and failure behavior on top of the usual security questions.
- Your FDA cybersecurity file already holds most answers; package it for hospital reviewers.
- Be specific about whether patient data leaves the hospital, where it goes, and whether it trains your model.
- Explain how model updates are approved, signed, and announced, and how the hospital can delay them.
- Keep the MDS2, [SBOM](/services/fda-compliant-sbom-services-for-medtech "SBOM generation and management"), and a short security summary current for each release.
Hospitals reviewing an AI medical device ask where patient data goes, whether an outside AI service sees it, how the model is protected and updated, who can change it, and what happens when it fails. Answer with evidence you already built for the FDA: architecture views, the threat model, SBOM, pen test summary, and update plan. Prepare these answers before the first hospital deal, not during it.
Reviewed October 14, 2026
FDA clearance gets a device to market. A hospital security review gets it into the building. For AI devices, those reviews now include questions that did not exist a few years ago, and generic answers stall deals for weeks.
The good news: most answers come from work you already did for your submission. This post lists the questions we see most often, explains what the reviewer is really checking, and shows what evidence to send. For the full review process, see our hospital security review journey.
Why This Matters
The FDA's February 3, 2026 premarket cybersecurity guidance asks makers to give users security information, including an SBOM and guidance on secure use. Hospitals use that information in their own risk reviews. Many also use the MDS2 form, a voluntary industry form (ANSI/NEMA HN 1-2019) that the FDA does not require.
AI adds new questions. The FDA's January 2025 draft AI-enabled device software functions guidance recommends clear user information about how the model works, its data, and its limits. It is still a draft, but hospital reviewers read the same documents and ask matching questions.
Questions About Patient Data
Does patient data leave our network? Say yes or no, then list what leaves, where it goes, and how it is protected in transit and at rest. A data flow diagram answers this faster than a paragraph.
Is our data used to train your model? Hospitals want a clear answer and a contract term to match. If you do train on customer data, explain de-identification, consent, and how a hospital can opt out.
Where is the data stored? Name the cloud provider and region. Our data sovereignty post covers how to answer location and transfer questions.
Questions About Outside AI Services
Do you send data to an outside AI provider? If a feature calls an outside model, name the provider, what data is sent, and the provider's retention terms. Reviewers ask this most often about chat-style features. Our generative AI device security post covers the controls behind a good answer.
What happens if that provider changes its model? Explain how you pin versions, test changes before they reach the device, and roll back.
Questions About the Model Itself
How do you stop someone from changing the model? Describe signing, verification on load, and who can approve a release. See our post on AI model integrity.
How do you protect the data the model learned from? Summarize provenance, access control, and dataset versioning, as in our training data security post.
Was the AI part tested by an outside team? Share a pen test summary that names the AI-specific tests, such as model swap, API abuse, and prompt injection where relevant.
Questions About Updates and Failure
See also: AI Model Integrity for Medical Devices: Signing and Updates, AI Training Data Security for Medical Devices: FDA Evidence, and Threat Modeling AI-Enabled Medical Devices: Worked Example.
How often does the model change, and can we delay updates? Give the update cadence, how updates are announced, and whether hospitals can schedule them. If you have a PCCP, explain in plain terms which changes it covers.
What happens if the model is unavailable or wrong? Describe the device's safe behavior: fallback modes, alerts, and limits enforced outside the model.
How will you tell us about vulnerabilities? Point to your vulnerability disclosure policy, your monitoring process, and the timelines in your postmarket plan.
Every answer should point to a document or test result. "We follow best practices" stalls reviews; "see data flow diagram, page 3, and pen test summary, section 4" moves them forward.
What to Have Ready
- A current MDS2 (our MDS2 generator helps draft one).
- An SBOM that lists models, AI runtimes, and outside AI services.
- A two-page security summary with a data flow diagram.
- A pen test summary that names AI-specific tests.
- Your update and vulnerability disclosure policies.
How Blue Goat Approaches This
We prepare the hospital-facing package from the same evidence we build for your FDA submission, so the two never disagree. That includes the security summary, data flow diagrams, MDS2 draft, SBOM, and a pen test summary that names the AI tests we ran. When hospitals send questionnaires, we help draft answers that point to evidence. This work supports both FDA clearance and hospital approval for your device; it does not cover the hospital's own IT security. See Hospital Security Review Support and AI/ML Medical Device Security.
FAQ
Do hospitals require an MDS2 for AI devices?
Many ask for one, though it is voluntary and the FDA does not require it. The form does not have AI-specific questions, so reviewers often add their own on data use, outside AI services, and model updates. Fill in the MDS2 accurately and attach a short AI section that answers those questions up front.
Should we share our full threat model with hospitals?
Usually not. A summary with the main threats, controls, and test results is enough, and it avoids exposing details an attacker could use. Offer the full model under NDA if a reviewer insists. Keep the summary in step with the version in your FDA file so the two never conflict.
What if our AI feature uses an outside chatbot service?
Expect detailed questions. Name the provider, the data sent, retention and training terms, and how you prevent patient data from reaching it when it should not. Many hospitals require a signed business associate agreement chain when patient data is involved. Have the answers and agreements ready before the review starts.
Can a strong FDA file replace a hospital review?
No, but it shortens it. Hospitals run their own risk process and will still send questions. If your FDA cybersecurity file is complete, most answers already exist and just need packaging. Teams that prepare that package early often finish reviews in days rather than weeks.
How often should we update these documents?
Update them with every release that changes data flows, models, outside services, or connections, and at least once a year. Hospitals often re-review at renewal. Keep a dated version history so you can show what changed and when.
CTA
Facing hospital security reviews for an AI device? Book a free 30-minute discovery call. We'll review your current evidence and send a fixed-fee proposal for the package. Nothing is billed until you approve it.
About the author
Christian Espinosa, MBA · Founder & CEO, Blue Goat Cyber
U.S. Air Force Academy graduate and veteran with 30+ years in cybersecurity. Founded Alpine Security in 2014 (acquired 2020), then Blue Goat Cyber in 2022. Has supported 275+ medical devices, with no cybersecurity-related rejections to date. Author of three books including The Smartest Person in the Room. Ironman triathlete and mountaineer.
Sources & references
Primary sources cited in this article. Links open in a new tab.