Kenya Patient Summary FHIR Implementation Guide
0.1.0 - ci-build
KE
Kenya Patient Summary FHIR Implementation Guide - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
This section defines the system actors involved in Kenya Patient Summary data exchange and the transactions between them. These actors map to the roles and systems described in the Kenya Health Information Architecture.
Health information systems operating at the facility or community level that capture clinical data and generate patient summary data.
Examples: KenyaEMR, Afya eCHIS, FunSoft HMIS, OpenMRS, proprietary hospital management systems.
Responsibilities:
Required capabilities:
POST /Bundle to submit patient summary bundlesGET /Patient/$summary or GET /Bundle?patient={id} to retrieve patient summariesPOST /Patient/$match for patient identity resolutionThe national interoperability middleware operated by the Digital Health Agency of Kenya (DHA). It serves as the central routing, validation, and coordination layer for all KPS data exchange.
Responsibilities:
Required capabilities:
The longitudinal health record repository maintained within the Kenya HIE that stores the accumulated patient summary data contributed by all Point-of-Service Systems.
Responsibilities:
The national identity resolution service that maintains Unique Patient Identifiers (UPI) and de-duplicates patient identities across systems.
Responsibilities:
$match)The Kenya Health Terminology Service, managed by DHA, that hosts all code systems and value sets used in this IG.
Responsibilities:
$expand and CodeSystem $lookup operationsThe national Monitoring & Evaluation (M&E) and disease surveillance platform that consumes de-identified or aggregated patient summary data.
Responsibilities:
| ID | Transaction Name | Initiator | Responder | FHIR Operation | Trigger |
|---|---|---|---|---|---|
| T-01 | Patient Identity Resolution | Point-of-Service System | Client Registry (MPI) | POST /Patient/$match |
Patient arrives at facility; system queries MPI to retrieve UPI |
| T-02 | Retrieve Patient Summary | Point-of-Service System | Kenya HIE / SHR | GET /Patient/{id}/$summary |
Clinician opens patient record; prior summary is fetched from SHR |
| T-03 | Submit Encounter Summary | Point-of-Service System | Kenya HIE → SHR | POST /Bundle (document type) |
Clinical encounter is completed; updated KPS resources are pushed to SHR |
| T-04 | Submit Referral Summary | Point-of-Service System (referring facility) | Kenya HIE → SHR / Receiving facility | POST /Bundle (transaction type) |
Referral is initiated; structured clinical summary is sent to receiving facility |
| T-05 | Emergency Patient Summary Access | Point-of-Service System (emergency) | Kenya HIE / SHR | GET /Patient/{id}/$summary |
Patient presents in emergency without being able to provide history; SHR is queried using ID |
| T-06 | Terminology Validation | Point-of-Service System or Kenya HIE | Kenya Terminology Server | GET /CodeSystem/$lookup, GET /ValueSet/$validate-code |
Coded elements in resources are validated against registered terminology |
| T-07 | Aggregate Data Reporting | SHR | Analytics Platform | Batch extract (de-identified) | Scheduled reporting cycle pushes aggregated, de-identified data to analytics platform |
The diagram below illustrates the high-level interaction pattern for the two most common workflows: patient encounter with SHR update and emergency patient summary access.
Encounter Workflow (T-01 → T-02 → T-03):
Emergency Access Workflow (T-05):
| Actor | SHALL | SHOULD | MAY |
|---|---|---|---|
| Point-of-Service System | Support T-01 (patient identity resolution) and T-03 (submit encounter summary) | Support T-02 (retrieve patient summary) and T-04 (referral summary) | Support T-05 (emergency access) and T-06 (terminology validation) |
| Kenya HIE | Accept and validate Bundle submissions; return OperationOutcome for failures; route to SHR | Log all transactions per IHE ATNA; support patient matching via MPI | Support real-time terminology validation |
| Shared Health Record | Store and version all received KPS resources; serve $summary operation |
Support FHIR document bundle generation for complete patient summary | Support subscription-based notifications to registered systems |