How DHA tests interoperability in Kenya

The short answer

Kenya now publishes its health-data exchange requirements as a layered set of FHIR implementation guides on the Digital Health Agency's own domain. A foundational guide called Kenya Core defines the base profiles and terminology. Domain guides for claims, patient summary and the cancer programme inherit from it and add their own.

For a vendor, that turns interoperability from a conversation into a test you can run yourself. Download the package for the guide you need, point the HL7 FHIR validator at your resource and read the error log. You do not need permission, an integration agreement or a meeting to find out whether your claim resource conforms.

The layer, and why it exists

The Kenya Core implementation guide describes itself as the national foundational layer, and states its purpose plainly: it is intended to be the national language for health data exchange, on which specialised guides build their own dialects.

Version 1.0.0 carries an active status and was published on 18 August 2026 against FHIR R4, version 4.0.1. It defines 25 profiles covering demographics, administrative resources and common clinical elements, alongside 42 value sets, 37 code systems and 6 extensions. It also sets base conformance rules for implementers covering naming, identifiers, FHIR version, RESTful API rules, security and provenance.

That version number matters when you read a vendor claim. Kenya Core reached 1.0.0. The domain guides that sit on top of it have not. The Kenya eClaims guide and the Kenya Patient Summary guide were both at version 0.1.0 with a draft status when this guide was written. Building against a draft is reasonable. Describing a draft as settled is not.

What the eClaims guide actually requires

For a dialysis provider the claims guide is the one that decides whether a submission is well formed. It covers six areas: claims submission, preauthorisation, claim response and adjudication, coverage and eligibility, clinical context, and payment notification. It defines 21 profiles, 37 extensions, 40 value sets and 40 code systems.

One design decision in that guide has more practical consequence than the rest. All coded data elements use a required binding strength. A required binding is the strongest available in FHIR: a code outside the value set does not produce a warning, it fails. Kenya-specific terminology is prioritised over SNOMED CT, so a system that maps to international codes and assumes they will be accepted will discover otherwise at validation time rather than at design time.

This is the concrete reason a facility should ask a vendor to show a validated resource rather than describe an integration. The difference between a warning and a failure is not a matter of interpretation here. It is declared in the guide.

The three things a validator checks

Reading a validator error log is easier when you know which kind of problem you are looking at. The three layers below are the same three the certification guide describes, seen from the implementer's side.

1. Syntax. Is this valid FHIR at all? Element names, cardinality and data types. These errors appear even without a guide package loaded.
2. Semantics. Does the resource make clinical sense and hold together by reference? A claim that references no patient fails here, as does a resource that does not satisfy a constraint the Kenya profile adds on top of base FHIR.
3. Terminology. Is each coded element drawn from the value set the guide binds it to? Under a required binding this is where a system built against international terminology usually fails first.

Vendors commonly test the first layer, sometimes test the second and rarely test the third until integration. Terminology is the layer that produces late surprises, and it is the cheapest one to test early.

How to run the check

The eClaims guide names the official HL7 FHIR validator as the recommended tool for conformance testing, and publishes the commands. Validating a single resource against the guide package takes this form:

java -jar validator_cli.jar path/to/your-claim.json \ -version 4.0.1 \ -ig fhir.kenyaClaimsIG#0.1.0 \ -recurse

Validating a bundle against a named profile takes this form:

java -jar validator_cli.jar path/to/claim-bundle.json \ -version 4.0.1 \ -ig fhir.kenyaClaimsIG#0.1.0 \ -profile <the profile canonical URL published in the guide>

The guide also points to the online validator at validator.fhir.org and to a hosted test server offering a validate operation.

What worked when this was checked

Publishing a command is not the same as the route behind it being available, so the cited guide pages and validator were checked again on 9 September 2026 and the result is recorded here rather than assumed.

• The guide pages themselves resolved and returned distinct content, and an invented path under the same host returned a genuine not-found rather than a default page.
• The eClaims package downloaded directly from the guide's own downloads page, at roughly 1.1 MB.
• The online validator at validator.fhir.org responded.
• The package registry path published for installation did not respond at that time, and the hostname given for the hosted test server did not resolve on the local resolver or on two public resolvers. These may be provisioned later.

The practical consequence is that a vendor can do the whole check offline today. Download the package from the downloads page, load it into the validator locally and read the log. Nothing in that route depends on a hosted environment being reachable. The endpoint observations above were made on 4 September 2026 and are not a permanent-state claim.

Check which version you are validating against

The implementation guides declare FHIR R4, version 4.0.1. A reference server published on the same domain advertises a later release in its capability statement. The two are close relatives and most resources behave the same way across them, but a validator run is only meaningful if you know which version produced it.

State the version explicitly on the command line, as the published commands do, rather than relying on a default. When you record a validation result as evidence, record the FHIR version, the guide package version and the date alongside it.

Common questions

Which FHIR version does Kenya use?

The Kenya Core implementation guide is published against FHIR R4, version 4.0.1. Domain guides such as eClaims declare the same version. Confirm the version your validator is running before reading its output, because a resource that passes against one version can fail against another.

Is there one Kenya implementation guide or several?

Several, arranged in a layer. Kenya Core is the foundational guide that domain guides inherit from. eClaims, Patient Summary and the cancer programme guide each build on it and add their own profiles, extensions and value sets.

Can I test a claim resource before integrating?

Yes. Download the guide package, then run the HL7 FHIR validator against your resource with the package loaded. That check is free, runs on your own machine and does not require a connection to any national environment.

Does passing validation mean my system is certified?

No. Validation checks that a resource conforms to a published profile. Certification is a separate assessment run by the Digital Health Agency across four domains, of which interoperability is one.

What to ask a vendor

1. Which Kenya implementation guides and which package versions do you build against?
2. Can you show a validator log for a real resource, including the FHIR version and the date it was run?
3. Which coded elements did you have to remap to Kenya terminology, and which are still mapped to international code systems?
4. How will you handle a guide moving from draft to a released version that changes a binding?
5. Which parts of your claim workflow are validated automatically before submission, rather than checked by a person?

A vendor that can answer these has done the work. A vendor that answers with the phrase HIE compliant has not yet been asked the right question. How to check whether a system is really DHA certified covers the certification side of the same problem.

Where Nanto Health fits

Nanto Health is a dialysis-specific electronic medical record and SHA claim-readiness platform for Kenyan facilities. It is not a general hospital-wide HMIS. Nanto Health does not currently claim DHA certification.

Interoperability is one of four equally weighted domains in the Agency's assessment, and validation against a published guide is evidence of conformance work rather than a certification result. Direct electronic submission remains gated by facility onboarding, testing, certification and production credentials. For the assessment as a whole, read DHA certification in Kenya. For the claim record itself, see SHA claim readiness.

Sources

Sources checked on 9 September 2026: the Kenya Core implementation guide, the Kenya eClaims implementation guide and its downloads page, and the Kenya Patient Summary implementation guide, all published by the Digital Health Agency. The HL7 FHIR validator was also loaded. Version numbers, publication dates, artefact counts, binding strength and the validator commands above are taken from those pages as published. Confirm the current guide versions and the current integration route with the Digital Health Agency before relying on any of this for a submission.