The Compliance Architecture Pattern: How to Wrap a Video Stack in HIPAA

This is engineering guidance, not legal advice. Confirm specifics with qualified counsel.

Why this matters

Block 2 of this section has covered the rules one at a time — what HIPAA requires, the BAA chain, encryption, audit logging. This article is where they assemble into one buildable shape. It is written for the founder or product lead who must answer a hospital security questionnaire, the hospital IT lead evaluating a vendor's architecture diagram, and the engineer who has a working video prototype and a launch date in a regulated market. The pattern here is the difference between retrofitting compliance under deadline — the most expensive way to get it — and building a stack where the compliance properties are structural. When an auditor, a payer, or an enterprise buyer asks "show me your architecture," this is the picture they expect to see.

What an auditor means by "architecture"

Start with the question the pattern answers. When the Office for Civil Rights (OCR) — the enforcement arm of the US Department of Health and Human Services (HHS) — investigates a telehealth product, or when a hospital's security team reviews one before buying, neither starts with your code. They ask structural questions. Where does patient data live? Who can reach it? Which vendors touch it, and under what contract? How would you know if someone accessed it who should not have? Each question maps to a requirement in the HIPAA Security Rule, the federal regulation at 45 CFR Part 164, Subpart C that governs electronic protected health information.

Two definitions before the pattern, because everything else hangs on them. Protected Health Information (PHI) is any health information that can be tied to an identifiable person — a diagnosis with a name, but also a video recording of a consult, a chat transcript, an appointment time attached to a patient account. In electronic form it is called ePHI. The less obvious part trips up engineering teams: metadata is PHI too. An IP address linked to a patient login, a room named oncology-follow-up-petrov, a log line saying patient 4711 saw Dr. Lee on Tuesday — each ties a person to the receipt of healthcare, and that is enough (45 CFR §160.103 defines the terms; the 18 identifiers are listed in §164.514(b)).

The second definition: a Business Associate Agreement (BAA) is the signed contract HIPAA requires before any outside vendor may create, receive, maintain, or transmit PHI on your behalf — the contractor's signed promise before they get a key to the building (45 CFR §164.502(e), §164.504(e)). Whether each vendor in your stack has one is a yes-or-no fact, and it decides most of your architecture for you.

With those two ideas, the pattern can be stated in one sentence: decide exactly where PHI is allowed to exist, draw a boundary around those places, and enforce six rules on everything inside. The rest of this article is the six rules, a worked example, and the build order.

Figure 1. The pattern on one page: the PHI boundary encloses only BAA-covered or self-hosted components, every hop is encrypted, the network is segmented into planes, audit logging watches everything, and outside systems receive de-identified data only. This is the diagram to hand an auditor — download it as a PDF.

Rule 1 — Draw the PHI boundary before you draw anything else

The PHI boundary (often called the compliance boundary) is the set of systems allowed to hold or see identifiable patient data. It is a design artifact, not a legal term: you will not find "boundary" in the rule text. What you will find is a list of obligations — encryption, access control, audit, contracts — that attach to every system handling ePHI. The boundary is simply the engineering move that keeps the obligated set small enough to defend.

Draw it by following the data, not the org chart. List every data element your product creates — video, audio, recordings, transcripts, chat, files, vitals, appointment records, login events — and trace where each one flows, including the flows nobody designed on purpose: crash reports, debug logs, analytics events, email receipts. Every system a PHI element reaches is inside the boundary, whether you meant it to be or not. The audit-logging article calls the resulting picture a data-flow map; the proposed 2026 Security Rule update would make maintaining exactly this artifact — a technology asset inventory and a network map showing how ePHI moves — a mandatory, annually refreshed requirement (90 FR 898, January 6, 2025; still a proposed rule as of June 11, 2026).

Two disciplines keep the boundary small. First, starve the edge. Systems that only route or schedule do not need names and diagnoses: a signaling server can run entirely on opaque identifiers — random tokens like room_c7f8 and user_1b9d that mean nothing without a lookup table held elsewhere. The mapping from token to person lives in one place inside the boundary, and a breach of the routing layer then leaks strings, not patients. (The tokens remain PHI in your hands while the lookup table exists, so the components stay inside the boundary — but the blast radius, the damage one compromised component can do, drops sharply.) Second, blind the rest. Any system that can do its job without PHI should never receive it: analytics gets de-identified events, the push-notification service gets "You have a new message" with no diagnosis attached, the error tracker gets scrubbed stack traces. Blinded systems sit outside the boundary, need no BAA, and cost you nothing in an audit. The de-identification standard that makes "blinded" a defined term rather than a hope — Safe Harbor's 18 removed identifiers or a documented expert determination (§164.514) — is covered in the analytics article.

A worked instance of the discipline: room names. A consult link like /room/dermatology-biopsy-results-ivanov puts a diagnosis and a surname into browser history, proxy logs, and every analytics tool that records URLs — systems far outside any boundary you drew. /room/c7f8-44a2 carries nothing. PHI in URLs is one of the classic telemedicine mistakes, and it is an architecture decision, not a coding slip: identifiers are assigned where the room is created.

Rule 2 — Only three kinds of components exist

Once the boundary is drawn, every component in your stack must be exactly one of three things:

1. Yours — self-hosted software on infrastructure covered by your cloud provider's BAA: your API, your database, an SFU you operate (a Selective Forwarding Unit, the media server that routes video between participants), your TURN relay (the fallback server that forwards media when two devices cannot connect directly).
2. A BAA-covered vendor — a managed service whose operator has signed a BAA that covers your specific use: a video API with a healthcare plan, a transcription API with a BAA and a zero-retention mode, cloud storage under the provider's BAA.
3. Blind by design — a service that never receives PHI because you de-identify or strip before it: product analytics, marketing email, app-store crash reporting.

There is no fourth category. "They're encrypted" is not a category — encryption without a contract is still a violation, because a BAA is required the moment a vendor maintains PHI, readable or not. OCR's cloud-computing guidance is explicit: a cloud provider storing encrypted ePHI without holding the decryption key is still a business associate — "no-view" services need the contract all the same. The narrow exception the guidance leaves open, the conduit, covers only pure transmission with at most transient storage — the postal service and its electronic equivalents, like an internet service provider. Teams regularly try to stretch the conduit exception over their TURN servers, their CDN, or their email relay; OCR built it for couriers, and stretching it is a bet your lawyers will not let you place.

Figure 2. The placement decision for every component, as a tree: blind it if you can, contract or self-host it if you cannot, and redesign anything that fails all three branches.

Two fine points on the categories. A cloud BAA covers services, not the account. AWS, Google Cloud, and Microsoft Azure all sign BAAs, but each agreement applies only to the provider's published list of HIPAA-eligible services — AWS alone lists 100+ and updates the list continually (Amazon Bedrock was added February 10, 2026). Using a non-eligible service for PHI is a violation with a signed BAA in hand. And the BAA does not configure your account: under the shared-responsibility model the provider secures the infrastructure; encryption settings, access policies, and network rules in your account remain your work. Vendor status is dated. Vendor capabilities and contracts shift — Twilio announced its Video API's end-of-life for December 2026, then reversed the decision in October 2024 and kept the product; LiveKit Cloud added a BAA offering; analytics vendors change PHI terms. The placement table below is therefore category-level; per-vendor BAA status, with dates, lives in the BAA article's vendor table and must be re-verified at contract time.

The table's pattern is the point: for media-path components the answer is a contract or self-hosting, because they cannot be blinded; for everything on the periphery the cheapest compliant answer is usually to blind it and keep the boundary small.

Rule 3 — Encrypt every hop, and hold the keys like they are the product

Encryption in this pattern is not one checkbox; it is a property asserted on every arrow and every cylinder in Figure 1. The full treatment — which layer satisfies which rule citation, and when end-to-end encryption is worth its costs — is in the encryption article; here is the architecture-level summary.

In transit, WebRTC — the real-time engine in every browser — gives you encrypted media by standard: there is no plaintext mode. Media runs over SRTP (RFC 3711) with keys negotiated via DTLS-SRTP (RFC 5764), per the WebRTC security architecture (RFC 8827). Signaling and APIs ride TLS, floor 1.2 and prefer 1.3 per NIST SP 800-52 Rev. 2. The hop teams forget is the internal one: SFU to recorder, recorder to storage, service to service. The pattern's rule is every hop, including the ones inside your own VPC — a flat trusted network behind one TLS terminator is exactly what Rule 4 exists to prevent. The protocol mechanics live in our Video Streaming section: how DTLS-SRTP actually works.

At rest, everything that lands on disk inside the boundary — recordings, transcripts, chat logs, the database, backups — is encrypted under keys managed in a key-management service (KMS), with envelope encryption: each object sealed with its own data key, each data key sealed by a master key that never leaves the KMS. Encryption at rest done to the relevant NIST specifications also buys the only discount HIPAA offers: under the HHS breach-notification safe harbor, properly encrypted data whose keys were not compromised is not a reportable breach when a disk or bucket goes missing.

Key custody is the part that makes encryption real. Three rules. The KMS lives logically apart from the data plane — services request decryption through it and every grant is logged; nobody downloads "the key file." Key access follows the same least-privilege logic as data access: the recorder can encrypt, only the playback service can decrypt, and the difference is two IAM policies. And keys rotate on schedule without re-encrypting history, which envelope encryption makes cheap. The same custody discipline extends to secrets — API tokens, database passwords, TURN shared secrets. Secrets in a repository or a CI environment variable are the quiet twin of PHI in logs: invisible until the breach report. Keep them in a secrets manager with rotation and audit, and prefer short-lived credentials wherever a protocol allows — TURN's standard ephemeral-credential mechanism (a time-limited HMAC instead of a static password) is purpose-built for exactly this. NIST SP 800-66 Rev. 2, the agency-written companion for implementing the Security Rule, maps these practices to named controls if you want the formal crosswalk.

Rule 4 — Segment the network into planes

Network segmentation is the practice of dividing infrastructure into zones with controlled crossings, so that compromising one zone does not hand over the rest. Today it is implied by the Security Rule's risk-analysis logic; the proposed 2026 update names it outright as a required technical control (90 FR 898) — one more reason this pattern treats it as a given. After the February 2024 Change Healthcare ransomware attack — 192.7 million people affected, entered through one remote-access portal without multi-factor authentication — segmentation and MFA stopped being negotiable in any healthcare security review.

A telemedicine video stack divides naturally into four planes:

• Media plane — SFU and TURN fleets. Public on exactly the ports WebRTC needs, hardened and patched on a deadline (the 2026 proposal: 15 days for critical vulnerabilities), and blind where possible: an SFU decrypts media to route it, so its hosts are inside the boundary, but they hold tokens, not names. East-west, the media plane can reach the recording pipeline and nothing else.
• Application plane — API, signaling, web and mobile backends. The only plane that talks to the identity provider and issues the short-lived tokens everything else trusts.
• Data plane — database, recordings store, transcripts, audit archive. Accepts connections only from named application-plane services; no public route exists. This is where the KMS grants concentrate.
• Admin plane — the deploy pipeline, bastion or zero-trust access path, monitoring consoles. Reached only by MFA-verified humans on managed devices; NIST SP 800-207's zero-trust architecture is the modern blueprint here, replacing the assumption that "inside the VPN" means "trusted."

The crossing rule is deny-by-default: every allowed edge between planes is enumerated, and the enumeration is the network map the 2026 proposal asks you to keep current. The clinical payoff of the discipline is concrete: when ransomware lands on a workstation in the admin plane, the consult in progress on the media plane does not drop, and the recordings store does not encrypt itself for a ransom note.

Figure 3. The four planes and the only crossings allowed. Each arrow is an explicit rule; everything else is denied. The enumerated edges double as the ePHI network map the proposed 2026 rule requires.

Rule 5 — Audit logging is a service, not a feature

Every plane in Figure 3 emits events to one pipeline that nobody — including your own administrators — can quietly edit. That is the whole rule. HIPAA's audit-control standard (45 CFR §164.312(b)) requires you to record and examine activity in systems containing ePHI; the architecture answer is a cross-cutting service: services emit structured events (who, what, when, from where), a collector ships them to write-once storage with hash chaining, the logging pipeline runs under credentials the production application cannot assume, and clocks are NTP-synchronized so an investigation can order events across the SFU, the API, and the EHR sync. Two properties matter at the pattern level: the logs themselves are PHI (they say who received care and when), so the pipeline sits inside the boundary; and log access is itself logged, because the visitor sign-in sheet needs its own sign-in sheet. Event taxonomy, retention arithmetic, and the review cadence that turns logs into compliance are in the audit-logging article — the architecture's job is to make that article implementable by design rather than by archaeology.

Rule 6 — PHI stays out of the places it does not belong

The first five rules protect PHI where it is supposed to be. The sixth defends the perimeter from the inside: in mature telemedicine builds, the violations that surface in audits are almost never "the database was public" — they are PHI seeping into systems nobody thought of as clinical. The seepage paths are predictable enough to engineer against:

• Logs. Request loggers capture URLs, headers, and bodies by default; a patient-search endpoint logs names by default. Fix structurally: scrubbing middleware on the logging path, allowlists of loggable fields, and log review as part of code review.
• Analytics. A session-replay or autocapture SDK on a clinical screen ships PHI to a vendor with no BAA the day it is installed. Fix: the de-identification gateway from Rule 1, and no third-party SDKs inside consult surfaces at all.
• Push notifications. "Your lab results for hepatitis panel are ready" renders on a locked screen and transits Apple's and Google's servers — which sign no BAA. Fix: content-free pings; the app fetches the real message over TLS after authentication.
• Support tooling. A screenshot pasted into a ticket carries a name and a diagnosis into the helpdesk vendor. Fix: redaction tooling, plan-level BAA for the helpdesk, staff training with teeth.
• Backups and copies. A database dump on a developer laptop is an unencrypted PHI store outside every control you built. Fix: backups encrypt under the same KMS regime, restores happen inside the boundary, and production data never seeds staging — synthetic data does.

A useful drill for each new integration: ask "what would the vendor see if I subpoenaed their storage?" If the honest answer includes a patient identity, the vendor is inside your boundary — contract or blind, no third option. The fuller failure gallery, with fixes, is in common HIPAA mistakes in telemedicine builds.

The five-minute self-audit. Five questions that catch most violations before an auditor does: (1) Can you name every system that stores or sees PHI — and does each have a BAA or your own ops team behind it? (2) Does any URL, log line, or analytics event anywhere contain a patient identifier? (3) Who can decrypt the recordings bucket, and is every decrypt logged? (4) If your office network were ransomwared today, would consults keep running? (5) Could you produce, this afternoon, the list of everyone who accessed a given patient's sessions last quarter? Anything you cannot answer is your backlog, in priority order.

The worked example: a 10,000-consult platform through the pattern

Abstractions earn trust by surviving contact with a real stack, so walk one through. A telemedicine startup runs 10,000 video consults a month — roughly 3,300 hours of clinical conversation — on a self-hosted SFU, with recordings on 40% of visits, a managed transcription API for the AI scribe, an EHR integration, and the usual periphery: analytics, email, push, support desk.

Placement first, straight from the table in Rule 2. Inside the boundary: the cloud account (BAA signed, eligible services only), both media fleets (SFU and coturn TURN, self-hosted, token-only), the application plane, the data plane with envelope-encrypted recordings, the transcription vendor (BAA plus zero-retention flag, so audio is processed and discarded), the EHR bridge (the EHR vendor is the covered entity's system; your connection rides the integration patterns), and the audit pipeline. Outside, blinded: analytics behind a de-identification gateway, content-free push, transactional email with no clinical content, and the support desk under a plan-level BAA because screenshots happen.

Now the question every founder asks: what does the compliance layer cost to run? Do the arithmetic in the open, on AWS list prices (US East, June 2026 — verify current rates; other clouds land within the same order of magnitude):

• Key management. Six master keys (database, recordings, transcripts, backups, audit archive, secrets) at $1 each, plus API calls. 4,000 recordings × 2 envelope operations = 8,000 calls, far under the $0.03-per-10,000 meter. ≈ $7/month.
• Immutable audit trail. ~60 events per consult × 10,000 consults ≈ 600,000 events ≈ 0.6 GB/month at ~1 KB each. Write-once object storage at $0.023/GB-month costs pennies now and ≈ $1/month even at the six-year accumulation plateau (~43 GB). ≈ $1/month.
• Segmentation plumbing. One NAT gateway so private planes can fetch updates without public exposure: ~$32/month fixed plus $0.045/GB processed — call it ≈ $40/month at this scale. (Consult media does not transit it; TURN talks to the internet on its own hardened interface.)
• Storage encryption on ~1 TB of recordings/month: server-side encryption is free; the cost was already in the storage bill.

Total: ≈ $50–100 a month of infrastructure to run the pattern — about the price of one provider's stethoscope, and roughly a 2–3% premium on what this platform already spends on compute and storage (the full operating budget is in the cost model). The real compliance spend is the proof cycle, the recurring evidence work the 2026 Security Rule update would formalize: an annual penetration test ($15,000–30,000 → $1,250–2,500/month amortized), vulnerability scanning each six months (tooling from ~$200/month), the annual risk-analysis and audit refresh (people-time), and BAA verification exchanges with every vendor. The architecture pattern is cheap to run and expensive to skip; the proof cycle is the line item to budget honestly.

The build order: wrapping an existing stack

Greenfield builds apply the rules top to bottom. Most teams are not greenfield — they have a working video product and a compliance deadline. The retrofit order that works, one step feeding the next:

1. Inventory the data flows. Two weeks of tracing every PHI element to every system it touches, including logs and SDKs. Output: the data-flow map — Rule 1's artifact and the 2026 proposal's required inventory, in one pass.
2. Draw the boundary on the map. Mark every component inside; flag everything that touches PHI but should not.
3. Triage every vendor. Three piles per the decision tree: has-or-can-sign a BAA; can be blinded; must be replaced. The third pile sets your critical path — contract cycles run weeks to months.
4. Close the encryption and key gaps. Transit inside the VPC, envelope encryption on stores, KMS custody, secrets out of code and into a manager with rotation.
5. Segment the planes. Stand up the four-plane layout and move services in, deny-by-default; media fleet first, because it is the public-facing one with the patch deadlines.
6. Stand up the audit pipeline. Cross-cutting collector, WORM storage, hash chaining, separate credentials; backfill what existing logs you can.
7. Sweep the egress paths. Rule 6 as a checklist against every outbound integration; then schedule the proof cycle — scans, pentest, annual review — on the calendar before the launch party.

Figure 4. The retrofit order. Each step produces an artifact the next one consumes; the vendor triage in step 3 starts earliest because contracts move slower than code.

Budget reality: steps 1–3 are days-to-weeks of senior attention; steps 4–7 are typically a one-to-three-month engineering effort for a small team, dominated by the media-plane rebuild if TURN/SFU were never isolated. That is the honest price of "wrap it later" versus designing on the pattern from day one.

What you hand the auditor

The deliverable this article promised the CTO: a single page showing the boundary, the planes, the encrypted hops, the BAA-covered components, and the audit spine — plus the evidence list behind it: the signed BAAs (cloud, video layer if managed, transcription, support desk), the asset inventory and network map with their last-reviewed dates, the KMS key policy and rotation schedule, a sample of the hash-chained audit trail, the latest vulnerability-scan and penetration-test reports, and the risk analysis that ties the controls to your actual threats. An architecture diagram with dated evidence behind every element is what turns a security questionnaire from a three-week scramble into an attachment.

Download the HIPAA telemedicine reference architecture (PDF) — the Figure 1 boundary diagram redrawn as a one-page handout, with the six rules as a checklist on the same page.

Where Fora Soft fits in

Fora Soft has built video software since 2005 — telemedicine platforms, video conferencing, streaming, surveillance, e-learning, 239+ shipped projects — and this pattern is how our healthcare builds start, not how they end. When we scope a telemedicine product, the PHI boundary and the vendor map are drawn before the first sprint: media fleets designed token-only, recordings pipelines that envelope-encrypt before the first byte lands, analytics blinded through a de-identification gateway, and an audit spine that exists because the architecture emits it. Teams come to us both ways — greenfield builds that want compliance structural from day one, and working products staring down a hospital questionnaire that need the retrofit sequence above executed without dropping live consults. If either is you, talk to our telemedicine team.

What to read next

• The telemedicine video reference architecture: the full picture — Block 3's overlay of this boundary on the complete video stack.
• Business Associate Agreements: the contract that makes or breaks your stack — the per-vendor table behind Rule 2.
• The HIPAA readiness checklist and audit-prep guide — the block capstone that turns this architecture into an ordered pre-launch run.

Call to action

• Talk to a telemedicine engineer — book a 30-minute scoping call to talk through your hipaa compliant architecture plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the HIPAA Telemedicine Reference Architecture — One page: the PHI-boundary reference diagram for a telemedicine video stack — BAA-covered components, encrypted hops, segmented planes, audit spine, blinded periphery — with the six pattern rules as a checklist.

References

1. 45 CFR §164.312 — HIPAA Security Rule, technical safeguards: access control (a), audit controls (b), integrity (c)(1), authentication (d), transmission security (e). eCFR, read 2026-06-11. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.312 Tier 1.
2. 45 CFR §164.502(e), §164.504(e) — business associate contracts requirement and mandatory clauses; §160.103 — definitions of PHI and business associate; §164.514(b), (d) — de-identification standard and minimum necessary. eCFR, read 2026-06-11. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164 Tier 1.
3. HHS OCR — HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information (NPRM), 90 FR 898, January 6, 2025 — proposed mandatory network segmentation, asset inventory and ePHI network map, encryption, MFA, patching deadlines, annual audits. Status re-verified 2026-06-11: still a proposed rule. https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information Tier 1.
4. HHS OCR — Guidance on HIPAA & Cloud Computing (2016, page reviewed/updated through 2026): no-view cloud services storing encrypted ePHI are business associates; the conduit exception is limited to transmission-only services with transient storage. https://www.hhs.gov/hipaa/for-professionals/special-topics/health-information-technology/cloud-computing/index.html Tier 2.
5. NIST SP 800-66 Rev. 2 — Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide (2024) — control-level crosswalk for the practices in Rules 3–5. https://csrc.nist.gov/pubs/sp/800/66/r2/final Tier 1.
6. NIST SP 800-207 — Zero Trust Architecture (2020) — the admin-plane access model replacing perimeter trust. https://csrc.nist.gov/pubs/sp/800/207/final Tier 1.
7. IETF RFC 8827 — WebRTC Security Architecture (mandatory SRTP/DTLS-SRTP); RFC 3711 (SRTP); RFC 5764 (DTLS-SRTP key establishment). https://datatracker.ietf.org/doc/html/rfc8827 Tier 1.
8. NIST SP 800-52 Rev. 2 — Guidelines for the Selection, Configuration, and Use of TLS Implementations — TLS 1.2 floor, 1.3 preferred (revision in public comment, May 2026). https://csrc.nist.gov/pubs/sp/800/52/r2/final Tier 1.
9. HHS — Guidance to Render Unsecured PHI Unusable, Unreadable, or Indecipherable (breach-notification encryption safe harbor, pointing to NIST SP 800-111 and TLS guidance). https://www.hhs.gov/hipaa/for-professionals/breach-notification/guidance/index.html Tier 2.
10. AWS — HIPAA Eligible Services Reference (list updated continually; Amazon Bedrock added 2026-02-10, reference page updated 2026-05-22) and Architecting for HIPAA Security and Compliance whitepaper — BAA covers eligible services only; shared-responsibility model. https://aws.amazon.com/compliance/hipaa-eligible-services-reference/ Tier 4.
11. Twilio — Twilio Video Will Remain a Standalone Product, changelog, October 21, 2024 — reversal of the December 2026 end-of-life announced March 2024; example of why vendor placement decisions carry dates. https://www.twilio.com/en-us/changelog/-twilio-video-will-remain-a-standalone-product Tier 4.
12. Change Healthcare breach reporting — 192.7 million individuals (OCR notification of 2025-07-31); entry via a remote-access portal without MFA per public reporting and congressional testimony. https://www.healthcareitnews.com/news/new-numbers-change-healthcare-data-breach-193-million-affected Tier 6 (outlet; figure traced to OCR portal).

Where lower-tier sources disagreed with rule text, the rule text won. Two recurring examples: vendor pages implying "encrypted = compliant" are contradicted by §164.502(e) and OCR's cloud guidance (a no-view, no-key cloud store is still a business associate); and articles stretching the conduit exception over TURN relays, CDNs, or email contradict the guidance's transmission-only, transient-storage framing — this article follows OCR and treats media relays as inside the boundary.