We develop mobile applications for electronic medical records (EMR) that solve a fundamental contradiction: data must be instantly accessible to physicians while being protected at the level of strict regulatory requirements. The goal is not just to display visit history but to provide secure access to personal medical data with the highest security class (HIPAA, 152-FZ) and UX that allows opening the needed record within 10 seconds in a clinic setting. Leveraging experience from dozens of healthcare projects, we guarantee compliance with jurisdictional requirements and integration with existing MIS. Our solution saves up to 40% of budget compared to purchasing a ready-made EMR.
Regulatory Frameworks — Foundation of Architecture
Choice of jurisdiction determines: where hosting is located, which encryption and logging are mandatory, whether Firebase Analytics can be used, and what notifications must be shown to the user.
- Russia. Ministry of Health Order №947н (EMD structure), Federal Law 323 "On the Basics of Health Protection", Federal Law 152 on personal data. Data — special category of personal data, processing only with explicit consent. Server — only within Russia.
- Europe. GDPR (special categories of data art.9), national implementations (e.g. DSGVO in Germany). Right to access, right to erasure.
- USA. HIPAA: Protected Health Information (PHI), Business Associate Agreement with every subcontractor, per HIPAA Privacy Rule, audit log for every access to patient data.
How Do Doctor and Patient Roles Affect Access Architecture?
At least two completely different users:
Patient. Sees their own data: history, diagnoses, lab results, prescriptions, allergies. Can display a QR for emergency access (no authentication — only critical data: blood type, allergies, chronic diseases). Manages consents for data processing by specific clinics.
Doctor / medical staff. Accesses patient data only within an active encounter. Access to records from another clinic — only if the patient has given consent. Every view is recorded in an audit log (WHO accessed WHAT at WHEN).
Audit log is not an optional feature under HIPAA; it is a mandatory requirement. Log entry structure: userId, resourceType, resourceId, action (view/edit/export), timestamp, ipAddress, deviceId. Stored for at least 6 years (HIPAA) or 3 years (Russia per 152-FZ).
Encryption and Storage
EMR data is never stored in plaintext on the device. Offline caching scenario for the doctor:
iOS: Core Data with encryption via NSPersistentStoreDescription + NSFileProtectionCompleteUnlessOpen. Encryption key in Secure Enclave with biometric protection.
Android: Room + EncryptedSharedPreferences + SQLCipher. Key in Android KeyStore with setUserAuthenticationRequired(true).
Data transmission: TLS 1.3 mandatory, TLS 1.2 allowed with restrictions. Certificate pinning. For inter-organization exchange — HL7 FHIR R4 as interoperability standard.
Case Study: Integration with a Laboratory System
After auditing the client's requirements, we designed a FHIR model including Observation, DiagnosticReport, and Specimen resources. We implemented a REST client on Flutter with an offline cache. Testing covered scenarios: 200 concurrent physicians, response time < 2 seconds. The project was completed in 2.5 months.Typical Threats and Their Mitigation
| Threat | Mitigation Measure |
|---|---|
| Unauthorized device access | Biometrics + encryption |
| Network data interception | TLS 1.3 + certificate pinning |
| Leak via synchronization | Local encryption, prohibit cloud backups |
| Unauthorized API access | OAuth 2.0 + JWT, rate limiting |
| Reverse engineering of the app | ProGuard/R8 (Android), code obfuscation (iOS) |
Why FHIR R4 as the Integration Standard?
If the EMR must integrate with other MIS, HL7 FHIR R4 is the de facto standard. Resources: Patient, Observation, Condition, MedicationRequest, DiagnosticReport, Encounter. Our solutions integrate with FHIR 2x faster than typical integrations thanks to team experience.
On mobile — REST API to a FHIR server (HAPI FHIR, Azure Health Data Services, Google Cloud Healthcare API). iOS: no official FHIR SDK, we use Alamofire + custom Codable models. Android: Google's android-fhir SDK (official, supports offline sync via FHIR Structured Data Capture).
Example request for patient observations:
GET /fhir/Observation?patient=Patient/123&category=vital-signs&_sort=-date&_count=20 Medical Data in the UI
Some elements are specific to medicine:
Reference range norms. A lab result "Glucose: 7.2 mmol/L" must be shown with context: normal range 3.9–6.1, previous value 6.8, rising trend. Charts/MPAndroidChart for trend graphs.
Drug interactions. If the app shows prescriptions, DDI (drug-drug interactions) checking is needed — via DrugBank or RxNorm API. This is a separate scope.
Emergency QR. An offline-accessible QR without authentication containing only critical data in Smart Health Cards or FHIR Patient Summary format. Generated and cached during the last online session.
How to Ensure Security of Medical Data?
- Implement data encryption on the device (SQLCipher, Core Data with NSFileProtection).
- Use biometric authentication for access.
- Configure certificate pinning and TLS 1.3 for transmission.
- Apply ProGuard/R8 on Android and code obfuscation on iOS.
- Set up remote wipe via MDM if the device is lost.
What Is Included in the Work
- Audit of regulatory requirements and alignment with the client
- Architecture design (FHIR model, access scheme, audit log)
- Mobile application development (iOS/Android/cross-platform)
- Implementation of encryption and secure storage
- Integration with FHIR server and external systems
- QA and penetration testing
- Documentation and user instructions
- Support during release to App Store / Google Play
Which Scenarios Should Be Tested Separately?
Scenario "doctor lost phone": patient data on the device must be destroyed via remote wipe (MDM) or inaccessible without biometrics after N minutes of inactivity.
Scenario "patient deceased": what happens to trusted persons' access? This is not a technical question — it is legal, but it affects the consent architecture.
Process
| Stage | Content | Duration |
|---|---|---|
| Requirements audit | Jurisdiction, roles, integrations (MIS, labs) | 1 week |
| Design | FHIR resources, data model, access schema, audit log | 1–2 weeks |
| Core development | Authentication, patient profile, medical record, prescriptions | 4–6 weeks |
| Encryption & security | Offline storage, SE/StrongBox, certificate pinning | 1–2 weeks |
| Integrations | FHIR server, lab systems, push | 2–3 weeks |
| QA + security audit | Penetration testing, audit log verification | 1–2 weeks |
Full MVP — 2–3 months. An app with full FHIR integration, doctor and patient support, HIPAA-compliant audit log — closer to three months. Timelines and costs for each project are evaluated individually after analyzing requirements and selected jurisdiction. Request a preliminary consultation to evaluate your project. Receive a fixed estimate based on requirements.