The first healthcare system deploy we shipped met every functional requirement and failed 60% of its security controls.
Three weeks of rework for encryption, audit logs, and session management that could have been solved in week one if the architecture had accounted for them from sprint zero.
In healthcare, regulatory decisions are architecture decisions, and postponing them multiplies the cost later.
How HIPAA, FDA, and GDPR shape architecture
Before picking a framework or a cloud provider, you need a threat model and a data flow diagram.
The threat model identifies what data qualifies as PHI under HIPAA or as sensitive data under GDPR, and that determines concrete decisions across the whole application.
Encryption is the most direct example. HIPAA requires encryption in transit and recommends it at rest for PHI, meaning TLS 1.3, AES-256 at rest, and key management through an HSM.
Authentication changes too: a plain email and password login is not enough. OpenID Connect with mandatory MFA for any clinical role satisfies both HIPAA and GDPR.
Every action on PHI needs an immutable audit record covering who, what, when, and from where.
- HIPAA requires TLS 1.3 encryption in transit and recommends AES-256 for PHI at rest, with key management through an HSM.
- GDPR requires explicit patient consent for every cross-organization integration, with documented authorization flows.
- The FDA classifies as SaMD any algorithm that influences clinical decisions, adding traceability requirements to CI/CD.
An EMR is a patient's digital record within a single practice, while an EHR adds the ability to share that information across organizations.
Every EHR integration needs its own authorization flow and consent record under GDPR or HIPAA's minimum-necessary rule.
If the software qualifies as an FDA medical device, code traceability and risk-benefit documentation get added to the pipeline, with every merge to main needing evidence of automated testing and review.
Interoperability with FHIR, HL7, and DICOM
FHIR, HL7, and DICOM are not just standards in a compliance document, they are data formats and protocols that require real integration work: adapters, transformations, and end-to-end tests against real systems.
FHIR became the dominant standard for health APIs, exposing resources like Patient and Observation as JSON, accessible for a team with REST experience.
The trap is in the profiles: each FHIR implementation can define different required fields, and your adapter needs to validate against the specific profile you are integrating with. A Nest.js backend with schema validation keeps this maintainable.
HL7 v2, the legacy format most hospitals still use for admissions and lab results, works with pipe-delimited messages that need specific parsers.
Integrating with HL7 v2 typically involves an adapter that transforms messages into FHIR resources, with robust error handling since real-world messages arrive with missing fields and inconsistent encodings.
A DICOM image is not just an image file, it includes patient metadata, study parameters, and equipment calibration data.
Validating one means checking metadata integrity and confirming headers match your system's record, across modalities and compression variations.
Standard | Main use | Integration challenge |
|---|---|---|
FHIR | REST APIs between modern systems, resources like Patient and MedicationRequest in JSON | Each implementation defines profiles with different required fields |
HL7 v2 | Admissions and lab results in legacy hospital systems | Messages with missing fields, inconsistent formats, unexpected encodings |
DICOM | Medical images with patient, study, and equipment metadata | Validating pixel integrity and header consistency across modalities |
For a telemedicine platform, this all converges.
You need a cross-platform frontend (Flutter for mobile, Next.js for web) talking to a backend in Kotlin or Nest.js through OAuth 2.0-protected APIs, with every hospital integration going through adapters tested against each provider's profiles.
At Somnio we have worked with this architecture on chronic-patient monitoring apps integrated with wearables that measure heart rate through the phone camera.
AI and realistic development timelines
AI in a medical product works as a layer inside the app, always with a human in the loop. A model that analyzes retina images or suggests ICD-10 codes from clinical notes adds real value, but a clinician validates, corrects, or rejects each suggestion.
That validation needs its own audit flow, and if the model influences clinical decisions, the FDA classifies it as SaMD with validation requirements proportional to risk.
A functional MVP with authentication, encryption, audit trails, and a basic FHIR integration takes 12 to 16 weeks with a team of 4 to 6 people.
"Functional" and "compliant" are different milestones: full HIPAA certification requires penetration testing, documented risk assessment, and organizational policies beyond code, typically adding 4 to 8 more weeks, the kind of landscape we map out in our look at healthcare products in 2026.
- Weeks 1 to 4: discovery, threat model, data flow diagram, security architecture, and CI/CD pipeline setup.
- Weeks 5 to 12: building the product core with encryption, auth, audit trails, and the first interoperability integrations.
- Weeks 13 to 16: penetration testing, remediation, compliance documentation, and audit prep.
The cost of getting this wrong is measurable. Healthcare remains the most expensive industry for data breaches, averaging 7.42 million USD per breach according to IBM's 2025 Cost of a Data Breach Report, its 14th consecutive year at the top.
Against that number, investing in compliant architecture from sprint zero stops being a technical decision and becomes the most profitable one in the project.
If your team needs to scope this before committing a timeline, a discovery sprint maps the regulatory landscape upfront, and staff augmentation covers gaps for teams without compliance-experienced engineers in-house.
Frequently asked questions
Do I need to comply with HIPAA if my product operates outside the US?
It depends on where the data resides and who the users are. If the product processes data for US patients or integrates with US health systems, HIPAA applies regardless of where the team sits. European products also need GDPR in parallel.
What is the difference between a SaMD product and clinical support software?
The FDA classifies software as SaMD when its function directly influences a clinical decision, like suggesting a diagnosis. Software that simply displays information without interpreting it does not qualify, though it may still need HIPAA or GDPR compliance if it handles PHI.
Can a standard database like PostgreSQL be used in a compliant healthcare system?
Yes, with the right configuration: encryption at rest, role-based access control, and audit logs sent to a separate, immutable store. The issue is usually the default configuration, not the technology.
How hard is it to integrate wearables into a compliant health platform?
Wearables introduce a continuous stream of biometric data that qualifies as PHI once tied to an identifiable patient. Integration requires end-to-end encryption from device to storage and validating that the manufacturer's SDK does not send data externally without user authorization.
When does it make sense to bring in an external compliance audit?
Before launching to production with real users, especially if the product handles PHI. An external audit catches gaps internal teams often miss, and remediation before launch costs far less than a breach or a fine after.
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.
