A patient portal built to survive an audit

The provider needed a patient-facing portal for appointments, records, and secure messaging. Two previous vendor attempts had failed external security review — the second over access-control defects that would have exposed one patient's record to another. Internal confidence was low, and the clinical team was understandably sceptical a third attempt would differ. The portal also had to integrate with a patient administration system predating modern interoperability standards.

1. 01

   Ran threat modelling before any interface design. Knowing what an attacker would try shaped the data model, and several convenient shortcuts were ruled out on day three rather than discovered in a penetration test.

2. 02

   Built authorisation as a single enforced layer rather than checks scattered through request handlers, making the defect class that sank the previous attempt structurally difficult to reintroduce.

3. 03

   Encrypted data at rest and in transit, with field-level encryption on the most sensitive records and keys held in a managed vault the application cannot read directly.

4. 04

   Integrated the legacy patient administration system behind a FHIR-shaped internal API, isolating decades of quirks at one boundary instead of letting them leak through the codebase.

5. 05

   Commissioned independent penetration testing before launch rather than after, and budgeted remediation time on the assumption something would be found.

The portal passed external security review at the first attempt with no critical or high findings. Two medium findings were remediated inside the scheduled window. It launched to patients on the original date, and the FHIR-shaped internal boundary has since made two further integrations substantially cheaper than they would otherwise have been.

• TypeScript
• Next.js
• PostgreSQL
• Azure
• FHIR
• Terraform