The 2026 US Founder's Guide to Building a Regulated Healthcare Product From India

In April 2021, I got a message at 11:30 PM IST from a Boston-based digital health founder, Series A, $9M raised, building a chronic care platform for Medicaid populations. She had been working with a self-described “HIPAA-compliant development agency” for seven months.

Her board meeting was six weeks out. Her CTO had just quit. And her compliance attorney had sent a three-page memo explaining that the AWS S3 buckets storing patient encounter notes were sitting outside any Business Associate Agreement.

She wasn’t naive. She had asked her previous agency in writing whether the product was HIPAA-compliant. They said yes.

What nobody told her: HIPAA compliance is not a certification. There is no badge from HHS. No government approval letter you frame on the wall. HIPAA compliance is a continuous operating posture, it lives in your architecture, your vendor contracts (45 CFR §164.308 requires written agreements with every Business Associate), your audit logs, your incident response runbook, and your team’s daily behavior.

Her vendor built a working product. They never built a compliant one.

Her board meeting was pushed eight weeks. The S3 migration, audit log backfill, and BAA renegotiation with AWS cost her $67,000 and eleven weeks.

I’ve been on 2,000+ calls with US founders since 2014. That story is not unusual. It’s not even particularly bad. I’ve seen a mental health platform serving 14 states discover, on the week of their payer contract signature, that their therapist session notes were stored in a database with no encryption at rest, violating §164.312(a)(2)(iv). Three-month delay. Lost the payer contract. Never recovered it.

This guide exists because I’m tired of watching US healthcare founders pay that tax twice.

Eight Questions US Healthcare Founders Ask Us First

• Can an Indian agency actually build a HIPAA-compliant product?

Yes, if they treat HIPAA compliance as architecture, not a feature toggle. EngineerBabu has shipped 140+ HIPAA-aware products for US healthcare founders since 2020. That means: ePHI data classification before any schema design, BAA coverage for every sub-processor in the stack, AES-256 encryption at rest, TLS 1.2+ in transit, immutable audit logs retained 6+ years per the HIPAA Security Rule (45 CFR §164.312), and a signed BAA with you on Day 1 of the engagement.

• What does a HIPAA-compliant healthcare build actually cost in 2026?

A HIPAA-ready Lean MVP, designed to minimize ePHI scope and get you to first patient interaction fast, runs $75K–$135K over 12–16 weeks. A full HIPAA + SOC 2-track healthcare MVP runs $140K–$260K over 16–24 weeks. These numbers come from our 2026 EB Healthcare Build Report (n=140 US healthcare products shipped since 2020). Not included in either number: your SOC 2 Type II audit ($45K–$95K plus tooling at $12K–$36K/year with Vanta, Drata, or Secureframe), penetration testing ($8K–$22K), or your legal counsel fees.

• Can you sign a BAA?

Yes. We sign BAAs governed by Delaware law. We maintain active HIPAA BAAs with AWS for HIPAA-eligible services and with GCP under the covered service list. Every sub-processor that touches ePHI in your product: Twilio, SendGrid, your LLM provider, carries a BAA. We give you the full sub-processor registry on Day 1 of handover.

• What’s the time zone reality?

IST is 10.5 hours ahead of PST, 9.5 ahead of EST. Our standard US-overlap window is 7:30–10:30 AM PST daily. For Series A+ founders who need more real-time coverage, we staff a US-based client lead in your timezone. That adds $4K–$7K/month. We say that upfront, not in month three.

• Do your engineers understand FHIR and HL7?

Yes, with a caveat. Understanding the FHIR R4 spec and building a production-grade FHIR integration for Epic’s SMART on FHIR sandbox are two different things. We have engineers with live Epic, Cerner, and Athenahealth integrations in production. We tell you which ones on the discovery call, not after you’ve signed.

• What happens if there’s a breach?

Every engagement includes an incident response runbook delivered at handover. HIPAA’s Breach Notification Rule (45 CFR §164.400) requires notification to affected individuals within 60 days. We build breach detection into the audit log architecture, not as an afterthought. We’re not your CISO. But we build products that make your CISO’s job possible.

• Can you work with OpenAI or Anthropic on a clinical product?

OpenAI and Anthropic both offer BAAs, but availability, scope, and which services are covered changes. As of 2026, OpenAI’s BAA covers the API under an Enterprise agreement. Anthropic’s BAA coverage requires direct enterprise negotiation. For clinical products where you can’t risk an uncovered LLM call touching ePHI, we default to AWS Bedrock (which falls under the AWS BAA) or Azure OpenAI with HIPAA mode enabled. We walk you through this choice in Week 1 of discovery, not Week 8 of build.

• What’s the honest failure mode of working with an Indian agency on a healthcare product?

Time zone friction on compliance-critical decisions, engineers who understand the HIPAA Security Rule in theory but haven’t worked through a real OCR audit scenario, and, most commonly, an agency that treats compliance as a delivery checklist rather than a product design constraint. I’ll say more about this in section 13.

Is Your Product Actually a HIPAA-Regulated Build?

Before we talk about what we build and how, you need to know whether HIPAA actually applies to your product, because the answer is not always obvious, and getting it wrong costs more than getting it right from Day 1.

The 12-question founder readiness audit:

1. Does your product create, receive, maintain, or transmit Protected Health Information (PHI) on behalf of a Covered Entity (a hospital, clinic, insurer, or healthcare clearinghouse)? If yes, you are likely a Business Associate under 45 CFR §160.103. You need a BAA before you touch a single byte of real patient data.

2. Does your product store patient encounter notes, diagnoses, lab results, prescription history, or any individually identifiable health information? If yes, ePHI is in scope. Encryption at rest (AES-256) and in transit (TLS 1.2+) are not optional; they are required under §164.312.

3. Are you a direct-to-consumer wellness app that never touches clinical data, only self-reported mood logs, steps, or sleep? Then you may be outside HIPAA’s scope entirely. FTC’s Health Breach Notification Rule may still apply. This is a legal question. Spend $500 on a healthcare attorney’s hour before you spend $200K on a build.

4. Does your product handle substance use disorder treatment records? If yes, 42 CFR Part 2 applies on top of HIPAA, with stricter consent requirements for disclosure. Most agencies miss this entirely.

5. Does your product involve clinical decision support that meets the FDA’s definition of Software as a Medical Device (SaMD) under the 21st Century Cures Act? If yes, you have an FDA regulatory pathway question that lives upstream of your engineering decisions.

6. Do you have a signed BAA with your cloud provider (AWS, GCP, Azure) for the specific services you intend to use? Not your account generally, the specific services. Not all AWS services are HIPAA-eligible. The list is at aws.amazon.com/compliance/hipaa-eligible-services-reference. If your previous agency used Lambda functions or S3 buckets that aren’t on that list without a corresponding BAA, you have a problem.

7. Have you identified which US states your product will operate in and confirmed the telehealth licensure requirements for each? The Interstate Medical Licensure Compact (IMLC) covers 40+ states for physicians. PSYPACT covers psychologists across 42 states. But not every provider type is covered by a compact, and not every state has joined.

8. Do you have a documented risk analysis and risk management process? §164.308(a)(1) makes this mandatory. Not optional. Not “we’ll do it before Series B.” Mandatory before you go live with real patient data.

9. Have you identified all the vendors in your product stack who will touch ePHI, your EHR integration partner, your video platform (if telehealth), your analytics tool, your email provider, and confirmed each has a BAA?

10. Are you building for payer or health system enterprise sales? If yes, SOC 2 Type II is the floor. HITRUST CSF certification is the ceiling many large payers and health systems require. Build for SOC 2 from Day 1; it takes 6–12 months minimum.

11. What is your incident response plan for a data breach? HIPAA requires notification to affected individuals within 60 days of discovery of a breach under §164.412. If the answer is “we’ll figure it out,” that’s a gap, and a liability.

12. What is your board’s timeline? If you have a board meeting or fundraise in 12 weeks and you don’t yet have a HIPAA-compliant architecture, you are behind. Not catastrophically, but you need to start the compliance mapping in Week 1 of discovery, not in QA.

EB Index 2026: Across 140 US healthcare products we’ve shipped since 2020, the median time from BAA signed to first ePHI write in production was 11 days. The MVPs that hit launch on time had one shared trait: HIPAA mapping happened in Week 1 of discovery, not Week 1 of QA.

Why US Healthcare Founders Choose India, And What They Get Wrong

The honest reason US healthcare founders come to EngineerBabu is economics. A senior full-stack engineer with FHIR experience in Boston costs $180K–$240K/year in salary alone.

The same engineer in Indore, on our team, trained on HIPAA Security Rule architecture, FHIR integration patterns, and US healthcare UX standards, costs you $22K–$38K/month for a full dedicated pod, not per engineer, for the team.

That’s real. That math works. That’s why 140 US healthcare founders have shipped with us.

But here’s what founders consistently get wrong about working with an Indian engineering partner:

• Wrong assumption #1: “HIPAA is just a compliance layer we add at the end.”

No US healthcare founder would say this out loud. But their vendor selection behavior says it constantly. They hire for engineering speed, then ask about HIPAA in month three. HIPAA is not a layer. It is a constraint that shapes every data model, every API contract, every third-party integration decision. The founders who ship on time treat it as a product design constraint from Day 1.

• Wrong assumption #2: “Any good engineer can figure out FHIR.”

FHIR R4 is a specification. Epic’s SMART on FHIR implementation of that specification, with its specific OAuth 2.0 scopes, its sandbox quirks, its production launch review process, and its requirements for app certification, that is a different thing. We have engineers who have been through Epic’s App Orchard process in production. We have engineers who have read the FHIR spec but never shipped a live Epic integration. We tell you which is which on the discovery call.

• Wrong assumption #3: “The time zone gap is manageable.”

It is manageable, with structure. Our US-overlap window (7:30–10:30 AM PST) covers three hours of synchronous work daily. For most product decisions, that’s enough. For compliance-critical decisions, like an architecture review that surfaces an ePHI handling question, or a BAA negotiation that needs your attorney and our team in the same conversation, three hours can feel very thin. We build async escalation protocols into every engagement for exactly this reason.

• Wrong assumption #4: “We can skip SOC 2 until we have enterprise customers.”

The moment you start talking to a health system, a large payer, or a Series A investor who has done healthcare deals before, SOC 2 Type II comes up. Not as a nice-to-have. As a procurement gate. We build SOC 2 readiness into the architecture from Day 1, not because it’s cheap, but because retrofitting it into a product that wasn’t designed for it costs 3–4× more than building it in.

From a US founder call: “I spent $180K with an agency that built a technically beautiful product. When I got to my first enterprise demo, the hospital’s procurement team asked for our SOC 2 Type II report. We didn’t have one. We didn’t even have the policies in place to start the audit clock. That was eight months and $95K ago.”, Series A telehealth founder, Atlanta.

Red flag: Any agency that tells you SOC 2 is “something we handle after launch” has never actually worked with a US healthcare enterprise buyer. Walk away.

The Three Engagement Models for US Healthcare Products

We run three models for US healthcare founders. Here’s the honest matrix:

• Model 1: Fixed-Scope HIPAA-Ready MVP

What it is: A time-boxed, fixed-price engagement to ship a HIPAA-compliant app with defined scope. Discovery → compliance mapping → build → QA → handover. One team, one sprint, one deliverable.

Best for: Pre-seed to Seed founders with $75K–$180K in product budget, a defined core use case, and a clear launch goal (first 100 patients, first pilot site, fundraise demo).

Cost range: $75K–$180K depending on ePHI scope, integrations (EHR, video, lab), and AI features.

Timeline: 12–20 weeks.

Compliance ownership: We deliver the HIPAA risk assessment, system security plan, data flow diagrams, and BAA registry. You own ongoing compliance operations post-launch. We recommend you hire a part-time fractional CISO or use a compliance automation platform (Vanta, Drata) from month one of launch.

Honest limitation: Fixed scope means fixed scope. Every FHIR integration you add mid-sprint, every new ePHI data type you decide to store, every additional state’s telehealth requirement you discover, these are change orders. We price them transparently and in advance. We are not a scope-creep-friendly model. Founders who know what they’re building do very well here. Founders who are still figuring it out mid-build struggle.

• Model 2: Dedicated Pod with Embedded Compliance Lead

What it is: A dedicated 4–8 person product engineering pod, PM, tech lead, 2–3 engineers, QA, and a HIPAA compliance lead embedded in the team, on a monthly retainer. You drive product direction. We execute.

Best for: Series A founders post-MVP who are scaling features, adding EHR integrations, expanding to new states, or moving toward SOC 2 Type II audit readiness.

Cost range: $22K–$38K/month depending on pod size and compliance lead seniority.

Timeline: Minimum 6-month commitment. We’ve had healthcare founders on this model for 3+ years.

Compliance ownership: Our embedded compliance lead owns the risk register, the vendor sub-processor list, the incident response runbook, and the SOC 2 readiness checklist on an ongoing basis. This is the closest thing to having an internal compliance team without the $300K/year hiring cost.

Honest limitation: You need a strong product manager on your side, either internal or our embedded PM. The pod is only as good as the product direction it receives. Founders who are still in discovery mode burn through the first two months of a pod engagement without meaningful output.

• Model 3: Tech Co-Founder Engagement

What it is: For non-technical healthcare founders, clinicians, operators, former payer executives, who need not just engineering but technical leadership and architecture ownership. We act as your CTO and engineering team simultaneously.

Best for: Pre-seed clinical founders who have deep domain knowledge (a physician building an RPM tool, a hospital administrator building a prior auth automation product) but no technical co-founder.

Cost range: $18K–$28K/month (smaller team, but higher strategic involvement from our side).

Timeline: 6–18 months, until you’re ready to hire your first in-house CTO.

Compliance ownership: We own it end to end. Architecture decisions, vendor selection, BAA negotiations, HIPAA risk assessments, all of it. We recommend your first in-house compliance hire at the point where you’re approaching 10,000+ active patients or entering enterprise payer contracts.

Honest limitation: This only works if you trust us with technical decisions. Founders who want to make every stack choice but don’t have the technical background to evaluate trade-offs create friction that slows the product and frustrates the team. The right frame is: you own clinical and business decisions, we own technical and compliance decisions, and we check in at every meaningful intersection.

The Real Cost Stack: What No One Tells You Upfront 

US healthcare founders consistently underestimate the total cost of a regulated build. Not because they’re bad at math, because their vendors only quote the engineering line item. Here is the full picture.

The engineering line (what you pay us):

• HIPAA-ready Lean MVP: $75K–$135K
• Full HIPAA + SOC 2-track MVP: $140K–$260K
• AI-native clinical product MVP: $130K–$290K
• Dedicated pod post-MVP: $22K–$38K/month

The compliance infrastructure line (what you pay, not us):

• SOC 2 Type II audit: $45K–$95K depending on auditor and scope (A-LIGN, Schellman, and Prescient Assurance are the auditors we’ve worked alongside most often for healthcare clients)
• SOC 2 compliance tooling: $12K–$36K/year (Vanta, Drata, or Secureframe, we recommend Vanta for most early-stage healthcare founders)
• HITRUST CSF assessment (if payer enterprise sales required): $80K–$150K
• Penetration testing: $8K–$22K (required for most SOC 2 audits and all enterprise payer procurement processes)

The legal line (what you pay your attorney):

• Healthcare attorney review of BA$3K–$8K
• State telehealth licensure legal review: $5K–$15K depending on number of states
• Privacy policy and terms of service for a HIPAA-covered product: $4K–$10K
• HIPAA-specific DPA drafting for enterprise customers: $2K–$6K per contract

The silent taxes:

• EHR sandbox access fees (Epic App Orchard): $5K–$25K/year
• Video infrastructure with HIPAA BAA (Daily.co, Vonage, Twilio Video under BAA): $0.5K–$3K/month depending on volume
• Cloud infrastructure for HIPAA-eligible services only: 20–35% more expensive than equivalent non-HIPAA infrastructure due to logging requirements, encryption overhead, and eligible service constraints
• Fractional CISO post-launch: $4K–$10K/month until you hire in-house

EB Index 2026: The median total first-year cost for a US healthcare MVP, engineering + compliance infrastructure + legal + cloud, was $287,000. The median engineering line item was $142,000. Founders who budget only for engineering are 50–60% short before their first enterprise demo.

What we’d cut: If you’re pre-seed with under $2M raised and a consumer health use case that can be designed to minimize ePHI scope (think: a wellness app that refers out to providers rather than storing clinical data), the HIPAA surface area shrinks dramatically. Design the ePHI scope out of your MVP. Ship to your first 500 users. Raise. Then build the full clinical data layer. We’ve helped 22 founders do exactly this.

Compliance trap: Founders who use AWS without specifically checking the HIPAA Eligible Services list at aws.amazon.com/compliance/hipaa-eligible-services-reference/ end up with ePHI on services not covered by the AWS BAA. The most common offenders: Amazon Rekognition (image analysis), Amazon Comprehend Medical (often used for clinical NLP), and certain Lambda configurations. Check the list before you architect. Then check it again before you go live.

The Compliance-First Discovery Loop

The single biggest difference between our healthcare builds that launch on time and the ones that don’t is where compliance enters the conversation.

Agencies that bolt compliance on at the end treat discovery as a product conversation, user flows, wireframes, feature lists, and treat HIPAA as something the QA team handles in the final sprint. This always fails.

It fails because an ePHI handling gap discovered in QA is a rebuild, not a fix. It fails because a data flow that wasn’t mapped for minimum necessary access (§164.502(b)) requires schema changes that cascade through the entire product. It fails because an audit log that wasn’t designed from Day 1 can’t be retrofitted without downtime.

Here’s how we run discovery for every US healthcare product:

• Week 1, Day 1–3: Jobs-to-be-Done and User Flows Before a single wireframe is drawn: who is the primary user, what job are they hiring this product to do, what data does the product need to do that job, and is any of that data PHI?
• Week 1, Day 3–5: ePHI Data Classification We map every data element the product needs to create, receive, maintain, or transmit. We classify each one: is it PHI? Is it ePHI? Is it de-identified under the Safe Harbor method (§164.514(b)) or the Expert Determination method? Can we design the MVP to not touch ePHI at all in the first version?
• Week 1, Day 5: HIPAA Scoping Decision Based on the data classification, we make an explicit decision: what is the HIPAA surface area of this product? Where does ePHI live? Where does it move? Who has access? This scoping decision drives every architecture choice that follows.
• Week 2: BAA Mapping and Vendor Selection We identify every third-party service the product will use, cloud infrastructure, video, email, analytics, LLM, and confirm BAA availability for each. For any service where a BAA is not available and the service will touch ePHI, we find an alternative. This week is also when we co-sign the BAA with you, the founder.
• Week 2–3: Mid-Fidelity Prototype and User Test Only after the compliance scoping is done do we move to mid-fidelity wireframes. Every user flow is annotated with the ePHI it touches, the access control required, and the audit log event it triggers.
• Week 3–4: Architecture Review and Security Design Data model, API development, encryption strategy, audit log schema, access control model (RBAC minimum, ABAC where needed), emergency access (“break glass”) protocol, and the backup and disaster recovery plan.

From a US founder call: “I came to Mayank after two previous agencies. Both of them told me about HIPAA in the first call and never mentioned it again until I asked. Mayank’s team was showing me the data flow diagram with ePHI annotated on Day 5 of discovery. That was the first time I felt like my compliance risk was actually being managed.”, Seed-stage RPM founder, Seattle.

Red flag: Any discovery engagement that produces wireframes and a feature list in week one without a data classification map is not a HIPAA-compliant discovery process. It is a general product discovery process with “HIPAA-compliant” in the pitch deck.

The 11–14 Week HIPAA-Ready MVP Sprint

This is our standard timeline for a Lean HIPAA-Ready MVP, designed to minimize ePHI scope and hit a first-patient-interaction milestone.

• Weeks 1–2: Discovery and Compliance Scoping

ePHI data classification, BAA mapping, vendor selection, architecture decision record, HIPAA risk assessment draft, BAA signed. The engineering team does not write a line of production code in these two weeks. That is intentional.

• Week 2: BAA Signed

We sign the BAA in Week 2. Not Week 6. Not “before launch.” Week 2. If a founder pushes back on this timeline, that is a signal that they don’t yet understand why the BAA can’t wait.

• Weeks 3–4: Architecture and Environment Setup

HIPAA-eligible infrastructure provisioned (AWS or GCP). VPC configuration. Encryption at rest enabled on every data store. TLS 1.2+ enforced at every network boundary. Audit log infrastructure set up, append-only, tamper-evident, retained 6+ years. CI/CD pipeline with security scanning (SAST via Semgrep or Snyk). Role-based access control framework implemented.

• Weeks 5–9: Core Feature Build

Feature build against the scoped product. Every pull request is reviewed against the data classification map, any new ePHI data element requires an explicit compliance review before merge. The audit log records every ePHI access, modification, and deletion event.

• Week 10: Internal QA + Compliance Review

Full test coverage for ePHI flows. Security regression testing. HIPAA risk assessment updated to reflect the as-built product. Any gaps against the risk assessment are triaged and resolved before the penetration test.

• Week 11: Penetration Testing

We recommend engaging a third-party pen-testing firm (not our internal team) for this step, it costs $8K–$22K and takes 1–2 weeks. The pen test report becomes part of your SOC 2 audit evidence package and your enterprise sales compliance folder. We pause the deployment to production until the pen test is complete and critical findings are remediated.

• Week 12: UAT and Clinical User Testing

User acceptance testing with real clinicians or patients (under appropriate consent frameworks). This is also when we validate that the product UX handles edge cases specific to regulated healthcare contexts, session timeouts that protect ePHI, minimum necessary access in the UI, patient consent flows that meet state-specific requirements.

• Week 13: SOC 2 Readiness Review

For founders on the SOC 2 track: we engage your compliance automation platform (Vanta, Drata) to begin the audit readiness assessment. The SOC 2 audit clock doesn’t start until you have 6 months of operational evidence. We start the clock here, not post-launch. This is a parallel workstream, not a sequential one.

• Week 14: Handover and Launch

Handover pack delivered: HIPAA risk assessment (final), system security plan, data flow diagrams with ePHI annotated, audit log specifications, incident response runbook, BAA registry (every sub-processor), vendor sub-processor list, penetration test report. Source code delivered to your repository. Infrastructure access transferred. Launch.

Compliance trap: Founders who push to skip the Week 11 penetration test to hit a board date are making a $15K saving that creates a $150K liability. If an OCR audit surfaces a vulnerability post-launch that a pen test would have caught, the lack of a pen test report is itself evidence of insufficient safeguards under §164.308(a)(1). Do the pen test.

Tech Stack Decisions for US Healthcare Products

Every stack decision in a HIPAA-regulated product starts with one question: where does ePHI live, and who can touch it?

• Frontend:

React (web), React Native or Flutter (mobile). For clinical products, EHR-adjacent tools, clinical scribes, RPM dashboards, React with a strong TypeScript foundation and server-side rendering via Next.js. Session management with automatic logout after 15 minutes of inactivity is a HIPAA requirement under §164.312(a)(2)(iii), not a nice-to-have.

• Backend:

Node.js/NestJS for API-first products with high concurrency (telehealth platforms, patient portals), Python/FastAPI for AI-native clinical products (clinical scribes, decision support, NLP pipelines). Go for high-throughput data pipelines where ePHI volume is large and latency matters (RPM data ingestion).

• Database:

PostgreSQL as the primary ePHI store, mature, well-understood encryption options, strong audit log support. Redis for session management (never for ePHI at rest). We avoid NoSQL databases for primary ePHI storage unless there is a specific clinical data model reason, the schema flexibility that makes NoSQL appealing also makes consistent access control and audit logging harder to implement correctly.

• Cloud:

AWS with HIPAA-eligible services only (confirmed against the published eligible services list before any architecture decision). For products with Google Workspace or Google Health integrations, GCP under the BAA-covered service list. Azure with HIPAA mode for Microsoft-ecosystem products or products requiring Azure OpenAI.

• FHIR Layer:

HAPI FHIR server for products that need to expose or consume FHIR R4 resources. Smile CDR for larger health system integrations. Firely SDK for .NET environments. We do not build our own FHIR implementations, the specification is complex enough that rolling your own is a reliability and compliance risk.

• Video (telehealth):

Daily.co (BAA available), Vonage Video API (BAA available), Twilio Video under the Twilio BAA. We do not recommend consumer video platforms, Zoom, Google Meet, Teams, for PHI-containing clinical sessions unless the specific HIPAA BAA configuration has been confirmed with legal counsel. The free tiers of these platforms are not covered.

• Audit Logging:

Immutable, append-only audit logs in a separate data store from the application database. We use AWS CloudTrail + CloudWatch Logs with log integrity validation enabled for infrastructure-level audit events. Application-level ePHI audit events (who accessed what patient record, when, from what IP) go into a dedicated audit log table with a write-only service account, no application process can delete or modify audit log entries.

What we’d cut: For a HIPAA-ready Lean MVP designed to get to first-patient interaction, we aggressively scope out any ePHI data element that isn’t strictly necessary for the core use case. A telehealth MVP does not need to store the patient’s full medication history to enable the first video visit. Store what you need. Define what you need explicitly. Store nothing else. Minimum necessary access (§164.502(b)) is a legal requirement, but it also makes the build faster, cheaper, and safer.

AI-Native Clinical Builds in 2026

The most common AI use cases we’re building for US healthcare founders in 2026:

Clinical AI scribes, LLM-based ambient documentation that listens to a patient encounter and generates a structured clinical note in the provider’s EHR. The ePHI risk surface here is significant: audio of a patient encounter is PHI. The transcript is PHI. The generated note is PHI. Every step of the pipeline needs BAA coverage, encryption in transit, and a retention and deletion policy.

AI-assisted clinical decision support, Rule-based or LLM-assisted systems that surface relevant clinical information, flag potential drug interactions, or suggest diagnostic considerations. The FDA’s clinical decision support guidance under the 21st Century Cures Act determines whether your CDS tool is exempt from FDA regulation or classified as a SaMD. Get this classification question answered by a regulatory attorney before you build, not after.

Patient-facing AI, Symptom checkers, medication adherence chatbots, mental health support tools. These carry the highest clinical risk profile because the end user is a patient, not a clinician. The UX must include explicit “I am not a doctor” framing, escalation paths to human providers, and crisis intervention flows for mental health products (suicide and self-harm screening is not optional for a mental health AI product serving US consumers).

The LLM selection decision tree for clinical products:

Does the LLM call touch ePHI? If no, use whatever performs best for your use case. If yes, the options in 2026 are:

• AWS Bedrock, Covered under the standard AWS BAA. Claude (Anthropic), Llama, Mistral, and others available. Our default recommendation for most clinical AI builds because the BAA situation is unambiguous and the service is in the HIPAA-eligible list.
• Azure OpenAI with HIPAA mode, Strong option for GPT-4 class models where Azure’s enterprise compliance posture aligns with your stack. Requires Azure enterprise agreement with HIPAA configuration confirmed.
• OpenAI API with Enterprise BAA, Available as of 2026 under an OpenAI Enterprise agreement. Review the BAA scope carefully with your healthcare attorney, what services and data uses are covered matters.
• Self-hosted open-source models (Llama, Mistral, Mixtral), Maximum privacy control, no BAA dependency, but significant infrastructure overhead. We recommend this only for products where the sensitivity of the clinical data makes any cloud LLM a non-starter with your legal team or your enterprise customers.

Hallucination guardrails for clinical AI: Every clinical AI output in a product we build includes: source citation (what clinical data or guideline does this response reference), confidence framing (“Based on the information available, a possible consideration is…”, not “You have [diagnosis]”), a human-in-the-loop escalation path, and an explicit “This is not medical advice and does not replace clinical judgment” disclaimer surfaced in the UI, not buried in the terms of service.

From a US founder call: “We launched a clinical decision support tool without a hallucination guardrail that flagged when the model’s response had no grounded citation. In month two, a physician flagged a response that confidently cited a drug dosing guideline that didn’t exist. We caught it before harm, but the near-miss cost us the first enterprise pilot.”, Series A clinical AI founder, NYC.

Compliance trap: Building a clinical AI scribe that stores audio recordings of patient encounters without a documented retention and deletion policy violates HIPAA minimum necessary requirements. Under §164.502(b), you may only use and disclose PHI to the minimum extent necessary to accomplish the intended purpose. Define your audio retention policy before you build the storage layer.

The Contract & IP Stack for US Healthcare Founders 

This is the section most Indian agencies skip. I’m going to give it to you straight.

• Master Services Agreement (MSA):

Governed by Delaware law. Dispute resolution by AAA or JAMS arbitration in Delaware, not Indian courts, not Indian arbitration. US healthcare founders need to be able to enforce their contracts in a US jurisdiction without a 3-year international legal process. Every EngineerBabu MSA with a US client is Delaware-governed.

• Business Associate Agreement (BAA):

Signed in Week 2 of every healthcare engagement, before any ePHI is shared or processed. The BAA specifies: permitted uses and disclosures of PHI, safeguards we implement, breach notification obligations (we notify you within 24 hours of discovering a suspected breach, well inside the HIPAA 60-day window to give you time to notify affected individuals), and sub-processor obligations.

• IP Assignment on Creation:

All intellectual property, code, architecture documents, design assets, data models, are assigned to you on creation, not on final payment. You own the work as it is built. We don’t hold IP hostage to payment disputes. This is in the MSA. Read it before you sign.

• Source Code and Infrastructure Access from Day 1:

You have access to the source code repository and the cloud infrastructure from Day 1 of the engagement. Not at handover. Day 1. If an agency tells you they’ll give you access to the repo “when the project is complete,” walk away. That is a leverage mechanism, not a delivery model.

• Statement of Work (SOW):

Every feature, every compliance deliverable, every handover artifact is listed in the SOW. If it’s not in the SOW, it’s not in scope. We are explicit about this because scope clarity is the single biggest predictor of a healthy engagement. Founders who sign vague SOWs get vague products.

The EB Handover Protocol: Every regulated healthcare engagement ends with this package: HIPAA risk assessment (final, as-built), system security plan, data flow diagrams with ePHI annotated, audit log specifications, incident response runbook, BAA registry (every sub-processor with BAA status), vendor sub-processor list, penetration test report, SOC 2 readiness summary. Delivered in Week 14 (or final sprint week). Not promised. Delivered.

Red flag: Any agency that does not offer a BAA, or that offers a BAA “once we’ve confirmed the scope,” is not structured to be a Business Associate under HIPAA. They are either ignorant of their obligations or deliberately deferring them. Either way: walk away.

Post-Launch: SOC 2, Scaling, and Graduating to In-House 

Launch is not the finish line for a regulated healthcare product. It is the start of the compliance operations phase.

The 6-month post-launch playbook:

• Month 1: Compliance automation platform live (Vanta, Drata, or Secureframe). Policies written and signed by your leadership. SOC 2 Type II audit clock started, the observation period begins now. You need at least 6 months of evidence before an auditor can issue a Type II report.
• Month 2–3: First internal access review (quarterly cadence). Audit log review. Vendor sub-processor list reviewed and updated. Any new third-party service that touches ePHI gets a BAA before it goes live, not after. Penetration test finding remediations verified.
• Month 4: SOC 2 readiness assessment with your compliance automation platform. Gap analysis against the Trust Services Criteria. Remediate gaps before the auditor engages.
• Month 5: Auditor engaged. We recommend A-LIGN, Schellman, or Prescient Assurance for early-stage healthcare companies. Budget 8–12 weeks for the audit process itself. Budget $45K–$95K for the audit fee.
• Month 6: First enterprise payer or health system pilot, now you have a SOC 2 Type I (point-in-time) report to show in procurement. SOC 2 Type II (observation period) report follows at month 12 of operations minimum.

When to hire your first in-house compliance role:

• You are approaching 10,000 active patients
• You are entering a payer or large health system contract
• You are starting your Series B fundraise
• Your SOC 2 Type II report is due for renewal

The first in-house hire is typically a VP of Engineering or Head of Security and Compliance, not a CISO. The CISO comes at Series B+. Before that, a fractional CISO ($4K–$10K/month) and a compliance automation platform cover most of the operational need.

The graduation plan: We build every engagement with the explicit goal of making ourselves replaceable. By month 12 of a dedicated pod engagement, you should have enough internal engineering knowledge, through co-documentation, architecture decision records, and our weekly knowledge transfer sessions, to hire your first in-house engineers with confidence. We do not make ourselves the single point of knowledge on your product. That is a trap for you, and a trap we won’t set.

When an Indian Agency Is the Wrong Call for Your Healthcare Product

I am going to give you 150 honest words here, because you deserve them before you sign anything.

An Indian product engineering partner is the wrong call if: your product requires FedRAMP High or CJIS authorization from Day 1, these US government security frameworks require US-person handling of certain data that creates compliance gaps with an offshore team.

If your product is so deeply PHI-adjacent that even architectural conversations need to happen with US-based, BAA-covered staff on a cleared basis, certain DoD health programs are in this category.

If your clinical workflow is so domain-specific that meaningful product decisions require a clinician in the room at 9 AM EST three times a week, and you’re not willing to fund the US-overlap staffing model to make that work.

If your founding team will struggle with the 10.5-hour time zone gap on a personal level, not every working style adapts to async-first communication, and founders who need synchronous energy to make decisions will be frustrated.

None of these are reasons most US healthcare founders face. But if any of them apply to you, I will tell you that on the first call.

The Agency Selection Scorecard™, Healthcare Regulated Edition

Use this to evaluate any agency, including us. Score each row 0 (absent), 1 (partial), or 2 (fully present). Maximum score: 70.

#	Criterion	Weight	Your Score
1	Offers BAA signed before ePHI is shared	2×	/4
2	Named HIPAA Security Rule compliance lead on the team	2×	/4
3	Uses only HIPAA-eligible AWS/GCP services (confirmed list)	2×	/4
4	Provides ePHI data classification map in discovery	2×	/4
5	Audit log architecture immutable, append-only, 6+ year retention	2×	/4
6	Penetration testing by third-party firm included or facilitated	1×	/2
7	SOC 2 Type II readiness built into architecture from Day 1	2×	/4
8	FHIR R4 live integration experience (not just spec knowledge)	1×	/2
9	Named EHR integration experience (Epic, Cerner, Athena)	1×	/2
10	BAA coverage confirmed for every sub-processor in the stack	2×	/4
11	IP assigned on creation (not on final payment)	2×	/4
12	Source code and infra access from Day 1	2×	/4
13	MSA governed by US law (Delaware or state of choice)	2×	/4
14	Incident response runbook delivered at handover	1×	/2
15	HIPAA risk assessment delivered at handover	2×	/4
16	LLM-under-BAA decision tree documented	1×	/2
17	Telehealth licensure guidance provided (state-by-state)	1×	/2
18	42 CFR Part 2 awareness (substance use disorder records)	1×	/2
19	US founder references available (healthcare-specific)	1×	/2
20	US-overlap window clearly defined and contractually committed	1×	/2
21	Named case studies in your sub-vertical	1×	/2
22	FDA SaMD pathway awareness	1×	/2
23	HITRUST CSF experience or partner	1×	/2
24	Honest “when we’re the wrong fit” statement	1×	/2
25	Minimum necessary access enforced in UI and API	2×	/4

Score interpretation:

• 55–70: Strong fit for a regulated healthcare build
• 40–54: Proceed with due diligence, identify which 2× items are missing
• Under 40: Significant compliance risk, do not proceed without remediation

EB Index 2026: EngineerBabu scores 64/70 on this scorecard. The 6 points we don’t claim: HITRUST CSF (we have partner relationships but not in-house certification), FDA SaMD pathway (we engage regulatory consultants, we are not regulatory attorneys), and CJIS/FedRAMP (genuinely out of scope for us, see Section 13).

Closing, 30 Minutes, No Slides

I’ve been on 2,000+ calls with US founders over twelve years. The founders who build regulated healthcare products well, who launch on time, who pass their first enterprise procurement review, who raise their Series A with a working product the investor could actually log into, share one trait. They treated compliance as a product constraint from Day 1, not as a problem to solve after launch.

The founders who paid the most, in money, in time, in board goodwill, treated compliance as someone else’s problem until it became their emergency.

You don’t have to be the second kind.

Book a 30-minute product audit call with me or Aditi. No slides. No pitch deck. We look at what you’re building, we tell you what the HIPAA surface area is, we tell you what it will cost, and we tell you if we’re the right fit, or if we’re not.

That conversation is free. The mistakes it prevents are not.

FAQ about How to Build HIPAA-Compliant Products From India

• Can EngineerBabu sign a Business Associate Agreement?

Yes. We sign BAAs governed by Delaware law. We are structured as a Business Associate under 45 CFR §160.103 for engagements where we handle ePHI on behalf of a Covered Entity or another Business Associate.

• Which AWS services are HIPAA-eligible?

The full list is maintained at aws.amazon.com/compliance/hipaa-eligible-services-reference. It changes, AWS adds services regularly. We check this list at the start of every healthcare engagement and recheck it before adding any new AWS service to a production healthcare product.

• Can I use OpenAI’s API for a HIPAA-covered clinical product?

Under an OpenAI Enterprise agreement, OpenAI offers a BAA for the API. Review the BAA scope carefully with your healthcare attorney, what data uses are covered and under what conditions matters. For products where the BAA scope is ambiguous or insufficient, we default to AWS Bedrock (covered under the AWS BAA) or Azure OpenAI with HIPAA mode.

• How long does SOC 2 Type II take?

The observation period minimum is 6 months of operating evidence. Add 8–12 weeks for the audit process. Budget 9–15 months from “we need SOC 2” to “we have the Type II report.” Start the clock at product launch, not at the enterprise sales conversation where the customer asks for it.

• What is the difference between HIPAA and HITRUST?

HIPAA is a US federal law. HITRUST CSF is a certification framework that maps to HIPAA (and 40+ other frameworks) and is increasingly required by large health systems and payers as a procurement condition. SOC 2 Type II is table stakes for most enterprise healthcare sales. HITRUST is the bar above that. Budget $80K–$150K for a HITRUST assessment. Most Seed-stage healthcare companies should focus on SOC 2 Type II first.

• How do you handle the 10.5-hour time zone gap?

Our standard US-overlap window is 7:30–10:30 AM PST / 10:30 AM–1:30 PM EST daily. We run async-first communication, every decision that can be made async is made async, with a written record. Every decision that requires synchronous alignment happens in the overlap window. For Series A+ founders who need more real-time coverage, we staff a US-based client lead. That is a real cost ($4K–$7K/month) and we quote it upfront.

• Do you have experience with Epic SMART on FHIR integrations?

Yes. We have shipped live Epic integrations through the App Orchard process for two US healthcare clients. The Epic sandbox process, App Orchard certification requirements, and production launch review process are each meaningfully different from simply reading the FHIR R4 spec. We will tell you which of our engineers has live Epic experience on the discovery call.

• What happens if there’s a data breach during the engagement?

Our BAA commits us to notifying you within 24 hours of discovering a suspected breach, well inside the 60-day window HIPAA’s Breach Notification Rule (45 CFR §164.412) gives you to notify affected individuals. We deliver an incident response runbook at handover so your team knows exactly what to do post-launch.

• Can you build a SaMD product?

We can build the software. The FDA regulatory pathway decision, whether your software qualifies for the clinical decision support exemption under the 21st Century Cures Act or requires a 510(k) or De Novo submission, is a regulatory attorney question, not an engineering question. We have partner relationships with regulatory consultants who specialize in this. We engage them in discovery for any product where SaMD classification is ambiguous.

• What is 42 CFR Part 2 and when does it apply?

42 CFR Part 2 is a federal regulation that protects records related to substance use disorder (SUD) treatment with stricter confidentiality requirements than standard HIPAA. It applies any time your product stores or handles records that identify a patient as having received SUD treatment. The consent requirements for disclosure are more stringent than HIPAA, a general authorization is not sufficient. Most agencies miss this. We flag it in discovery.

• How do you handle minimum necessary access in the UI?

Every role in the product’s access control model is mapped to the minimum data it needs to perform its function, we call this the data access matrix, and it is produced in discovery before any UI/UX design begins. The UI enforces that matrix, a billing administrator does not see clinical notes, a care coordinator does not see financial records. This is not just good UX. It is required under §164.502(b).

• What do you deliver at handover?

HIPAA risk assessment (final, as-built), system security plan, data flow diagrams with ePHI annotated, audit log specifications, incident response runbook, BAA registry with every sub-processor, vendor sub-processor list, penetration test report, SOC 2 readiness summary, and all source code and infrastructure access transferred to you.