CEHR

Overview

CEHR is national-scale health infrastructure: a single, persistent record that follows a citizen across hospitals, clinics, pharmacies, laboratories and public-health systems. The screens are the surface. The backend is the engine (identity, interoperability, consent and auditability), and that's the part I built.

The problem

A patient's history is scattered across every facility they've ever visited, usually on paper. Doctors treat strangers. Records are lost when people move. And any system that fixes this holds the most sensitive data a person has, so it has to be strict about who may read what, while still letting a doctor act in an emergency.

The solution

• Patients create a health identity, manage family profiles, view their history across providers and control permissions.
• Providers (hospitals, clinics and labs) register, get verified and connect through a portal or API keys.
• Practitioners maintain profiles, certifications, availability and reviews.
• Records are created and retrieved through providers, with every access logged.
• Consent governs who can read a record, with an emergency override for when consent can't be given, and that override is itself audited.
• Public-health authorities get analytics and surveillance views.

Architecture

1. Clients

   • Patient app
   • Provider portal
   • Partner APIs (API keys)
   • Health authority dashboards
2. Identity & access

   • Auth + refresh tokens
   • Roles & role-change log
   • API keys
3. Domain modules

   • Patients
   • Providers
   • Practitioners
   • Records
   • Consent
   • Billing
   • Notifications
   • Analytics
4. Platform

   • Audit & access logs
   • Storage
   • Scheduled jobs
   • Monitoring
5. Data

   • Prisma ORM
   • SQLite in development
   • PostgreSQL in Docker

Engineering challenges

Break-glass access, done properly

Emergencies are where privacy systems usually fail: either a doctor is locked out when it matters, or there's a backdoor nobody watches. CEHR models the emergency override as its own record with its own audit log, alongside the consent audit log and a general access log. Overriding consent is possible, visible and attributable, and every override is granted to a named user, with a reason and a required expiry, so break-glass access ends on its own.

Every sensitive action leaves a trail

Role changes, refresh tokens, consent changes and record access are all written to dedicated logs, and a scheduled job prunes them after a configurable retention period (ninety days by default), so the audit trail itself doesn't become a privacy liability. In a system like this, the audit trail isn't a feature; it's what makes the rest of the system trustworthy.

Staged, testable delivery

The build followed a stage-by-stage test plan (auth, patients, providers, practitioners, records, consent, storage, then full regression), with fourteen end-to-end suites and a GitHub Actions workflow that type-checks the code and runs them on every push. Each stage had to pass before the next began.

Outcome

A working backend covering identity, registries, records, consent, billing, notifications, analytics and production hardening, delivered stage by stage with continuous integration. Design work for the patient and provider interfaces sits alongside it.

Lessons learned

• Design the exception first. How a system behaves in an emergency tells you whether its rules are real.
• Logs are part of the product when the data is someone's health.
• Stage the build so each layer is proven before the next depends on it.