Business Associate Agreement
The standard clickwrap Business Associate Agreement governing HIPAA liabilities, client-side zero-knowledge execution, and data protection boundaries.
STANDARD BUSINESS ASSOCIATE AGREEMENT
This Business Associate Agreement (BAA) is entered into by and between the user of the Services who has affirmatively accepted this Agreement via electronic clickwrap (Covered Entity) and ConsentCollect (Business Associate). This Agreement modifies and supplements the master Terms of Service.
1. Purpose and Scope
Covered Entity utilizes Business Associate's digital platform (Services) to facilitate electronic documentation and consents. In the course of providing these Services, Business Associate may have technical access to electronic Protected Health Information (ePHI) as defined under the Health Insurance Portability and Accountability Act of 1996 (HIPAA) and the HITECH Act.
2. Permitted Uses and Disclosures
Business Associate shall not use or disclose ePHI other than as permitted or required by this Agreement, the master Terms of Service, or as required by law. Business Associate shall implement administrative, physical, and technical safeguards that reasonably and appropriately protect the confidentiality, integrity, and availability of ePHI.
3. Cryptographic Conditions and Zero-Knowledge Framework
- Client-Side Cryptographic Blindness: The Services operate on a strict, end-to-end zero-knowledge architecture. All data inputs, including form answers, patient fields, and signatures, are encrypted locally on the device of the Covered Entity or patient before being transmitted to Business Associate's cloud infrastructure.
- Encryption Standards: The software enforces industry-standard client-side encryption using AES-256-GCM for payload data and 4096-bit RSA keys for secure key exchange.
- No Decryption Capability: Business Associate does not possess, manage, or have access to the cryptographic decryption keys. Consequently, Business Associate cannot read, alter, or view ePHI in human-readable or plaintext form.
- Unencrypted Metadata Restrictions: Covered Entity is strictly prohibited from entering identifiable patient information into unencrypted metadata fields, including but not limited to: account names, custom form titles, file names, or notification email subject lines.
4. Breach Notification and Availability
- Data Visibility Breaches: Because all stored ePHI is encrypted client-side using advanced cryptography, a third-party server intrusion or database leak does not constitute a Breach of Unsecured PHI under 45 CFR Section 164.402, provided the encryption layer remains unbroken and the corresponding decryption keys have not been compromised.
- Availability Breaches: In the event of a material server outage, ransomware incident, or system error that destroys data or interrupts access to the Services for more than twenty-four consecutive hours, Business Associate will notify the Covered Entity within seventy-two hours of confirming the incident.
5. Downstream Subcontractors
In accordance with 45 CFR Sections 164.502(e)(1)(ii) and 164.308(b)(2), Business Associate ensures that any cloud infrastructure, database providers, or hosting subcontractors utilized to maintain the system are contractually bound to safeguard the stored data. Because all hosted data consists of cryptographically unreadable ciphertext blobs, Business Associate's infrastructure layer satisfies HIPAA security requirements through zero-knowledge technical isolation.
6. State-Specific Retention and Compliance (Texas HB 300)
Business Associate maintains its infrastructure in compliance with heightened state-specific data protection regulations, including but not limited to the Texas Health and Safety Code Section 181.001 (Texas HB 300). Business Associate ensures that electronic tracking logs and system infrastructure prevent unauthorized access. Covered Entity remains solely responsible for managing mandatory patient record retention periods and fulfilling individual patient data access requests via their local administrative cryptographic keys.
7. Limitation of Liability
NOTWITHSTANDING ANYTHING TO THE CONTRARY CONTAINED IN THE MASTER TERMS OF SERVICE OR THIS AGREEMENT, BUSINESS ASSOCIATE'S TOTAL AGGREGATE LIABILITY FOR ANY HIPAA VIOLATIONS, SECURITY INCIDENTS, REVENUE LOSS, OR BREACH CLAIMS ARISING OUT OF THIS AGREEMENT SHALL BE STRICTLY CAPPED AT THE TOTAL FEES PAID BY COVERED ENTITY TO BUSINESS ASSOCIATE IN THE TWELVE MONTHS IMMEDIATELY PRECEDING THE CLAIM.
8. Term and Termination
This Agreement becomes effective when the Covered Entity completes account registration and checks the acceptance box, or clicks the confirmation button within the platform UI. It will terminate automatically upon the deletion or cancellation of the Covered Entity's account and the complete purging of their encrypted cloud database items. Upon termination, Business Associate shall, if feasible, return or destroy all electronic Protected Health Information (ePHI) received or created on behalf of the Covered Entity. If such return or destruction is infeasible, Business Associate shall extend the protections of this Agreement to such ePHI and limit further uses and disclosures to those purposes that make the return or destruction infeasible.
Developer Integration: clickwrap compliance audit logging
If you are self-hosting your patient forms or integrating with our API, use the schema and logic pattern below to structure compliant clickwrap forensic logs in your database:
// Sample TypeScript schema and handler for compliant Clickwrap logging.
// This structure ensures clear forensic proof during regulatory audits.
interface ClickwrapAuditLog {
userId: string;
accountEmail: string;
documentVersionId: string; // example: "baa-v2026-06"
legalDocType: "baa" | "tos" | "privacy";
signatureMethod: "clickwrap";
timestamp: number; // Unix epoch timestamp
ipAddress: string;
userAgent: string; // Browser forensics
isAccepted: boolean;
}
async function recordClickwrapAgreement(log: ClickwrapAuditLog): Promise<boolean> {
if (!log.isAccepted) {
throw new Error("Consent must be affirmatively given.");
}
// Example database persistence routine
const recordSuccess = await db.insert("baa_signatures", {
userId: log.userId,
email: log.accountEmail,
version: log.documentVersionId,
method: log.signatureMethod,
signedAt: log.timestamp,
forensics: {
ip: log.ipAddress,
ua: log.userAgent
}
});
return recordSuccess ? true : false;
}