01
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
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.
01
$4.99M
Global average cost of a data breach
IBM’s 2026 report puts the global average at $4.99M, “a 12% increase over last year and a record high”. Audit logs, access control and encryption cost far less to build in than a breach costs to clean up.
Source: IBM, Cost of a Data Breach Report 2026(opens in a new tab)02
164.312(b)
Audit controls, in the rule itself
The HIPAA Security Rule calls for mechanisms “that record and examine activity in information systems”. We build audit logging in from the first sprint.
Source: 45 CFR 164.312, via Cornell LII(opens in a new tab)03
DTAC
The NHS baseline for digital tech
The NHS: “If you want your technology to be used in the NHS and social care, it needs to meet the standards set by the DTAC.” We prepare the technical evidence as we build.
Source: NHS AI and Digital Regulations Service, DTAC(opens in a new tab)
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.
| Safeguard | What we build into the app | What your organization owns |
|---|---|---|
| Audit controls (164.312(b)) | Logs that record who viewed or changed health data, and when | Reviewing 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 path | Who 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 service | Recording the decision in your risk analysis |
| Integrity and authentication | Tamper-evident records, strong sign-in and multi-factor authentication | Your identity and password policies |
| Vendors | Hosting and services that offer business associate agreements, flagging any that don’t | Signing a BAA with each vendor that handles PHI |
| Policies and people | Technical documentation to support your risk analysis | Policies, 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 pageFIG 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.

02
Telehealth and video visits
03
Remote patient monitoring and wearables
04
Clinician and care-team tools
05
Practice and clinic management
06
EHR integration
07
Security engineering
08
Accessible patient UX
Deliverables
12
deliverables, in writing
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
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
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
Data integration
- Standards
- HL7 FHIR R4, and HL7 v2 where needed
- Includes
- Mapping, validation and error queues
- Why
- Records that agree everywhere
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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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
Startups
From MVP to your first health system deal.
Digital health startups that need to launch fast without building something that stalls in a health system’s security review later.
- MVP scope with safeguards built in
- Device-status check early
- Investor-ready demo
- Architecture that scales
UK and NHS
Built for the NHS pathway.
UK products heading for NHS buyers, run through our London client partner with engineering in New Delhi. We build to DTAC, support your Clinical Safety Officer under DCB0129 and design for UK GDPR.
- London client partner
- DTAC evidence as we build
- Hazard-log input for your CSO
- UK hosting on request
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.
New York
North America
--:--ET
New Delhi team Your working day- Shared working time
- ≈ 3 hours today
- New Delhi is
- 10.5 h ahead
- Live calls, your time
- 9 a.m. to 12 p.m. ET
London
UK & Europe
--:--UK
New Delhi team Your working day- Shared working time
- ≈ 4.5 hours today
- New Delhi is
- 5.5 h ahead
- Live calls, your time
- 9 a.m. to 1:30 p.m. UK
Three ways to work together
- 01
Fixed-scope project
A written scope, one fixed price and a dated plan. Suits websites, apps and MVPs.
- 02
Dedicated team
Designers and engineers on your roadmap every month, billed monthly.
- 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
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.
| Driver | Why it moves cost and time | How to keep it down |
|---|---|---|
| Platforms | iOS, Android, web and wearables each add build and test work | Start cross-platform, or with the platform your patients use most |
| EHR integration | Vendor access, sandboxes and approvals add steps outside your control | Start read-only with FHIR, then add write-back |
| Compliance evidence | HIPAA risk analysis support and DTAC or DCB0129 evidence take real time | Build the evidence as you go, not at the end |
| Device status | A medical device pathway adds documentation and testing | Decide intended use and claims early |
| Video, messaging and devices | Real-time features and Bluetooth devices add complexity | Use proven vendors for video and messaging |
| Accessibility and testing | Patients use older devices and assistive technology | Design 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 guideFIG 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.
| United States | United Kingdom | |
|---|---|---|
| Main data rules | HIPAA Privacy and Security Rules, for covered entities and business associates | UK GDPR and the Data Protection Act 2018 |
| Selling to health organizations | Security reviews and BAAs with each vendor that handles PHI | NHS DTAC, plus DSPT for organisations with access to NHS data |
| Clinical safety | Device rules where the software is a medical device | DCB0129 for manufacturers and DCB0160 for NHS deployers |
| Medical devices | FDA, including Software as a Medical Device | MHRA |
| Who signs off | Your compliance and privacy officers | Your Clinical Safety Officer, your DPO and the NHS buyer |
| What we do | Build the safeguards and the evidence | Build 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 telehealth platform | Off-the-shelf patient portal | |
|---|---|---|---|
| Fits | Your clinical workflow and brand exactly | Standard visits under your brand | Your EHR vendor’s standard features |
| Integration | Any EHR or system with an API | What the platform supports | Built into one EHR |
| Running cost | Hosting you own, plus maintenance | A subscription per provider or per visit | Usually part of your EHR contract |
| Differentiation | High | Low to medium | Low |
| Best for | New care models and digital health products | Getting a standard telehealth service live | Practices 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.
FIG 18 · Related
Keep exploring
Telemedicine App Development
Video visits, e-Rx, RPM & FHIRApp Development
iOS, Android & cross-platformFlutter App Development
One codebase for iOS & AndroidIoT App Development
Connected devices & wearablesWeb Portal Development
Customer, partner & employee portalsCloud & Deployment
Hosting, CI/CD & DevOpsApp development, New York
iOS, Android & AI apps on Eastern Time
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.
Pick a day for your call
OpenPick a day. You'll choose a time in your own time zone on the next step.






