How to Build a Medical App in 2026: Users, PHI, FDA and EHRs

Start with four decisions

A medical app is not one product category. A symptom diary, a doctor appointment app and an insulin dose calculator all count, and they live under very different rules.

Four questions sort them out:

1. Who is the user? Patients, clinicians, caregivers or staff. Each role needs its own screens, permissions and often its own app.
2. Does it touch PHI? If a covered entity or its vendor stores health data tied to a person, HIPAA applies. Consumer apps may fall under the FTC instead.
3. Is it a medical device? Software that diagnoses, treats or drives clinical decisions can be regulated by the FDA.
4. Does it read or write EHR data? Integration with hospital records means FHIR, SMART on FHIR and a security review at every site.

Your answers usually place you in one of four product types:

Each type has its own budget band. The tier check in our healthcare app development cost guide places your idea in one and shows the range.

How to build a medical app, step by step

Eight steps, ordered so the regulated questions are settled before anyone designs a screen. The same order works for a healthcare app of any size.

1. Write the intended use in one paragraphWho uses it, for what, and what it does not do. "Helps patients book and prepare for lab visits" is a scope. This paragraph later decides whether the FDA has a say, so write it carefully and keep it.
2. Map the roles and the workflowSit with the people who will use it: a nurse, a front desk lead, a patient with the condition. Draw the journey from first contact to follow-up. Most medical apps have three or more roles, and each needs different screens and permissions.
3. Classify the dataList every field you will store and mark which ones are PHI. Decide what stays on the phone, what goes to your servers, and what never leaves the EHR. This drives your HIPAA scope and your vendor list.
4. Get a regulatory read on clinical featuresIf any feature scores, flags, recommends or calculates something clinical, ask a regulatory specialist whether it is a device function. The answer can move your timeline by a year.
5. Pick your integration pathDecide which EHRs, labs, devices or pharmacies you connect to in version one. Register in the EHR developer programs and test in sandboxes early. Production access comes later and slower.
6. Design for each role and for accessibilityPatients may be older, anxious or unwell. Clinicians are busy and interrupted. Follow WCAG for contrast, text size and screen readers, and test with real users in each role.
7. Build in thin slices with security from sprint oneAccess control, audit logging and encryption go in with the first feature, not before launch. Retrofitting them means touching every endpoint twice.
8. Pilot with one clinic or one health systemReal workflows expose what interviews missed: double bookings, shared devices at the nurse station, patients without email. Fix those, then sign the next site.

Is your app a medical device?

This is the question with the biggest price tag, so answer it on paper first. The FDA regulates software as a medical device when it is intended to diagnose, cure, mitigate, treat or prevent a disease or condition. Intended use is judged by what you claim, in the app, on the store listing and in your marketing.

Most healthcare software sits outside that line:

• Not devices: scheduling, billing, records access, secure messaging, telehealth visits, care team coordination.
• General wellness: low-risk apps that support a healthy lifestyle, such as sleep, stress or activity tracking, without disease claims. FDA's general wellness policy covers these.
• Enforcement discretion: some low-risk tools that technically meet the device definition, such as apps that help patients self-manage a condition without suggesting treatment changes. FDA's policy on device software functions and mobile medical apps lists examples.
• Clinical decision support: software that gives recommendations to clinicians can fall outside device rules if it meets the criteria in FDA's clinical decision support guidance. A key one: the clinician can review the basis for the recommendation and doesn't rely mainly on the software.
• Devices: software that analyzes images or signals, calculates doses, or tells patients to change treatment. These need a regulatory pathway such as 510(k), De Novo or premarket approval, plus design controls and a quality system.

EHR integration: FHIR, SMART and site approvals

If your app needs records, orders or results from a hospital, you will integrate with an EHR. In the US that now starts with FHIR.

The 21st Century Cures Act pushed the industry here. Certified EHRs must offer standard FHIR APIs for patient and clinical data, and the information blocking rules discourage health systems and vendors from unreasonably blocking access to electronic health information. In practice that means you can get the data. It doesn't mean you get it fast.

• FHIR R4 and US Core. The data model most US EHRs expose: patients, encounters, conditions, medications, observations, appointments. Map to it once in your own integration layer.
• SMART on FHIR. An authorization standard based on OAuth 2.0. An EHR launch opens your app inside the clinician's EHR with the patient already selected. A standalone launch lets a patient connect your app to their portal account.
• Scopes. Ask for the minimum data you need. Health system reviewers notice broad scopes, and so do patients on the consent screen.
• Sandbox to production. The vendor sandbox works in days. Each health system then runs its own security questionnaire, approval and testing. Budget months per site, and start the first one early.
• Older interfaces. Some workflows, such as lab orders and results, still run on HL7 v2 messages through an interface engine. Ask early which one your partner uses.

What you build and what you rent

Healthcare teams that ship on time rent the commodity parts under signed agreements and build the workflow that makes the product worth using.

Every vendor that stores or processes PHI for you needs a business associate agreement. Our guide on how to build a HIPAA compliant app covers the vendor list and the safeguards in detail.

Architecture rules for a medical app

Medical apps fail in quiet ways: the wrong patient's result, a reminder that leaks a diagnosis, a sync that drops one record a week. These rules prevent most of it.

• Roles first. Model patients, clinicians, staff, caregivers and admins explicitly, with permissions per organization. A clinician at clinic A must never see clinic B's patients.
• PHI in as few places as possible. One encrypted store, one API in front of it. Notifications, logs, analytics and crash reports carry IDs, not health details.
• One integration layer. All EHR, lab and device data passes through a single service that maps it to your model and records where each value came from.
• Patient matching you can explain. Never match records on name alone. Use stable identifiers from the source system, and send uncertain matches to a human queue.
• Audit everything that touches PHI. Who viewed or changed which record, when, from where. Clinics and their auditors will ask for it.

On stack: native Swift and Kotlin when you rely on Bluetooth devices or deep platform features; React Native or Flutter for most patient and staff apps. A relational database, a typed backend and separate environments with synthetic data only.

What goes into the first version

A medical MVP should do one clinical job end to end for one type of organization. A typical split:

If you only need the patient side to start, a cross-platform app plus a web console is usually enough. Our mobile app development cost guide compares native and cross-platform budgets.

Built by Gilzor

Results we’ve shipped

70+products launched

98%delivered on time

85%clients come back

Retail · Startup700+stores aggregatedMobile application for Grocery shops→Food delivery3.5 moto MVP launchOptimizing and controlling delivery for a Pizzeria Chain→EdTech4 moto a full iOS app on the App StoreA mobile app to develop brain functions→

Talk to the people who build it. Tell us about your project and get a free estimate of scope, timeline and cost.

See how we’d approach yours →

Timeline and budget at a glance

A wellness app that stores no PHI can start around $40k and 3–5 months. EHR-integrated platforms typically run $250k–600k, and medical device software usually passes $500k. US onshore agencies quote about 2–2.5 times these figures. The full breakdown, hidden costs and a calculator are in our healthcare app development cost guide.

Mistakes that cost the most later

• Clinical claims in marketing that the product team didn't plan for. A landing page that says "detects" or "diagnoses" can change how the FDA views your software. Keep marketing copy in line with the intended use.
• Building for clinicians without clinicians. A workflow that adds clicks gets abandoned within weeks. Put a practicing clinician in every design review.
• Treating the EHR integration as an API call. The code takes weeks. Approvals, data mapping and testing at each site take months.
• PHI in push notifications. "Your HIV test result is ready" on a locked screen is a disclosure. Say "You have a new message" and show details after login.
• One database user for everything. Shared credentials make audit logs useless. Every person and service gets its own identity.
• Skipping the pilot. Launching to ten clinics at once multiplies every workflow bug by ten, with ten support channels.

Medical app readiness checklist

Tick what is already true. It shows how close you are to putting the app in front of patients or clinicians.

FAQ

Where Gilzor fits

We design and build healthcare software: native and cross-platform mobile apps, web portals, integrations and QA. For a US blood testing laboratory, our team built native iOS and Android apps plus web apps that connect patients, doctors and phlebotomists from online consultation to results, working with US attorneys on HIPAA authorization. For a mental health startup, we built a mobile app that reads heart rate and breathing from wearables over Bluetooth Low Energy and suggests calming exercises. We work from Poland and Cyprus, with a few shared hours a day with the US East Coast.

Send us your intended use, the roles who will use the app and the systems it must connect to. We'll help you answer the four scoping questions and cut a first version one clinic can pilot.