Skip to content

FIG 01 · Healthcare App Development

Healthcare app development, built for HIPAA in the US and the NHS in the UK

Patient apps, telehealth, remote monitoring and clinician tools, built to the HIPAA Security Rule’s safeguards for US clients and prepared for NHS DTAC and DCB0129 assessment in the UK, with EHR integration through FHIR.

See how it works
Doctor and app developer testing a patient appointment app on a tablet in a bright clinic

FIG 02 · Quick answer

What is healthcare app development?

Healthcare app development is designing and building patient, clinician and telehealth apps that handle health data safely. Elgrith builds to the HIPAA Security Rule for US clients, with audit logs, access controls and encryption, and prepares UK products for NHS DTAC, DCB0129 clinical safety and DSPT, then integrates EHRs through FHIR.

Rulebooks we design for: HIPAA in the US, the NHS pathway in the UK
2
Projects delivered since 2015
1,000+
Clients across the USA, UK and India
250+
Your code, cloud accounts and data
100%

FIG 03 · Why it matters

Health data raises the stakes. The rules say how.

From IBM’s Cost of a Data Breach Report 2026, the HIPAA Security Rule (45 CFR 164.312) and the NHS AI and Digital Regulations Service, read in October 2026.

FIG 04 · US · HIPAA

HIPAA compliant app development (US): who does what

There is no HIPAA certification for apps, and no developer can make your organization compliant. HIPAA obligations sit with covered entities and their business associates. What a development team can do is build the technical safeguards the Security Rule describes and leave you clear evidence. Here is the split.

HIPAA safeguards: what we build vs what your organization owns
SafeguardWhat we build into the appWhat your organization owns
Audit controls (164.312(b))Logs that record who viewed or changed health data, and whenReviewing the logs and acting on what they show
Access control (164.312(a))Unique user IDs, role-based access, automatic logoff and an emergency access pathWho gets which role, and removing access when people leave
Encryption (addressable)Encryption in transit and at rest by default, with keys in a managed key serviceRecording the decision in your risk analysis
Integrity and authenticationTamper-evident records, strong sign-in and multi-factor authenticationYour identity and password policies
VendorsHosting and services that offer business associate agreements, flagging any that don’tSigning a BAA with each vendor that handles PHI
Policies and peopleTechnical documentation to support your risk analysisPolicies, risk analysis, workforce training and breach response

“Addressable” doesn’t mean optional: the covered entity assesses it and documents its decision. This summarizes the Security Rule in general terms; it isn’t legal advice, and your privacy and compliance advisers decide what applies to you.

Healthcare websites, SEO and hosting? See our healthcare industry page

FIG 05 · What you get

What healthcare apps we build

Mobile and web apps for patients, clinicians and care teams, designed around clinical workflows and built to the health-data rules in the US and the UK.

Phone showing a health app heart-rhythm line beside a stethoscope and a smartwatch
Healthcare App Development · built in-house

01

Patient apps and portals

Booking, records, results, medications, messaging and reminders, on iOS, Android and the web, accessible to every patient.

02

Telehealth and video visits

Scheduling, waiting rooms, encrypted video and visit notes, using video vendors chosen for health data.

03

Remote patient monitoring and wearables

Readings from Bluetooth devices, Apple Watch and Wear OS, through HealthKit or Health Connect, charted for care teams with alert thresholds clinicians set.

04

Clinician and care-team tools

Tablet and web tools for rounds, handovers, care plans and tasks, launched from or beside the EHR.

05

Practice and clinic management

Scheduling, intake forms, reminders and front-desk dashboards that sync with your practice system.

06

EHR integration

HL7 FHIR R4 and SMART on FHIR integrations, with mapping, validation and error queues so records agree.

07

Security engineering

Audit logs, role-based access, encryption and secure sign-in designed in from the first sprint.

08

Accessible patient UX

Designed and tested to WCAG 2.2 AA, with large targets, plain language and screen reader support.

Deliverables

12

deliverables, in writing

Included in every build, written into your fixed quote before work starts.

FIG 06 · Interoperability

EHR and interoperability: how your app connects

A health app is only as useful as the records it can read and write. We build to HL7 FHIR R4 and SMART on FHIR, the standards EHRs such as Epic and Oracle Health (formerly Cerner) open to third-party apps. Access is granted by the EHR vendor and the health system, and we confirm the exact interfaces in discovery.

  • Patient phone
  • Wearable or device
  • Clinician tablet
  • Web portal
  • EHR via FHIR R4
  • Scheduling
  • Secure messaging
  • Audit log
  • Patient app

    Reads
    Appointments, results and medications via FHIR
    Writes
    Bookings and patient-reported data
    Sign-in
    SMART on FHIR where the EHR supports it
    iOS App Development
  • Telehealth visit

    Video
    Encrypted, via a vendor chosen for health data
    Before
    Booking, intake forms and a waiting room
    After
    Visit summary written back, if agreed
  • Remote patient monitoring

    From
    Wearables and Bluetooth devices
    To
    Readings stored and charted for the care team
    Alerts
    Thresholds set by clinicians
    IoT App Development
  • Clinician tool

    Where
    Tablet or web, inside or beside the EHR
    Launch
    SMART on FHIR EHR launch
    Why
    Fewer screens and less re-keying
  • Clinic portal

    Who
    Front desk and practice managers
    Does
    Scheduling, forms and reminders
    Data
    Synced with your practice system
    Web Portal Development
  • Data integration

    Standards
    HL7 FHIR R4, and HL7 v2 where needed
    Includes
    Mapping, validation and error queues
    Why
    Records that agree everywhere
    API Integration

FIG 07 · UK · NHS

Building for the NHS (UK)

Selling into the NHS has its own pathway. We build with it in mind and prepare the technical evidence; the assessments are run by the NHS organisations buying your product. This is general guidance, not legal or regulatory advice.

06principles

  • DTAC

    The Digital Technology Assessment Criteria cover clinical safety, data protection, technical security, interoperability, and usability and accessibility. We build to them and assemble the technical evidence as we go.

  • DCB0129 clinical safety

    The clinical risk management standard for manufacturers of health IT: a Clinical Safety Officer, a hazard log and a clinical safety case report. Your CSO owns them; we supply the design and test evidence they need.

  • DCB0160

    The deploying NHS organisation’s own clinical safety standard. We give their clinical safety team what they need to assess your product.

  • DSPT

    The Data Security and Protection Toolkit is the NHS self-assessment for organisations with access to NHS patient data and systems. We build the controls it asks about; your organisation completes it.

  • UK GDPR

    Health data is special category data under UK GDPR. We design for data minimisation and retention rules, and give you what you need for your data protection impact assessment.

  • UK hosting

    Hosting in UK regions where your NHS buyer or your own policy asks for it.

FIG 08 · Regulation

Is your app a medical device?

A health app can become a regulated medical device once its intended use is medical, such as diagnosing or guiding treatment. We flag this early; regulatory advice comes from specialists.

06principles

  • FDA: Software as a Medical Device

    The FDA describes SaMD as “software intended to be used for one or more medical purposes” that performs them “without being part of a hardware medical device.”

  • UK: the MHRA

    In the UK, the MHRA regulates software that is a medical device. If your app may qualify, plan for it before you build the features that cross the line.

  • Intended use decides it

    What your app claims to do, in the app and in your marketing, decides whether it is a device. We review feature lists and copy for wording that crosses the line.

  • Wellness vs medical

    Step counts and reminders are a different category from software that suggests a diagnosis or a dose. Where the line falls depends on intended use, so ask a regulatory specialist.

  • Evidence by design

    If you are on a device pathway, we keep requirements, risk notes and test records traceable, so your regulatory specialists have what they need.

  • Specialists, not us

    We are engineers, not regulatory consultants. We work alongside your regulatory adviser and build to their plan.

FIG 09 · Accessibility

Accessibility for patients

Patients include people with low vision, tremors, low literacy and screen readers, often on older phones. We design and test to WCAG 2.2 AA.

06principles

  • WCAG 2.2 AA

    Contrast, focus order, labels, target sizes and error messages checked against WCAG 2.2 AA on every screen.

  • Large text that holds up

    Layouts that survive Dynamic Type and Android font scaling without hiding buttons or clipping results.

  • Screen readers

    Tested with VoiceOver and TalkBack, with charts and results described in words.

  • Plain language

    Short sentences and clear next steps, especially around results, bookings and consent.

  • Motion and contrast

    Reduced-motion and high-contrast settings respected throughout the app.

  • Accessibility audits

    Audits and remediation guidance for existing apps and patient portals.

    Website accessibility

FIG 10 · Process · 7 steps

Healthcare software development company: how we work

Every phase leaves evidence behind: the artifacts your compliance team, your Clinical Safety Officer or a DTAC assessor will ask for. You own the code, the cloud accounts and the documents.

  1. Step 01

    Discovery

    Users, clinical workflows, data flows and the rules that may apply: HIPAA, DTAC, DCB0129, UK GDPR and device status. You get a data-flow map, a written scope and a fixed quote.

  2. Step 02

    Design

    Patient and clinician journeys designed and tested for accessibility. You get prototypes, WCAG 2.2 AA checks and hazard notes for your Clinical Safety Officer.

  3. Step 03

    Architecture and security

    Hosting, encryption, access model and audit logging designed before the build. You get the security architecture and a vendor list for BAAs or data processing agreements.

  4. Step 04

    Build in sprints

    Weekly demos on a test environment that uses synthetic data, not real patient records. You get tested code with audit logging covered.

  5. Step 05

    Integration and testing

    FHIR and EHR integrations tested against vendor sandboxes, plus security and accessibility testing. You get test reports and an issue log.

  6. Step 06

    Launch

    App store submission, production cut-over and monitoring. You get runbooks and an evidence pack for DTAC or your HIPAA risk analysis.

  7. Step 07

    Support

    OS updates, fixes and new features, on support terms agreed in your written scope.

FIG 11 · What you get

Everything included

Written into your fixed quote, so you know exactly what you are paying for before work starts.

12items

  • Data-flow map and rules summary
  • Written scope and fixed quote
  • Accessible patient and clinician UX
  • Security architecture
  • Audit logging and role-based access
  • Encryption in transit and at rest
  • FHIR and EHR integration
  • Test, security and accessibility reports
  • Evidence pack for DTAC or your HIPAA risk analysis
  • App store submission
  • Runbooks and admin training
  • Code, cloud accounts and docs, all yours

FIG 12 · Tech & tools

The tools behind the work

Proven, well-supported tools, chosen for your project and set up in accounts your business owns.

  • Swift
  • SwiftUI
  • Kotlin
  • Flutter
  • React Native
  • React
  • Next.js
  • Node.js
  • Python
  • PostgreSQL
  • HL7 FHIR R4
  • SMART on FHIR
  • HealthKit
  • Health Connect
  • AWS
  • Google Cloud
  • Microsoft Azure

FIG 13 · Who it’s for

Healthcare apps for providers, startups and digital health teams.

In the US and the UK.

3 audiences

US providers

Apps built around your compliance team.

Clinics, practices and health systems in the US that need patient apps and portals built to the HIPAA Security Rule’s safeguards and connected to their EHR.

  • Technical safeguards built in
  • Vendors that offer BAAs
  • Epic or Oracle Health via FHIR
  • Evidence for your risk analysis

FIG 14 · Working with us from the USA and UK

Built in New Delhi. Run on your hours.

Every project gets a point of contact in New York or London and an engineering team in New Delhi. Here is how today’s working days line up, live.

Three ways to work together

  1. 01

    Fixed-scope project

    A written scope, one fixed price and a dated plan. Suits websites, apps and MVPs.

  2. 02

    Dedicated team

    Designers and engineers on your roadmap every month, billed monthly.

  3. 03

    White label

    For US and UK agencies: our work, your brand, unbranded deliverables.

Every engagement

  • Fixed quote in USD, GBP or INR after a free 30-minute call
  • NDA before discovery. You own all code, designs and content
  • A working demo every sprint, not status slides
  • Reply within one business day, calls inside your hours
Book a call

Calls on ET or UK hours

FIG 15 · Cost and timeline

What drives healthcare app cost and timeline

We don’t publish prices or promise timelines before discovery. These are the things that move both, for any healthcare app.

What drives healthcare app cost and timeline
DriverWhy it moves cost and timeHow to keep it down
PlatformsiOS, Android, web and wearables each add build and test workStart cross-platform, or with the platform your patients use most
EHR integrationVendor access, sandboxes and approvals add steps outside your controlStart read-only with FHIR, then add write-back
Compliance evidenceHIPAA risk analysis support and DTAC or DCB0129 evidence take real timeBuild the evidence as you go, not at the end
Device statusA medical device pathway adds documentation and testingDecide intended use and claims early
Video, messaging and devicesReal-time features and Bluetooth devices add complexityUse proven vendors for video and messaging
Accessibility and testingPatients use older devices and assistive technologyDesign to WCAG 2.2 AA from the first screen

After discovery you get a written scope, a phased plan and a fixed quote from us.

Read our 2026 healthcare app development cost guide

FIG 16 · US vs UK

US vs UK: health app rules side by side

The same app meets different rules on each side of the Atlantic. A summary, not legal or regulatory advice.

US vs UK: health app rules side by side
United StatesUnited Kingdom
Main data rulesHIPAA Privacy and Security Rules, for covered entities and business associatesUK GDPR and the Data Protection Act 2018
Selling to health organizationsSecurity reviews and BAAs with each vendor that handles PHINHS DTAC, plus DSPT for organisations with access to NHS data
Clinical safetyDevice rules where the software is a medical deviceDCB0129 for manufacturers and DCB0160 for NHS deployers
Medical devicesFDA, including Software as a Medical DeviceMHRA
Who signs offYour compliance and privacy officersYour Clinical Safety Officer, your DPO and the NHS buyer
What we doBuild the safeguards and the evidenceBuild to DTAC and supply evidence to your CSO

FIG 17 · Compare

Custom healthcare app, white-label platform or off-the-shelf?

Custom healthcare app, white-label platform or off-the-shelf?
Custom healthcare appWhite-label telehealth platformOff-the-shelf patient portal
FitsYour clinical workflow and brand exactlyStandard visits under your brandYour EHR vendor’s standard features
IntegrationAny EHR or system with an APIWhat the platform supportsBuilt into one EHR
Running costHosting you own, plus maintenanceA subscription per provider or per visitUsually part of your EHR contract
DifferentiationHighLow to mediumLow
Best forNew care models and digital health productsGetting a standard telehealth service livePractices that only need the basics

FAQ

Frequently asked questions

Straight answers about Healthcare App Development with Elgrith.

It depends on the platforms, the number of user types, EHR integration, video and device features, the compliance evidence you need and whether the app is a medical device. We don’t publish prices: after a free discovery call you get a written scope and a fixed quote. Our 2026 healthcare app cost guide explains published market ranges.

Free 30-minute call

Build it right before patients use it.

Tell us who the app is for and where it will be used. After a free discovery call you get a written scope, a rules summary for your advisers and a fixed quote.

connect@elgrith.com+91 96039 20001Start a project

Pick a day for your call

Open

Pick a day. You'll choose a time in your own time zone on the next step.

See all times