How to build a compliant healthcare software or startup
Every week, someone comes to us with a version of the same question: "I'm building something in healthcare — what do I need to be compliant?"
And every week, the answer starts the same way: it depends on what you're building.
Not all healthcare products carry the same compliance burden. A platform that connects patients to providers has different obligations than one that houses lab results. A network that shares clinical protocols digitally operates under different rules than an app that collects intake forms. The compliance path changes based on what your product does, what data it touches, and who's on the other end.
The mistake we see over and over is founders treating compliance as one monolithic thing — either ignoring it entirely or throwing $150K at certifications they don't need yet while missing the requirements that could actually shut them down.
This guide is organized by what you're actually building. Find your scenario. Understand what applies. Build accordingly.
Before Everything: The Two Questions That Determine Your Compliance Path
Before we get into scenarios, answer these honestly:
1. Does your product touch Protected Health Information (PHI)?
PHI includes any individually identifiable health information — names tied to diagnoses, treatment records, lab results, insurance information, appointment details, billing records, or any data that could identify a patient in connection with their health status or care. If your platform stores, processes, transmits, or even temporarily displays PHI, HIPAA applies to you. Full stop.
2. Does your product make clinical decisions — or help clinicians make them?
If your product independently diagnoses, recommends treatment, or makes clinical determinations without a clinician reviewing the output, you may be in FDA territory (Software as a Medical Device). If a clinician independently reviews and evaluates the product's output before acting, you're most likely a platform — not a device — and the FDA's January 2026 guidance generally keeps you outside device regulation. (Akin Gump)
Most of what follows assumes you answered yes to question 1 and no to question 2. You're building a healthcare platform, not a medical device. Here's what that means for compliance.
Scenario 1: You're Building a Network That Connects Patients to Providers
Examples: A marketplace matching patients to clinicians. A referral network. A platform connecting specialists across health systems. A telehealth routing platform.
What you need to worry about:
HIPAA is your foundation. The moment patient information flows through your platform — even if it's just a name, a condition, and a provider match — you're processing PHI. You need encryption in transit and at rest, role-based access controls, audit logging, and BAAs with every vendor in your stack. (Foley & Lardner)
Information blocking rules matter here. If your network involves exchanging electronic health information between providers, the ONC's information blocking regulations apply. HHS launched a broad enforcement initiative in 2025, shifting from education to active oversight. Your platform cannot create unnecessary friction in data exchange — and if it does, you could face enforcement action. Nearly 500 million health records have been exchanged through the federal TEFCA framework as of early 2026, and the expectation that health data flows freely between authorized parties is now regulatory reality. (Xtalks | Covington)
State telehealth licensing. If your platform routes patients to out-of-state providers, the providers on your network need proper licensure in the patient's state. This isn't your compliance burden directly, but if your platform facilitates unlicensed practice, you have exposure. Build licensure verification into your onboarding workflow.
If your network uses AI for matching or triage: State AI disclosure laws apply. Texas requires written disclosure when AI is used in connection with healthcare services. California restricts AI from implying it holds a healthcare license. If your algorithm recommends a provider or triages a patient's urgency, that's an AI-in-healthcare function under these laws. (Akerman LLP)
Your certification priority: SOC 2 first (enterprise buyers will require it), then HITRUST as you scale into health system contracts.
Scenario 2: You're Building a Platform That Houses Patient Data
Examples: A patient portal. An EHR-adjacent data layer. A chronic care management platform. A patient intake and records system. A data warehouse aggregating clinical information.
What you need to worry about:
This is the highest HIPAA exposure scenario. You're not just transmitting PHI — you're storing it. That means the full weight of the HIPAA Security Rule applies: encryption (AES-256 at rest, TLS 1.2+ in transit), multi-factor authentication, role-based access, comprehensive audit trails, workforce training, annual risk analysis, and a documented incident response plan.
The 2026 HIPAA Security Rule update is coming for you specifically. The proposed revision would make previously flexible security guidelines into mandatory, enforceable standards. All covered entities — regardless of size — must implement specific cybersecurity controls. Key requirements include mandatory MFA for all system access, mandatory encryption for all ePHI, network segmentation, comprehensive asset inventories (including AI systems), and access revocation within one hour of workforce termination. Finalization is expected by mid-2026 with a 180-day implementation window. (MedicalITG)
Healthcare ransomware is the context here. Ransomware attacks exposed over 276 million healthcare records in 2024 — a 64% increase from the prior year. The average U.S. healthcare data breach cost $10.22 million in 2025. If you're housing patient data, you are a target. Your security posture is not just a compliance requirement — it's an existential business risk. (Groovy Web)
Business Associate Agreements need real substance. Every vendor in your stack that touches PHI needs a BAA. But in 2026, a boilerplate BAA isn't sufficient. The proposed HIPAA updates require BAs to provide annual written compliance verification and 24-hour breach notification. Your vendor contracts need to reflect this. (Healthcare Law Insights)
Data rights and consent management. If you're aggregating data from multiple sources — provider systems, patient inputs, connected devices — you need clear data rights agreements and consent management. Patients increasingly have the right to access, correct, and request deletion of their data. Multiple states now have consumer privacy laws (Indiana, Kentucky, Rhode Island as of January 2026) that supplement HIPAA with additional rights around profiling and data portability. (Akerman LLP)
Your certification priority: HIPAA compliance from day one. SOC 2 Type II as soon as you're in production. HITRUST r2 as you pursue health system and payer contracts — this is the certification that says "we take data stewardship seriously at an institutional level."
Scenario 3: You Facilitate Medical Testing and Share Protocols Digitally
Examples: A lab ordering platform. A digital protocol-sharing system for clinical workflows. A platform distributing clinical guidelines or testing procedures across practices. A results delivery system.
What you need to worry about:
If you're transmitting lab results or diagnostic information, that's PHI. Full HIPAA applies. Lab results tied to patient identifiers are among the most sensitive categories of health information. Encryption, access controls, audit logging — all non-negotiable.
CLIA and state lab regulations may apply. If your platform is involved in the ordering, processing, or reporting of laboratory tests, the Clinical Laboratory Improvement Amendments (CLIA) regulatory framework comes into play. Even if you're not running the lab yourself, platforms that facilitate test ordering and results delivery need to understand how CLIA intersects with their workflow — particularly around result accuracy, authorized access, and reportable conditions.
Interoperability standards are regulatory requirements now. If your platform connects to EHR systems or exchanges clinical data, you need to align with current interoperability standards. The HTI-1 final rule requires USCDI Version 3 as the baseline data standard effective January 2026, and the CMS Interoperability and Prior Authorization Final Rule drives payer-side API obligations beginning in 2026. The HTI-5 proposed rule (December 2025) pushes further toward API-focused certification and third-party app integration. If your protocols or results need to flow into or out of certified EHR systems, standards compliance is not optional. (Covington)
Information blocking applies to you. If a provider using your platform can't easily share test results or clinical protocols with another provider or the patient, you may be creating an information blocking condition. HHS is actively enforcing this in 2026.
Clinical protocol content carries liability. If your platform distributes clinical protocols, guidelines, or decision trees, the content itself creates a liability layer. If a provider follows a protocol distributed through your platform and a patient is harmed, the question of who is responsible for the protocol's accuracy will arise. Have clear terms around protocol authorship, clinical validation, and liability allocation.
Your certification priority: HIPAA from day one. SOC 2 for enterprise sales. If you're exchanging data with health systems, interoperability standards alignment (FHIR, USCDI) is a practical prerequisite — not a certification, but a technical requirement that buyers will verify.
Scenario 4: You're Building a Patient-Facing App or Tool
Examples: A symptom checker. A patient engagement platform. A wellness app with health tracking. A mental health chatbot. A medication adherence tool.
What you need to worry about:
The "does this touch PHI" question is more nuanced here. If your app collects health information directly from patients and you're a HIPAA-covered entity or business associate, HIPAA applies. But many patient-facing apps are built by companies that are not covered entities — and HIPAA may not directly apply to them. In that case, the FTC's Health Breach Notification Rule fills the gap for non-HIPAA-covered health apps, and state consumer privacy laws apply. Either way, you have data protection obligations. (HIPAA Journal)
State AI laws hit patient-facing tools hardest. If your app uses AI in any patient interaction, you are squarely in the crosshairs of the 2025–2026 state AI wave:
California SB 243 (effective 1/1/26): Companion chatbots need self-harm prevention protocols, crisis referrals, and clear AI disclosure. Private right of action — $1,000 per violation plus attorney's fees.
California AB 489 (effective 1/1/26): AI cannot use language or design implying it holds a healthcare license.
Illinois (effective 8/1/25): AI cannot make independent therapeutic decisions or interact therapeutically with clients without licensed-professional oversight. If your mental health chatbot offers anything beyond administrative support, this law applies.
New York (effective 11/4/25): AI companion law with $15,000/day AG penalties.
Texas TRAIGA (effective 1/1/26): Written AI disclosure required for healthcare services.
(Nixon Law Group | Manatt Health)
The Sharp HealthCare lawsuit is relevant even if you're not recording visits. The core legal theory — that AI tools processing patient information without proper consent create liability — extends beyond ambient scribes. If your patient-facing tool collects, processes, or shares health information using AI, and the patient doesn't understand that or hasn't meaningfully consented, you have exposure. (Fisher Phillips)
If your app involves wellness claims, the FDA's 2026 general wellness guidance matters. Noninvasive apps that track fitness metrics, sleep, or activity can qualify as general wellness products — provided they avoid disease, diagnostic, or clinical management claims. The moment your marketing implies clinical capability, you've crossed into potential device territory. (Faegre Drinker)
Your certification priority: SOC 2 for credibility with partners and app stores. HIPAA if you're a covered entity or BA. State AI compliance built into the product from day one — this is a design requirement, not a legal afterthought.
The Universal Compliance Checklist (Regardless of Scenario)
No matter what you're building, if it operates in healthcare, these apply:
☐ Map your data flows. Know exactly what data your product collects, where it goes, who can access it, and how long it's retained. You cannot be compliant with anything if you don't know where your data lives.
☐ Determine your HIPAA status. Are you a covered entity, a business associate, or neither? This determines which rules apply directly to you.
☐ Execute BAAs with every vendor that touches health data. Cloud providers, analytics platforms, AI vendors, email services — all of them. No BAA, no PHI access.
☐ Encrypt everything. AES-256 at rest. TLS 1.2+ in transit. This is non-negotiable in 2026.
☐ Implement access controls and MFA. Role-based access. Multi-factor authentication. Session timeouts. Access revocation procedures.
☐ Conduct an annual risk analysis. Document it. This is the single most cited HIPAA violation in enforcement actions.
☐ Build a deletion workflow. If a patient requests their data be deleted, can you execute that across all systems — including vendor systems — with a documented timeline?
☐ Map your state obligations. Identify every state where your users or patients are located. Determine which state AI, privacy, and healthcare laws apply.
☐ Build disclosure and consent into the product. Not as a legal add-on. As a product feature. Configurable by state.
☐ Get your certifications in the right order. HIPAA infrastructure first. SOC 2 Type I to get into procurement conversations. SOC 2 Type II to close enterprise deals. HITRUST when you're selling into health systems.
The Cost of Getting This Wrong vs. Getting It Right
Getting it wrong looks like this: you build for 12 months, spend $200K–$500K, and then a health system prospect asks for your SOC 2 report and you don't have one. Or a state AG's office sends a letter about AI disclosure requirements you didn't know existed. Or your data architecture can't satisfy the HIPAA risk analysis because you didn't design with PHI flows in mind. Now you're rebuilding.
Getting it right looks like this: you spend a few weeks mapping your compliance landscape before you build. You design data flows, consent workflows, and access controls into the architecture from day one. You pursue certifications in the right order. And when the enterprise buyer asks whether you're compliant, you hand them the documentation instead of asking for six months to get ready.
The delta between those two paths is hundreds of thousands of dollars in wasted development, stalled deals, and regulatory rework.
How We Help
Camino Strategy Group works with health tech founders, clinician-entrepreneurs, and healthcare organizations to get the compliance architecture right before it gets expensive to fix.
We sit between you and the regulatory landscape and tell you, in plain language, what applies to your specific product, in what order, and what you can defer versus what you need now.
What that looks like:
Compliance readiness assessments — we tell you exactly where your gaps are before a buyer or a regulator finds them
HIPAA infrastructure design — data flow mapping, BAA strategy, risk analysis frameworks, vendor governance
SOC 2 and HITRUST roadmapping — which certifications you need, in what sequence, and how to get there without overspending
State AI and privacy law mapping — which laws apply based on where your users are, and what product-level changes you need
Interoperability and data sharing compliance — information blocking, TEFCA alignment, FHIR/USCDI readiness
Multi-state telehealth compliance for clinician-led practices and MSO–PC structures
We help companies save hundreds of thousands of dollars in wasted development, blown timelines, and deals that die in procurement — by making sure the compliance questions get answered before the engineering starts, not after.
If you're building in healthcare and you're not sure what compliance actually looks like for your specific product, that's the exact conversation we have.
Sources
Akin Gump: FDA Digital Health Guidance Updates, January 2026
Healthcare Law Insights: Top 2025 Privacy and Security Issues
Fisher Phillips: Class Action Targets Healthcare AI Recordings
Xtalks: Healthcare Regulations 2026 — Data Sharing and Privacy
KFF: Efforts to Advance Electronic Health Information Sharing
