HIPAA in-progress: an honest compliance posture for beta clinical software

The conversation we have most often with prospective clinical partners ends in one of two ways. Either we get asked "are you HIPAA compliant?" and we say "in progress, here is the breakdown," and the conversation continues. Or we get asked the same question and the conversation ends because the prospect has been told by every other vendor that the answer is yes, and "in progress" sounds like a no.

The conversation that ended is the one this post is for. Here is why "in progress" is the only honest answer for a pre-GA clinical product, what we are and are not doing today, and what we are committing to ship before we accept production PHI.

What HIPAA actually requires

HIPAA is not a badge. The 1996 Health Insurance Portability and Accountability Act, together with the 2009 HITECH Act and the 2013 Omnibus Rule, is a regulatory framework with three components that matter for software vendors:

The Privacy Rule governs how Protected Health Information may be used and disclosed. It defines the categories of identifiable information, the permitted uses, and the patient rights (access, amendment, accounting of disclosures, etc.).

The Security Rule specifies administrative, physical, and technical safeguards for electronic PHI. The technical safeguards are the part most software vendors focus on: access control, audit controls, integrity, transmission security.

The Breach Notification Rule specifies what a covered entity (or its business associate) must do if PHI is exposed.

A software vendor that handles PHI on behalf of a covered entity is a Business Associate. The relationship is governed by a Business Associate Agreement, which has its own required terms (mandated by the HIPAA Privacy Rule, Section 164.504(e)).

A vendor that says "we are HIPAA compliant" is, at a minimum, claiming that they have signed BAAs in place with their covered-entity customers, that their technical safeguards meet the Security Rule's standards, that their breach notification procedures are documented and tested, and that their administrative safeguards (training, access management, sanction policy) are operational.

That is a lot of things to be true at once. Most pre-GA companies that claim it are claiming aspirations.

What we ship today

Nyra is in beta and is not handling production PHI from production clinics yet. Our current development posture is to assume PHI is contaminating in any environment that touches it, and to keep our build and development environments structurally separated from any pathway that could ever see it.

Concretely:

• No production PHI in development. The development environments use synthetic patient data, generated locally from a seed corpus we wrote. Real patient records do not exist in dev, ever.
• PHI-shape detection in CI. Every commit runs a build-time check that scans the client bundle for PHI-shaped strings (date-of-birth patterns, SSN patterns, MRN patterns, names against a corpus). The check fails the build on any match.
• Service-role keys are server-only. The Supabase service role key is never bundled into the client. The client can only execute under the user's authenticated context. A leaked dev token cannot read another patient's record, by row-level security on the database, not by hope.
• Logs are scrubbed. Server logs do not capture request bodies for the waitlist or any patient-data endpoint. The default we shipped was no entry-level logging; the previous trust pass removed even the placeholder console writes.
• Audit chain is append-only. Every action on a patient record is written to a hash-chained audit log. The log is structurally append-only at the database layer and cannot be revised by application code.

These are the technical safeguards we have in production today. They map directly to the HIPAA Security Rule's technical safeguard standards: access control (per-row, per-clinic scope), audit controls (the chain), integrity (immutable audit), and transmission security (TLS-only with HSTS).

What is in active build

The items we are in the middle of and have not finished:

• A formal Business Associate Agreement template. Drafted with counsel, in review with our pilot clinics, not yet signed.
• SOC 2 Type II audit. Type I scoping is complete, control framework is mapped to the AICPA Trust Services Criteria, observation window starts when our auditor confirms control design adequacy. We expect a Type I report this calendar year and a Type II report twelve months after the observation period begins. We do not display a SOC 2 logo before the audit reports exist.
• HIPAA risk assessment. The Security Rule requires a documented risk assessment (§164.308(a)(1)(ii)(A)). Ours is partially complete and is the gating artifact for our first production deployment.
• Encryption-at-rest verification on Supabase. The platform defaults are sufficient on paper; we are verifying via a third party for the audit trail.
• Workforce training. All three founders have completed a basic HIPAA-awareness course. A formal training program with documented attestations is being put in place for any additional team members.

What is on the roadmap, not on the floor

The items we are explicitly not promising before production:

• HITRUST certification. Distinct from SOC 2 and HIPAA, HITRUST is a separate framework with its own audit. We do not have it and are not pursuing it for v1.
• 21 CFR Part 11 (FDA electronic records). Applies if and when Nyra becomes a regulated medical device. The current product is decision support, which sits outside the FDA's medical-device boundary by design. If a future feature crosses into a regulated indication, the Part 11 work is on the path; today it is not relevant.
• 42 CFR Part 2 (substance use disorder confidentiality). Higher bar than HIPAA, applies to programs that hold themselves out as primarily for the treatment of SUD. Nyra is not such a program. Patients who are also receiving SUD care in another program have their HIPAA protections intact; the additional Part 2 protections live with the SUD program's records, not with Nyra.
• State-level privacy frameworks (CCPA, CPRA, etc.). Default-applicable; we have a posture but no certifications. Patients in California have full Privacy Rule rights through their clinic plus the additional consumer rights through CCPA/CPRA. Both apply.

How to read a "we are HIPAA compliant" claim from any vendor

Three questions worth asking any vendor who claims compliance:

Can you produce your most recent risk assessment? A vendor without a documented risk assessment is not Security Rule compliant, full stop. The assessment is the foundation of the rule.

Can you produce your audit report? A vendor claiming "SOC 2 compliant" without a Type II report is making a marketing claim. SOC 2 is a report, not a state.

Can you produce your BAA template before contract? A vendor that asks you to sign a generic BAA at contract time without showing you the template before negotiation is hoping you will not negotiate it.

These three questions sort the vendors who do the work from the vendors who use the language. They also tell you whether the answer to the original "are you HIPAA compliant?" question is honest.

Our timeline, with dates

We try to publish dates only when we can defend them. The current commitments:

• Production deployment with the first design-partner clinic: targeting Q4 2026, gated on the HIPAA risk assessment, BAA execution, and a final pass on the Security Rule technical safeguards.
• SOC 2 Type I report: targeting Q1 2027.
• SOC 2 Type II report: targeting Q1 2028 (a year of observation after Type I).
• HIPAA-compliant production posture across all controls: gated on the above; will be claimed only with documented evidence.

The /security page carries the same status in shorter form and updates as items move from "in build" to "in production." We do not back-date a badge we have not earned.

The "trust us, we are good people" failure mode

The hardest thing about a compliance posture is that most of it is invisible to the customer at contract time. A clinic considering a vendor cannot, on their own, audit the vendor's risk assessment, control framework, or BAA template. They are trusting either the vendor's word or the vendor's certifications.

The work of building trust here is the work of making the invisible visible. Publishing this post is part of that. The in-production / in-build / not yet table on the security page is part of that. The willingness to send our BAA template to a prospect before signing anything is part of that. None of it is a substitute for the actual controls being in place; all of it is a public commitment that we are doing the work, not gaming the perception.

A compliance program is not a badge. It is a posture. The posture is "in progress" and we are happy to show our work.

Where to go next

If you are a clinic decision-maker who needs to understand our compliance posture before a pilot conversation, book a thirty-minute discussion. The walkthrough includes the security architecture, the BAA template, and the in-build items above with current status.

If you are a builder integrating against our agent SDK, the security model that flows from the compliance posture is documented at the API layer (DPoP-bound OAuth, signed request bodies, append-only audit, per-clinic scope). The pricing page is also explicit that the SOC 2 / HIPAA pathway is in progress, not back-dated.