SPHERE
Secure Patient HEalth Record Exchange
Irish hospitals, GPs and pharmacies each run their own systems, and those systems don't talk to each other. During my MSc research at the University of Galway, our team surveyed and interviewed healthcare professionals and confirmed it in numbers most engineers wouldn't expect: an ease-of-access score of −50, and 80% reporting patients arriving without records or repeating a lab test that had already been done. SPHERE is my answer to that problem: a conceptual framework from the research, and a working local prototype I built to prove the architecture actually holds up in code.
MSc Information Systems Management Research Project
The idea
A translation layer, not a replacement
Rather than asking any hospital to abandon its existing EHR, SPHERE sits alongside them as a five-layer architecture. A small connector translates each system's own data into HL7 FHIR (healthcare's standard data-exchange format), pushes it into one secure cloud repository, and lets it flow back out again to whoever the patient has approved to see it.
SPHERE's five-layer architecture, from the MSc research report: the conceptual blueprint the prototype below is built from.
Local Healthcare Systems
The existing systems of record (hospital EHRs, GP software, pharmacy and lab systems, even insurance agencies) stay exactly as they are. Each remains the primary source of truth for what it already does well, and nothing about them has to change.
Integration Connector Layer
A FHIR-based interconnect sits beside each local system, never inside it, acting as translator in both directions. It extracts native data and converts it to HL7 FHIR on the way out, and maps a FHIR bundle back to native fields on the way in.
Central Cloud Repository
The aggregated single source of truth: medical history, prescriptions, allergies, labs and clinical notes, unified per patient. A version-control mechanism tracks every update for integrity, and a consent and governance layer decides who's allowed to read any of it.
Security & Access Control
Role-Based Access Control, encryption in transit and at rest, an intrusion detection system, and a blockchain audit ledger wrap the repository, so that every read and write is authenticated, restricted, and permanently logged.
Patient Application Layer
The one part of the system a patient actually touches directly: approve or deny access requests, review who has looked at their record and when, and request deletion. It's the governance layer made real, not theoretical.
What I built
From blueprint to a running system
I didn't stop at the framework. To actually prove the architecture, I built a working local prototype: independent services standing in for a hospital, a GP practice and the exchange itself, plus a real translation layer between them. Each one has its own backend, its own database, and its own field shapes, exactly as they'd be owned by separate organisations in the real world.
Epic & Evolve
Two independent mock systems, a hospital and a GP practice, each with its own Node.js/Express backend and its own database engine (Epic on MongoDB, Evolve on PostgreSQL), plus deliberately different native data shapes (one calls it "medications," the other "prescriptions"). That difference means the mapping layer has real translation work to do, not a trivial rename.
The Interconnect
A separate service, installed alongside each hospital's system the way a Stripe SDK is installed by a merchant, never editing the hospital's own code. It calls the local system's existing API, maps native fields to proper FHIR resources (Condition, AllergyIntolerance, MedicationStatement), and pushes a FHIR transaction Bundle to SPHERE.
An embedded widget, not a shared login
The doctor connects to SPHERE through a small widget embedded as an iframe, the same pattern Stripe Elements uses for card details. The hospital's own page never sees the doctor's SPHERE password: the two logins are deliberately, verifiably separate.
Consent, enforced in code
Every read of a patient's aggregated record is gated by a real access-control check, not a diagram. A patient's own portal lets them approve or deny each request, every access is permanently written to an audit log, and patients can request their record be deleted from SPHERE entirely, a working right-to-erasure, not just a policy claim.
Consent model
Three ways in, and the patient decides two of them
Matching the framework's design, access to a patient's record follows one of three paths, and every single one of them is written to the audit trail.
Pre-authorised
A patient's own trusted provider reads their record without re-approval on every visit.
New request
An unfamiliar provider triggers a real approval request straight to the patient's app, and nothing is shared until they say yes.
Emergency override
A clinician can bypass consent when it's genuinely urgent. It's logged immediately, and the patient is notified after the fact.
See it running
A quick walkthrough
Screenshots only go so far. Here's a walkthrough of SPHERE actually running: how data moves between two independent systems, Epic and Evolve, and how the patient stays in control of their own record the whole way through.
Limitations & future work
Where this stands, honestly
SPHERE is a conceptual framework backed by real interview and survey data, and a prototype that proves the architecture holds together in code. It isn't a legally reviewed, production-hardened product yet, and I'd rather say that plainly than gloss over it.
The research sample, while spanning multiple Irish healthcare roles, wasn't large. Integrating with genuinely legacy hospital systems will always be harder in practice than in a diagram, given how much varies between vendor agreements and API maturity. And while the framework was designed with GDPR and Irish healthcare regulation in mind, it hasn't been through formal legal evaluation.
None of that undercuts the architecture. It's the honest boundary between a well-grounded blueprint and a shipped product, and exactly where the next phase of work begins: hardening the prototype, deploying it to real cloud infrastructure, formal legal and compliance review, and testing it against a wider set of real-world systems.
Want to talk through the architecture?
I'm happy to walk through any part of this in more depth: the framework design, the FHIR mapping, or the consent model.