An app that collects clinical data and fails a HIPAA audit can cost more in fines than it cost to build. Penalties start at 100 USD per compromised record and scale up to 2.19 million USD per violation category per year.
That makes regulatory compliance the first architecture decision, well before picking a framework or a cloud provider.
Why HIPAA, GDPR, and FDA are not three separate checklists
The real problem is that HIPAA, GDPR, and FDA overlap, and sometimes conflict. HIPAA requires Protected Health Information (PHI) to be encrypted and audited with full traceability.
GDPR requires granular consent with the right to erasure, which can clash with the clinical data retention rules the FDA imposes when your app qualifies as Software as a Medical Device (SaMD).
Designing the architecture without mapping these tensions from day one generates rework that can double a project's timeline.
What separates apps that survive audits is treating every regulatory framework as an architecture driver, not a legal topic resolved at the end.
How that translates into engineering decisions
The data layer is where compliance becomes concrete. A FHIR-ready backend structures clinical information into standardized resources that simplify EHR interoperability and audits, since every piece of data follows a predictable schema.
At Somnio we typically build this on Nest.js with modules exposing FHIR R4 endpoints, connected to databases where PHI is encrypted at rest through AWS KMS or a dedicated HSM when the project requires it.
Consent needs its own service. A consent management module that logs every user action (what they accepted, when, which privacy notice version) with immutable timestamps solves both GDPR's right to be informed and HIPAA's accounting-of-disclosures requirement.
Storing consent as a boolean field on the users table is exactly what breaks an audit. For authentication, OAuth2 with OpenID Connect covers both the user session and service-to-service communication.
Adding device attestation verifies that the device accessing PHI is not rooted or compromised, blocking attack vectors that authentication alone does not cover.
- TLS 1.3 in transit sets the minimum protection floor for any data on the move.
- Static analysis runs on every pull request to catch hardcoded secrets or injection risks before production, the same rigor behind Flutter Health Audit.
- Dynamic analysis runs in staging before each release, closing the validation loop static analysis cannot cover at runtime.
- Structured logging automatically redacts sensitive fields and retains records for the period the applicable jurisdiction requires, so a security team can reconstruct any incident without touching plaintext PHI.
Where wearables and health APIs fit in
Device integration is where complexity multiplies, since each platform enforces its own rules for biometric data access.
Apple HealthKit requires granular permissions per data type and does not allow background reads without justification Apple reviews manually.
Google Health Connect on Android 14+ has a similar permission model with a different API and its own verification process.
For BLE wearables, sync needs a gateway that handles intermittent connectivity without losing data. A pattern that works well is using MQTT between the wearable and a local broker on the phone, which syncs to the backend once connectivity returns.
Maintaining two native apps (Swift for iOS, Kotlin for Android) with duplicated BLE, HealthKit, Health Connect, and consent logic multiplies the regulatory error surface, since every compliance fix needs replicating and testing in two repos.
With Flutter as the cross-platform vehicle, business logic, consent management, and audit flows live in one place, while platform channels handle native calls where needed.
At Somnio we apply this pattern on chronic-patient monitoring apps integrated with wearables that sync biometric data, including heart-rate measurement through the phone camera.
This approach validates that a single codebase with targeted native bridges reduces regulatory maintenance effort each release, through our full product development service.
What it costs and how long it takes
App type | Estimated timeline | Estimated budget |
|---|---|---|
Wellness app with no PHI (habits, meditation) | 3 to 4 months | 45,000 to 80,000 USD |
Remote patient monitoring with wearables, FHIR backend, and HIPAA compliance | 6 to 10 months | 90,000 to 180,000+ USD |
SaMD app with FDA regulatory process (510(k) or De Novo) | 3 to 6 additional months | Variable based on review complexity |
Figures reflect typical industry ranges as of early 2026 and vary by scope; treat them as a starting point for your own estimate, alongside the broader landscape we cover in our look at healthcare products in 2026.
A 2-to-4-week discovery sprint maps the applicable regulatory landscape, defines the real MVP scope, and avoids the rework that comes from starting without clarity on what data counts as PHI.
Its cost is marginal against the cost of correcting architecture decisions mid-build.
- Mean Time to Detect (MTTD) for security incidents, which should stay under 24 hours.
- Audit log coverage over operations touching PHI, targeting 100%.
- Consent collection success rate, measuring how many users complete the flow without abandoning.
- Response time to Data Subject Access Requests (DSAR) under GDPR, where the legal limit is 30 days but a well-designed system should resolve them in under 72 hours.
If your team is scoping a compliant health app right now, let's talk about what your discovery sprint should cover.
Frequently asked questions
Does my health app need to comply with HIPAA even if it operates outside the US?
HIPAA applies when the app handles PHI for patients covered by the US health system, regardless of where the server is hosted. If your app also processes EU user data, GDPR applies in parallel, meaning you likely need both frameworks at once.
What differentiates a wellness app from one that qualifies as SaMD?
The FDA considers an app SaMD when its core function is to diagnose, treat, prevent, or monitor a specific medical condition. A general meditation app does not qualify, but an app detecting arrhythmias from heart rhythm almost certainly does.
Why isn't storing consent as a boolean field in the database enough?
GDPR requires being able to show which privacy notice version the user read, when they accepted it, and what specific permissions they granted. A boolean field captures none of that, making it impossible to respond to an audit or a Data Subject Access Request with sufficient evidence.
Is Flutter a viable option for apps handling sensitive clinical data?
Flutter lets you implement consent management, encryption, and audit logic in a single codebase, while platform channels delegate native calls to HealthKit or Health Connect per platform. This reduces the regulatory error surface since each compliance fix applies once and gets tested on both platforms.
When does it make sense to run a discovery sprint before building the app?
Whenever the regulatory scope is not fully clear from the start, which is the most common situation. Discovery identifies whether the data the app collects qualifies as PHI, which frameworks apply, and what the real MVP is, avoiding costly rework once development is underway.
At Somnio Software, we work closely with companies to design and build high-quality digital products using modern technologies and development best practices.
If you're looking for a trusted partner to bring structure, expertise, and innovation to your next software project, we'd love to connect. Contact us to learn how we can help turn your product vision into reality.
