Prototype hub
Module 3 · SOW §4

FHIR R4 Foundation & API

The core resource/profile set for Phase 1, and the OpenAPI-documented API approach.

FHIR R4 is the foundational interoperability standard from day one, not a later add-on. Every clinical fact in the platform — a patient, an encounter, an allergy, a medication — is modelled and stored as a standard FHIR resource, so the same record that powers the provider interface is what a future national system, lab, or external EHR would consume. This is provable, not just claimed: open the FHIR icon in the top bar on any screen in this prototype to see the live R4 JSON behind whatever's on screen, or explore it directly in the FHIR Explorer.

Phase 1 resource set

Patient the hub every other resource references Organization tenant identity Practitioner clinician identity Encounter a visit / clinical event AllergyIntolerance critical safety data MedicationStatement active medications Consent sharing permission AuditEvent system-generated, read-only

API approach

REST + OpenAPI

Every resource is exposed as standard FHIR REST (GET /Patient/{id}, GET /Encounter?patient={id}, …), documented in OpenAPI so any integrating system gets a machine-readable contract, not just prose. See the API reference.

Consent-aware, audited

Every read and write carries the requesting actor's identity and is checked against RBAC and the patient's consent/treatment-relationship state before data returns — see Module 5. Every call is logged as an AuditEvent.

Comprehensive FHIR profiling (full SNOMED CT bindings, an extended resource catalogue, formulary integration) is a later phase — Phase 1 uses a pragmatic terminology subset (ICD-10 / a core drug list) sufficient to prove the connected-care journeys. See Roadmap.
← Data Model & MPI Next — Interoperability & Offline