Electronic Health Record systems manage the most sensitive data in technology — patient medical histories, diagnoses, prescriptions, and lab results. Designing an EHR tests your understanding of strict regulatory compliance (HIPAA), data interoperability standards (HL7 FHIR), audit logging, role-based access control, and the unique challenges of healthcare data. This is a niche but increasingly common system design question, especially at health tech companies.
HIPAA Compliance Architecture
HIPAA (Health Insurance Portability and Accountability Act) governs how Protected Health Information (PHI) is stored, accessed, and transmitted. Technical requirements: (1) Encryption at rest — all PHI must be encrypted. AES-256 for database encryption (PostgreSQL pgcrypto or transparent data encryption). S3 server-side encryption for medical documents and images. (2) Encryption in transit — TLS 1.2+ for all API communication. No unencrypted PHI transmission. (3) Access controls — role-based access: doctors see their patients records, nurses see assigned patients, billing sees financial data only, and patients see their own records. Minimum necessary principle: each role sees only the data required for their function. (4) Audit logging — every access to PHI must be logged: who accessed what data, when, from where, and for what purpose. Audit logs are immutable and retained for 6 years minimum. (5) Business Associate Agreements (BAA) — every cloud provider handling PHI must sign a BAA. AWS, GCP, Azure offer HIPAA-eligible services with signed BAAs. Not all services are eligible — verify each one. (6) Breach notification — if PHI is exposed, patients and HHS must be notified within 60 days. Penalties: $100 to $50,000 per violation, up to $1.5 million per year per violation type.
Patient Data Model
Core entities following HL7 FHIR (Fast Healthcare Interoperability Resources) standard: (1) Patient — demographics: name, date of birth, gender, contact info, insurance, emergency contacts. Unique identifier: MRN (Medical Record Number). (2) Encounter — a visit: patient_id, provider_id, facility, date, type (outpatient, inpatient, emergency), diagnosis_codes (ICD-10), procedures. (3) Observation — clinical data: vitals (blood pressure, heart rate, temperature), lab results (blood glucose, cholesterol), and measurements (height, weight, BMI). Each observation: patient_id, code (LOINC), value, unit, date, status. (4) Medication — prescriptions: patient_id, medication_code (RxNorm), dosage, frequency, prescriber_id, start_date, end_date, status (active, completed, discontinued). (5) Condition — diagnoses: patient_id, code (ICD-10), onset_date, status (active, resolved), severity. (6) Document — clinical notes, imaging reports, discharge summaries. Stored as FHIR DocumentReference pointing to the actual document in S3. Database: PostgreSQL for structured clinical data (relational integrity for patient safety). S3 for medical images (DICOM format from CT/MRI/X-ray) and documents (PDF clinical notes). Elasticsearch for clinical search (find all patients with diabetes AND hypertension prescribed metformin).
Interoperability: HL7 FHIR API
Healthcare systems must exchange data: a hospital sends lab results to a patient primary care doctor. HL7 FHIR is the modern standard for healthcare data exchange. FHIR API: RESTful API with standardized resources (Patient, Observation, MedicationRequest, etc.). Each resource has a defined JSON structure. Example: GET /Patient/12345 returns the patient demographics in FHIR JSON format. GET /Observation?patient=12345&code=8867-4 returns all heart rate observations. Standard operations: read, search, create, update, delete, and history (version history of a resource). SMART on FHIR: an authorization framework for healthcare apps. Uses OAuth 2.0 with healthcare-specific scopes: patient/*.read (read all resources for the authorized patient), user/Observation.write (write observations as the authorized user). This enables third-party apps (patient portals, wearable integrations) to access EHR data securely. CDS Hooks (Clinical Decision Support): the EHR triggers hooks at key workflow points (prescribing a medication, ordering a test). External CDS services receive the clinical context and return recommendations (drug interaction warnings, guideline-based suggestions). Real-time interoperability. Data exchange patterns: (1) Pull — a provider queries another system FHIR API for patient data. (2) Push — a system sends data to another (lab sends results to the EHR via FHIR message). (3) Subscription — a system subscribes to notifications when specific data changes (notify me when a lab result is available for patient X).
Audit Logging
Every access to PHI generates an audit log entry. This is non-negotiable for HIPAA compliance. Audit log entry: timestamp, user_id, user_role, action (read/create/update/delete), resource_type (Patient/Observation/Medication), resource_id, patient_id (whose data was accessed), IP_address, user_agent, facility, and justification (why the access occurred — e.g., “treating physician,” “billing review”). Volume: a hospital with 1000 providers each accessing 50 patient records per day = 50,000 audit entries per day. A large health system: millions per day. Storage: append-only log in a separate audit database (not the same database as clinical data — separation of concerns and preventing audit log tampering). Use a write-optimized store: Kafka -> ClickHouse or AWS CloudTrail -> S3 + Athena. Immutability: audit logs must be tamper-proof. Write to an append-only store with no delete permissions. Use S3 Object Lock (WORM — Write Once Read Many) for archived audit logs. Alert on suspicious access patterns: a provider accessing records of patients not assigned to them, bulk record access (downloading many records), and access outside normal working hours. These may indicate insider threats or compromised credentials.
Clinical Decision Support and Safety
EHR systems have life-critical safety requirements: (1) Drug-drug interaction checking — when a provider prescribes a medication, the system checks all active medications for interactions. Severity levels: mild (informational), moderate (warning), and severe (hard stop — requires override justification). Interaction databases: First Databank (FDB), Multum, and RxNorm. (2) Allergy checking — before prescribing, check the patient allergy list. Alert if the prescribed medication or its class matches a documented allergy. (3) Dosage validation — verify the prescribed dose is within the therapeutic range for the patient age, weight, and kidney function. Alert on: overdose (exceeds maximum), underdose (below therapeutic minimum), and renal dose adjustment needed. (4) Order set templates — standardized order sets for common conditions (sepsis bundle, post-surgery care) reduce errors and ensure evidence-based care. These safety checks must be real-time (during the prescribing workflow) and reliable (false negatives — missing a dangerous interaction — are unacceptable). The CDS engine runs locally within the EHR (low latency) with a regularly updated drug database. Override tracking: when a provider overrides a safety alert, log the override with justification. Review overrides regularly for patterns indicating alert fatigue (providers clicking through all alerts without reading).
{“@context”:”https://schema.org”,”@type”:”FAQPage”,”mainEntity”:[{“@type”:”Question”,”name”:”What are the key HIPAA technical requirements for an EHR system?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”HIPAA mandates: (1) Encryption at rest — all PHI encrypted with AES-256. Database TDE or column-level encryption. S3 server-side encryption for documents/images. (2) Encryption in transit — TLS 1.2+ for all communication. No unencrypted PHI transmission. (3) Role-based access control — minimum necessary principle. Doctors see their patients, nurses see assigned patients, billing sees financial data only. (4) Audit logging — every PHI access logged: who, what, when, where, why. Immutable logs retained 6+ years. (5) Business Associate Agreements — every cloud provider handling PHI signs a BAA. Not all cloud services are HIPAA-eligible. (6) Breach notification — patients and HHS notified within 60 days of a PHI breach. Penalties: $100-$50,000 per violation, up to $1.5M per year per type.”}},{“@type”:”Question”,”name”:”What is HL7 FHIR and why is it important for EHR interoperability?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”HL7 FHIR (Fast Healthcare Interoperability Resources) is the modern standard for healthcare data exchange. It defines RESTful APIs with standardized resources: Patient, Observation, MedicationRequest, Condition, Encounter. Each resource has a defined JSON structure. Example: GET /Observation?patient=12345&code=8867-4 returns heart rate observations. SMART on FHIR adds OAuth 2.0 authorization with healthcare scopes (patient/*.read). This enables third-party apps (patient portals, wearable integrations) to access EHR data securely. CDS Hooks trigger external clinical decision support at key workflow points (prescribing, ordering). Data exchange: pull (query another system API), push (send results), subscription (notify on changes). FHIR is mandated by US regulation (21st Century Cures Act) for patient data access.”}}]}