A HIPAA app architecture review should answer one blunt question: where can electronic protected health information go? Trace the request through every service, log, backup, support tool, and vendor. Then attach an owner and a safeguard to each copy. The checklist is evidence for a risk analysis, not a compliance badge.
Takeaways:
- HHS requires administrative, physical, and technical safeguards; an encryption checkbox covers only part of the job.
- A cloud provider that maintains ePHI is a business associate even if it cannot decrypt the data.
- Access, audit, integrity, authentication, and transmission security each need design evidence.
- The architecture packet should survive one test: can an engineer trace and delete every ePHI copy?
Start with the request path, not the cloud logo
Take a real event. A patient submits a symptom form. The browser sends it to an API. A queue hands it to a worker. The worker writes a record, emits a log, and calls an outside service. A backup copies the database overnight. On Wednesday, a support engineer opens the account after a clinic reports a problem.
That story is the architecture review. Boxes labeled “HIPAA cloud” hide the interesting parts: the queue retry that retains a payload, the error logger that captures a request body, the support console with broad production access, and the backup no one has restored in a year.
HHS says the Security Rule protects the confidentiality, integrity, and availability of ePHI through administrative, physical, and technical safeguards. Its current summary names access control, audit controls, integrity, authentication, and transmission security as technical standards. NIST SP 800-66 Rev. 2 maps those requirements to practical cybersecurity resources. Neither source prescribes one framework or one cloud.
The architecture evidence table
Use one row for every system that creates, receives, maintains, or transmits ePHI. A blank cell is work, not “not applicable,” until somebody proves otherwise.
| Evidence | Question the team must answer | Artifact to keep |
|---|---|---|
| Data inventory | Which fields are ePHI, and why does this service need them? | Field-level inventory with purpose and owner |
| Identity | How is the person or workload authenticated? | Identity-flow diagram and test evidence |
| Authorization | Which role can read, change, export, or delete each record? | Role-permission matrix with denied cases |
| Audit | Which access and administrative actions are recorded? | Event catalog, sample events, and review owner |
| Integrity | How do you detect improper alteration or destruction? | Change history, validation rule, or integrity control |
| Transmission | How is ePHI protected across each network hop? | Protocol and certificate inventory |
| Storage | Where do primary, replica, cache, and search copies live? | Store list with encryption and retention settings |
| Recovery | Can the team restore usable ePHI when the primary system fails? | Dated restore exercise with recovery result |
| Vendors | Which subcontractor touches ePHI, including support and AI services? | BAA register and approved data-flow scope |
| Disposal | What happens to primary data, backups, logs, and exports after deletion? | Tested deletion and retention procedure |
Do not accept “the vendor handles it” as an answer. HHS’s cloud guidance says the customer and cloud provider should confirm in writing how each party addresses Security Rule responsibilities. Shared responsibility needs named controls on both sides.
Four traps found outside the database
Logs
Request bodies, stack traces, and model prompts can copy ePHI into a logging system with different access and retention. Redact at the source. Then test the redaction with realistic failures, because the happy path is rarely what leaks the chart.
Support
Support access is production access. Give it a narrow role, a reason code, a time boundary, and an audit event. A shared admin password cannot tell you which person opened a record, which defeats the point of unique identity and audit evidence.
Backups
Availability is part of the Security Rule. HHS’s cloud guidance notes that encryption alone does not keep ePHI available or protect it from corruption. A backup job that reports success is not a recovery test. Restore it into an isolated environment, verify the record count and application read path, then retain the dated result.
Analytics and session replay
An analytics tag can receive identifiers, form values, URLs, or page content. HHS has separate guidance on online tracking technologies used by regulated entities. The clean architecture default is to keep tracking code off authenticated clinical surfaces unless the data flow and legal basis have been reviewed and documented.
The BAA follows the data
HHS says a cloud service provider is a business associate when it creates, receives, maintains, or transmits ePHI on behalf of a covered entity or business associate. The rule still applies when the provider stores only encrypted ePHI and cannot decrypt it. Encryption changes risk; it does not erase the relationship.
Keep a vendor register next to the diagram. Record the service, data categories, permitted purpose, subprocessors, contract owner, BAA date, termination path, and evidence that data can be returned or destroyed. HHS’s sample BAA guidance covers safeguards, incident reporting, subcontractors, access to records, and return or destruction at termination.
Apply the same test to an AI scribe
An ambient scribe adds a sensitive input path: clinical audio and the text derived from it. Map capture, processing memory, transcript, draft note, model provider, user edits, signed output, logs, support access, and deletion. Ask which artifacts persist at every hop.
Patient Square is an AI clinical platform. Practice Copilot brings the whole practice under one AI copilot: an ambient AI Medical Scribe that hands back a structured SOAP note, ICD-10 suggestions, and a prescription draft minutes after the visit, plus a bundled AI EHR, scheduling, and messaging as you move up the plan. Hospitals get Hospital Copilot.
Patient Square states that visit audio is processed in memory and discarded after the note drafts, notes use TLS 1.2 or higher in transit and AES-256 at rest, access is role-scoped and logged, and BAAs are available. Its SOC 2 Type II audit is in progress, not complete. Those are product assertions to verify during procurement, alongside your own workflow and risk analysis. The security page is the right starting artifact.
A 60-minute design review
Put the request-path diagram on screen. Pick one create event, one support event, one backup restore, and one deletion. Walk each path slowly. For every service, ask: what data arrives, what data leaves, what is retained, who can see it, and what proof exists?
We think one hour spent naming copies beats a week polishing a generic policy. End with a defect list that has owners and due dates. Run the path again after fixes. For a wider vendor review, pair this architecture packet with the AI scribe security checklist and the BAA and consent guide.