Bluebird Health Platform

role
Full-stack engineer
client
Bluebird (health platform, Southern Africa)
stack
ASP.NET Core, Entity Framework Core, SQL Server, Docker
when
A few months
outcome
Built the "single pipe" API layer that lets any lab, regardless of source system, post results into Bluebird's national lab pipeline
demo
live
Screenshot of the Bluebird Health Platform homepage
Bluebird's public site — the lab-results API sits behind it, not the patient-facing surface

The product

Bluebird is a clinical platform used across the Southern African healthcare system, built over more than 25 years. It spans a hospital EHR designed around patient safety rather than billing, tools for doctors’ practices and long-term care facilities, a national communicable disease surveillance system, a lab results service that acts as a single API for results from any laboratory, and a Single Digital Patient Record built on FHIR.

During the COVID-19 emergency it ran as the conduit for lab results nationally for the South African National Department of Health, and powered the national track and trace system.

They have also since added AMES, which they position as a digital registrar rather than an ambient scribe: it listens to the consultation and produces the clinical note, lab and imaging orders, prescriptions with interaction checks, referral letters and billing codes.

(Written from their public site. Trim this to the parts you actually worked on.)

The problem

Reliably receiving a lab result is mission-critical for a doctor or a hospital ICU, but each lab sending results into the pipeline had its own format and its own point-to-point integration — slow to onboard, and each one a separate thing that could break, with a doctor’s or a hospital’s patient safety on the other end of the wire.

What I built

An ASP.NET Core API that’s the “single pipe” every lab posts results through, regardless of their source system, with JWT authentication and role-based access control scoped per lab, backed by Entity Framework Core against the results database. One integration surface for the pipeline instead of one per lab.

Decisions and tradeoffs

  • Standardized on FHIR for the interface even where a partner’s native format was something else, so onboarding a new lab means mapping their format once rather than the pipeline learning a new shape every time.
  • Per-lab JWT scopes rather than one shared credential, so a lab’s access can be revoked or rate-limited without touching anyone else’s.

Outcome

New labs onboard against one documented pipe instead of a bespoke integration each. No public number to point to — this is infrastructure a patient never sees directly, on a platform whose lab-results service has run for close to 30 years without missing a result during South Africa’s national COVID-19 response.