A team that starts building a telemedicine or patient engagement app without mapping regulations first ends up rewriting 30% to 40% of the code before reaching production.
HIPAA in the US, GDPR in Europe, and the FDA's Software as a Medical Device (SaMD) guidance are not layers added at the end.
They determine how the database is structured, where logs live, which endpoints stay exposed, and how every clinical data point flows from the patient's device to the server.
If your team is scoping a healthcare mobile app, let's talk through the compliance requirements before the architecture gets locked in.
If you need extra hands to get there, staff augmentation covers gaps for teams without compliance-experienced engineers in-house.
What defines the architecture of a healthcare app
- HIPAA requires encryption of PHI both at rest and in transit, role-based access control with a full audit trail, and a breach notification mechanism.
- GDPR adds the right to portability and erasure, forcing a data model with clean delete cascades and interoperable export formats from the first sprint.
Those constraints define which features are viable and how they get built.
A patient engagement app with video consultations, clinical messaging, scheduling, and remote vital-sign monitoring needs every module to inherit the same access and retention policies.
If the chat module skips the encryption and audit rules the medical records module follows, the app fails compliance evaluation as a whole.
The architecture has to be born with a centralized authorization middleware, with OAuth 2.0 and OpenID Connect as the standard.
How patient information gets protected
The threat model of a mobile healthcare app covers attack surfaces conventional apps do not face: a device can be stolen, rooted, or connected to a compromised WiFi network in a waiting room.
Each scenario needs a concrete technical answer, not a policy written in a PDF, the kind of rigor behind Flutter Health Audit.
On-device protection starts with file-level encryption using AES-256 for any PHI stored locally. On iOS, the Secure Enclave manages encryption keys without exposing them to user space.
On Android, the equivalent is the Trusted Execution Environment or StrongBox KeyStore. Key management strategy needs to separate data encryption keys from master keys, rotating master keys at least every 90 days.
For data in transit, TLS 1.3 with certificate pinning eliminates the most common attack window on public networks.
Every API call validates the server certificate against a hash embedded in the binary, rejecting any connection that fails that check even if the OS accepts it.
OAuth 2.0 session tokens should have a short TTL, 15 minutes as a good starting point, with refresh tokens stored in the device's secure keychain.
- Every read, write, modification, and deletion of PHI needs an immutable record with timestamp, user ID, IP, device fingerprint, and the data type accessed.
- Logs go to a separate bucket with a write-once policy, because if an attacker compromises the main database and can also delete audit logs, the breach stays invisible until it is too late.
How it integrates with EHR across platforms
EHR integration is where many healthcare projects stall. Legacy EHRs (Epic, Cerner, Allscripts) expose data through FHIR R4, the HL7 standard defining JSON resources for patients, encounters, observations, and medications.
A mobile app reading a patient's history needs a FHIR client handling SMART on FHIR authentication, a clinical-context OAuth 2.0 profile, and error handling when the EHR responds with multi-second latency.
The typical flow starts when the patient authorizes access in the EHR portal. The app receives an authorization code, exchanges it for a scoped access token, and uses it to query FHIR resources.
The token travels in the Authorization header on every request, never in query params, and the app has to handle the case where the EHR revokes access at any time.
Strategy | Codebases | Compliance impact |
|---|---|---|
Separate iOS + Android + Web | 3 independent codebases | Triple compliance surface, three independent security audits |
Flutter (single codebase) | 1 shared codebase | One encryption and audit-logging implementation, validated once and deployed to all three platforms |
At Somnio we work with this approach on healthcare projects like chronic-patient monitoring apps integrated with wearables that measure heart rate through the phone camera.
The stack combines Flutter as the presentation layer with Nest on the backend, Firebase for real-time sync, and AWS for HIPAA-enabled infrastructure, through our full product development service.
Kotlin and Swift come in when a specific module needs native access Flutter does not cover directly, like deep HealthKit or BLE sensor integration.
Timelines and clinical validation
A realistic timeline for a regulated healthcare app has four phases that cannot be compressed without generating technical debt that surfaces in the audit.
- Discovery (2 to 4 weeks): maps regulatory requirements, defines the threat model, documents PHI data flows, and produces wireframes validated with clinical stakeholders.
- MVP build (8 to 14 weeks): covers the security architecture, FHIR integration with at least one sandbox EHR, and core modules with complete encryption and audit trails. Clinical testing includes usability sessions with real health professionals, not just functional QA.
- Validation and compliance (4 to 6 weeks): runs penetration testing against the OWASP Mobile Top 10, a code review focused on PHI handling, and audit documentation prep. If the app qualifies as SaMD, the FDA requires verification and validation (V&V) documentation proving the software works as clinically specified.
- Launch and ongoing monitoring (2 to 3 weeks for initial deploy, ongoing after): configures security alerts, audit log anomaly monitoring, and an incident response process meeting notification timelines under each jurisdiction.
The total, from discovery to production, runs 16 to 27 weeks depending on EHR integration complexity and the regulatory level that applies, part of the broader landscape covered in our look at healthcare products in 2026.
If your team needs help scoping this, a discovery sprint maps the requirements before the architecture gets locked in.
Frequently asked questions
Do HIPAA and GDPR both apply if the app operates in both jurisdictions?
Yes. An app serving patients in the US and Europe must comply with both simultaneously. Since GDPR is stricter on erasure and portability, designing for GDPR first usually covers most HIPAA requirements, though notification timelines differ: 72 hours under GDPR versus 60 days under HIPAA.
Is Flutter an accepted option for apps that qualify as SaMD?
The FDA evaluates the development process and V&V documentation, not the specific framework. Flutter is valid as long as security implementation, testing, and requirements traceability meet FDA guidance for SaMD.
What happens if the EHR does not support FHIR R4?
Some legacy EHRs expose earlier versions or only offer proprietary APIs. In those cases, integration requires an adaptation layer translating resources to the app's data model, increasing development time and the surface that needs security review.
How often should penetration testing happen after launch?
Industry best practice recommends at least one annual pentest and an additional review whenever significant changes are introduced to the security architecture or EHR integrations. Continuous audit log monitoring complements those formal review cycles.
Does remote monitoring with wearables change the applicable regulatory level?
It can, if wearable data is used to make clinical decisions, since that may qualify the app as SaMD under FDA guidance. If the data is used only for engagement or wellness without influencing diagnosis or treatment, the regulatory level is usually lower.
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.
