A hospital security questionnaire can run to hundreds of questions, and the first one feels impossible. It stops feeling impossible when you notice that the questions repeat. Hundreds of questions are asking about a few dozen controls from different angles.
This post lists the clusters and says what the reviewer is trying to learn from each. It is a framework from building and reviewing healthcare software, not a compliance guarantee, and your buyer’s form will have its own wording. Ask them what standard they review against before you assume.
The clusters
1. Where PHI lives and moves. A data-flow diagram and an inventory of stores. The reviewer wants to know every place PHI is stored, processed, or transmitted, including logs, backups, analytics, and support tools. A missing box on this diagram is the most common reason reviews stall.
2. Who can access it. Authentication, role-based access, least privilege, session handling, and how access is granted and removed. The question behind the questions: if an employee leaves tomorrow, can you prove their access ended? See role-based access in Firebase.
3. Whether you can prove what happened. Audit logging of PHI access, who reviews it, and how long you keep it. Reviewers want an answer to “who touched this record” in minutes. See the audit trail design.
4. Encryption. In transit, at rest, and key management. Easy to say yes to, so expect follow-ups about who holds the keys and how they rotate.
5. Vendors and subprocessors. Every service that can see PHI, and whether it is under a Business Associate Agreement. This catches teams out, because a vendor “covered” in marketing may not be covered for the product you use. For one example, see what Google’s BAA does and does not cover, and for AI vendors, sending PHI to LLM APIs.
6. Incident response and breach notification. A written plan, an owner, and a realistic timeline. The reviewer is checking that the plan exists and that someone has read it.
7. Backup, recovery, and availability. What you back up, how often, and whether you have ever restored one.
8. Data retention and deletion. How long you keep data, how a customer gets theirs back, and what happens when the contract ends.
9. Secure development. Code review, dependency management, secrets handling, separation of environments, and whether production PHI ever reaches development.
10. Risk analysis and policies. A documented risk analysis, security policies, and workforce training. For a one-person practice this is short, but it must exist.
How to have the answers ready
- Write one short document per cluster, in plain language, describing what the system actually does.
- Keep a diagram of PHI flows and a vendor list, both dated.
- Collect evidence once: screenshots of access settings, sample audit entries, a copy of the incident plan.
- Answer honestly where you have a gap and say when it will close. A stated gap with a date reads better than a vague yes.
- Reuse the same material across every buyer, and update it when the system changes.
None of this is a substitute for a certification where a buyer requires one, and none of it replaces legal review of your agreements. But a system built with these clusters in mind produces the answers as a side effect, which is the point of treating compliance as architecture instead of paperwork.