I help digital health startups, healthcare AI companies, and telehealth platforms build the legal foundation they need — from HIPAA-compliant agreements to Terms of Service that protect both the company and its users.
If you're building a healthcare SaaS product, an AI-powered clinical tool, or a telehealth platform, your legal documents need to do more than the standard tech startup boilerplate. HIPAA compliance, Business Associate Agreements, data processing obligations, and regulatory disclaimers are table stakes — not afterthoughts.
This hub consolidates every generator, template, and guide I've built for healthcare technology companies. Whether you need a single Terms of Service review or a complete legal document suite, start here.
Companies I work with:
Healthcare AI startups (clinical decision support, diagnostics, NLP)
Digital health and telehealth platforms
Healthcare SaaS companies (EHR integrations, practice management)
Medical device software (SaMD) companies
Health data analytics and population health platforms
The Healthcare SaaS Regulatory Landscape
Understanding the overlapping federal and state regulations that apply to healthcare technology companies.
Healthcare SaaS companies operate at the intersection of multiple regulatory frameworks. Unlike general-purpose software, any product that touches patient data, clinical workflows, or health information must satisfy requirements that go far beyond standard terms of service and privacy policies. Here's the landscape I navigate with every healthcare tech client:
HIPAA (Health Insurance Portability and Accountability Act)
HIPAA's Privacy Rule and Security Rule apply to "covered entities" (hospitals, clinics, insurers) and their "business associates" — which is what your SaaS company becomes the moment it handles protected health information (PHI) on behalf of a healthcare provider. The Privacy Rule governs how PHI can be used and disclosed. The Security Rule mandates administrative, technical, and physical safeguards for electronic PHI (ePHI). As a business associate, your obligations are enforced directly by HHS — you don't get a pass just because you're a vendor, not a provider.
HITECH Act
The HITECH Act (2009) extended HIPAA's security provisions and breach notification requirements directly to business associates. Before HITECH, only covered entities faced direct liability. Now, SaaS vendors face the same penalty tiers. HITECH also introduced mandatory breach notification: if a breach affects 500+ individuals, you must notify HHS, affected individuals, and prominent media outlets. For smaller breaches, you must maintain a log and report annually. The 60-day notification clock starts when you discover the breach — not when you finish investigating it.
FDA Software as a Medical Device (SaMD)
If your AI product makes clinical recommendations, aids in diagnosis, or influences treatment decisions, the FDA may classify it as a Software as a Medical Device (SaMD). The FDA's 2023 final guidance on Clinical Decision Support (CDS) software narrowed the exemptions: if your software is intended for use by healthcare professionals and its recommendations are not "transparent" enough for independent review, it's likely regulated. I help clients assess their SaMD classification risk using the International Medical Device Regulators Forum (IMDRF) framework, which categorizes SaMD into four risk classes (I through IV).
State Health Privacy Laws
HIPAA is the federal floor, not the ceiling. Multiple states impose additional requirements that healthcare SaaS companies must satisfy. California's CMIA (Confidentiality of Medical Information Act) is often stricter than HIPAA — it applies to a broader category of entities and provides a private right of action that HIPAA lacks. Washington, New York, Texas, Connecticut, and Colorado all have health-specific data protection provisions that layer on top of their general consumer privacy laws. I cover the major state variations in the State Privacy Law table below.
CCPA/CPRA & General Privacy Frameworks
While HIPAA-covered data is generally exempt from CCPA/CPRA, the exemption is narrow. It applies only to PHI maintained by a covered entity or business associate acting in that capacity. If your SaaS product also collects non-HIPAA personal information (user analytics, marketing data, employee data), CCPA/CPRA applies to that data separately. Many healthcare SaaS companies need both a HIPAA-compliant privacy framework AND a CCPA/CPRA-compliant one operating in parallel.
Document Generators
Self-service generators for healthcare SaaS legal documents. Each produces a customizable draft you can use as-is or bring to me for review.
Most healthcare SaaS companies need 6-10 legal documents. Here's how they interlock — from the umbrella agreement down to compliance-specific attachments.
1
Master Service Agreement (MSA)
The umbrella contract governing the entire relationship: liability, IP ownership, indemnification, dispute resolution. All other documents attach to or reference this.
2
Order Form
Specifies what the customer is buying: subscription tier, seat count, pricing, term length. References the MSA. Each new purchase = new Order Form, same MSA.
3
Statement of Work (SOW)
Defines implementation scope: milestones, deliverables, acceptance criteria, timeline. Critical for EHR integrations and custom configurations.
4
Service Level Agreement (SLA)
Uptime guarantees, response times, support hours, remedies for downtime. Hospitals require 99.9%+ uptime and defined RTO/RPO for PHI systems.
5
HIPAA Business Associate Agreement (BAA)
Required by law when your platform handles PHI. Defines permitted uses, safeguard obligations, breach notification procedures, and termination rights.
6
Data Processing Agreement (DPA)
Required for GDPR/CCPA compliance. Covers non-HIPAA personal data: lawful basis, data subject rights, cross-border transfers, sub-processor lists.
The key insight: your MSA is the trunk, and everything else branches off it. When a hospital procurement team asks for "your standard agreements," they expect this full stack — not just a Terms of Service page. I draft these as a coordinated suite so defined terms are consistent across all documents and there are no gaps or contradictions between them.
BAA vs DPA: When You Need Which (or Both)
These two agreements serve different regulatory masters. Most healthcare SaaS companies need both.
Dimension
HIPAA BAA
Data Processing Agreement (DPA)
Legal basis
HIPAA Privacy & Security Rules (45 CFR 164)
GDPR Art. 28 / CCPA/CPRA service provider provisions
Triggers when
Your platform handles PHI on behalf of a covered entity
You process personal data of EU/UK residents or CA consumers
Data covered
Protected Health Information (PHI) — 18 HIPAA identifiers linked to health data
All personal data (name, email, IP, device IDs, behavioral data, etc.)
Key obligations
Safeguards for ePHI, breach notification within 60 days, restrict uses/disclosures, allow covered entity audits
Document lawful basis, honor data subject rights, restrict sub-processors, enable data portability, conduct DPIAs
Breach notification
60 days to covered entity; covered entity notifies individuals & HHS
GDPR: 72 hours to controller. CCPA: reasonable time; no fixed deadline
Penalties
$137–$68,928 per violation; up to $2.07M/year per category
GDPR: up to 4% of global revenue or €20M. CCPA: $2,500–$7,500 per violation
Private right of action
No (HIPAA has no private right of action; enforcement is HHS/state AGs)
Yes under GDPR (Art. 82) and CCPA (§1798.150 for data breaches)
Cross-border transfers
Not specifically addressed (but PHI must remain protected regardless of location)
Requires SCCs, adequacy decisions, or other GDPR Chapter V mechanisms
Bottom line: If your healthcare SaaS product handles PHI for US healthcare providers, you need a BAA. If you also process personal data of EU/UK residents or California consumers (including user analytics, marketing data, or employee information), you need a DPA too. These are not interchangeable — a BAA does not satisfy GDPR requirements, and a DPA does not satisfy HIPAA requirements. I draft both as companion documents that reference each other and avoid contradictions.
HIPAA Breach Penalty Calculator
Estimate the potential penalty range for a HIPAA violation based on 2025 adjusted penalty amounts.
Per-Violation Minimum$—
Per-Violation Maximum$—
Annual Cap (per category)$—
Estimated Total Range$—
Breach Notification Required?Enter details
Media Notification Required?Enter details
Based on 2025 HHS inflation-adjusted penalty amounts (84 Fed. Reg. 68703). Actual penalties depend on OCR investigation findings, cooperation, and corrective actions. This calculator provides estimates only.
HIPAA Compliance Checklist for SaaS
Interactive checklist covering the key HIPAA requirements for healthcare SaaS vendors. Track your compliance status — progress is saved in your browser session.
0 of 0 items completed
Administrative Safeguards
Security risk assessment documented and updated annually
Required under 45 CFR 164.308(a)(1). Document all threats to ePHI, assess likelihood and impact, and implement reasonable safeguards. Update annually or when your environment changes.
Workforce HIPAA training program with completion records
All employees with potential PHI access must be trained. Track completion dates — HHS auditors specifically request these records.
Designated Privacy Officer and Security Officer appointed
Required under 45 CFR 164.530(a) and 164.308(a)(2). Can be the same person in smaller companies, but must be formally designated in writing.
Incident response and breach notification plan documented
Must include discovery procedures, risk assessment methodology, notification templates, and the 60-day timeline. Test annually with tabletop exercises.
Sanctions policy for workforce non-compliance
Required under 45 CFR 164.308(a)(1)(ii)(C). Document progressive discipline for HIPAA violations — from retraining to termination.
Technical Safeguards
PHI encrypted at rest (AES-256 or equivalent)
While HIPAA calls encryption 'addressable' not 'required,' the breach safe harbor (45 CFR 164.402) only applies to encrypted data. Practically, this means encryption is mandatory.
PHI encrypted in transit (TLS 1.2+ required)
All API calls, web traffic, and data transfers involving ePHI must use TLS 1.2 or higher. TLS 1.0 and 1.1 are deprecated and fail audits.
Role-based access controls with MFA for PHI access
Implement least-privilege access. MFA for PHI access is increasingly expected by covered entity procurement teams, even though HIPAA doesn't mandate a specific authentication method.
Audit logging for all PHI access, modification, and deletion
Required under 45 CFR 164.312(b). Logs must capture who, what, when, and from where. Retain for minimum 6 years.
Automatic session timeout for inactive users
Required under 45 CFR 164.312(a)(2)(iii). Industry standard: 15-minute timeout for clinical applications, 30 minutes for administrative.
Data backup and disaster recovery procedures tested
Required under 45 CFR 164.308(a)(7). Define Recovery Time Objective (RTO) and Recovery Point Objective (RPO). Test restoration procedures at least annually.
Physical Safeguards
Cloud hosting provider is HIPAA-eligible (e.g., AWS, GCP, Azure with BAA)
Your cloud provider must sign a BAA with you. AWS, GCP, and Azure all offer HIPAA-eligible configurations, but you must enable specific settings and sign their BAA.
Workstation security policies for remote development teams
Remote developers accessing production environments with ePHI need encrypted laptops, VPN access, screen lock policies, and secure home network requirements.
Device and media disposal procedures for hardware containing PHI
Required under 45 CFR 164.310(d)(2). Document how you wipe drives, destroy physical media, and verify disposal. Keep destruction certificates.
Contractual Requirements
BAA executed with every covered entity client
No BAA = no legal basis to handle PHI. This is non-negotiable. I see startups skip this with early beta customers — that's a violation from day one.
Subcontractor BAAs in place (cloud hosting, analytics, support tools)
If any of your vendors touch PHI (hosting, monitoring, support desk, analytics), they are subcontractor business associates and need BAAs. This includes Datadog, PagerDuty, Zendesk, etc. if they can access ePHI.
The 60-day clock starts at discovery, not at the conclusion of investigation. Document your internal escalation chain, risk assessment methodology, and notification templates.
Data use and disclosure limitations specified in all agreements
Your BAA must specify permitted uses of PHI. Common mistake: allowing PHI for 'improving services' without proper de-identification. Keep data use provisions narrow.
Data return/destruction obligations on contract termination
BAAs must address what happens to PHI when the relationship ends. Standard: return or destroy within 30 days, with certification of destruction.
Documentation
Written HIPAA policies and procedures maintained
Required under 45 CFR 164.316. Must be written, accessible to workforce, and reviewed periodically. HHS requires retention for 6 years from creation or last effective date.
Training records retained for 6 years (HIPAA requirement)
45 CFR 164.530(j) requires 6-year retention of training documentation. Track: employee name, training date, content covered, and acknowledgment signature.
Business associate inventory current and reviewed quarterly
Maintain a list of every vendor that handles PHI on your behalf. Review quarterly to catch new tools your engineering team may have adopted.
SOC 2 Type II or HITRUST certification obtained (or roadmap documented)
Not required by HIPAA, but increasingly required by enterprise healthcare customers. SOC 2 Type II is the minimum; HITRUST is the gold standard. If you don't have it yet, document your timeline.
HIPAA Breach Notification Timeline
What happens after you discover a breach — obligations, deadlines, and parallel notification tracks.
Day 0 — Discovery
Breach Discovered or Should Have Been Discovered
The 60-day clock starts now. "Discovery" includes when any employee or agent of the business associate knew or should have known about the breach. Willful ignorance does not stop the clock.
Days 1-3 — Immediate Response
Activate Incident Response Team
Contain the breach, preserve evidence, engage forensics if needed. Begin the 4-factor risk assessment: (1) nature and extent of PHI, (2) unauthorized person involved, (3) whether PHI was actually viewed/acquired, (4) extent of risk mitigation.
Days 3-14 — Investigation
Complete Risk Assessment & Scope Determination
Determine: How many individuals affected? What PHI was exposed? Is there a low probability of compromise (which would make it not a "breach" requiring notification)? Document everything.
As a business associate, you must notify your covered entity customer within 60 days of discovery. Your BAA may require a shorter timeframe (many hospital BAAs specify 24-72 hours). Check your BAA.
The covered entity must notify affected individuals within 60 days of their discovery. Written notice via first-class mail or email (if individual consented). Must include: description of breach, types of PHI involved, steps to protect themselves, what you're doing to mitigate harm.
Day 60 — If 500+ Individuals
HHS & Media Notification
If 500+ individuals in a state/jurisdiction are affected: (1) notify HHS immediately via breach portal, and (2) notify prominent media outlets serving the area. HHS publishes breaches of 500+ on its public "Wall of Shame."
Within 60 Days of Calendar Year End
Small Breach Annual Report (Under 500 Individuals)
Breaches affecting fewer than 500 individuals must be logged and reported to HHS annually, within 60 days of the end of the calendar year in which they were discovered.
Is Your AI Product a Medical Device?
Use this decision tree to assess whether the FDA may regulate your software as a Medical Device (SaMD). This is a screening tool — not a regulatory determination.
1. Does your software provide information used to make clinical decisions about individual patients?
2. Is the software intended to acquire, process, or analyze a medical image or signal from an IVD or medical device?
3. Is the recommendation transparent enough that a healthcare professional can independently review the basis for the recommendation?
4. Is the software intended to assist a healthcare professional, not replace their judgment?
✅ Likely Not FDA-Regulated
Your software appears to fall outside FDA device regulation. It doesn't provide patient-specific clinical decision support. However, if your marketing materials or intended use evolves toward clinical recommendations, reassess this determination.
Still needed: HIPAA compliance, privacy policies, and standard healthcare SaaS agreements.
⚠️ Likely FDA-Regulated as SaMD
Software that processes medical images/signals from devices is generally regulated as SaMD. You'll need to determine your device classification (Class I, II, or III) and follow the appropriate premarket pathway (510(k), De Novo, or PMA).
Action items: Engage an FDA regulatory consultant, implement a Quality Management System (QMS), and ensure your legal agreements address FDA-regulated product provisions.
✅ Likely CDS Exemption Applies
Your software appears to meet the criteria for the Clinical Decision Support (CDS) exemption under 21st Century Cures Act §3060. The key factors: it's intended for HCP use, the basis for recommendations is transparent, and the HCP can independently review the underlying data.
Caution: The CDS exemption is narrow and fact-specific. Document your intended use carefully and avoid marketing language that implies the software replaces clinical judgment.
⚠ Borderline — CDS Exemption May Not Apply
If your software's recommendations are not transparent to the HCP (a "black box" AI model), the CDS exemption likely does not apply under FDA's 2023 final guidance. The FDA expects HCPs to be able to independently review the basis for any recommendation.
Next steps: Consider whether you can make your model's reasoning more transparent (explainable AI), or plan for FDA device classification. This is a rapidly evolving area — I can help you assess your specific situation.
🚨 Likely FDA-Regulated — Autonomous Clinical Function
Software that drives clinical actions without HCP review is generally regulated as a medical device, regardless of transparency. The CDS exemption requires that the software "enable" an HCP to independently review — not replace their judgment entirely.
Classification: Likely Class II or III depending on the clinical risk. You'll need a robust regulatory strategy before market launch.
Disclaimer: This decision tree is a screening tool based on FDA's 2023 Clinical Decision Support guidance and the IMDRF SaMD framework. It does not constitute a formal regulatory determination. FDA classification depends on your specific intended use, risk level, and product design. I can help you prepare a formal regulatory assessment.
Which Documents Do You Need?
Find your company type below. Each scenario maps to the specific documents and generators you'll need.
Answer 4 questions to get a customized document checklist for your next healthcare deal.
Question 1 of 4
Who is your primary customer?
Hospital / Health System
Clinic / Medical Group
Health Plan / Insurer
Another Health Tech Company
Question 2 of 4
Does your product handle Protected Health Information (PHI)?
Yes — directly handles PHI
Only de-identified data
No — no health data at all
Not sure
Question 3 of 4
What's the typical deal size?
Under $25K ARR
$25K – $100K ARR
$100K – $500K ARR
$500K+ ARR
Question 4 of 4
Do you serve customers outside the US?
US only
US + EU/UK
Global
Not sure yet
Your Document Checklist
7 Legal Mistakes Healthcare SaaS Startups Make
These are the issues I see repeatedly across healthcare tech engagements. Each one creates real liability.
Mistake #1
Using a Generic SaaS Terms of Service
Standard SaaS ToS templates (even from well-known legal platforms) don't address HIPAA obligations, clinical disclaimers, PHI handling, or healthcare-specific liability limitations. A ToS that works for a project management tool creates dangerous gaps for a platform handling patient data.
Fix: Start with a healthcare-specific template, then customize for your product's PHI handling, clinical context, and regulatory status.
Mistake #2
Treating the BAA as a Formality
Many startups sign their customer's BAA template without reviewing it. Hospital BAAs often contain one-sided provisions: unlimited liability for breaches, unreasonable audit rights, overly broad indemnification, and data use restrictions that prevent legitimate product improvement.
Fix: Always have your own BAA template ready. Negotiate from your paper. At minimum, review every BAA for liability caps, audit scope, breach notification timelines, and permitted uses of de-identified data.
Mistake #3
Missing Subcontractor BAAs
Your engineering team uses AWS for hosting, Datadog for monitoring, PagerDuty for alerts, and Zendesk for support tickets. If any of these services can access ePHI, they are subcontractor business associates under HIPAA. I've seen companies with BAAs from their hospital clients but zero BAAs with their own vendors.
Fix: Audit every third-party tool in your stack. If it can access, store, or process ePHI, get a BAA. AWS, GCP, Azure, Datadog, and others all offer HIPAA-eligible configurations with BAAs — you just have to enable them and sign.
Mistake #4
No Clinical Disclaimer in the Product or ToS
AI health products that provide clinical insights, risk scores, or treatment suggestions without explicit disclaimers invite malpractice and products liability claims. Even if your product is a decision-support tool (not a diagnostic), the absence of a disclaimer can be used against you in litigation.
Fix: Include clear clinical disclaimers in your ToS, in-product UI, and marketing materials. Standard language: "This platform does not provide medical advice, diagnosis, or treatment. Always consult a qualified healthcare professional."
Mistake #5
Using PHI for Product Improvement Without De-Identification
Many healthcare SaaS companies want to use aggregate patient data to improve their algorithms. This is permitted under HIPAA — but only if the data is properly de-identified using either the Safe Harbor method (remove all 18 identifiers) or Expert Determination method (statistical certification). Using raw PHI for model training without de-identification is a HIPAA violation.
Fix: Build de-identification into your data pipeline from day one. Specify in your BAA exactly what de-identified data you may create and use. Get your de-identification methodology documented before your first covered entity customer.
Mistake #6
Ignoring State Health Privacy Laws
HIPAA preempts state laws only when the state law is "less stringent." Many states have health privacy provisions that are more stringent than HIPAA — and those survive. California's CMIA provides a private right of action for unauthorized disclosure of medical information. Washington's My Health My Data Act covers consumer health data that HIPAA doesn't reach.
Fix: Map your customer base geographically and identify applicable state laws. At minimum, address California (CMIA), Washington (MHMDA), and any state where you have significant customer concentration.
Mistake #7
No Breach Response Plan Until After the Breach
The 60-day HIPAA breach notification clock starts ticking at discovery. If you don't have a response plan, you'll spend the first two weeks figuring out process instead of executing it. I've seen companies miss the notification deadline simply because they didn't have templates, escalation contacts, or a risk assessment methodology ready.
Fix: Create an incident response plan before you need it. Include: internal escalation chain, risk assessment criteria, notification templates (for covered entities, individuals, and HHS), forensic investigation procedures, and media response protocols for breaches affecting 500+ individuals.
State Health Privacy Laws Beyond HIPAA
HIPAA is the federal floor. These state laws add requirements that healthcare SaaS companies must satisfy.
State
Law
Key Addition Beyond HIPAA
Private Right of Action?
California
CMIA (Civ. Code §56)
Broader definition of "medical information" and "provider of health care." Covers entities HIPAA doesn't reach. Requires written authorization for most disclosures. Applies to employers handling medical info.
Yes — $1,000 statutory + actual damages + attorney fees
Washington
My Health My Data Act (2023)
Covers "consumer health data" broadly — including fertility, mental health, and biometric data not covered by HIPAA. Requires consent for collection and sharing. Geofencing prohibition around health facilities.
Yes — private right of action under CPA
New York
SHIELD Act + Mental Hygiene Law
SHIELD Act mandates reasonable security measures for private information (broader than HIPAA). Mental Hygiene Law §33.13 restricts disclosure of mental health records beyond HIPAA minimums.
AG enforcement; limited private action for data breaches
Texas
THIPA (Health & Safety Code Ch. 181)
Applies to any entity that handles, creates, or obtains identifiable health information — not just HIPAA covered entities. Restricts electronic disclosure. Marketing use requires explicit authorization.
Yes — $5,000–$25,000 per violation + injunctive relief
Connecticut
CT Data Privacy Act (2023) + Insurance Code
Consumer health data gets "sensitive data" classification requiring opt-in consent. Insurance information code restricts disclosure of health-related insurance data.
AG enforcement only (no private action)
Colorado
CPA + HB 1363 (health data)
Consumer health data requires opt-in consent for processing. Universal opt-out mechanism required. Data Protection Assessments mandatory for health data processing.
AG enforcement only
Nevada
SB 370 (consumer health data)
Modeled after Washington's MHMDA. Broad definition of consumer health data. Requires consent for sale or sharing. Effective January 2025.
AG enforcement; private action for violations
Practical impact: If you sell to healthcare organizations in California, Washington, or Texas, you likely need to address their state-specific requirements in your privacy documentation — even if you're HIPAA-compliant. I build state-specific addenda into privacy policies and BAAs when the customer base warrants it.
90-Day Legal Launch Roadmap for Healthcare SaaS
A staged approach to building your legal foundation — from pre-launch compliance through post-first-customer obligations.
Pre-LaunchFoundation & Compliance Setup
Conduct initial HIPAA security risk assessment and document findings
Choose HIPAA-eligible cloud infrastructure and sign provider BAAs (AWS/GCP/Azure)
Implement encryption at rest and in transit for all ePHI
Establish role-based access controls and audit logging
Create written HIPAA policies and procedures manual
Assess FDA SaMD classification risk (if AI/clinical product)
Designate Privacy Officer and Security Officer
LaunchGo-to-Market Legal Infrastructure
Finalize SaaS Agreement / MSA + Order Form + SOW templates
Execute BAAs with first customers before any PHI transfers
Deploy Terms of Service and Privacy Policy on platform
Implement incident response and breach notification plan
Complete initial workforce HIPAA training for all employees
Audit all third-party tools for subcontractor BAA requirements
Set up data backup and disaster recovery procedures
Post-First CustomerOngoing Compliance & Scale
Establish quarterly business associate inventory review
Schedule annual HIPAA risk assessment update
Begin SOC 2 Type II or HITRUST certification process
Draft Data Processing Agreement if serving EU/UK customers
Build state-specific privacy addenda (start with CA, WA, TX)
Conduct first tabletop breach response exercise
Review and update document suite based on customer negotiation patterns
Implement de-identification pipeline if using data for product improvement
Real OCR Enforcement Actions Against Tech Vendors
These are actual penalties HHS Office for Civil Rights has imposed on technology companies and business associates.
2024
$4.75 Million
Montefiore Medical Center & IT Vendor
Employee of an IT contractor stole PHI of 12,517 patients over six months. OCR found the medical center failed to conduct a thorough risk analysis and failed to implement adequate monitoring of IT system activity. Both the covered entity and the vendor faced penalties.
2023
$1.25 Million
Banner Health (Cloud Breach)
Cyberattack compromised ePHI of 2.81 million individuals through unpatched systems. OCR found insufficient risk analysis, inadequate security measures, and failure to regularly review audit logs. Settlement included a corrective action plan with 2 years of monitoring.
2023
$1.3 Million
L.A. Care Health Plan (Business Associate Failure)
OCR found L.A. Care failed to conduct a risk analysis, implement adequate access controls, and maintain proper business associate agreements. Settlement addressed systemic compliance failures affecting 1.3 million members.
2022
$875,000
Business Associate (Oklahoma State Medical Association)
Business associate failed to provide breach notification within 60 days. The underlying breach affected only ~1,300 individuals, but the notification delay triggered separate enforcement. Demonstrates that process failures carry independent penalties.
Key takeaways for SaaS vendors: OCR does not distinguish between "we're just a vendor" and "we're a healthcare provider." Business associates face the same penalty framework. The most common findings in enforcement actions are: (1) failure to conduct a risk analysis, (2) insufficient access controls, (3) missing or inadequate BAAs, and (4) delayed breach notification. Every one of these is preventable with proper legal and compliance infrastructure.
Healthcare SaaS Legal Glossary
Key terms you'll encounter in healthcare technology agreements and compliance frameworks.
PHI (Protected Health Information)
Any individually identifiable health information transmitted or maintained by a covered entity or business associate. Includes 18 specific identifiers (name, DOB, SSN, medical record numbers, etc.) when linked to health data.
ePHI (Electronic PHI)
PHI that is created, stored, transmitted, or received electronically. This is what the HIPAA Security Rule primarily governs. For SaaS companies, virtually all PHI you handle is ePHI.
Covered Entity
A healthcare provider, health plan, or healthcare clearinghouse that transmits health information electronically. Your hospital and clinic customers are covered entities.
Business Associate
A person or entity that performs functions involving PHI on behalf of a covered entity. If your SaaS platform handles PHI for healthcare providers, you are a business associate.
BAA (Business Associate Agreement)
A contract required by HIPAA between a covered entity and a business associate. Establishes permitted uses of PHI, security requirements, breach notification obligations, and termination provisions.
DPA (Data Processing Agreement)
A contract required by GDPR (Art. 28) between a data controller and processor. Covers lawful basis for processing, data subject rights, sub-processor management, and cross-border transfer mechanisms. Separate from a BAA.
SaMD (Software as a Medical Device)
Software intended to be used for medical purposes without being part of a hardware device. FDA regulates SaMD based on the IMDRF framework with four risk categories (I-IV). Includes AI diagnostic tools and clinical decision support that doesn't qualify for exemption.
De-Identification
The process of removing identifying information from PHI so it no longer identifies an individual. Two HIPAA methods: Safe Harbor (remove all 18 identifiers) and Expert Determination (statistical certification by a qualified expert).
CMIA (Confidentiality of Medical Information Act)
California law (Civ. Code §56) governing medical information privacy. Often stricter than HIPAA: broader entity coverage, private right of action, and specific consent requirements. Applies to employers, contractors, and entities HIPAA doesn't reach.
Minimum Necessary Standard
HIPAA principle requiring that uses and disclosures of PHI be limited to the minimum amount necessary to accomplish the intended purpose. Your platform should be designed to access only the PHI fields your features actually require.
CDS (Clinical Decision Support)
Software that provides clinicians with knowledge and patient-specific information to enhance decision-making. May be exempt from FDA device regulation under 21st Century Cures Act §3060 if it meets four criteria (transparency, HCP review, etc.).
SOC 2 Type II
An audit report from an independent CPA firm verifying that your security controls are designed effectively (Type I) AND operating effectively over a period of time (Type II). Increasingly required by enterprise healthcare customers as a procurement prerequisite.
Related Resources
Deep-dive guides, NDA packs, and compliance tools for healthcare technology companies.
Healthcare SaaS legal work from BigLaw vs. boutique vs. my flat-fee model.
Document / Service
BigLaw $500-1,000/hr
Mid-Size Firm $350-600/hr
Terms.Law Flat Fee
Terms of Service
$8,000 – $15,000
$4,000 – $8,000
Included in package
Privacy Policy
$5,000 – $12,000
$3,000 – $6,000
Included in package
HIPAA BAA
$3,000 – $8,000
$2,000 – $4,000
Included in package
SaaS Agreement / MSA
$10,000 – $25,000
$5,000 – $12,000
Included in package
DPA (GDPR)
$5,000 – $10,000
$2,500 – $5,000
Included in package
Compliance Gap Memo
$8,000 – $20,000
$4,000 – $8,000
Included in package
Full Document Suite Total
$39,000 – $90,000
$20,500 – $43,000
$2,500 flat
90%+ savings
vs. BigLaw for the same document suite — with faster turnaround and healthcare-specific expertise
What Healthcare Tech Clients Say
★★★★★
"We needed a full legal suite before our Series A — ToS, BAA, MSA, privacy policy. Sergei delivered everything in under a week at a fraction of what our previous firm quoted. He actually understood our product."
M
CEO, Clinical AI Startup
Series A • San Francisco
★★★★★
"Our hospital clients kept redlining our BAA because it was a generic template. Sergei rewrote it with healthcare-specific provisions and we haven't had a single pushback since."
R
COO, EHR Integration Platform
Growth Stage • Austin
★★★★★
"The HIPAA compliance checklist alone saved us from two gaps our previous counsel missed. The document quiz helped us realize we needed a DPA we didn't know about."
K
CTO, Telehealth Platform
Seed Stage • Irvine
Attorney Services for Healthcare SaaS
Flat-fee packages for healthcare technology companies. No hourly billing surprises.
Document Review
$500 flat fee
Single contract, ToS, or agreement review with written markup and recommendations.
What legal documents does a healthcare SaaS company need?▼
At minimum: Terms of Service, Privacy Policy, HIPAA Business Associate Agreement (BAA), and a SaaS subscription agreement. If you integrate with hospital systems or handle PHI through APIs, you also need a Data Processing Agreement, API License Agreement, and Service Level Agreement.
Companies selling to enterprises typically need an MSA/SOW framework — the MSA covers the ongoing relationship, while individual SOWs define specific implementation projects or service scopes. I can generate drafts of all these documents using the generators above, then review and customize them for your specific product.
When is a HIPAA Business Associate Agreement required for SaaS?▼
A BAA is required whenever your SaaS platform creates, receives, maintains, or transmits protected health information (PHI) on behalf of a covered entity — that means hospitals, clinics, insurers, and their business associates.
This includes cloud hosting PHI, processing claims data, providing analytics on patient records, or offering any service that touches identifiable health data. Even if you only store encrypted PHI, you need a BAA. The only exception is if you can demonstrate your platform never touches PHI in any form, which is rare for healthcare SaaS.
How should AI healthcare products handle HIPAA compliance?▼
AI healthcare products face additional compliance layers beyond standard SaaS. Model training data must be de-identified per HIPAA Safe Harbor or Expert Determination methods. Inference outputs containing PHI require BAA coverage. And algorithmic decision-making in clinical contexts may trigger FDA software-as-medical-device (SaMD) considerations.
Your Terms of Service should clearly disclaim clinical decision-making authority and define the AI's role as a decision-support tool. I recommend explicit language that the platform does not provide medical advice, diagnosis, or treatment — even if the underlying model is capable of clinical reasoning.
What should healthcare SaaS Terms of Service include?▼
Beyond standard SaaS ToS provisions (subscription terms, payment, IP ownership, limitations of liability), healthcare-specific terms must address: HIPAA compliance obligations, PHI handling and de-identification policies, clinical disclaimer language, FDA regulatory status (if applicable), data retention and destruction policies, and breach notification procedures (within 60 days per HIPAA).
California-based companies should also address CMIA (Confidentiality of Medical Information Act) requirements, which in some cases are stricter than HIPAA. I incorporate both federal and California-specific provisions in every healthcare ToS I draft.
Do digital health startups need Data Processing Agreements?▼
Yes, if you process personal health data of EU residents (GDPR), UK residents (UK GDPR), or handle data subject to state privacy laws like CCPA/CPRA. A DPA is separate from a HIPAA BAA — you may need both.
The DPA covers general personal data processing obligations (lawful basis, data subject rights, cross-border transfers), while the BAA specifically addresses HIPAA-regulated PHI. Most healthcare SaaS companies operating nationally need both documents. My Healthcare SaaS Legal Package includes both.
What are the penalties for HIPAA violations by SaaS vendors?▼
HIPAA penalties for business associates (including SaaS vendors) range from $137 to $68,928 per violation, with annual maximums of $2,067,813 per violation category (2025 adjusted amounts). Willful neglect that is not corrected carries mandatory penalties.
The HHS Office for Civil Rights can also require corrective action plans and monitoring. Beyond federal penalties, state attorneys general can bring additional enforcement actions, and breach incidents often trigger class action litigation. For a SaaS company, a single breach affecting multiple covered entities can create cascading liability across all your BAA relationships.
Ready to Build Your Legal Foundation?
Book a free 30-minute consultation to discuss your healthcare SaaS legal needs.
