The Kenya Health Information Exchange, Explained for Hospitals

Compliance · 8 min read · Updated 2026-10-28

The Health Information Exchange is the piece of the Digital Health Act that a facility actually touches every day. It is the national layer, run by the Digital Health Agency (DHA), that sits between your facility and everyone else who needs to know about a patient: SHA when you claim, another facility when the patient moves, the Ministry when you report.

If the Digital Health Act guide covers the why, this one covers the how: the parts of the exchange, what each one expects from your registration desk and your clinicians, and the questions to ask a software vendor who says they are "integrated".

This is a practical overview, not an official specification. The DHA publishes its own documentation and changes it, so check the current version before you build a process around any detail here.

The three registries: who, where and by whom

Almost everything on the exchange starts by identifying three things the same way everywhere.

The Client Registry: who the patient is

Every person in the Client Registry has a CR number. The registry is matched on national ID or other identification documents, and it records family relationships too, which is how a dependant is linked to the principal member whose cover they share.

For a facility this means identity has to be captured properly at registration. A national ID typed into a free-text notes field, or an ID number with a digit missing, is a patient the registry cannot find, and everything downstream (cover checks, claims, the shared record) stops with it. Children and others without an ID still have a CR number through the person they are registered under, so a good registration screen lets you look a patient up either way.

The Facility Registry: where care happened

Your facility has a code in the Facility Registry. It travels on every claim and every record you send, and it is what ties your facility to its KEPH level, its SHA contract and the services it is allowed to claim for. A system that does not hold your registry code, or holds the wrong one, cannot take part in the exchange at all. If you are not sure what level you are registered at, our guide to Kenyan facility levels explains why it matters.

The Health Worker Registry: who provided it

Clinicians are identified through the Health Worker Registry, which draws on the regulators' registers: the Kenya Medical Practitioners and Dentists Council, the Clinical Officers Council, the Nursing Council and others. When a claim or a record names the treating clinician, the exchange checks that name against the registry. A licence that has lapsed, or a registration number typed in the wrong format, is a claim held up for a reason that has nothing to do with the care given.

The Shared Health Record

The Shared Health Record (SHR) is a summary of a patient's care that follows them between facilities. When a patient consents, a facility sends the encounter to the SHR: the visit, observations such as vitals, and coded diagnoses. Another facility can then read it, again with consent.

The SHR speaks HL7 FHIR R4, shaped by the Kenya Core implementation guide, and it is strict. In practice it expects:

• Coded data. Diagnoses in ICD-11 and observations with standard codes, not sentences.
• Correct references between resources, so an observation clearly belongs to its encounter.
• National code systems. A local or internal code that the exchange does not recognise is refused.
• Recorded consent, tied to the visit, before anything is shared.

The practical lesson is that a system has to capture data in a structured way at the point of care. No amount of export formatting will turn a free-text diagnosis into a valid coded one later.

SHA claims run through the exchange

For most facilities the exchange matters first because of money. SHA eligibility checks, claims and preauthorisations run through it:

1. Cover check. The patient's CR number or ID is checked against SHA, which returns the schemes they are covered under.
2. Consent. The claim is opened with the patient's consent, by a one-time code to their phone or by biometric verification, depending on the facility and the patient.
3. Services and tariffs. Each service is chosen from SHA's benefit package, with its payment rule and the tariff for your facility level. Some need preauthorisation first.
4. Documents. SHA states the documents each service needs, typically including the signed claim form and the final bill.
5. Submission and review. The claim is submitted, reviewed, and either moves towards payment or comes back with a reason.

Our step-by-step guide on how to submit SHA claims goes through each stage and the most common reasons claims are returned.

What this asks of your facility

• Registration has to capture identity documents properly and link patients to their CR number.
• Clinicians need current registrations, and their details in the system need to match the regulator's register.
• Clinical records need coded diagnoses and structured observations, captured during the visit.
• Consent has to be asked for and recorded, at the point it is needed.
• Your software has to be connected to the exchange and kept up to date as DHA's requirements change.

Questions to ask a vendor that says it is "HIE integrated"

1. Which parts of the exchange does the system actually use today: client lookup, facility and health worker checks, the Shared Health Record, SHA eligibility, claims, preauthorisations?
2. What is its status with the Digital Health Agency? Ask for the actual stage, not "we are compliant".
3. Can it show a claim moving from cover check to submission in DHA's test environment?
4. How does it handle a patient without an ID, an emergency patient who cannot be identified yet, or a returned claim?
5. When DHA changes a requirement, who updates the system, and how quickly?

Where AfyaConnect stands

AfyaConnect connects to the exchange for client lookup by ID or CR number, facility and health worker registry checks, the Shared Health Record, and SHA eligibility, claims, preauthorisations and emergency claims. These flows have been run end to end in DHA's test environment. DHA certification is in progress, and we will say AfyaConnect is certified when it is, not before. The claims side is described on the SHA claims software page, and you can register your facility to see it with your own setup.