HIPAA Security Architecture for AI-Assisted Clinical Documentation
A reference architecture and assessment method for a platform that turns spoken clinical information into a structured nursing note — and an argument that the decisive design question is not how to secure the protected health information you store, but why you are storing it at all.
What this is. An authored reference architecture and assessment method, written to be used before an application processes real patient information. It describes no client, no engagement, no assessment result and no product. The technology stack named throughout — React Native, Node.js, a managed Postgres service, a third-party model API — is a representative composition chosen because it is what small healthcare AI products are actually built from, not a description of anyone's system.
What it is not. It is not legal advice, it is not a compliance opinion, and it does not certify anything. Architecture supplies mechanisms; an organization implements and operates controls; evidence demonstrates them; an accountable person accepts the residual risk. Every regulatory statement below is dated and sourced, because this subject moves — see what this is not before relying on any of it.
01 The exposure chain
A nurse speaks for ninety seconds. Somewhere between that and a formatted note in a chart, the words pass through a mobile application, an API, a speech model, a language model, a database, a logging pipeline and a backup schedule. Each of those is a place where protected health information can come to rest, and most of them were never designed as a place to keep it.
This is the specific problem with AI-assisted clinical documentation, and it is not the problem most security reviews go looking for. A conventional review asks whether the application is encrypted, whether authentication is sound, whether the database is exposed. Those questions matter and this reference covers all three. But they assume a fixed set of places where the data lives, and the defining property of an AI documentation pipeline is that the data does not stay in one form. It arrives as audio, becomes a temporary file, becomes a transcript, becomes part of a prompt, becomes a model response, becomes a stored note, becomes a row in a backup, and along the way it may become a line in a log that nobody meant to write.
Every one of those is protected health information if it identifies a patient. Every one of them sits in a different system, often under a different provider's administrative control, frequently with a different retention default. And the retention defaults are the part that surprises people, because they were set by engineers solving a different problem — a thirty-day abuse-monitoring window at a model provider, a seven-day point-in-time recovery window at a database provider, a log aggregator that keeps request bodies because that is what makes debugging possible.
The assessment method in this reference starts from that chain rather than from a control list, for one reason: a control list tells you whether the controls you have are configured well. It does not tell you that the transcript is sitting in a temporary directory because a request timed out four hours ago, or that the log aggregator has been capturing request bodies since a debugging session in March. Those are the findings that matter, and they are only visible if the first thing you draw is where the data goes.
02 Where PHI actually lives
The first deliverable of a healthcare architecture assessment is not a control list. It is a map of every place the patient's information comes to rest, how it got there, how long it stays if nobody intervenes, and who has administrative control over the storage. Twelve locations recur in this class of application. Most product teams can name four of them without looking.
The explorer below is the working form of that map. For each location it records what the information is in that place, why it is there at all, what the default retention behaviour is when nobody has configured otherwise, the control that actually holds if something goes wrong, and the question to put to the engineering team. The last column is the one that produces findings, because the answer is frequently “I would have to check” — which is itself the finding.
A note on what counts. Protected health information is health information that identifies an individual, or for which there is a reasonable basis to believe it can be used to identify one. A transcript with no name in it is not automatically outside that definition — a nursing note routinely carries dates, a location, a condition and a sequence of events, and the Safe Harbor de-identification method at 45 CFR 164.514(b)(2) — removal of eighteen categories of identifier, of the individual and of their relatives, employers and household members — exists12 precisely because that combination identifies people. Treat every one of the twelve locations as holding PHI until someone has done the work to show otherwise.
03 Trust boundaries
The question is not “is it encrypted?”
It is: how many organizations have to be trusted with this patient's information, what does each of them receive, and could the architecture have avoided sending it to them at all?
Encryption answers a question about the channel. Trust-boundary analysis answers a question about the map. Both matter, but only one of them changes the architecture, and it is routinely the one that gets skipped — because every boundary in the list below was crossed for a good engineering reason, and each reason was individually sound.
Six boundaries appear in the reference composition. Two of them are frequently discovered rather than designed: the hosting provider, because the temporary file has to land on somebody's disk, and the observability stack, because a logger was configured to serialize request bodies during a debugging session and nobody changed it back.
The boundary question, asked properly
For each boundary the assessment asks four things in order, and the order is deliberate. First: does protected health information actually have to cross this boundary to deliver the feature? Second: if it does, what is the smallest thing that could cross instead? Third: what happens to it on the far side by default — not what the marketing page says, what the configuration currently does? Fourth: what contractual and technical position exists, and could the organization describe it accurately to a hospital's privacy officer on a phone call?
The first question is the one that changes architectures. A transcription boundary is unavoidable if the product transcribes speech. A note-generation boundary is unavoidable if the product generates notes. A logging boundary carrying full request bodies is entirely avoidable, and eliminating it removes a whole vendor from the compliance surface rather than adding a control to it.
04 Minimum necessary architecture
The governing design principle for a healthcare AI product is short: do not store protected health information because the technology makes storing it convenient. Every persistent copy is a copy that has to be encrypted, access-controlled, backed up, retained to a policy, deleted on request, disclosed in a subprocessor list, and produced in a breach investigation. Copies that do not exist need none of that.
Get the legal framing right, because it is easy to overstate. The minimum necessary standard at 45 CFR 164.502(b) and 164.514(d) is a Privacy Rule standard11, and it governs uses, disclosures and requests: a covered entity or business associate must make reasonable efforts to limit protected health information to the minimum necessary to accomplish the intended purpose. It does not mandate any particular technology, it is subject to explicit exceptions — including disclosures to or requests by a health care provider for treatment at 164.502(b)(2)(i) — and it is not the authority for a transient-processing design. The right way to describe the architecture below is as a reasonable engineering means of satisfying the implementation specifications at 164.514(d), and as a risk-reduction decision driven by the risk analysis required at 164.308(a)(1)(ii)(A). It is not a compliance claim.
Two models, drawn against the same pipeline
The difference between the two designs below is not the components. It is how many of them keep a copy after the nurse has read the note.
The transient processing model, stated precisely
- Clinical audio is captured on an authenticated device, in an authenticated session.
- Audio is transmitted over an encrypted channel and never written to device storage as an unprotected file.
- On the server, the audio exists for the duration of the request. Memory-only handling is preferred; where a file is unavoidable it lives in a mode-restricted, encrypted, non-shared location with a name that reveals nothing.
- A transcript is produced and held in memory.
- The transcript, plus the minimum instructions required, is sent to the note-generation service.
- The generated note is validated for structure, then returned to the authenticated user who initiated the request.
- Temporary audio and the transcript are securely deleted on the success path and on every failure path.
- No server-side clinical content is retained unless a business requirement demands it, and that requirement is written down.
Step seven is where implementations fail, and it has its own section below. Step eight is where product management pushes back, and the pushback is sometimes right: an integration with a records system may require a durable queue, a customer may contractually require an audit copy, a clinical safety case may require the source transcript to remain available for a defined period. The architecture question is not whether retention is ever justified. It is whether it was chosen or defaulted into.
What persistent storage buys
- A note that survives a lost device, a reinstall or a failed sync.
- An amendment and version history the clinical record may need.
- A source transcript to compare against when a note is disputed.
- Analytics on quality, latency and edit rates that improve the product.
- An easier integration story with downstream records systems.
What it costs
- Every stored note enters the encryption, access-control, retention, deletion and breach-notification perimeter permanently.
- Backups and point-in-time recovery keep copies that a delete request does not reach.
- Tenant isolation becomes a load-bearing control rather than a defensive one.
- The product becomes a clinical record repository, which is a different regulatory conversation with every customer.
- The blast radius of a credential compromise changes from one session to the whole corpus.
For an early-stage documentation-assistance product, the honest answer is often that persistence was never a requirement — it was the default behaviour of the framework someone reached for. Establishing that during design costs an afternoon. Establishing it after the first hospital security questionnaire costs a migration.
05 Temporary audio and the failure path
Clinical audio is the most sensitive artifact in the system and the shortest-lived, which is exactly the combination that produces careless handling. It captures whatever was audible in the room — the patient, the family member, the colleague at the next bed — and it exists for perhaps four seconds on a good day. Nobody designs a retention policy for four seconds. That is the gap.
The question that finds the defect: what happens to the temporary audio when processing fails halfway through?
Almost every implementation deletes correctly on the success path. The failure paths are written later, under time pressure, by someone getting the retry logic to work — and a retry that leaves the source file in place is the correct engineering decision for reliability and the wrong one for exposure.
What the review examines
01 Whether disk is used at all
Streaming the audio through memory to the transcription call removes the entire class of finding. Where a library requires a file path, the question becomes whether an in-memory filesystem or an ephemeral, non-persistent volume is available.
02 Where the file lands
The system temporary directory is shared, world-traversable on many images, and outlives the process. A dedicated directory with restrictive modes, owned by the service account, is the minimum.
03 What the filename says
Filenames end up in logs, in stack traces, in directory listings and in support tickets. A name built from a patient identifier, an encounter number or a clinician name is a disclosure in every one of those places.
04 Encryption at rest, and of what
Volume encryption protects a stolen disk. It does nothing against a process, a container escape or an operator with shell access. For a file holding raw clinical audio, that distinction is worth stating explicitly rather than assuming.
05 Deletion on every exit
Success, handled exception, unhandled exception, timeout, cancellation, rate limit, container termination. A cleanup that lives only in the success branch handles one of seven.
06 The sweeper that catches the rest
Because some of those exits cannot be handled in process, a scheduled sweep over the temporary location with a hard age limit is not redundancy. It is the control that covers the crash.
07 Retry semantics
Retries need the source. That is legitimate, and it means the retention decision is really about the retry budget: how many attempts, over what window, before the file is destroyed and the request fails cleanly.
08 Whether anyone would know
A metric for files older than the age limit, alerting above zero. Without it, the residue is discovered by whoever next runs out of disk.
None of this is exotic. All of it is the kind of work that gets deferred in an early-stage product because it does not appear in a demo, and all of it is considerably cheaper to build before a hospital's information security team asks where the audio goes.
06 The model processing boundary
Putting a language model in the path creates a processing boundary with properties no other component in the stack has: the thing on the far side is probabilistic, it is operated by someone else, its behaviour changes when they change it, its price changes when they change it, and the content you send it is the most sensitive material in the product.
The model is not a trusted output
In a clinical workflow the temptation is to treat a well-formed response as a correct one, and the temptation is strongest when the response arrives as a formatted, signed-ready note. The confidence of the presentation is a property of the template, not of the analysis. The application around the model has to carry the safety case.
The measured behaviour of speech-to-text in this setting is worth stating plainly, because it is more specific than the usual hand-waving about hallucination. In a peer-reviewed study of a widely used open speech recognition model, roughly one percent of audio transcriptions contained entire hallucinated phrases or sentences that did not exist in any form in the underlying audio, and thirty-eight percent of those hallucinations included explicit harms — perpetuating violence, fabricating associations, or implying false authority. The rate was higher for speakers with aphasia than for controls.27 That is a transcription-layer finding, before any note generation happens on top of it. A pipeline that summarizes a hallucinated sentence produces a confident, well-formatted, entirely invented clinical observation, and the nurse signing the note is the only remaining control.
That last point is not incidental. The American Medical Association's guidance on AI in the exam room puts accountability where the regulation and professional practice both put it: the clinician who signs the note carries responsibility for its content.29 An architecture that makes review difficult — by discarding the transcript before the note can be checked against it, or by presenting generated text in a form that discourages editing — is transferring risk onto that clinician rather than reducing it. Separately, the deployment evidence on ambient documentation is genuinely encouraging on clinician burden and genuinely thin on downstream effects: an independent 2025 assessment found ambient scribes potentially effective at reducing documentation time and cognitive load, while noting gaps in evidence on productivity and financial performance.28
What the assessment examines at this boundary
Content What actually leaves
Reconstruct the exact payload from the code, not from the design document. A prompt assembled by string interpolation over a patient record sends whatever that record contains, including the fields nobody remembered were in scope. The question is what the smallest sufficient payload is, and whether identifiers can be stripped before the call and reattached after it.
Config Retention and training settings
Read the provider's current documentation and the account's actual configuration, not the marketing page. Defaults change and vary by endpoint. Confirm what is retained, for how long, for what stated purpose, and whether the account is provisioned for the reduced-retention mode the provider requires for healthcare use.
Structure Output validation
Validate that the response is the shape the application expects, and define the behaviour when it is not: fail closed with a clear error, never render a partial or malformed note as if it were complete. Schema conformance is not correctness — a structurally perfect note can be clinically wrong — but a structural gate is the one deterministic control available here.
Trust Injection through content
The model's input is dictated speech from outside the organization. Treat instructions embedded in that content as reachable, and put the safety case on controls that hold regardless: the model has no tool access, no database credentials, no ability to reach another tenant's data, and no authority to take an action. Output filtering is a mitigation, not a boundary.
Ops Timeouts, retries, rate limits
Every one of these is a PHI-handling decision as well as a reliability decision, because each of them determines how long the source material stays resident. See the failure paths.
Exit Portability and outage
What happens to the product when the provider has an incident, deprecates the model, or changes its healthcare terms. An abstraction over the model call and a tested fallback is an availability control; it is also the thing that makes it possible to leave a provider whose retention terms become unacceptable.
Nothing published by OCR speaks to this specifically. As of 8 September 2026 I could find no HIPAA guidance from the HHS Office for Civil Rights addressed to artificial intelligence, large language models, or ambient clinical documentation.34 The adjacent technology guidance that does exist — on cloud computing and on online tracking technologies — is useful by analogy and is cited where it applies. This is an absence-of-evidence statement, not an assertion that OCR has taken a position. Design against the Security Rule as written and against the risk analysis it requires, not against guidance that has not been issued.
07 Vendors and the business-associate chain
Technical security alone does not settle this. Any third party that creates, receives, maintains or transmits protected health information on behalf of a covered entity or a business associate is itself a business associate, and the definition at 45 CFR 160.103 expressly reaches subcontractors.6 The contract requirements sit in two places — the Privacy Rule at 164.504(e)7 and the Security Rule at 164.314(a)8 — and both carry an express flow-down duty to subcontractors. The obligation flows down the whole chain, and the platform in the middle owns the flow-down.
Two things that are widely misunderstood
The conduit exception is narrow. HHS has been explicit that it excludes only entities providing mere courier services — the postal service, a package carrier, an internet service provider passing traffic — and that the distinguishing property is the transient rather than persistent nature of the opportunity to access the information. In the same preamble HHS states that a data storage company with access to protected health information qualifies as a business associate even if it does not view the information.9 Anything in the architecture that persists PHI — object storage, a queue with retention, a cache, a log store, a backup service, a vector index — is outside the exception.
Encryption does not remove business-associate status. OCR's cloud computing guidance states that lacking an encryption key for the encrypted data it receives and maintains does not exempt a cloud service provider from business associate status, and that a business associate agreement is required regardless.10 Customer-managed keys and no-view arrangements are defensible risk-reduction and responsibility-allocation strategies. They are not a route around a contract.
Vendor position as of 8 September 2026
The table below records what the named providers say about their own healthcare offerings. Every row is vendor-stated and every row is dated, because these terms change and a stale table is worse than no table. Re-verify before relying on any of it.
| Provider | Position as stated by the vendor | The part that catches people |
|---|---|---|
| Model and transcription API OpenAI |
A business associate agreement is offered, requested by email; an enterprise agreement is not required for the API platform, though a BAA for the assistant product is limited to specific sales-managed plans.18 A named list of HIPAA-eligible products and endpoints is published, and eligibility for the API is stated to be contingent on the account being provisioned with a modified-retention configuration.19 | The HIPAA-eligible endpoint list and the zero-retention-eligible endpoint list are not the same set. Assistant and thread endpoints appear as HIPAA-eligible while being excluded from zero data retention.20 An architecture assuming that a signed BAA implies no retention anywhere is wrong on the provider's own documentation. Separately, the healthcare addendum still uses the older “zero retention” wording while the help centre uses “modified retention”, and no page I found defines the relationship between them.21 |
| API defaults OpenAI |
API data is stated not to be used to train or improve models by default, and abuse-monitoring logs are stated to be generated for all API feature usage and retained for up to thirty days unless longer retention is required by law.20 | Thirty days of abuse-monitoring logs containing clinical audio and transcripts is a retention position, whether or not anyone decided it. Zero data retention requires prior approval and additional terms, and image and file inputs may still be retained for child-safety scanning regardless.20 |
| Managed Postgres Supabase |
A signed BAA and an enabled HIPAA add-on are stated to be required when handling PHI, after which projects are marked as high-compliance; the add-on is offered on the paid team and enterprise tiers.22 | The provider documents customer-side settings as mandatory, not optional: point-in-time recovery (which itself requires a compute add-on), SSL enforcement, network restrictions and Postgres connection logging, with further automated checks surfaced in a security advisor.22 The provider states its own position as shared responsibility, and that it holds agreements with its vendors that could access ePHI.23 Enabling the add-on is the start of the work. |
| Hyperscale cloud AWS, Google, Microsoft |
All three sign a BAA covering an enumerated subset of services. AWS states that customers agree not to use its HIPAA-eligible services with PHI without first entering a BAA; Google instructs customers to disable or otherwise not use products not explicitly covered; Microsoft states that using its services does not on its own achieve HIPAA compliance.242526 | This is the general shape of the trap. A provider advertising healthcare capability says nothing about whether a given plan, service, region or configuration is appropriate, and the customer carries the obligation to keep PHI inside the covered subset. Google adds the point worth quoting to any founder: there is no HHS-recognized certification for HIPAA compliance.25 |
| Speech services various |
Google names Speech-to-Text in its covered products and states that customers with a BAA should not opt into its data logging program.25 AWS lists Amazon Transcribe and HealthScribe as HIPAA-eligible.24 Deepgram states it is a business associate and will provide a BAA on request. | Eligibility is per-service and sometimes per-feature. I was not able to confirm Azure AI Speech's specific in-scope status from a current public page; Microsoft's BAA covers “in-scope” services and the authoritative list defers to an access-controlled document. Treat that as unverified rather than as either a yes or a no. |
The finding this table exists to produce. A vendor advertising HIPAA capability does not make every service, plan, endpoint, region or configuration appropriate for protected health information — and in at least one case above, two of the vendor's own eligibility lists disagree about the same endpoint. The assessment question is therefore never “does this provider support HIPAA?” It is: for the specific endpoints this application calls, on the specific plan this account is on, with the specific settings currently configured, what does the provider say it does with the content?
Vendor inventory: the question set
For every third party in the architecture — model and transcription providers, hosting, database, object storage, logging, monitoring, backup, email, analytics, crash reporting, customer support tooling, and anything a developer added to solve a problem in an afternoon — the assessment asks one question first: does this provider receive protected health information? If the answer is no, the next question is how that is enforced rather than intended. If the answer is yes, five follow: is the provider's healthcare offering appropriate for this use; is the necessary contract in place; are the required technical settings actually enabled; what is the provider's retention behaviour on this plan; and could the organization state all of the above accurately to a customer's privacy officer without going away to check.
08 Identity and authorization
Authentication answers who you are. Authorization answers what you are allowed to do. Both are enforced on the server, or neither is enforced at all — a mobile interface that hides a button has expressed a preference, not a control.
In a multi-tenant healthcare product the authorization question has a specific shape: a clinician at one healthcare organization must never be able to reach another organization's records, and the enforcement of that cannot depend on the client sending the right organization identifier. The client is a program running on a device the platform does not control, operated by a user who is authenticated but not trusted with arbitrary requests.
Authentication
- Credential storage and reset flow
- Session and token lifetime, revocation, rotation
- Token signing, algorithm pinning, key rotation
- Multi-factor support, and whether it is available to the customer's administrators
- Behaviour on a lost or stolen device
Authorization
- Server-side enforcement at every endpoint, without exception
- Record ownership validated before the database operation, not after
- Organization and tenant context derived from the session, never from the request body
- Role definitions that reflect the clinical roles the customer actually has
- Least privilege for service accounts and background jobs
Privileged access
- Who at the vendor can read a customer's clinical content, and under what process
- Whether support tooling exposes note content or only metadata
- Break-glass access: approval, scope, time bound, and a record the customer can see
- Database administrative access as a separate question from application administrative access
- Termination: what happens to access on the day someone leaves
What a usable finding looks like. A healthcare security assessment that says “implement access controls” has produced a sentence, not a task. The same observation, written so a developer can act on it:
Finding. API authorization relies primarily on client-side controls. Endpoint handlers accept an organization identifier from the request body and use it to scope the query.
Risk. An authenticated user of any tenant can modify the request and attempt to read or write another tenant's records. The blast radius is the whole corpus rather than one account, and the access would be indistinguishable from legitimate traffic in the current logs.
Recommendation. Derive organization and tenant context from the authenticated session on the server. Enforce authorization at every endpoint against that derived context. Validate record ownership before the database operation. Add database-level tenant isolation as an independent second control, so that an application-layer mistake does not become a cross-tenant disclosure. Add a negative test to the suite for each endpoint: a valid session from tenant A requesting a known record of tenant B must return a not-found response, and the test must fail the build.
09 Database and tenant isolation
If transcripts or generated notes are retained, the database becomes the highest-value asset in the system, and tenant isolation stops being a defensive measure and becomes load-bearing.
Row-level policies are the right mechanism and they have a specific failure mode worth naming: managed Postgres platforms typically issue a privileged service key intended for server-side use that bypasses those policies entirely. That key is what makes the application work, which means the isolation guarantee holds only for code paths that do not use it. An architecture that enforces tenancy in row-level policies while running every query as the privileged role has bought a control it is not using.
| Area | What to examine | The question that finds the defect |
|---|---|---|
| Tenant isolation | Row-level policies, the roles queries actually execute as, and whether any path uses a policy-bypassing key | Write a test that attempts a cross-tenant read with a valid session. Does it fail closed, and does the test run in CI? |
| Encryption at rest | Storage-level encryption, key custody, and whether any column-level protection exists for clinical content | Who holds the key, and what class of attacker does this actually stop? |
| Connections | TLS enforcement on every path, including migrations, admin tools and analytics readers | Is enforcement configured at the server, or merely requested by the client? |
| Credentials | Distinct credentials per environment and per service, rotation procedure, and where they are stored | Could production be reached with a credential a former contractor still has? |
| Database logs | Statement logging, slow-query logs, and whether parameter values are captured | Is clinical content being written into a log because a query was slow? |
| Non-production | Whether production data is copied into development or staging, and under what redaction | Has anyone restored a production backup to debug something, and is that copy still there? |
| Exports | Ad-hoc exports for support, analytics or migration, and where those files went | Is there a spreadsheet of clinical notes in someone's downloads folder? |
| Deletion | Whether deletion is a flag, a row removal, or a lifecycle operation that reaches every copy | See deletion reach — this is almost never as complete as it looks. |
10 Logging without building a second PHI store
Logging is required for security monitoring and it is the most common accidental PHI store in this class of application. Both statements are true at once, and the design resolves them by separating the security event from the clinical content.
The Security Rule's audit controls standard at 45 CFR 164.312(b) requires mechanisms that record and examine activity in information systems that contain or use electronic protected health information.1 Two things follow that are worth stating precisely. First, the standard has no implementation specifications, so the required-versus-addressable distinction does not apply to it — the standard itself must be implemented. Second, the regulation prescribes nothing about what to log, how long to keep it, or how often to review it. Those are decisions the risk analysis at 164.308(a)(1)(ii)(A) is supposed to drive.2 Note the word examine: logs that are collected and never reviewed do not satisfy the standard.
Log this
- User identifier and organization, from the session
- Timestamp, request identifier, correlation identifier
- Authentication events, including failures and lockouts
- Administrative and privileged actions, with the actor
- Record access events: who touched which record identifier, and what operation
- Outcome, error class, and duration
- Source address and device or client identifier
- Configuration and permission changes
Never log this
- Request bodies containing audio, transcripts or notes
- Response bodies from the model or the transcription service
- Prompt text, including the system instructions if they embed patient context
- Patient names, identifiers or dates carried as free text
- Full SQL statements with bound parameter values
- Stack traces that serialize a request object
- Temporary filenames built from clinical identifiers
- Anything a debug flag enables that nobody remembers turning on
The practical test is not a policy. It is a search: take a known patient identifier, a distinctive phrase from a test note, and the string that a transcript would contain, and grep the log store for all three. Do the same in the crash reporter, the analytics platform and the support tool. The result of that search is a finding either way — and unlike most controls, it produces evidence a customer's assessor can be shown.
One consequence worth designing for deliberately: a record-access event is itself useful clinical audit material, and it does not need the note's content to be useful. “User 4471 at organization 12 opened note 88213 at 09:14 from a managed device” answers every question an investigation needs to ask without putting a single clinical word into a system that was never scoped to hold one.
11 Encryption and key management
The counterintuitive fact, and it matters. Under the Security Rule as currently in force, encryption is addressable, not required — both at rest, at 45 CFR 164.312(a)(2)(iv), and in transmission, at 164.312(e)(2)(ii).1 Addressable does not mean optional: it means the entity must assess whether the specification is a reasonable and appropriate safeguard, implement it if it is, and document why not and what equivalent measure was used if it is not. For clinical audio traversing the public internet to a third-party model provider, the assessment that concludes encryption is not reasonable and appropriate is one I cannot construct. Do it, and document the decision rather than treating it as a box that was already ticked.
The January 2025 notice of proposed rulemaking would change this — it proposes removing the addressable and required distinction and making encryption of ePHI mandatory at rest and in transit with limited exceptions, along with multi-factor authentication, a technology asset inventory and a network map.3 Those are proposals. As of 8 September 2026 the rule has not been finalized and has not been withdrawn; the Unified Agenda carries it under long-term actions with a projected final action in July 2027.4 Do not design to it as law, and do not let anyone tell you the final rule already exists. Design to it as a strong signal of direction, because building the proposed controls now is cheaper than retrofitting them later.
Where it applies
In transit
- Mobile application to backend
- Backend to database, enforced server-side
- Backend to transcription and model providers
- Between internal services, including inside a private network
- Administrative interfaces and management planes
- Backup transfer and any export path
At rest
- Database storage and its backups
- Object storage holding audio or generated documents
- Temporary files, for as long as they exist
- Log stores, if anything clinical could ever reach them
- Device storage, on both mobile platforms
- Any development copy of production data that exists at all
Encryption alone is not the control, though. Key management is what determines whether the encryption is doing anything: who holds the key, where it lives, who can retrieve it, whether it can be rotated without an outage, whether the same key protects production and development, and whether the key is stored next to the data it protects. A key held by the same account that holds the ciphertext, retrievable by the same credential, is an inventory item rather than a boundary.
The breach-notification consequence
Encryption has a second effect that is worth understanding precisely, because it is frequently overstated. Breach notification obligations attach to unsecured protected health information — PHI that has not been rendered unusable, unreadable or indecipherable through a technology or methodology specified by the Secretary.13 The specifying guidance recognizes two methodologies, encryption and destruction, and requires that the key enabling decryption has not itself been breached; for encryption it points to the relevant NIST publications, validated to FIPS 140-2 as the guidance is written.14 So PHI encrypted consistently with that guidance, with the key intact, is outside the notification requirement.
That is a safe harbour conditioned on meeting a specified methodology and on key integrity. It is not “we encrypt, therefore we do not have to notify”, and it does nothing for a compromise that occurs on the plaintext side of the boundary — which, for an application that necessarily decrypts clinical content in order to display it, is most of the realistic scenarios. Note also that the guidance still references FIPS 140-2, which NIST has since superseded with FIPS 140-3; quote the guidance as written and handle the difference in the risk analysis rather than silently modernizing the citation.
12 Secrets
A mobile application is a distributed binary. Anything embedded in it is published, and shipping a model provider's API key inside a React Native bundle publishes a credential that can be extracted, replayed and billed — and, in a healthcare product, one that reaches an endpoint that has been receiving clinical audio.
Never in the client
Model and transcription API keys, database credentials, privileged service keys, signing secrets. The mobile application should hold exactly one credential class: a short-lived token that identifies the user to your own backend.
Never in the repository
Including in history. A credential removed from the working tree but present in a previous commit is still disclosed, and it is disclosed to everyone who has ever cloned the repository — contractors, ex-employees, and whoever receives the code in a future transaction.
Separated by environment
Distinct credentials for development, staging and production, scoped as narrowly as the provider allows. A shared key means a developer's laptop and the production service are the same principal from the provider's point of view.
Rotatable, and rotated
A rotation procedure that has never been executed is a document. The specific credentials that matter here: the model provider key, database credentials, the privileged service key, token signing secrets, administrative accounts and the deployment pipeline's own credentials.
Two checks find most of this quickly: scan the repository history rather than the working tree, and pull the shipped mobile bundle apart and search it for high-entropy strings and provider key prefixes. Both are cheap. Both regularly produce a finding that belongs in the pre-production category.
13 The mobile endpoint
The device is the one component in the architecture that leaves the building. It is carried between wards, shared between shifts, left on trolleys, and occasionally lost. Everything the application caches there is protected health information sitting on hardware the platform does not administer.
iOS Keychain and data protection classes
Apple documents accessibility classes that govern when a keychain item can be read, and the choice is a real security decision rather than a default to accept. The device-only variants are protected with the device unique identifier when copied during a backup, rendering them useless if restored to a different device; items in the passcode-set device-only class do not sync to iCloud Keychain, are not backed up, and are not included in escrow keybags.31 For a session token on a shared clinical device, that is the class to argue about explicitly.
Android A deprecation most reviews have not caught up with
All APIs in the security-crypto Jetpack library — which is where EncryptedSharedPreferences and EncryptedFile live — were deprecated in the stable 1.1.0 release, and Google states there will be no subsequent releases of the library.30 Recommending it for PHI at rest in 2026 cites an unmaintained component. The stated direction is platform APIs and direct use of the Android Keystore; note honestly that the deprecation notice does not name a drop-in replacement, which is a real gap rather than a reviewer's oversight.
Policy Platform rules, not just regulation
Apple's review guidelines state that apps may not store personal health information in iCloud, and that medical apps may be reviewed with greater scrutiny, must substantiate accuracy claims, and should remind users to check with a doctor.32 Google Play requires a health apps declaration, an in-app and console privacy policy, comprehensive disclosure of data handling, and — for apps not regulated as medical devices — an explicit disclaimer to that effect.33 These are conditions of distribution, and a failure here stops the product reaching users regardless of the HIPAA position.
Scope The medical-device line
Worth checking early rather than late, and worth noting that a model provider's own healthcare terms may address it: the healthcare addendum for one of the providers named above states the services are not intended to be used in a manner that constitutes a medical device.21 A documentation-assistance product that stays on the documentation side of that line has a materially simpler regulatory path than one that drifts across it, and the drift is usually a feature request rather than a decision.
Device-side questions
- What does the application write to disk, and does any of it contain clinical content or identifiers?
- Is audio ever queued locally for later upload, and what protects it while it waits?
- What is cleared on sign-out, on session expiry, and on app deletion — and is that tested?
- Does anything clinical reach the platform backup or a cloud sync, deliberately or by default?
- What does the app screenshot look like in the task switcher, and does it show a note?
- Is there a remote sign-out path when a device is lost, and does it invalidate tokens server-side rather than only clearing local state?
- What does the crash reporter transmit, and has anyone read a real crash payload?
- Does the application behave correctly on a shared device where two clinicians use it in one shift?
14 Retention and deletion reach
The most consequential architectural decision in this system is how long it keeps clinical content, and the most common architectural mistake is believing that deleting a row deletes the information.
Choose the retention model deliberately
Persistent repository
The product becomes an ongoing store of clinical notes. Highest utility, highest obligation: the full encryption, access, retention, deletion, breach and disclosure perimeter applies permanently, and the product is now part of the customer's records estate.
Limited retention
Content exists for a defined and short period — until synchronization with a records system, or for a stated number of days — then goes. Most of the utility, a fraction of the standing exposure, and a retention policy that can actually be stated to a customer in one sentence.
Transient processing
Content lives only long enough to produce the requested output. Lowest exposure and lowest utility; the right default for an early-stage documentation-assistance product unless a business requirement says otherwise, and the requirement is written down.
The balance to strike involves clinical workflow, user experience, the customer's own record-keeping obligations, integration requirements, security risk and operational complexity. None of those is a security question on its own, which is exactly why the decision belongs to the architecture rather than to a framework default.
Logical deletion is not lifecycle deletion
The honest position for most early-stage products is that complete lifecycle deletion within minutes is not achievable, because backups exist for good reasons and their retention windows are what makes recovery possible. That is not a failure; it is a trade-off. What is a failure is a privacy notice or a customer commitment that promises immediate and complete deletion while the backup schedule keeps a copy for thirty days. State the real behaviour: the record is removed from live systems immediately, and expires from backup media within the stated backup retention period, after which no copy remains.
This is also the strongest single argument for the transient model. The cleanest deletion architecture is the one where there was never anything to delete.
15 Security Rule crosswalk
This maps the architecture to the HIPAA Security Rule as currently in force at 45 CFR Part 164, Subpart C. The column names are deliberate. Architecture supplies a mechanism. An organization runs an operational process. Evidence demonstrates that the process ran. Those are three different things, and collapsing them is how a design document starts sounding like a compliance claim.
This is an architectural crosswalk, not a statement of conformity. No claim of compliance with any regime is made anywhere on this page. Whether an entity satisfies a standard depends on its own risk analysis, its implementation, its documentation and an accountable person's acceptance of residual risk — none of which a reference architecture can supply. Where a specification is marked addressable, the rule requires the entity to assess whether it is reasonable and appropriate, implement it if so, and document the alternative if not.
| Standard | Architecture mechanism | Operational process | Example evidence |
|---|---|---|---|
| 164.308(a)(1)(ii)(A) Risk analysis required | The PHI location map and boundary ledger in sections 02 and 03 are the technical input; they are not the analysis. | An accurate and thorough assessment of potential risks and vulnerabilities to the confidentiality, integrity and availability of ePHI held by the entity. | The completed analysis, dated, with scope, method, the systems considered and the risks identified. |
| 164.308(a)(1)(ii)(B) Risk management required | The prioritized gap register in section 16, with severity and effort per finding. | Implementing measures sufficient to reduce risks to a reasonable and appropriate level. | Remediation decisions with owners and dates, and written acceptance for what was not remediated. |
| 164.308(a)(1)(ii)(D) Information system activity review required | The metadata-only audit event stream in section 10. | Regular review of records of information system activity: audit logs, access reports, incident tracking. | Dated review records showing what was examined and what was escalated. |
| 164.308(a)(3) Workforce security | Role definitions and least-privilege service accounts; no standing production access to clinical content. | Authorization, supervision and termination procedures for anyone who could reach ePHI. | Access request and approval records; evidence that access was removed on the day someone left. |
| 164.308(a)(4) Information access management | Server-side authorization, tenant context from the session, database-level isolation as a second control. | Access authorization and modification procedures, and periodic review of who holds what. | A completed access review with a named reviewer, and the exceptions it recorded. |
| 164.308(a)(5) Security awareness and training | Nothing. This one is entirely operational, and saying so is more useful than pretending otherwise. | Security reminders, malicious software protection, log-in monitoring and password management for the workforce. | Training completion records, and the content that was delivered. |
| 164.308(a)(6) Security incident procedures | The audit event stream, alerting on anomalous access, and a documented path to identify affected records. | Identifying, responding to, mitigating and documenting security incidents and their outcomes. | An incident record showing detection time, actions taken and the harm assessment. |
| 164.308(a)(7) Contingency plan | Backup coverage, replication, and a restore path that has been executed rather than described. | Data backup, disaster recovery and emergency mode operation plans, with testing and revision. | A restore test record with a date, a duration and a named person — not a green backup dashboard. |
| 164.308(a)(8) Evaluation | The assessment method on this page, re-run when the architecture changes. | Periodic technical and non-technical evaluation in response to environmental or operational change. | The dated evaluation, and the change that triggered it. |
| 164.308(b) Business associate contracts | The vendor inventory and boundary ledger identify who is in scope; the architecture decides who needs to be. | Obtaining satisfactory assurances from every business associate, and from subcontractors down the chain. | Executed agreements, and a current subprocessor list that matches what the code actually calls. |
| 164.310(a) Facility access controls | Inherited from the hosting and database providers. The architecture's job is to keep ePHI inside services those providers cover. | Vendor due diligence and periodic review of the provider's own attestations. | The provider's current audit report, and a record that someone read it. |
| 164.310(d) Device and media controls | Mobile storage minimization, remote sign-out, and no clinical content in platform backups. | Disposal and media re-use procedures, and accountability for hardware movement. | Device inventory, and the procedure that runs when a device is lost. |
| 164.312(a)(1) Access control | Unique identity per user, session-derived tenant context, automatic session expiry, emergency access defined rather than improvised. | Granting, reviewing and revoking access; testing that the controls behave as designed. | A failing cross-tenant access test in CI is the best evidence available here. |
| 164.312(a)(2)(iv) Encryption and decryption addressable | Encryption at rest across database, object storage, temporary files, backups and device storage; keys held outside the data's own account. | Assessing whether the specification is reasonable and appropriate, implementing it, and documenting the decision either way. | The documented assessment, the key management procedure, and evidence of a completed rotation. |
| 164.312(b) Audit controls | Metadata-only event stream: actor, tenant, record identifier, operation, outcome, time, source. No clinical content. | Recording and examining activity. The examination is part of the standard, not an optional extra. | The review record, plus a negative test showing that clinical content does not appear in the log store. |
| 164.312(c) Integrity | Structural validation of model output, immutable audit records, and versioning where a note can be amended. | Procedures to protect ePHI from improper alteration or destruction, and to detect it if it happens. | Validation failure records, and the amendment history for a note. |
| 164.312(d) Person or entity authentication | Verified identity for users, workload identity for services, no shared accounts anywhere in the path. | Verifying that a person or entity seeking access is the one claimed, including for administrative paths. | Authentication configuration, and the absence of shared credentials in the secret store. |
| 164.312(e) Transmission security | Encrypted transport on every hop including internal ones; integrity controls on the model and transcription calls. | Guarding against unauthorized access to ePHI transmitted over a network. | Enforced transport configuration at the server, not merely requested by the client. |
| 164.314(a) Business associate contracts | The architecture determines which vendors receive ePHI, which is what determines the contract set. | Contracts requiring Security Rule compliance, subcontractor flow-down, and reporting of security incidents. | The executed contracts, and evidence that the flow-down obligation was passed on. |
| 164.316 Policies, procedures and documentation | Architecture decision records, the data-flow map and the retention design are the durable technical documentation. | Maintaining policies and procedures in writing, retaining them for the period the rule specifies, and reviewing and updating them as the environment changes. | Versioned documents with review dates, and a change history that shows they were actually maintained. |
Two observations about this table are worth more than the table itself. The first is that the physical safeguards row is honest: in this architecture they are almost entirely inherited from providers, and the entity's real obligation is to keep ePHI inside services those providers actually cover — which is an architecture decision, not a facility decision. The second is that four of the highest-value rows have no architectural mechanism at all. Training, evaluation, incident procedures and contract management are operational, and a technically excellent platform with none of them in place has a real and unremediated compliance problem.
16 Findings and severity
Findings are only useful if they are ordered by consequence and written so an engineer can start work. Two things make that possible: a severity model tied to PHI risk rather than to CVSS, and a register schema that forces every finding to carry its evidence and its effort.
Critical
Should stop production processing of real patient information until resolved. Protected health information reaching an unapproved third party; exposed production credentials; broken tenant isolation; PHI reachable without authentication; an authentication bypass.
High
Significant weakness requiring remediation before production deployment or before a healthcare customer's approval. Missing failure-path deletion for clinical audio; clinical content in logs; no restore has ever been tested; a required vendor agreement absent for a service that receives PHI.
Medium
Materially improves the security position and belongs in the roadmap. Weak session lifetime, missing rate limiting on an expensive endpoint, no alerting on temporary-file residue, retention configured but not documented.
Low
Hardening, documentation, operational maturity and defence in depth. Header hygiene, dependency currency, a runbook that exists but is out of date, an architecture diagram that no longer matches the code.
The register schema
| Field | What it holds, and why it is there |
|---|---|
| Identifier | A stable reference, so the finding can be tracked through remediation and re-tested by name. |
| Area | Architecture, security, AI layer, operations, dependency, vendor or cost. Groups work by the team that will do it. |
| Finding | What is true, stated plainly, without the recommendation mixed in. |
| Evidence | Code and line, configuration value, command output, test result or document. No evidence, no register entry — unevidenced observations become open questions instead. |
| PHI exposure | Which of the twelve locations is implicated, and in what form. This is the field that distinguishes a healthcare register from a generic one. |
| Likelihood and impact | Rated separately, so the reader can disagree with one without discarding the other. |
| Severity | Critical, high, medium or low, per the model above. |
| Recommendation | Specific enough to become an engineering ticket without translation. See the worked example in section 08. |
| Estimated effort | Engineering time. A recommendation without one cannot be sequenced against a release plan. |
| Priority | Before real PHI, first thirty days, thirty-one to ninety days, or backlog. |
| Owner | A role, so the finding has somewhere to go when the report is handed over. |
| Safeguard reference | The Security Rule standard the finding bears on, where one applies — and explicitly blank where none does, so that good practice is never presented as an obligation. |
The last field is the one that keeps the report credible. Not every weakness maps to a regulatory requirement, and inflating a finding count by dressing good practice as a breach is the fastest way to lose the confidence of the people who will check.
17 Target architecture
Assembled, the design is nine layers, and the ordering is the argument. Identity comes before transport, transport before processing, processing before storage, and storage is conditional on someone having decided it is needed.
The weaker question: how do we secure the PHI we store?
The stronger one: why are we storing this PHI at all? Reducing the amount, the duration and the number of places protected health information exists removes whole categories of risk rather than adding controls to them — and in an AI documentation pipeline, where the same utterance is otherwise duplicated across a device, a server, a temporary file, a database, two providers, a log store and a backup, that reduction is available in a way it rarely is elsewhere.
18 Production readiness
The assessment terminates in a decision, not a list. Two categories separate what stops production from what stops a hospital saying yes, because those are different conversations with different people on different timelines.
Must fix before real PHI
- PHI reaching any third party without an appropriate agreement and configuration in place
- Production credentials exposed in a client bundle or in repository history
- Tenant isolation that fails a cross-tenant access test
- Any clinical content reachable without authentication
- Clinical audio or transcripts persisting on server disk with no deletion path
- Clinical content written to a log, crash reporter or analytics platform
- No usable backup, or a backup that has never been restored
- A subprocessor the organization cannot name when asked
Recommended before healthcare organization approval
- Multi-factor authentication available to customer administrators
- A written and implemented retention position, honest about backup reach
- Documented incident response with a named contact path
- Access review procedure with evidence that one has been run
- Centralized security logging with alerting and a review cadence
- Infrastructure as code and environment separation
- A model abstraction with a tested fallback
- Architecture and data-flow documentation a customer's assessor can read
- A completed risk analysis, because it is the thing enforcement asks for first
That last item is not a formality. The Office for Civil Rights runs a named risk analysis enforcement initiative and numbers its actions under it publicly — settlements announced in March 2025, August 2025 and March 2026 were each identified in the announcement as the fifth, tenth and twelfth actions in that initiative respectively.151617 The failure being penalized is not a breach of a technical control. It is the absence of an accurate and thorough risk analysis. For a small company that means the cheapest defensible thing it can do is also the thing it is most likely to have skipped.
The four outcomes
Proceed
No material obstacle to processing real patient information on the current architecture. Rare for a first assessment, and worth saying plainly when it is true.
Proceed with remediation
Risks are real and manageable through a defined plan with owners and dates. The common outcome for a competently built early-stage product.
Proceed with conditions
Specific items must be resolved, funded or contractually addressed before real PHI is processed or before a named customer goes live.
Pause
One or more risks could materially affect confidentiality, continuity or the viability of the healthcare proposition. Stopping is cheaper here than anywhere later.
19 What this is not
Every reference of this kind should say where it stops. This one stops in several places, and knowing which ones is the difference between using it well and misusing it.
Not legal or regulatory advice
This is a technical control and architecture reference. Compliance determinations, contract interpretation, medical-device classification and privacy notices are questions for counsel and for the entity's own compliance function.
Not a client engagement
No client, no assessment, no findings and no product are described. The technology composition is representative of how products in this category are built, and nothing more.
Not a compliance claim
The crosswalk in section 15 maps architecture to standards. It does not assert that any entity satisfies any standard, and no such claim appears anywhere on this page.
Not durable
Every regulatory and vendor statement here was verified on 8 September 2026 and carries that date. Vendor healthcare terms in particular change without notice, and one of the vendors cited already contradicts itself across two of its own current pages.
What is most likely to change first
- The Security Rule itself. The January 2025 proposal remains proposed. If it is finalized, the addressable and required distinction that section 11 turns on may cease to exist, and several rows of the crosswalk would need rewriting rather than editing.34
- Model provider healthcare terms. Eligible endpoint lists, retention modes and their names are moving quickly enough that a six-month-old architecture decision may already rest on a superseded page.
- Mobile platform guidance. The Android storage deprecation in section 13 landed in 2025 and has not yet propagated into most security checklists; the replacement guidance is still incomplete.30
- Guidance specific to AI in healthcare. There is none from OCR today.34 That is unlikely to remain true, and the sensible posture is to design against the Security Rule as written and the risk analysis it requires.
Stated qualifications
- The claim that no OCR guidance exists on AI, large language models or ambient clinical documentation is an absence-of-evidence finding from a search of the OCR guidance index and HHS material on 8 September 2026. It is not an affirmative statement by OCR.34
- Azure AI Speech's specific HIPAA in-scope status could not be confirmed from a current public page; Microsoft's business associate agreement covers “in-scope” services and the authoritative list defers to an access-controlled document. That is recorded as unverified rather than as a yes or a no.26
- The breach-notification guidance references FIPS 140-2, which NIST has since superseded with FIPS 140-3. The guidance is quoted as written.14
- NIST Special Publication 800-66 Revision 2 remains the current implementation resource for the Security Rule; no later revision existed as of the verification date.5
- Vendor rows in section 07 are labelled vendor-stated throughout and are never presented as independent verification.
20 Sources
Regulatory text is cited to the Electronic Code of Federal Regulations rather than to a secondary summary. Vendor positions are cited to the vendor's own current documentation and labelled as vendor-stated. Everything below was verified on 8 September 2026.
- 45 CFR 164.312 — Technical safeguards. Electronic Code of Federal Regulations. ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312
- 45 CFR 164.308 — Administrative safeguards, including the required risk analysis implementation specification at (a)(1)(ii)(A). ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.308
- HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information. Notice of proposed rulemaking, 90 FR 898, published 6 January 2025; comment period closed 7 March 2025. federalregister.gov — document 2024-30983
- Unified Agenda entry for RIN 0945-AA22, carrying the rulemaking under long-term actions with a projected final action date of July 2027. Status confirmed 8 September 2026: not finalized, not withdrawn. reginfo.gov
- NIST Special Publication 800-66 Revision 2, Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule: A Cybersecurity Resource Guide, published 14 February 2024. csrc.nist.gov/pubs/sp/800/66/r2/final
- 45 CFR 160.103 — definitions, including business associate and the express inclusion of subcontractors at paragraph (3). ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-160/subpart-A/section-160.103
- 45 CFR 164.504(e) — business associate contract requirements, including the subcontractor flow-down at (e)(2)(ii)(D). ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.504
- 45 CFR 164.314(a) — organizational requirements for business associate contracts, including flow-down at (a)(2)(iii). ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.314
- Modifications to the HIPAA Privacy, Security, Enforcement and Breach Notification Rules (the Omnibus Rule), 78 FR 5566, 25 January 2013 — the preamble discussion narrowing the conduit exception and confirming that a storage provider with access to PHI is a business associate even without viewing it. federalregister.gov
- HHS Office for Civil Rights, Guidance on HIPAA & Cloud Computing — including that lacking an encryption key does not exempt a provider from business associate status. hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing
- 45 CFR 164.502 — uses and disclosures, including the minimum necessary standard at (b) and its exceptions at (b)(2). ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.502
- 45 CFR 164.514 — de-identification at (a) and (b), and the minimum necessary implementation specifications at (d). ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.514
- 45 CFR Part 164, Subpart D — Notification in the Case of Breach of Unsecured Protected Health Information, including the definition of breach and of unsecured PHI at 164.402. ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-D
- HHS, Guidance to Render Unsecured Protected Health Information Unusable, Unreadable, or Indecipherable to Unauthorized Individuals — the encryption and destruction methodologies, referencing FIPS 140-2 as written. hhs.gov/hipaa/for-professionals/breach-notification/guidance
- HHS press release, 21 March 2025 — settlement with Health Fitness Corporation, identified as the fifth enforcement action in OCR's Risk Analysis Initiative. hhs.gov/press-room
- HHS press release, 18 August 2025 — settlement with BST & Co. CPAs, identified as the tenth enforcement action in the Risk Analysis Initiative. hhs.gov/press-room
- HHS press release, 5 March 2026 — agreement with MMG Fusion, identified as the twelfth enforcement action in the Risk Analysis Initiative. hhs.gov/press-room
- OpenAI help centre — how to obtain a business associate agreement, and which products it can cover. Vendor-stated. help.openai.com
- OpenAI help centre — HIPAA-eligible products and functionality, including the enumerated endpoint list and the modified-retention condition. Vendor-stated. help.openai.com
- OpenAI developer documentation — data controls: default training position, abuse-monitoring log retention, and the endpoint-specific scope of zero data retention. Vendor-stated. developers.openai.com/api/docs/guides/your-data
- OpenAI Healthcare Addendum — eligible services definition and the medical-device exclusion. Vendor-stated; note the terminology divergence from the help centre. cdn.openai.com/osa/healthcare-addendum.pdf
- Supabase documentation — HIPAA projects: the BAA and add-on requirement, high-compliance marking, and the mandatory project settings. Vendor-stated. supabase.com/docs/guides/platform/hipaa-projects
- Supabase documentation — HIPAA compliance and the shared responsibility position, including agreements with its own vendors that could access ePHI. Vendor-stated. supabase.com/docs/guides/security/hipaa-compliance
- Amazon Web Services — HIPAA eligible services reference. Vendor-stated. aws.amazon.com/compliance/hipaa-eligible-services-reference
- Google Cloud — HIPAA compliance and the covered products list, including the instruction not to use products outside it with PHI and the statement that no HHS-recognized certification exists. Vendor-stated. cloud.google.com/security/compliance/hipaa
- Microsoft — HIPAA and HITECH offering, including the statement that using its services does not on its own achieve compliance. Vendor-stated. learn.microsoft.com/compliance/regulatory/offering-hipaa-hitech
- A. Koenecke, A. S. G. Choi, K. Mei, H. Schellmann and M. Sloane, Careless Whisper: Speech-to-Text Hallucination Harms, ACM Conference on Fairness, Accountability and Transparency (FAccT), 2024. Peer-reviewed. doi.org/10.1145/3630106.3658996
- Peterson Health Technology Institute, assessment of ambient AI scribes, 25 March 2025 — effective at reducing documentation time and cognitive load, with gaps in evidence on productivity and financial performance. phti.org
- American Medical Association — guidance on using health AI in the exam room, 9 October 2025, including the position that responsibility rests with the clinician who signs the note. ama-assn.org
- Android developer documentation — cryptography, and the androidx.security release notes recording the deprecation of all APIs in the security-crypto library at version 1.1.0. Vendor-stated. developer.android.com/privacy-and-security/cryptography
- Apple Platform Security — keychain data protection and the accessibility classes, including the device-only and passcode-set behaviours. Vendor-stated. support.apple.com/guide/security
- Apple App Store Review Guidelines — guideline 5.1.3 on health and health research data, and guideline 1.4.1 on medical apps. Vendor-stated. developer.apple.com/app-store/review/guidelines
- Google Play — Health Content and Services policy, including the health apps declaration and the medical-device disclaimer requirement. Vendor-stated. support.google.com/googleplay/android-developer
- HHS Office for Civil Rights — HIPAA guidance materials index, searched 8 September 2026 for guidance addressing artificial intelligence, large language models or ambient clinical documentation; none located. hhs.gov/hipaa/for-professionals/privacy/guidance