Hospital App Development: Mobile Guide to FHIR, Cost and Rollout

Hospital app development is the work of building mobile apps that let patients and staff use a hospital's own systems, usually through an EHR connection based on FHIR. In 2024, 81% of US hospitals already enabled patient access through apps, so the real decisions now are integration depth, rollout and cost.

A hospital app is a mobile application tied to one health system's records, scheduling and billing, as opposed to a general health app that works for any user. Hospital mobile app development therefore starts with the hospital's IT estate, not with a feature list.

Key takeaways

• In 2024, 81% of US non-federal acute care hospitals enabled patient access using apps, and 70% did so through FHIR-based access, per ASTP Data Brief No. 79 (August 2025).
• The gap is wide: large hospitals reached 94% app access against 76% for small hospitals, and hospitals on the market-leading EHR developer reached 92% against 70% for others (ASTP, 2025).
• The US certification criterion for patient and population APIs names FHIR Release 4.0.1 and SMART App Launch 2.0.0 as baseline standards (ASTP/ONC, 170.315(g)(10)).
• Cleveroad prices hospital apps from $60,000 to $110,000 without a direct EHR connection to $220,000 to $400,000 for a full multi-facility build (Cleveroad, updated September 2026).
• In England, the NHS App is linked to every acute trust and has 41 million registered users (NHS England, 2026).

Who this is for: hospital CIOs, digital leads and product owners, and the founders and CTOs building apps for them, in the US, UK and Australia or New Zealand. You will learn which hospital app to build first, how the EHR connection works, what it costs, and how hospitals buy and roll out apps. For general app types, store rules and regulation, read our companion guide to healthcare mobile app development.

Planning an integration-heavy build? Talk to our healthcare software development team about your EHR and rollout plan.

What is a hospital app, and how is it different from a patient portal?

A hospital app is the mobile front end to a hospital's systems, while a patient portal is the older web-based record viewer that many hospitals still run. The two often share the same EHR data, so choose terms carefully when you write a brief.

• Hospital app: mobile-first, covers appointments, results, messaging, payments and navigation for one health system.
• Patient portal: usually web-first and EHR-vendor supplied. ASTP reports that 99% of hospitals let patients view records electronically (ASTP, 2025).
• Clinic app: a lighter app for a practice with one or two sites. See the comparison table later in this guide.
• Hospital information system (HIS): the internal system of record. Building one is a separate, much larger program. See our healthcare software development guide.
• Telehealth app: built around video visits. We cover it in our telemedicine app development guide and in building a white-label telemedicine app.

Takeaway: Say which of these five you mean before you scope, because each has a different owner inside the hospital.

Which hospital app should you build first?

The patient app is the right first build when the aim is access and fewer missed visits, and the staff app is the right first build when the aim is internal speed. Do not start with both, because each needs its own EHR permissions.

Our guide to building custom medical billing software covers the payments side in more detail.

Takeaway: Pick the app with the lowest EHR dependence that still solves a real problem, then expand.

How does a hospital app connect to the EHR?

A hospital app connects to the EHR through APIs, and in the US those are increasingly FHIR APIs secured with SMART App Launch. FHIR is a standard for exchanging healthcare information electronically, built on resources as its basic building block (HL7).

SMART App Launch authorizes a user-facing app to connect to a FHIR server. It can pass context such as the currently selected patient, and it uses scopes to limit what the app may read or write (HL7 SMART App Launch). The current published version is 2.2.0.

The US certification criterion at 170.315(g)(10) sets the baseline: FHIR Release 4.0.1, SMART App Launch 2.0.0 with the Patient Access for Standalone Apps and Clinician Access for EHR Launch capability sets, and US Core 6.1.0 (ASTP/ONC). Build to those versions first, then support newer ones the hospital's EHR offers.

How common is FHIR app access in hospitals?

FHIR-based app access reached 70% of US hospitals in 2024, while any app access reached 81% (ASTP, 2025). The EHR vendor changes the odds: 83% of hospitals on the market-leading EHR developer had FHIR app access, against 56% for others.

Epic states that it offers over 750 no-cost APIs and interfaces and that almost 800 patient-facing apps are live through its individual access services (Epic on FHIR). Epic's page does not state a review process or listing fee, so ask the hospital team what its app approval route requires.

What does each integration involve?

Cleveroad notes that write access for scheduling is harder to obtain than read access, and that marketplace review often drives the effort more than the data format (Cleveroad). Plan for that in your timeline.

Takeaway: Treat the EHR connection as the critical path, and ask for sandbox access in week one.

Is the hospital's EHR ready for your app?

The readiness check below belongs in a session with the hospital IT team before you sign a scope. Each answer changes cost, timeline or risk.

Takeaway: A hospital that cannot answer these six questions is not ready to start a build.

Do hospitals have to let patients use third-party apps?

In the US, hospitals are bound by information blocking rules that discourage unreasonable interference with access to electronic health information. The Cures Act applies to healthcare providers, certified health IT developers, and health information exchanges and networks (ASTP/ONC).

Providers are covered when they know a practice is unreasonable and likely to interfere. HHS has also issued a final rule setting disincentives for providers that the HHS Office of Inspector General finds to have committed information blocking. That gives patient-facing app builders a basis to ask for API access, but not a right to production access on your timeline.

If a hospital contracts you to build its app, the privacy picture changes. HHS OCR concludes that a developer hired by a provider for patient management services, with data flowing into the provider's EHR, is a business associate (HHS OCR). A business associate must notify the covered entity of a breach no later than 60 days after discovery (HHS).

For regulation beyond hospitals, including FDA device policy, FTC rules and store policies, see our healthcare mobile app development guide.

Takeaway: Sign the business associate agreement before you receive any patient data, including test data drawn from production.

What does the UK and Australia version of this look like?

England and Australia use different gates from the US, and the app builder should plan for them early. In England, NHS England's DTAC is the assessment framework that commissioners and providers use for digital health technology, covering clinical safety, data protection, technical security, interoperability, and usability and accessibility (NHS England). An updated form applies from 24 February 2026, and the previous version should not be used from 6 April 2026.

The NHS App is already the main patient channel there. Hospital patients at every NHS trust in England can check referrals and appointments, about 64% of hospital appointments are visible, and referral and appointment views reached 8.7 million in March, up 93% year on year (NHS England, 2026). A standalone trust app must justify why it exists beside that channel.

In Australia, a software-based medical device must be registered with the TGA before supply unless an exemption applies, and the developer must decide its own status (TGA).

Takeaway: Outside the US, check the national assessment route and the national patient app before you design a standalone one.

Should a hospital build, buy or extend its EHR vendor's app?

A hospital should extend its EHR vendor's patient app when the needs are standard, and build custom when the experience or workflow is a point of difference. Most hospitals mix the two.

Our white-label telemedicine guide compares white-label and custom builds for the video-visit case, which is a useful reference when you weigh the last row.

Takeaway: Start with the smallest option that closes the gap, and build custom only for the parts that differentiate.

Which features should a hospital app include?

A hospital app should launch with the features that remove a phone call or a paper step: appointments, results, messaging and payment. Everything else can follow once usage data exists.

• Appointments: view, reschedule and cancel, with reminders. NHS England says many patients can now reschedule or cancel in the app, which should reduce missed appointments (NHS England).
• Records and results: a clear view with plain-language labels and a rule for delayed release.
• Secure messaging: routing to the right team, with response-time expectations shown.
• Billing: statement view, payment plans and receipts.
• Wayfinding: a campus map tied to the appointment location.
• Staff tools: secure messaging, on-call directory and alerts, scheduled with care for shift workers. Our guide to medical staff scheduling software covers the rostering side.
• Accessibility: large text, screen reader support and language options from the first release.

Takeaway: Launch with four patient features that cut calls, and measure each one.

How should a hospital app handle security and patient data?

A hospital app should hold as little patient data as possible on the device and send the rest through the hospital's secured services. The controls below are common team practice and should be confirmed in the hospital's own security review.

• Thin client design. Fetch records on demand over the FHIR API and avoid copying them into local databases.
• Scoped access. Request only the SMART scopes the feature needs, and document why for each one.
• Generic alerts. Push messages should not carry test names or diagnoses.
• Caregiver and proxy access. Model parents, guardians and carers as separate roles with their own permissions.
• Audit trail. Log who viewed or changed what, and keep logs free of record contents.
• Breach plan. Agree in the contract who investigates and who notifies, within the 60-day business associate window.

Takeaway: Hold less data on the phone, request fewer scopes, and write the breach plan into the contract.

How much does hospital app development cost?

Published estimates run from about $50,000 for a basic hospital app to about $400,000 for a full multi-facility build, and the EHR connection is the largest swing factor. Compare scope before price.

The sources agree on the shape: costs roughly double when EHR integration is added, and rise again when the app becomes multi-facility. Cleveroad assumes $50 to $80 per hour in its estimates.

Programs larger than an app are priced differently. Appic's healthcare software page lists enterprise hospital or EHR programs at $200,000 to $1M+ over 20 to 36 weeks.

Plan for yearly running cost too. Appinventiv puts maintenance and support at 15% to 20% of the initial development cost per year (Appinventiv).

Takeaway: Ask every vendor to price the EHR connection as a separate line, and compare only like scopes.

How do you roll out a hospital app step by step?

A hospital rollout works best as a staged pilot on one department, then a wider release. The plan below keeps clinical, IT and communications teams aligned.

1. Appoint owners. Name a clinical sponsor, an IT integration owner and a privacy lead.
2. Sign the paperwork. Complete the business associate agreement, security questionnaire and data processing terms.
3. Connect the sandbox. Build against test data and confirm every FHIR resource you need.
4. Pass security and clinical-safety review. In England, prepare the DTAC form at this stage.
5. Pilot in one unit. Choose a department with a motivated lead and a measurable pain point.
6. Measure and fix. Track activation, completion of the core task and support tickets.
7. Expand by wave. Add departments only when the pilot metrics hold.

Takeaway: Name a clinical owner and an IT owner before the first sprint, or the rollout stalls at review.

What is the difference between a hospital app and a clinic app?

A hospital app serves a multi-department organization with deep EHR dependence, while a clinic app serves a small practice with simpler needs. The scope gap explains most of the cost gap.

Small and independent hospitals sit between the two. ASTP found app access at 76% for small hospitals and 71% for independent hospitals, against 94% for large hospitals and 86% for system-affiliated ones (ASTP, 2025).

Takeaway: If you serve a clinic, scope it as a clinic app and skip the hospital integration layer.

How do hospitals buy apps, and how do you sell one into a health system?

Hospitals buy through a gated process led by IT, clinical and privacy teams, and a vendor wins by arriving prepared for each gate. Bulk or multi-facility deals follow the same gates with a longer pilot.

Agree the pricing unit early: per facility, per user or per patient. Multi-facility buyers compare on that unit across vendors.

Takeaway: Win the pilot with evidence on one problem, then use the same evidence pack for the next facility.

Which metrics show that a hospital app is working?

A hospital app is working when it removes a measurable manual step, such as a phone call, a paper form or a missed visit. Set the baseline before launch so the pilot has something to beat.

NHS England says rescheduling and cancelling in the app should reduce missed appointments, but it publishes usage figures rather than a no-show result (NHS England). Measure your own result instead of assuming one.

Takeaway: Pick two metrics tied to a cost the hospital already tracks, and report them weekly during the pilot.

What mistakes slow hospital app projects?

Hospital app projects slow down at integration and sign-off, not at coding. These are the patterns to avoid.

• Scoping features before confirming which EHR resources the hospital will release.
• Assuming read and write access come together.
• Leaving clinical content approval until after build.
• Launching to the whole hospital with no pilot.
• Duplicating the national or regional patient app with no clear added value.
• Pricing support as an afterthought, when yearly maintenance is a standing cost.

Takeaway: Fix ownership, access and review gates first, then write code.

Next step: plan your hospital app with Appic

Appic Softwares was founded in 2018 and works from Jaipur, Frisco in Texas and Munich. AI development is its largest service line, and it builds Flutter and React Native apps. Its Clutch profile shows a 5.0 rating, a minimum project size of $5,000 and an hourly rate under $25 (checked 2 November 2026); those are starting floors, not a price for an EHR-integrated hospital build.

Share your EHR, your first user group and your target facility count, and our team will help you shape a phased plan. Start with our healthcare software development services. If you are still choosing between app types, read the healthcare mobile app development guide first.

Takeaway: Bring an EHR name and one measurable problem, and you can get a useful estimate in a single call.