Healthcare App Development: Regulations, HIPAA & What You Need to Know

Here's a question we get at least once a month: "We're building a health app. Does it need to be HIPAA compliant?"

The answer is almost always "it depends," which is frustrating. So let me be more specific. About 40% of the health-related apps people pitch to us don't actually need HIPAA compliance. A fitness tracking app that doesn't connect to medical providers? Not HIPAA. A wellness platform that collects self-reported data? Probably not HIPAA. A mental health journaling app where users enter their own thoughts? Not HIPAA (unless it integrates with a therapist's clinical records).

But a telehealth platform where doctors see patients? HIPAA. An app that pulls data from a hospital's EHR system? HIPAA. Anything that handles Protected Health Information (PHI) on behalf of a healthcare provider, health plan, or clearinghouse? HIPAA.

The distinction matters because HIPAA compliance adds real cost and complexity to a build. Not enough to make it impossible, but enough that you don't want to do it unnecessarily. And you definitely don't want to skip it when it's required.

Let's break down what HIPAA actually means technically, when it applies, and how to build health tech efficiently regardless.

Key takeaways:

• About 40% of health-related apps don't actually need HIPAA compliance — consumer wellness, fitness tracking, and self-reported data apps are generally exempt.
• HIPAA-specific engineering adds roughly 20-30% to development cost, not 200%. A $30,000 app might need an extra $6,000-$9,000 for compliance.
• You cannot host a HIPAA-covered app on platforms that won't sign a BAA (Business Associate Agreement). AWS, GCP, and Azure will; Vercel and many popular platforms won't.
• EHR integration timelines are driven more by vendor approval processes (weeks to months for Epic access) than by technical complexity.
• A HIPAA-compliant healthcare MVP takes 4-8 weeks and costs $20,000-$50,000 with a specialized team.

In this post:

• What HIPAA Actually Requires (Technically)
• Common HIPAA Misconceptions
• FDA Considerations for Clinical Apps
• EHR/EMR Integrations (HL7 FHIR)
• Telehealth Features
• Patient Data Handling Best Practices
• What a Healthcare App MVP Looks Like
• Working with the Right Development Partner
• FAQ

What HIPAA Actually Requires (Technically)

Most articles about HIPAA talk about the law in legal terms. Here's what it means for the engineers building your app.

The Security Rule: What You Must Build

The HIPAA Security Rule has three categories of safeguards: administrative, physical, and technical. The technical ones are what affect your software directly.

Encryption at rest and in transit. All PHI must be encrypted. In transit, that means TLS 1.2 or higher for every connection (this is standard practice for any modern web app). At rest, that means AES-256 encryption for PHI stored in your database. Most cloud databases (AWS RDS, Google Cloud SQL) support encryption at rest as a configuration option. It's not hard to implement. It's just a box you need to check before you start storing data.

Access controls. Every user who accesses PHI needs a unique identifier. You need role-based access so that a receptionist can't see the same data as a physician. You need automatic logoff after inactivity. You need emergency access procedures for when the system is down but patient care requires data access.

In practice, this means: user authentication with MFA, role-based permissions at the API level (not just the UI level), session timeout policies, and a documented emergency access process.

Audit controls. You must record who accessed what PHI, when, and what they did with it. Every read, write, update, and delete of PHI needs a log entry. These logs must be retained for at least six years (HIPAA's requirement) and must be tamper-evident.

This is the requirement that affects your architecture the most. You can't add audit logging as an afterthought. It needs to be built into your data access layer so that every database operation involving PHI automatically generates a log entry.

Integrity controls. You need mechanisms to ensure PHI hasn't been improperly altered or destroyed. In practice, this means database checksums, validation on data entry, and backup verification processes.

Transmission security. Beyond basic TLS, you need to ensure that PHI sent via email, API, or file transfer is encrypted end-to-end. If your app sends PHI via email notifications (appointment details, lab results), those emails need encryption, not just the connection to the email server.

The Privacy Rule: What You Must Do Operationally

The Privacy Rule is less about code and more about process, but it has technical implications.

Minimum necessary standard. You should only access, use, or disclose the minimum amount of PHI needed for a given purpose. In your app, this means API endpoints should return only the fields needed for the requesting user's role, not the entire patient record every time.

Patient access rights. Patients have the right to access their health records and request corrections. Your app needs a mechanism for patients to view their data and submit amendment requests. This isn't optional.

Business Associate Agreements (BAAs). If you're a developer or agency building a HIPAA-covered app, you're a business associate. You need a BAA with the covered entity (the healthcare organization). Your cloud provider also needs to sign a BAA. AWS, Google Cloud, and Azure all offer BAAs. Vercel does not (as of early 2026). This matters for your hosting decision.

Important point on hosting: you cannot deploy a HIPAA-covered application to a provider that won't sign a BAA. This eliminates some popular hosting platforms. AWS, GCP, and Azure are the standard choices for HIPAA-covered workloads.

Common HIPAA Misconceptions

The U.S. Department of Health and Human Services reported over 700 major healthcare data breaches in 2023 alone, affecting more than 130 million individuals. Getting compliance right isn't just about avoiding fines — it's about protecting real people's most sensitive information.

We've seen founders waste significant time and money based on misunderstandings about HIPAA. Here are the ones that come up most often.

"My app collects health data, so it must be HIPAA compliant."

Not necessarily. HIPAA applies to covered entities (healthcare providers, health plans, clearinghouses) and their business associates. If your app collects health data directly from consumers and doesn't share it with or act on behalf of covered entities, HIPAA likely doesn't apply.

A fitness app where users log their own workouts and calories? Not HIPAA. That same app if it shares data with the user's physician as part of a treatment plan? Now you're in HIPAA territory.

The FTC's Health Breach Notification Rule may apply to non-HIPAA health apps, so you're not entirely off the hook. But the compliance requirements are significantly lighter.

"HIPAA means we need SOC 2 certification."

HIPAA doesn't require SOC 2. They're separate frameworks. Some healthcare organizations may require SOC 2 as part of their vendor evaluation, but HIPAA itself doesn't mandate it. Don't let an agency tell you SOC 2 is a HIPAA prerequisite.

"We need to build everything from scratch for HIPAA compliance."

You don't. AWS and GCP have HIPAA-eligible services. PostgreSQL supports encryption at rest. Standard authentication libraries support MFA. Audit logging libraries exist for every major framework. The HIPAA-specific engineering adds maybe 20-30% to the development effort, not 200%.

"HIPAA compliance is a one-time thing."

It's ongoing. You need annual risk assessments, regular security reviews, staff training, and incident response procedures. The technical build is step one. Maintaining compliance is the ongoing work.

FDA Considerations for Clinical Apps

Here's where things get more complex. If your app is used in clinical decision-making, the FDA may classify it as a medical device (specifically, Software as a Medical Device or SaMD — software that performs a medical function on its own, without being part of a physical medical device).

Apps the FDA regulates:

• Software that diagnoses conditions based on patient data
• Apps that recommend treatment changes
• Tools that analyze medical images (radiology AI, pathology analysis)
• Clinical decision support that doesn't just present information but actively recommends actions

Apps the FDA generally doesn't regulate:

• Patient portals that display existing health records
• Appointment scheduling tools
• Medication reminder apps (that don't make dosing recommendations)
• Wellness and fitness apps
• Clinical decision support that simply presents information for a clinician to interpret

The FDA published guidance on this distinction, and it's more nuanced than a one-paragraph summary can capture. If your app is anywhere near the clinical decision-making line, consult a regulatory affairs specialist before you build. FDA clearance (510(k) or De Novo) can add 6-18 months and $50K-$300K to your timeline and budget. You want to know whether it's required before you start.

EHR/EMR Integrations (HL7 FHIR)

If your health app needs to exchange data with electronic health record systems (EHR — the digital version of a patient's medical chart), you'll be working with FHIR (Fast Healthcare Interoperability Resources), which is essentially a standardized language that lets different health systems share patient data with each other. FHIR is the modern standard for health data exchange, and it's becoming the required format under the 21st Century Cures Act.

What FHIR Integration Actually Involves

The good news: FHIR is a REST-based API standard. If your team has built REST APIs before, the concepts are familiar: resources, endpoints, JSON payloads, authentication.

The less-good news: Healthcare data is messy. The FHIR spec defines hundreds of resource types, and different EHR systems implement them differently. Epic's FHIR implementation doesn't behave identically to Cerner's, which doesn't behave identically to Allscripts'. You'll spend time handling these differences.

Typical integration scope:

• Patient demographics (reading patient records)
• Clinical data (conditions, medications, allergies, lab results)
• Scheduling (appointments, availability)
• Clinical notes (progress notes, discharge summaries)

Timeline: A basic FHIR integration (read patient demographics and clinical data from one EHR system) takes 2-4 weeks. A full bi-directional integration with multiple EHR systems can take 2-4 months.

The biggest hurdle isn't technical. It's getting access. EHR vendors (especially Epic) have approval processes for third-party apps that can take weeks to months. You need to apply to their developer program, get your app reviewed, and go through a testing process before you get production access. Start this process early.

SMART on FHIR

SMART on FHIR is the authentication and authorization framework for FHIR apps. It uses OAuth 2.0 and allows your app to launch from within an EHR's interface (like an app within an app). If you're building for clinical users who are already working in an EHR, SMART on FHIR is the expected integration pattern.

Telehealth Features

Telehealth has become a standard expectation for healthcare apps. Here's what the technical implementation looks like.

Video calling: Use a HIPAA-compliant video API. Twilio Video and Vonage (formerly Tokbox) both offer HIPAA-eligible plans with BAAs. Don't try to build video calling from scratch with WebRTC unless you have a very specific reason. The time and cost of getting raw WebRTC to production quality (handling network issues, fallback to relay servers, recording, multiple participants) is significant.

Integration cost: $3,000-$8,000 for basic video consultation features (one-on-one calls, waiting room, call recording with consent).

Scheduling: Appointment booking with provider availability, timezone handling, automated reminders, and cancellation policies. This integrates with the FHIR scheduling resources if you're connected to an EHR.

E-prescribing: If your platform involves prescriptions, you'll need to integrate with a pharmacy network (Surescripts) through a certified intermediary. This is a specialized integration that adds significant scope.

Asynchronous communication: Secure messaging between patients and providers. This is PHI, so it needs encryption and audit logging. Don't use standard chat SDKs without verifying their HIPAA compliance.

Patient Data Handling Best Practices

Beyond the legal requirements, here's how we approach patient data from an engineering perspective.

Separate PHI from non-PHI data. Use different database schemas or tables for PHI vs. application data (user preferences, UI settings, etc.). This makes it easier to apply encryption and access controls selectively and simplifies your audit scope.

De-identify when possible. If you need patient data for analytics or reporting, de-identify it (remove the 18 HIPAA identifiers). Your analytics database shouldn't contain PHI unless it absolutely needs to.

Minimize data collection. Don't collect PHI you don't need. Every data point you collect is a data point you need to protect, audit, and potentially produce in response to a patient access request. Collect the minimum necessary for your application to function.

Plan for data portability. Patients have the right to their data. Build export functionality early. FHIR-formatted exports are ideal if you're in the clinical space.

Breach notification procedures. Despite your best efforts, breaches can happen. HIPAA requires notification within 60 days of discovery. Have an incident response plan documented before you launch, not after something goes wrong.

What a Healthcare App MVP Looks Like

You can build an MVP fast even in healthcare. The key is understanding which compliance requirements apply from day one and which can be phased in.

A HIPAA-compliant healthcare MVP typically includes:

• User authentication with MFA and role-based access
• Encrypted data storage (PHI encrypted at rest and in transit)
• Audit logging for all PHI access
• Core clinical feature (telehealth, patient portal, or care coordination)
• Patient-facing data access (view their own records)
• Admin panel for provider management
• BAA-compliant hosting (AWS or GCP)

Timeline: 4-8 weeks for a web application. Add 2-4 weeks for mobile.

Cost: $20,000-$50,000 for an MVP with a specialized agency. The HIPAA compliance layer adds roughly 20-30% to what the same app would cost without it.

What to defer to v2:

• EHR integrations (start with standalone, add integrations later)
• E-prescribing (complex, specialized integration)
• Advanced analytics and reporting
• Multi-provider scheduling with complex availability rules

The goal of your MVP is to prove the clinical workflow works and users (both patients and providers) will adopt it. The integrations and advanced features come after you've validated that core proposition.

Working with the Right Development Partner

Healthcare app development requires a team that understands both the technical and compliance dimensions. When evaluating a custom software development partner for health tech, ask these questions:

• Have you built HIPAA-compliant applications before? Can you show me the architecture?
• Which cloud provider do you use, and do they have a BAA in place?
• How do you handle audit logging? Is it built into the architecture or added on top?
• What's your approach to encryption key management?
• Can you help us determine which compliance requirements apply to our specific product?

A good development partner won't just build what you ask for. They'll tell you when you're over-engineering compliance (spending money on requirements that don't apply) and when you're under-engineering it (missing requirements that could expose you to liability).

FAQ

Does my health app need HIPAA compliance?

It depends on whether you handle Protected Health Information (PHI) on behalf of a covered entity (healthcare provider, health plan, or clearinghouse). Consumer wellness apps, fitness trackers, and self-reported health data generally don't fall under HIPAA. Apps that connect to healthcare providers, access clinical records, or facilitate telehealth visits almost certainly do. When in doubt, consult a healthcare attorney. The cost of a consultation is far less than the cost of getting it wrong.

How much does HIPAA compliance add to development costs?

Roughly 20-30% on top of the base development cost. For a $30,000 app, expect an additional $6,000-$9,000 for compliance-specific work (encryption implementation, audit logging, access controls, BAA-compliant hosting setup). The ongoing compliance costs (annual risk assessments, security reviews, staff training) are separate and typically run $5,000-$15,000/year.

Can I use AWS or Google Cloud for a HIPAA-compliant app?

Yes. Both AWS and GCP offer HIPAA-eligible services and will sign Business Associate Agreements. You need to configure the services correctly (enable encryption, restrict access, enable logging), but the infrastructure supports HIPAA compliance out of the box. Azure also offers HIPAA-eligible services with BAAs.

How long does it take to build a healthcare app?

An MVP takes 4-8 weeks with an experienced team. A full-featured platform with EHR integrations, telehealth, and advanced clinical features can take 3-9 months. The biggest timeline variable is usually EHR integration, since getting approved by Epic or Cerner's developer programs can add weeks to months of waiting time.

Do I need FDA approval for my healthcare app?

Only if your app qualifies as Software as a Medical Device (SaMD), meaning it's used for clinical diagnosis, treatment recommendations, or medical image analysis. Patient portals, scheduling tools, medication reminders, and wellness apps generally don't need FDA clearance. If your app makes clinical recommendations or diagnoses, consult a regulatory affairs specialist early, as FDA clearance can add 6-18 months and significant cost to your project.

Planning a healthcare application? Reach out to us. We'll help you determine which compliance requirements actually apply to your product, scope the MVP, and build it on a solid technical foundation. No unnecessary compliance theater, just the right architecture for your specific use case.