When we started building Coral, one of the earliest architectural decisions we made was to treat HIPAA compliance and BAA readiness as foundational requirements, not as features to be added once we had customers. This was a deliberate choice, and it influenced decisions about data architecture, infrastructure selection, access controls, and incident response processes before we had written a single line of application code.
This article explains what that decision meant technically, why we made it, and what BAA-readiness actually requires beyond the signed document itself.
What a BAA Actually Commits You To
A Business Associate Agreement is a contract between a covered entity (the healthcare provider) and a business associate (any vendor who handles protected health information on the provider's behalf). Under HIPAA, covered entities are required to have BAAs with all business associates before sharing PHI.
The BAA creates legal obligations for the business associate to safeguard the PHI they handle, to use it only for the purpose for which it was shared, to report breaches, and to flow down the same obligations to any subcontractors who also touch the PHI. If a business associate has a security incident involving PHI, the BAA defines the notification obligations and the process.
Signing a BAA without having the underlying technical and organizational safeguards in place to back up those commitments creates legal exposure without creating actual protection. A BAA that commits to breach notification within a defined timeframe is meaningless if your incident detection and response processes cannot actually detect a breach and trigger the notification chain. A BAA that commits to limiting PHI use to contracted purposes is meaningless if your data architecture stores customer PHI in ways that make it accessible to processes unrelated to the contracted service.
This is the distinction between BAA compliance as a checkbox and BAA readiness as a system state. We wanted to be ready, not just signed.
What We Built to Back Up the Commitment
Data isolation was the first architectural requirement. Every customer's PHI is isolated at the storage layer. Referral documents and extracted clinical fields from one customer's account are not co-mingled with another customer's data in a way that could create cross-customer access risk. This isolation extends to how we process documents: processing jobs run in isolated contexts, not in shared compute environments where document data from one customer's job could be accessible to another.
Access controls are implemented at the application layer and the infrastructure layer. Application-layer controls determine which users and which service accounts can access which customer data. Infrastructure-layer controls enforce these boundaries at the storage level, so that a misconfiguration at the application layer does not automatically become a PHI exposure. We maintain audit logs of access to customer data that are retained and reviewable.
Our data retention policy is explicit and enforced. Referral documents are retained for a configurable period (30 days by default, adjustable to 7 or 90 days based on clinic needs) and then deleted using a process that makes recovery from standard storage infeasible. Extracted field data follows a separate retention timeline. We do not retain PHI indefinitely as a product feature, because retention beyond operational need creates risk without creating value.
Encryption is applied to PHI at rest using AES-256 and in transit using TLS 1.3. This covers both the document files that come in through fax ingestion and the structured field data that is produced by extraction. Both categories contain PHI, and both are encrypted.
The Incident Response Piece That Gets Underweighted
Most conversations about healthcare vendor compliance focus on preventive controls: encryption, access controls, BAA. The incident response dimension, specifically what happens when something goes wrong, gets less attention but is equally important for a BAA commitment.
Under HIPAA, if a business associate discovers a breach of unsecured PHI, they must notify the covered entity without unreasonable delay, and no later than 60 days after discovering the breach. The covered entity then has their own notification obligations to affected individuals and to HHS under the Breach Notification Rule.
Meeting this 60-day notification requirement starts with incident detection. You cannot notify of a breach you have not detected. We implemented monitoring and alerting for anomalous access patterns and unauthorized data access attempts. This is not sophisticated by enterprise security standards, but it is real and it is appropriate for the current scale of our operation. As we grow, we will need to scale these controls accordingly.
Our BAA specifies what we commit to do in the event of a breach: notify the covered entity within 5 business days of discovery, provide the categories of PHI involved, an estimate of the number of affected individuals if determinable, the nature of the breach, steps we have taken to mitigate harm, and steps to prevent recurrence. That specificity is in the document because we built the response process first and then documented it, not the other way around.
Why We Made This Decision Early Rather Than Later
The practical argument for deferring compliance work until you have customers is real: compliance infrastructure takes time and attention that could otherwise go into product features. For a small early-stage team, every hour spent on access control design is an hour not spent on extraction accuracy or user interface.
We made the opposite choice for a specific reason: the architecture decisions you make when you build the first version of your data handling system are much harder to change than the decisions you make in the application layer. Retrofitting data isolation onto a system that was originally designed with shared storage is a significant undertaking that risks introducing new vulnerabilities in the process. Retrofitting encryption onto a system that stored data unencrypted means dealing with the existing unencrypted data while migrating to the new state.
Building the right architecture at the start was a smaller total investment than building the wrong architecture and then rebuilding it. The compliance constraints also shaped the architecture in ways that turned out to be technically sound regardless of HIPAA: isolated storage per customer makes it easier to delete a customer's data when they leave, easier to audit access per customer, and easier to apply different retention policies to different customers. These are good properties for a multi-tenant SaaS product independent of their compliance value.
What BAA-Ready Does Not Mean
BAA readiness does not mean HIPAA certification. There is no HIPAA certification process. Organizations that claim to be "HIPAA-certified" are typically referring to a third-party audit against the HIPAA standards, not a government-issued certification. These audits can be valuable as evidence of a systematic security review, but they are not required and their absence does not indicate non-compliance.
BAA readiness also does not mean zero risk. No technical or organizational control eliminates the possibility of a security incident. What it means is that the safeguards appropriate to the risk profile are in place, the incident response processes exist, and the legal framework for handling a breach is defined. The goal is not perfect security; it is appropriate security with clear accountability.
For infusion centers and DME providers evaluating document processing vendors, BAA-readiness should be a threshold requirement, not a differentiator. What differentiates vendors is the depth and specificity of what backs up the BAA commitment. Asking for specifics on data isolation, access logging, retention policies, and incident response commitments is the right way to evaluate that depth.