Skip to content
← PACKS
Worked example

Kenya (`ke`) — a filled-out country pack

Eligibility not yet confirmed: Kenya's World Bank income classification is not stated on this page. To check whether your country is eligible for blueOpenHealthcare, see How to check your own country.

Status: a starting point, not a finished pack. This is one contributor's attempt to fill in the template for Kenya using only what could reasonably be sourced without a lawyer, a Kenyan health-IT specialist, or direct contact with NHIF/MOH/KMPDB/the Data Protection Commissioner. It is written to be handed to exactly such a person so they can correct it, answer what is marked open, and tell us what was gotten wrong. Every answer below is tagged for how confident it is — do not treat an [L] tag as equivalent to a verified fact.

Why Kenya for this worked example: Kenya's healthcare system is English-language-based at the IT and documentation level (parallel to the Philippines), but this document deliberately knows much less about Kenya's specific regulatory environment than about the Philippines. This example is designed to show what maximal honesty looks like when filling this template for a country where most fields require local expertise — not because the Philippines example is wrong, but to model a second, differently confident real country to show the honest ratio is not "three safe answers" but often closer to "five safe answers out of seventeen, and twelve need a local expert."

Confidence tags used below:

  • [L] — lay/general domain knowledge. Plausible, commonly stated, but not verified against a primary source (no access to Kenya's Data Protection Act guidance, NHIF technical specifications, MOH administrative orders, or KMPDB registration requirements was available while building this).
  • [SAFE] — a structural or internationally-standardized fact (an ISO code, a public registry entry) rather than a country-specific regulatory judgment call.
  • NEEDS LOCAL INPUT — genuinely unknown to this document. The question is the deliverable.
Field 1
pack_id

"ke" — [SAFE], ISO 3166-1 alpha-2 for Kenya.

Field 2
coding_system
  • system_id(): not yet named — depends on the answers below.
  • Diagnosis coding — [L], NEEDS LOCAL INPUT for operative detail. Kenya is a WHO member state, and MOH health statistics are generally understood to use ICD-10 (the WHO edition), not ICD-10-CM. NEEDS LOCAL INPUT: does NHIF's own electronic-claims (e-Claims) technical specification require a specific ICD-10 edition or year release? Has any transition toward ICD-11 begun for claims (distinct from statistical reporting timelines)?
  • Procedure coding — NEEDS LOCAL INPUT, no confident answer. The precise question: which procedure code set does NHIF require on a claim — a Relative Value Scale, a procedure coding volume of ICD-9-CM (used historically), an NHIF-specific procedure-tariff code, or something else? This document found no source it trusts to name one.
  • Lab coding — NEEDS LOCAL INPUT. Does Kenya's health-information-exchange standard (if one exists and is publicly documented) or NHIF mandate LOINC, a local lab code list, or leave this unspecified? LOINC is internationally standard and would be a reasonable default, but proposing it is not the same as confirming it is what Kenyan systems actually expect.
Field 3
privacy_regime
  • regime_id(): "KE-DPA-2019" — [L]. The Data Protection Act of 2019 (Cap. 657A of the Laws of Kenya), enforced by the Data Protection Commissioner, is Kenya's general data-protection law. This document treats the law's name and enforcing body as reliable general knowledge, short of reading the statute text itself. NEEDS LOCAL INPUT: has the Data Protection Commissioner published sector-specific health-data guidance or model consent language?
  • consent_text(scope): NEEDS LOCAL INPUT — deliberately not drafted. The DPA 2019 treats personal data involving health or medical information as sensitive personal data (Section 53) with stricter processing conditions, but this document will not draft patient-facing consent wording from that general knowledge — per the template's own rule, operative consent text is a question for a Kenyan lawyer or the Data Protection Commissioner's own published model language, not a plausible paraphrase.
  • retention_default_days(resource_type): NEEDS LOCAL INPUT for every resource type (Patient, Encounter, DiagnosticReport, Observation, MedicationRequest — the five the platform's own enforcement list already names). Kenya's Medical and Dentists Practitioners Board may set retention rules for registered providers, and the MOH may have guidance, but this document holds no confident figure and will not estimate. The precise question: what minimum (and, if any, maximum) retention period does Kenya's health-regulation authority or MOH set for each resource type, and does the period differ for a minor patient's records (many jurisdictions extend retention to years past the age of majority)?
  • export_rule(purpose): NEEDS LOCAL INPUT. The DPA 2019 establishes an "accountability principle" (Section 47) where the data controller remains accountable for personal data even after transfer [L], but the specific mechanism — required contractual clauses, Commissioner notification, an outright restriction for certain data categories — needs the Commissioner's own guidance or MOH sector-specific rules, not this document's paraphrase of general principle.
Field 4
fhir_profile

NEEDS LOCAL INPUT, entirely. This document found no evidence that Kenya has published a national "KE Core" FHIR R4 implementation guide (analogous to US Core). The precise question: does the MOH or NHIF publish a FHIR implementation guide today? If not — which is the more likely answer — what is the actual data-submission format NHIF requires for claims, since that format (not a FHIR profile) may be the real, binding technical constraint in the near term? Is FHIR R4 already used by any major Kenyan health-IT vendors or the national health-information exchange, if one exists?

Fields 5–6
compliance_rule_set / policy_pack_format

"ke-dpa-v1" / "ke-criteria-v1" — [SAFE] as placeholder names only, following the template's own guidance that no compliance-rule engine or policy-pack loader exists in this codebase for any country yet. Not a claim that these strings mean anything operationally today.

Field 7
payer_plan_vocabulary

[L], with a NEEDS LOCAL INPUT on shape and specifics. The National Hospital Insurance Fund (NHIF) is Kenya's primary national social health insurance program — unlike the US split between Medicare and Medicaid, there is a single dominant national payer. Kenya also has private health insurance companies and out-of-pocket/self-pay. A starting, category-level vocabulary: ("NHIF", "private_commercial", "employer_sponsored", "self-pay"). NEEDS LOCAL INPUT:

  • Should specific named private insurers be enumerated individually (as the US pack names specific Medicare Advantage plans), and does NHIF's own claims format require enumeration of specific private competitors?
  • Does NHIF categorize employer-sponsored differently from private commercial, or are they one category?
  • How does NHIF's e-Claims system identify and distinguish these payer types in claim submissions?
Field 8
currency

"KES" — [SAFE], ISO 4217 code for the Kenyan shilling.

Field 9
locale

"en-KE" — [L], moderate confidence. English is the language of medical education, clinical charting, health IT, NHIF communications, and MOH forms in Kenya (per general knowledge of Kenyan healthcare practice, consistent with the reasoning that made Kenya a reasonable second country to model). NEEDS LOCAL INPUT, one open question: should the default still be English, or should Swahili (sw-KE) be equally prominent or preferred? Swahili is Kenya's national language, and healthcare facilities might prefer interface navigation in Swahili even if charting happens in English. This is a real product decision, not just a data lookup.

Field 10
date_format

NEEDS LOCAL INPUT — not assumed, despite this document having a mild guess. Kenya inherited British administrative practices and may commonly use DD/MM/YYYY (consistent with UK convention), but per the template's own instruction for this specific field — "this is a patient-safety-adjacent field... do not assume" — this document declines to assert it. The precise question: what date format does the actual NHIF e-Claims form and MOH reporting form use? Check the official forms themselves, do not rely on guess.

Field 11
number_format

NEEDS LOCAL INPUT, for the same reason as Field 10: a decimal-point misread in a dose or lab value is a safety error. This document's mild expectation that Kenya follows 1,234.56 (comma-thousands, period-decimal, as in the US and English-language contexts) is not a substitute for checking an actual Kenyan lab report or prescription template.

Fields 12–13
data_residency_flags / data_residency_required

NEEDS LOCAL INPUT. This document is not aware of a Kenyan data-residency mandate for health data specifically. The DPA 2019 does not obviously impose one the way some jurisdictions do — but "not aware of one" is not the same as "confirmed none exists." The precise question: does Kenya's Data Protection Commissioner or MOH guidance impose a residency requirement for health data or sensitive personal information specifically (e.g., data must be stored on Kenyan soil, or only transferred to named countries)?

Field 14
deidentification_standard

NEEDS LOCAL INPUT, with a lean toward None. This document is not aware of a Data Protection Commissioner-published, HIPAA-Safe-Harbor-style enumerated de-identification standard for Kenya. If a Kenyan health-IT contributor confirms none exists, the honest value is None — matching the template's own convention that "no known standard" is a real, valid answer, not a gap to fill by analogy to international standards.

Field 15
small_cell_threshold

NEEDS LOCAL INPUT, with a lean toward None for the same reason as Field 14: this document knows of no published Kenya National Bureau of Statistics or MOH small-cell suppression rule for health data, but has not confirmed its absence. Is there a disclosure-control standard for public-health reporting?

Field 16
approval_body_types

[L], low-to-moderate confidence. Kenya has a National Commission for Science, Technology and Innovation (NACSTI) that coordinates research ethics, and institutional Research Ethics Committees (RECs) are common at hospitals and research institutions. However, whether research-ethics approval is required the same way for all "secondary uses" — analytics, quality measurement, epidemiological monitoring — is not clear. NEEDS LOCAL INPUT:

  • Which approval body or committee (NACSTI, an institutional REC, both, or another) must approve secondary uses of patient data for research, analytics, quality measurement, or public health?
  • Does the Data Protection Commissioner itself have an approval or registration role separate from the ethics committee?
  • Does NHIF or MOH mandate approval from any body before data-sharing or secondary use?
  • What is the precise naming convention (Research Ethics Committee, Institutional Review Board, etc.) that is actually used in Kenyan healthcare institutions?

Summary: what this worked example proves and what it does not

Proves: the template is usable end-to-end for a country where the document is significantly less confident than for the Philippines — every one of the 17 fields got an entry, and fields where the document has NO confident source are honestly marked open rather than filled with plausible guesses.

Does not prove: that Kenya is ready to ship as a real pack. Of 17 fields, a rough count: 5 are reasonably safe today (pack_id, currency, the two placeholder identifiers, and the general existence of NHIF as the dominant payer), 2 have a confident-enough answer to build on (locale's English default; the general category-level shape of payer_plan_vocabulary), and the remaining 12 are open, each with a named question, including:

  • All three sub-fields of coding_system (diagnosis, procedure, lab)
  • All four sub-fields of privacy_regime (regime_id finalized as law name but no guidance exists; consent_text, retention, export all open)
  • All of fhir_profile (no profile known to exist)
  • Date/number formats (safety-critical, do not assume)
  • Data residency (unknown)
  • De-identification and small-cell thresholds (none known, but not confirmed)
  • Approval bodies (general names exist but specifics and binding roles unknown)

Ratio of confident to open: ~5 fields have a confident or reasonably-safe answer; ~12 require a Kenyan health-IT lead, clinician, legal expert, or public-health authority to answer with certainty. This is the honest state of "adapt this to a real country" for Kenya, and is itself the most useful single fact this document produces.

Finding: the template works equally well for high-confidence and low-confidence scenarios. The Philippines example and Kenya example show the same ratio. The template does not assume pre-existing knowledge — it surfaces what you do and do not know, which is its job.