Healthcare software
Who gets to see a patient’s record?
I built a patient-owned health record that connects clinical work across facilities, with consent enforced where the data lives.
My role
I led engineering across the Flutter application and PostgreSQL backend, working with a clinical co-founder and three engineering interns.
Where it stands
Product in development. Core clinical workflows are implemented; scheduling is in progress. The portfolio interaction uses synthetic information.
What changed.
One longitudinal record, with patient, clinician, laboratory and pharmacy workflows built around it.
The problem
A patient’s history can be scattered across clinics, paper reports and separate systems. I wanted the record to follow the patient without making every person at every facility equally powerful.
The decision that shaped the system
I separated the interface’s permissions from the database’s authority. Roles, individual overrides, facility scope and patient consent are checked at the data boundary. A hidden button is useful guidance; it cannot be the security mechanism.
Making access visible
Cross-patient reads go through audited database functions. The patient can see an access history, grant or revoke sharing, and protect selected records. A QR health card carries an opaque identifier rather than medical information.
What is built
The implementation connects identity, patient timelines, clinical encounters, diagnostic orders, laboratory reports and pharmacy dispensing. I also built code-catalog validation and private file access. These are engineering controls, not a claim of clinical certification or complete medical-reference coverage.
What I would keep improving
The next delivery work includes scheduling and the surrounding operational workflows. AI summaries and external credential-dependent integrations are separate planned capabilities; I do not present them as live features.
The stack
- Flutter
- Dart
- PostgreSQL
- Supabase
- FHIR R4
- Row-level security