Medical App Development: What a Compliant Build Takes

A compliant medical app is not a consumer app with a privacy policy stapled to the front. The work that makes it compliant is five technical safeguards the HIPAA Security Rule names in 45 CFR 164.312: access control, audit logging, integrity, authentication, and transmission security. Those are lines of code and architecture decisions, not a document you sign at the end. On top of the build, the HIPAA layer alone (security architecture, a third-party penetration test, business associate agreements, encrypted storage) adds $15,000 to $50,000. And the bar is moving: a federal proposal published January 6, 2025 would make encryption and multi-factor authentication mandatory instead of optional.

We’re gmware, a custom software development firm in Austin, TX with engineering centers in Bangalore and Mohali, India, and healthcare builds are part of our delivery history. We also run production data systems of our own. Shield Suite, our retail-intelligence product, processes data across more than 60,000 beverage-alcohol storefronts, so the guardrails below aren’t theory we read about. They’re the kind of controls we operate every day. What follows is what a compliant build actually takes: the five safeguards in plain terms, the rule change coming, whether your app is even a medical device, the EHR reality, and where the cost goes.

One opinion up front. The cheapest medical app is the one where compliance lives in the first sprint, not the last. Retrofitting audit logging and access control onto a finished app costs more than designing them in. Every time.

What “HIPAA-compliant” actually means for an app

It means five things your code has to do, and they come straight from the regulation. HIPAA’s technical safeguards sit in 45 CFR 164.312, and they are specific enough that you can hold a build accountable to them.

Access control. Only the right people see the right data. In practice that’s unique user identification (required), an emergency access procedure (required), automatic logoff, and encryption of data at rest. A shared admin login fails this on day one.

Audit controls. A record of who touched what. The rule requires “hardware, software, and/or procedural mechanisms that record access to and activity in” systems holding patient data. If you can’t answer “who opened this chart and when,” you don’t have it.

Integrity. Proof the data wasn’t altered or destroyed without authorization. A patient record that can be silently edited is a liability, not a feature.

Authentication. Verify that the person or system asking for data is who it claims to be. This is where multi-factor authentication earns its keep.

Transmission security. Protect patient data while it moves over a network. In real terms, that’s encryption in transit, end to end.

Now the part most estimates skip. Under the current rule, some of these are “addressable,” which the industry has long read as “optional if you document a reason.” Encryption, for instance, is an addressable specification today, not a flat requirement. That flexibility is exactly what’s about to disappear.

The HIPAA Security Rule is getting stricter, and you should build to it now

The rules behind a compliant medical app haven’t materially changed since 2003. That’s ending. The HHS Office for Civil Rights published a Notice of Proposed Rulemaking on January 6, 2025, and the comment period closed March 7, 2025. As of mid-2026 there’s no final rule, but the direction is unambiguous, and building to it now is cheaper than retrofitting later.

The headline change: the proposal removes the “addressable versus required” distinction, so the flexibility becomes about how you implement a control, not whether you do. Encryption stops being optional. Specifically, the NPRM would make encryption of patient data at rest and in transit mandatory, require multi-factor authentication across systems handling that data, and add operational obligations: a current asset inventory and network map, vulnerability scans every six months, and a penetration test at least annually.

We treat the proposed bar as the design target for anything we scope this year, because the alternative is shipping an app that’s compliant on launch day and non-compliant the day the rule finalizes. If you want the full picture of what’s shifting and how to migrate existing systems, our HIPAA cloud migration guide covers the Security Rule changes in depth.

Is your app even a medical device? The FDA question to settle first

Before you scope a line of HIPAA work, answer a different question: does the FDA regulate this thing? Because if your app diagnoses or treats a condition, HIPAA is only half your problem.

The FDA regulates Software as a Medical Device, defined as software intended for a medical purpose that isn’t part of a hardware device. The line is intended use. An app that reads imaging to detect cancer, or analyzes a signal to flag a condition, is a medical device and needs FDA review. An app that tracks steps, coaches sleep, or books appointments is general wellness or administrative software and generally is not.

This matters because it changes the whole project. A wellness app is a HIPAA build. A diagnostic app is a HIPAA build plus a regulated-device build, with design controls, clinical validation, and a submission pathway that can add a year and a different class of budget. We’ve watched founders discover this in month four, when an investor’s diligence asks for a 510(k) plan that doesn’t exist. Settle it in week one. If there’s any chance your app crosses into diagnosis or treatment, get a regulatory read before the architecture is locked, not after.

The EHR question: where medical apps quietly blow their budget

Most medical apps eventually need to talk to an electronic health record, and that’s where the budget goes sideways. Reading a patient’s appointment list is one project. Writing a clinical note back into the chart is a different, bigger one, because write-backs carry validation, error handling, and a liability conversation that reads don’t.

The numbers are wide for a reason. EHR integration runs from about $15,000 for a single read-only FHIR connection to $150,000 or more for bidirectional sync across several platforms. Vendor matters too: Epic typically runs $18,000 to $80,000, the priciest of the majors because of its certification process, while athenahealth comes in at $10,000 to $48,000 since it built its API for outside developers early.

Our standing advice is to start read-only. We’ve talked more than one client out of write-back for version one, because that’s where cost and certification spike together. And don’t forget the recurring line: each live interface costs $3,000 to $15,000 a year to maintain, because both ends of the pipe keep moving. We break the per-vendor math down in our EHR integration cost guide so you can size it before anyone quotes you.

What a medical app actually costs to build in 2026

Scope drives everything, so here’s the honest spread. A simple patient-facing app with booking and HIPAA-compliant storage runs $40,000 to $80,000. A full telemedicine platform with video consultations, EHR integration, and real-time messaging reaches $150,000 to $300,000 or more. The HIPAA layer is a line item inside that, not a discount: adding HIPAA compliance (security architecture, a third-party pen test and audit, BAAs, encrypted storage) costs $15,000 to $50,000, which tracks with the 20% to 30% premium regulated builds carry across the board.

Two recurring costs people forget. A penetration test for a small business runs $3,000 to $15,000, and the proposed rule wants one annually. And maintenance runs 15% to 25% of build cost a year, higher than a typical consumer app, because security patches and compliance updates never stop. For the full telehealth-build budget, with the MVP-versus-platform fork laid out, see our HIPAA telehealth app cost guide. If you’re scoping the video side specifically, our companion piece on telemedicine software development covers the WebRTC stack and the BAA details that come with live video.

There’s a reason the compliance spend is worth it, and it’s not abstract. A US healthcare data breach averaged $7.42 million in 2025, per IBM’s annual study, and healthcare has been the costliest industry to breach for 14 years running. The pen test is cheap insurance against the six-figure consequence.

When you should not build a custom medical app

Custom is a means, not a trophy, and sometimes the honest answer is don’t. Three cases where we’d tell you to hold off or buy instead.

If you’re still validating demand, don’t build custom yet. When you don’t know whether patients will even book, prove that with the cheapest thing that works. A white-label or template platform gets you live fast and tells you what you actually need before you spend on a custom build.

If a certified product already does the job, license it. An EHR marketplace app that covers your workflow for a single clinic is a better trade than rebuilding it to own it, at least until your workflow is genuinely the differentiator.

And if the workflow isn’t the product, custom is the wrong tool. It earns its cost when the patient experience or the integration depth is the thing competitors can’t copy. A standard intake form at custom prices is just a commodity you overpaid for.

That’s the same discipline we apply to any build: the most useful thing we sometimes deliver is talking you out of scope you don’t need yet. It’s also covered in our broader guide on how to choose a software development company, which has the vendor-vetting checklist worth running before you sign anything.

How gmware scopes a compliant medical app

We run healthcare builds as fixed-scope engagements inside our healthcare software development practice: Austin-based leads own discovery, the data-flow map, the regulatory read, and the BAA paperwork on US hours, while our Bangalore and Mohali teams build. Compliance is designed into the first sprint, not audited in the last. That’s the difference between the 20% HIPAA premium and the 30% one.

The blended model is also the cost story. On healthcare work, US-only rates run $100 to $150 an hour against $40 to $80 for a blended US-India team, at the identical compliance bar, because HIPAA governs the controls in the build, not the engineer’s location. And when an app needs an intelligence layer (triage, summarization, pattern detection on clinical data) we scope it through our AI and machine learning practice with the same validation rigor, because a model that’s wrong about a patient is worse than no model.

We’ll also tell you when not to hire us. If a certified platform fits, license it. If you’re still proving the idea, prove it cheaply first. A custom medical app is a serious commitment, and it should clear that bar before you make it.

Tell us what you’re building and which EHRs you need to reach. Send us the shape of it and we’ll come back within 48 hours with a straight read on scope, the compliance premium, and timeline.