ProxForm under HIPAA

Why ProxForm is not a Business Associate

HIPAA's definition of "business associate" at 45 CFR 160.103 includes entities that "create, receive, maintain, or transmit" PHI on behalf of a covered entity. HHS guidance carves out a conduit exception for entities that only transmit PHI without persistent access — examples cited include the US Postal Service, private couriers, and telecom carriers. ProxForm fits that pattern.

• No persistent access to PHI. Patient answers travel directly browser-to-browser over a WebRTC peer-to-peer data channel. Artivicolab is not a hop in the path — the link goes through the open internet, not through our infrastructure.
• No ability to decrypt. The handshake metadata is encrypted with a passphrase known only to the two peers. We have no key, no key escrow, no recovery path. Even if we could intercept traffic, we couldn't read it.
• No storage, transient or otherwise. ProxForm has no application server. There is nothing on our infrastructure to subpoena, to breach, to retain, or to leak.
• No service-side logging of PHI. We do not log who connected to whom, what passphrase was used, or what data was exchanged. There is nothing to log because we are not in the path.
• The covered entity controls the entire lifecycle. The clinic builds the form, generates the invite, shares the passphrase out-of-band, receives the answers in their own browser, and chooses whether to retain a local copy. Every step is under the clinic's control.

Closest precedent: a clinic using a fax machine, a paper courier, or a USB stick to move forms between desks. The hardware vendor is not a Business Associate.

HIPAA Security Rule technical-safeguards mapping

Even though ProxForm is not a Business Associate, the architecture satisfies — or exceeds — every technical safeguard in the HIPAA Security Rule that a covered entity would need to evidence for the ProxForm portion of their workflow.

• §164.312(a)(1) Access Control. The clinic's existing endpoint controls (device lock screen, browser profile, MDM, idle timeout) gate access to ProxForm. ProxForm itself adds a privacy shield that masks patient data with *** after configurable idle time (30 s – 5 min) — additional access control specific to PHI display.
• §164.312(a)(2)(iii) Automatic Logoff. ProxForm's idle privacy shield + the clinic's browser/OS lock together cover this. The shield engages on the application layer; the lock screen covers the device layer.
• §164.312(a)(2)(iv) Encryption and Decryption (addressable). PHI at rest on the clinician's device sits in IndexedDB — its at-rest encryption is governed by the device's existing controls (FileVault, BitLocker). PHI on our infrastructure: not applicable, as none exists.
• §164.312(b) Audit Controls. ProxForm does not log PHI access because it has no view into PHI access. The covered entity's existing audit infrastructure (EHR access logs, device login logs, network telemetry) covers HIPAA audit-control obligations for the activity that does happen on their devices. ProxForm offers an End-Shift action that wipes patient data with a single click — useful as a documented shift-change procedure.
• §164.312(c)(1) Integrity. AES-256-GCM authenticates the ciphertext during handshake (any tampering fails decryption). WebRTC DTLS 1.3 authenticates the data channel. The SAS verification code lets both endpoints confirm there's no person-in-the-middle.
• §164.312(d) Person-or-Entity Authentication. Two-channel out-of-band sharing authenticates the receiving party: the link goes through one channel, the passphrase through another. Possession of both implies the intended recipient. SAS provides additional human-verifiable proof during the handshake.
• §164.312(e)(1) Transmission Security. AES-256-GCM on handshake metadata (key derived from passphrase via PBKDF2 100k SHA-256). DTLS 1.3 on the WebRTC data channel itself. Both exceed the addressable encryption-in-transit standard.

What stays on the covered entity (clinic)

HIPAA's administrative and physical safeguards live with the covered entity — not with software vendors. ProxForm does not replace them.

• §164.308 Administrative Safeguards. Security management process, workforce training, sanction policies, contingency planning — these are organizational programs the clinic owns.
• §164.310 Physical Safeguards. Facility access controls, workstation security, device and media controls — these apply to the clinic's premises and hardware.
• §164.404 Breach Notification. If the clinic's device is lost, stolen, or compromised, the clinic's existing breach-notification procedures apply to whatever PHI was on that device. ProxForm has no separate breach to notify about — there is no Artivicolab system holding PHI to breach.
• Workforce training on the ProxForm workflow. Train staff on: how to send invites, the two-channel rule (link by email, passphrase by phone — never both in the same message), how to use the privacy shield, when to End Shift.
• Retention policies. Decide which local submissions to keep, for how long, and where. ProxForm provides Export JSON and Print/PDF for portable records.

Cryptography & transport detail

• Key derivation. PBKDF2 with SHA-256, 100,000 iterations, derives a 256-bit key from the shared passphrase. A fresh random salt is generated per session.
• Handshake encryption. AES-256-GCM with a fresh 96-bit IV encrypts the SDP offer and answer carried in the URL fragment. The fragment never leaves the browser to an Artivicolab server — it's only visible to the two peers.
• Data-channel transport. WebRTC data channel over DTLS 1.3 (browser default), with SCTP framing. Both peers verify each other's DTLS fingerprints, which are themselves authenticated via the encrypted SDP exchange.
• Session verification (SAS). Each side generates a random nonce, exchanges it in the first data-channel message, then hashes both nonces together. The short hex code displayed on both screens must match — if they don't, abort.
• No long-term keys. Every session uses a fresh passphrase, fresh salt, fresh IVs, fresh nonces. Nothing is reused across sessions.

What ProxForm is not under HIPAA

• Not a HIPAA-compliant SaaS. We don't carry that label because we don't fit the SaaS mould — there's no service to make compliant.
• Not a substitute for an EHR. ProxForm transmits intake forms; it doesn't replace your records system. Move important submissions into your EHR using Export JSON or printed PDF.
• Not a long-term storage system. Submissions live on the clinician's own device. End-Shift wipes them on demand. Plan your retention separately.
• Not a substitute for legal advice. Your Privacy/Security Officer must still review ProxForm's fit into your HIPAA program. Use this page as the technical basis for that review.

If your compliance officer wants a BAA anyway

Some compliance teams ask for a Business Associate Agreement reflexively, even where the conduit exception applies. We will sign one on request — drafted to reflect the actual relationship (we don't access PHI, we don't store it, we don't transmit it through our infrastructure). Contact us through the link in the footer.

• Plain-language BAA available on request. Says what we do (provide the software) and what we don't (touch PHI). Sets out the few obligations that apply (notification if our software is shown to be the cause of an incident, cooperation with audits at your request).
• Security Rule mapping (this page) as the technical appendix to your HIPAA program documentation.
• Architecture letter on Artivicolab letterhead summarising the conduit-exception position, available on request for audit packets.