Abstract

A woman sits on a wooden bench in a district hospital corridor with a creased card in her hand. The card is the only part of the health system that remembers her.

Zimbabwe has started to build something to remember her instead. The Ministry of Health and Child Care publicly describes Impilo as Zimbabwe's National Health Operating System. The 2026 National Budget provides for Smart Health deployment at 174 health institutions and for interoperability-platform development. Researchers are already studying Impilo's strengths and limits in longitudinal and multimorbidity care. So the country is not at zero, waiting for someone to invent an architecture. It is somewhere harder: the foundations are poured, and nobody has yet settled what reference architecture, governance model, interoperability regime, institutional capability and evaluation framework would make the evolving system national, interoperable, resilient, extensible and safe.

This paper proposes that architecture. It argues that Zimbabwe should treat digital health as national digital public infrastructure, not as a collection of disconnected applications; that the right pattern is centralised rails with distributed systems of record and controlled exchange; that identity, registries, interoperability, offline operation, governed analytics and bounded clinical AI form one coherent stack; and that institutions, procurement and governance carry as much load as the software does. The requirements come from the conditions people actually work in — intermittent connectivity, intermittent power, heterogeneous systems, constrained technical capacity, mixed public–private provision, and a legal framework that treats health information as sensitive data.

The contribution is not a finished national system design. It is a defensible reference architecture and institutional model for evolving a landscape that already exists, together with the measurable technical, governance, safety and economic conditions under which that evolution could succeed. The paper says plainly which claims are established, which are engineering recommendations, and which are empirical hypotheses still waiting to be measured. It defines maturity gates, proposes an evaluation framework, presents a threat model, treats equity as a core architectural concern, gives a bottom-up cost model with three scenarios, specifies a staffing model that accounts for the senior engineering supervision AI-augmented development demands, and states its own limitations.

The whole argument comes down to one sentence, which the rest of the paper keeps returning to: centralise the rails, not every application; govern the network, not merely the database; and keep the human accountable for the decision.

Preface: what this paper is, and what it is not

This is not a report of a controlled experiment. It is not a systematic review, and it is not a formal architecture evaluation with comparative benchmarks. It is a reference-architecture and institutional-design position paper, a form with a legitimate tradition in health informatics, digital public infrastructure and national e-government.

The category matters because it sets what you, the reader, are entitled to demand.

Where I state an established fact — that FHIR exists, what DHIS2 can do, what Zimbabwe's Cyber and Data Protection Act provides, what the UNICEF-supported Village Health Worker pilot recorded — I cite it, and I expect you to check.

Where I make an engineering recommendation — use a national implementation guide, build offline-first, establish conformance testing, keep free text out of the job of carrying interoperable clinical concepts — I label it as a recommendation and show the reasoning.

Where I state an empirical hypothesis — that AI tooling compresses engineering effort by some factor, that a cost envelope is achievable, that a timeline is realistic — I label it a hypothesis, give the assumptions behind it, and name the measurement that would confirm or kill it.

Earlier drafts did not keep that discipline. They slid from defensible proposal to established fact without paying for the crossing. I wrote those drafts. This revision corrects them. The literary voice stays, because prose can carry an argument that bullet points flatten. But every number is now supported, labelled as an estimate, or withdrawn.

The thesis has survived the corrections:

Zimbabwe should build the rails on which many applications can run, rather than one application that tries to be every rail.

Everything that follows is that sentence, examined under Zimbabwean conditions.

PART I — THE BATTLEFIELD

1. The world is not merely a psychological landscape

The convenient lie is that everything starts inside the mind.

Ideas. Fears. Grievances. Ambitions. We picture society as people carrying private weather around and occasionally bumping into each other.

Stand in a clinic queue in Mashonaland at ten in the morning and the lie stops working.

The bench is hard. The fan isn't turning, because the power went at seven. A child coughs in that wet, specific way that makes every mother on the bench look up at once. Somewhere behind a door, a nurse is looking for a folder.

None of this is psychological.

All of it is a battlefield.

Ideologies meet there without introducing themselves. Money meets hunger. Knowledge meets distance. Compassion meets a fourteen-hour shift. Under it all the oldest forces keep moving — fear, love, territoriality, survival, the need to belong, the urge to control what cannot be controlled — and they move through institutions, the way water moves through cracked concrete.

The battle doesn't announce itself.

It sits in a missing laboratory result.

It sits in the cupboard where the medicine should be.

It sits in the doctor who has five minutes to rebuild ten years of a stranger's body from memory and guesswork.

It sits in the village two hours from the nearest hospital, two hours being a distance that is nothing in a car and everything in a fever.

It sits in the spreadsheet a clerk has kept for six years, reconciling systems that were never introduced to one another.

Each failure is small.

Then they add up.

And what they add up to has a name we use too casually: poverty.

Not poverty as a line in a household survey. Poverty as a mechanism. The thing that turns illness into debt. Distance into danger. A late referral into lost wages, lost wages into a sold goat, a sold goat into a child kept home from school. Poverty as compound interest on friction.

So healthcare is one of the clearest places to see what technology actually does to human welfare. A health system is not a set of buildings with clinicians inside.

It is a coordination problem.

It is memory.

It is identity.

It is logistics, money, knowledge, timing.

And, more and more, it is software.

Which means Zimbabwe has to stop thinking about digital health as a shopping list of applications. The bigger opportunity is a national digital-health infrastructure: one technical foundation through which hospitals, clinics, laboratories, pharmacies, medical-aid organisations, health programmes, researchers, technology companies, health workers and patients can take part, securely, in one health ecosystem.

This is not a someday question. Zimbabwe's approved 2026 budget explicitly includes developing and implementing e-health solutions, including electronic health records and telemedicine, alongside health-financing, workforce and primary-healthcare interventions.

So the question is what we do next.

Do we build dozens more systems that cannot speak?

Or do we build the rails on which those systems can finally become one network?

I believe the rails.

And I believe we should build them AI-native. Not because AI is fashionable. Fashion is a bad reason to put anything near a patient. Because AI is leverage, and leverage — though its size is uncertain — deserves to be tested as a capability multiplier against measurable criteria for quality, security, clinical safety and cost.

That is not optimism.

It is a disciplined engineering position, which is a less romantic thing and a more useful one.

2. The problem is not a lack of software

A patient walks into a clinic in Chitungwiza.

Her name is entered. Her history is taken. She is referred.

She arrives at the district hospital with the referral letter folded into quarters inside a plastic bag that once held bread.

"Zita renyu?" the receptionist asks. Your name?

She gives it.

Again.

Date of birth.

Again.

Current medication.

Again.

Allergies.

Again.

She tries to remember. Maybe she does. Maybe the record is on paper in the plastic bag. Maybe the paper got wet in October's first storm. Maybe she married and changed her surname and the old file is under the old name. Maybe someone registered her twice, and somewhere there are two of her, each half-known. Maybe the laboratory result she is here about exists, in a building eleven kilometres away, in a system that does not answer.

So everyone improvises.

Developing countries have become extraordinarily good at improvising around broken systems.

We call it resilience.

Sometimes it is.

Sometimes it is just a polite word for people doing unpaid systems integration with their own lives.

A nurse remembers what the computer forgot.

A doctor phones a doctor.

A patient keeps a photo of a prescription on a cracked phone.

Someone checks WhatsApp. Someone opens Excel. Someone goes through a filing cabinet that smells of dust and old rain.

Everybody gets the job done.

Until they don't.

That is the hidden cost of fragmentation: no single workaround looks expensive. Five minutes. Ten minutes. One repeated test. One missed follow-up. One referral that sat in a tray over a long weekend. One medicine order placed after the stock had already gone.

The system absorbs each failure.

The household absorbs the consequence.

At some point inefficiency stops being an administrative problem and becomes a public-health problem. Nobody can say exactly when. That is part of the horror of it.

Zimbabwe does not lack software.

Zimbabwe lacks shared rails.

Look at what exists. Impilo, the national EHR initiative the Ministry describes as Zimbabwe's National Health Operating System, with deployments in progress and an architecture still evolving. DHIS2 for aggregate reporting, established and national. Smart Health, a facility digitisation programme with 2026 Budget provision for 174 health institutions. OpenMRS in some facilities, paper in others. OpenELIS in some reference laboratories, nothing in most. Donor-funded vertical programmes, each with its own database and its own reporting deadline. Private-sector medical-aid claims systems that cannot see a single public-sector encounter. A Village Health Worker programme that ran on paper and SMS, plus a UNICEF-supported DHIS2 mobile pilot that raised on-time monthly reporting from 43% to 75%.

It is the pattern every developing country knows: a graveyard of well-meant pilots and no nervous system connecting them.

The problem isn't that nobody built anything.

Plenty of people built things. I have built some of them.

The problem is that nobody built the thing underneath everything.

And that thing is not a database.

It is a network of governed exchanges.

PART II — THE LANDSCAPE

3. Zimbabwe's digital health state in 2026

An architecture that doesn't start from the existing landscape isn't an architecture. It's a fantasy wearing a lanyard.

Zimbabwe enters 2026 with digital health capability that is substantial, uneven and partly undocumented. The honest place to start is an inventory, not a blank page.

3.1 What exists

Impilo. The Ministry of Health and Child Care is rolling out Impilo as a national EHR platform, publicly described as Zimbabwe's National Health Operating System. It offers nationwide EHR functionality, provider and facility registration, telemedicine and other modules, and it is the platform most of this paper's proposals are designed to support, extend or integrate with. Its existence changes the question. The question is no longer should Zimbabwe build a national health operating system? It is: Zimbabwe has begun building one — so what reference architecture, governance model, interoperability regime, institutional capability and evaluation framework will make it national, interoperable, resilient, extensible and safe?

DHIS2. Zimbabwe reports health data through DHIS2. Monthly facility reports and VHW submissions flow into it. It is established and national, but it is built for aggregate reporting, not individual patients, and it runs beside the clinical systems instead of being fed by them automatically. Someone, every month, is the integration layer.

Smart Health. The 2026 budget funds Smart Health equipment and connectivity at health institutions. It is a facility digitisation programme, separate from Impilo but complementary to it. Approved expenditure documents report Smart Health sites and an interoperability-platform development target.

Community health. The Village Health Worker programme is one of the main interfaces between households and formal care, with a national ambition of 40,000 VHWs by 2030. A UNICEF-supported DHIS2 mobile pilot raised on-time monthly reporting from 43% on paper to 75% through the mobile workflow. The same pilot named connectivity, power and training as real constraints.

Laboratory. OpenELIS runs in some reference laboratories. Most laboratory work is on paper. There is no national laboratory information system strategy.

Supply chain. UNICEF-supported supply-chain work found stockouts, delays and technical limitations, and stressed the need for stronger evidence on causes before targeting investment.

Private sector. Medical-aid claims systems, private hospital systems and pharmacy systems mostly run in isolation from the public sector. There is no standards-based exchange between the two.

Legal framework. The Cyber and Data Protection Act treats health information as sensitive data and provides for a unique patient identifier distinct from other identification numbers, under the relevant public authority. Turning that into technical controls and governance instruments is unfinished work.

Identity. National registration exists. A health-specific identifier is not yet operating nationally. There is no national Master Patient Index — which means that, at national scale, the state cannot reliably tell whether it has met a person before.

3.2 The gap

This table should be kept as a living document, not left to yellow as an appendix. An architecture that cannot describe where it is starting cannot honestly describe where it is going.

3.3 Why this matters for originality

An earlier draft wrote as if Zimbabwe were at zero. It was wrong, and the error cheapened the paper. When the past is erased, a proposal looks original only because nothing older is left in the room to compare it with.

The contribution here is not the idea that Zimbabwe should build a national health operating system. Zimbabwe is already building one. The contribution is the reference architecture, governance model, interoperability regime, institutional capability and evaluation framework needed to make it national, interoperable, resilient, extensible and safe.

That is a harder question and a more useful one. It forces the paper to deal with what is already in the room — Impilo, DHIS2, Smart Health, OpenELIS, the VHW programme, donor systems, private systems, existing law — instead of designing in an empty field.

It also means every recommendation has to work with a programme that is already moving, or say explicitly what should change. A moving train doesn't care about your blueprint.

So the architecture that follows is an evolution path from the 2026 baseline. It is not a replacement.

4. Research question and methodology

4.1 Research question

How should Zimbabwe's existing digital health environment evolve into interoperable national digital public infrastructure under conditions of intermittent connectivity, intermittent power, heterogeneous systems, mixed public–private provision, constrained technical capacity, and a legal framework that treats health information as sensitive data?

4.2 Sub-questions

1. What design requirements follow from Zimbabwe's operating conditions?
2. What reference architecture satisfies those requirements?
3. What institutional, governance and procurement arrangements are required to sustain it?
4. What evaluation framework would demonstrate whether the architecture is working?
5. What are the principal uncertainties and limitations of the proposal?

4.3 Methodology

The architecture comes from a structured design process, not from an experiment. I'd rather say that up front than let you discover it in the limitations.

Step 1 — Requirements elicitation. Requirements come from four sources: (a) documented Zimbabwean operating conditions (connectivity, power, workforce, law); (b) documented digital health deployments in Zimbabwe and comparable settings; (c) established health informatics standards and reference architectures (OpenHIE, WHO digital health platform guidance, FHIR, SMART Guidelines); (d) principles stated explicitly in this paper (infrastructure over application; centralise rails; govern the network; keep the human accountable).

Step 2 — Reference pattern selection. Candidate patterns — centralised monolith, distributed peer-to-peer, hub-and-spoke HIE, federated read with distributed write, and hybrid — were tested against those requirements. Section 6 documents the choice, the rejected options and the reasons.

Step 3 — Component specification. Each layer — identity, registries, interoperability, offline operation, analytics, AI, governance — is specified by its responsibilities, interfaces and non-functional requirements.

Step 4 — Evaluation framework. Section 39 defines maturity gates and success metrics, so that the proposal can be tested empirically once it is built.

Step 5 — Limitations. Section 54 states what this paper does not demonstrate and what it would take to strengthen its claims.

This is design science in the information-systems tradition: the contribution is an artefact (a reference architecture), evaluated by argument and by specified future measurement, and the paper is explicit that empirical validation is still owed.

It is not a controlled study. It is not a meta-analysis. It doesn't pretend to be either.

5. Design requirements

5.1 Functional requirements

The architecture must support: patient identification across facilities; retrieval of authorised longitudinal history; structured clinical documentation; laboratory ordering and result exchange; pharmacy dispensing and stock visibility; referral management with closed-loop confirmation; scheduling and queue management; billing and claims exchange; community health workflows; public health surveillance; and governed analytics and research.

Written as a list, it reads like a procurement annex.

Read it slowly. Each item is a place where, today, a human being is the integration layer.

5.2 Non-functional requirements

Seventy-two hours of offline operation is not a gold-plated number. It's roughly a long weekend with the power out and the network gone. Anyone who has worked in a rural clinic will recognise it as a modest ambition.

5.3 Legal requirements

The Cyber and Data Protection Act treats health information as sensitive data and provides for a unique patient identifier distinct from other identification numbers, under the relevant public authority. The architecture has to turn that provision into technical controls: a dedicated health identifier namespace; purpose-bound access; consent management; retention rules grounded in Zimbabwean law rather than imported wholesale; and audit that can answer who looked, at what, when, from where, under whose authority, and for what purpose.

Where the paper cites international comparators — HIPAA de-identification standards, GDPR data subject rights, IMDRF software-as-a-medical-device classification — they are comparisons. Citation does not make them Zimbabwean law. Section 26 maps Zimbabwean legal requirements to technical controls and lists foreign comparators separately, so nobody mistakes one for the other.

5.4 Clinical safety requirements

Any system that influences a clinical decision needs: provenance and source attribution; controlled, versioned clinical knowledge; human oversight; audit logging; incident reporting; and hard boundaries around autonomous action. Section 19 sets these out.

5.5 Equity requirements

The architecture must handle: shared mobile devices; SIM replacement and credential recovery; disability and accessibility; varying literacy; elderly patients; minors and dependent identities; undocumented persons; migrants and refugees; gendered access to devices; assisted digital access; coercive access by family members; patients who decline digital records; culturally sensitive data; and patients whose identity cannot be verified straight away.

These are not footnotes. For a national health identity, they are the architecture. Section 25 takes them one at a time.

5.6 Operational requirements

The architecture must be operable by a national engineering organisation of bounded size; supportable by facility staff with limited IT training; maintainable through documented interfaces; and exit-able. The government must be able to replace any vendor without losing its memory.

Remember that word, exit-able. It comes back.

PART III — ARCHITECTURE

6. Architectural principles and pattern selection

6.1 Five principles

Principle 1 — Centralise the rails, not every application. Identity, standards, registries, interoperability, security policy, critical infrastructure and national analytics are centralised. Facility workflows, application design, systems of record and innovation are distributed. The centre routes; the edge records.

Principle 2 — Govern the network, not merely the database. The thing being designed is not a store of records. It is a set of governed exchanges between systems of record. The database is a component. The network is the system.

Principle 3 — Offline is a first-class state, not an error condition. The architecture assumes connectivity and power will fail, because they will. Offline operation is designed, tested and monitored. It is not handled as an exception at the bottom of a stack trace.

Principle 4 — The human remains accountable for the decision. Software, AI included, assists, retrieves, explains and surfaces uncertainty. It does not quietly become clinical policy. Clinical logic lives in governed, versioned, testable artefacts that don't depend on any model.

Principle 5 — Infrastructure must outlive the people who build it. Architecture is documented, standards are public, data is portable, interfaces are open, contracts contain exit mechanisms, and no critical knowledge lives in one person's head. Including mine.

Each principle holds a paradox it refuses to resolve. Central, but not too central. Powerful, but refusing authority. Permanent, but built by people who are not.

6.2 Pattern selection

Five candidate patterns were tested against the requirements in Section 5.

The monolith is tempting the way a single strong man is tempting: one face, one decision, one place to point. It also has one place to fail, and a rural clinic with no network isn't a place it can reach.

The selected pattern — federated read, distributed write, governed aggregation — is documented through the rest of the paper.

6.3 Layered architecture

Seven layers, with three planes cutting across them.

Layers (bottom to top):

1. Infrastructure — compute, storage, network, power, physical security, at national, regional and facility level.
2. Identity and Trust — patient identity, provider identity, facility identity, device identity, credentialing, authentication, key management.
3. Registries — client registry, provider registry, facility registry, terminology service, service registry.
4. Interoperability — HIE routing, FHIR facade, message bus, transformation, validation, consent enforcement, policy enforcement.
5. Systems of Record — facility EMRs, laboratory systems, pharmacy systems, community health systems, claims systems, private-sector systems.
6. Analytical Platform — ingestion, lakehouse, semantic layer, visualisation, research enclave.
7. Intelligence — retrieval, decision support, forecasting, anomaly detection, evaluation, governance.

Cross-cutting planes:

• Security plane — encryption, segmentation, least privilege, monitoring, incident response.
• Observability plane — metrics, logs, traces, audit, alerting.
• Governance plane — policy, standards, certification, clinical safety, data stewardship, AI governance.

Infrastructure sits at the bottom, under identity. The order is deliberate. Before the system can know who you are, it needs electricity. Figure 1 shows how the layers meet at runtime.

6.4 What the Health Operating System must guarantee

A list of components is not an architecture. A set of guarantees is. These are the promises the national Health Operating System has to keep:

Ten guarantees. Read them as a person would, not a vendor. You will be recognised. Your history will follow you. Someone will answer for every glance at your file. The system will keep working when ZESA doesn't. Nobody can sell your memory back to the country that paid for it.

The guarantees are the architecture. The technology stack is how we try to keep them.

6.5 Architecture decision framework

A fair complaint about architecture papers is that they list technologies without justifying them, like a menu with no prices. This paper uses a decision framework for each major component: requirement, candidates, evaluation criteria, trade-offs, decision, rejected alternatives.

These decisions should be revisited in Phase 0 against the full national operating model and recorded as Architecture Decision Records. A choice nobody wrote down is a choice the next team will make again, at the country's expense.

7. The first battle is identity

Before a patient can have a history, the system has to know who she is.

That sounds primitive.

It is primitive.

It is also one of the hardest problems in the whole architecture.

People move. Names change at marriage, at baptism, at the whim of a clerk who heard Tendai as Tendayi. Children become adults. Birth certificates go missing. Patients cross provinces, cross into private care, cross the Limpopo and come back. Families share names across three generations because sharing names is how families remember. A typo made at registration in 2019 becomes a permanent fact about a human body.

The body stays the same.

The database doesn't always agree.

Zimbabwe's Cyber and Data Protection Act recognises health information as sensitive data and provides that it should be processed against a unique patient identifier distinct from other identification numbers, under the relevant public authority.

That provision should become a foundational national service.

A National Health Identifier.

Not the national ID number copied into a health database.

A health identity of its own.

7.1 The identity problem is not the identifier problem

A UUID can uniquely identify an identifier record while the system still hands two identifiers to the same human being. This difference — identifier generation versus patient identity — is the problem national health identity programmes most often step around.

The architecture keeps five concerns apart:

1. Identifier generation — producing a unique, persistent, non-reassignable identifier for each identifier record.
2. Identity proofing — establishing, to a defined level of assurance, that a person is who they claim to be.
3. Patient matching — deciding, probabilistically, whether two identifier records refer to the same person.
4. Duplicate resolution — the workflow by which match candidates are reviewed, merged, split or kept separate.
5. Merge governance — the policies, audit trails and reversal mechanisms that make merges safe.

An earlier draft treated generation as the whole of identity. It isn't. Generating an identifier takes a few microseconds. Recognising a person is something an institution has to keep getting right for decades.

The Master Patient Index looks like a database problem. Underneath it sits an older, human one: whether an institution can recognise the same person twice.

7.2 Identifier generation

National health identifiers are generated as UUIDv7: time-ordered, sortable, and generatable at the edge without asking the centre for permission.

A note on "unique." UUIDv7 does not guarantee freedom from collisions. It makes them so improbable that they are not a practical engineering concern. RFC 9562 is explicit that UUIDs alone cannot guarantee true global uniqueness. So the architecture treats UUIDv7 as practically unique, monitors for collisions as defence in depth, and never relies on identifier uniqueness alone for patient safety. Patient safety depends on matching, review and merge governance. In the end it depends on people.

Sequential integers are rejected because they need central coordination, which fails the offline requirement. National ID numbers are rejected as health identifiers because not everyone has one and they don't stay stable, and because using them would create exactly the linkage risk the Act's separate-identifier provision exists to prevent.

7.3 Identity proofing

Proofing depends on the site and the role. A patient registering at a rural clinic with no documents is proofed at a lower assurance level than one enrolling in a national insurance scheme. The architecture supports several assurance levels and records which one each identity was proofed at.

A grandmother with no papers is still a patient. The system has to be able to say we are less certain who you are without saying you do not exist.

7.4 Matching

Matching is probabilistic — Fellegi-Sunter, or a lighter combination of Jaro-Winkler, Levenshtein and phonetic encoding — tuned on Zimbabwean name distributions across Shona, Ndebele, English and the variant spellings that come from transliteration and haste. Matching produces candidate pairs with confidence scores. Above a high threshold, candidates are merged automatically, with audit. Between the thresholds, they go to human review. Below the low threshold, they stay separate.

For automated merges, precision matters more than recall. A false merge is a patient-safety incident: two people's allergies, two people's HIV status, one file. So the auto-merge threshold is set high, and the architecture accepts that some true matches will wait for a human.

7.5 Duplicate resolution and merge governance

Every merge produces an immutable audit event. Every merge can be reversed. A merge that cannot be undone is a clinical hazard, and policy forbids it.

Splits — reversing a merge — are supported and audited. Corrections to demographic data are supported and audited. The system keeps the full history of every identity change, and any clinician viewing a record can see that the identity changed and why.

The record has to remember its own mistakes. That is not a flaw in the design. It's the point. Figure 2 traces the path from arrival to a confirmed identity.

7.6 Provider, facility and device identity

Provider identity is built on FHIR Practitioner and PractitionerRole, synchronised with the Health Professions Authority and the Nurses Council. Credential status can be queried in real time. A suspended provider cannot prescribe. Facility identity is built on FHIR Location and Organization, with a stable national identifier, geocoding, hierarchy and capability metadata. Device identity uses X.509 certificates issued by a national device CA, with per-device enrolment, rotation and revocation.

The tablet gets an identity too. In this architecture, even a machine has to be accountable for where it has been.

7.7 Authorisation: ABAC with purpose-of-use

The primary authorisation model is attribute-based access control with purpose-of-use. The paper does not claim ABAC is the only model that survives clinical work. Role-based access, relationship-based controls, contextual controls, least privilege and break-glass all have a place. The requirement is that every authorisation decision takes in:

who (authenticated identity) + what (resource type) + which record (resource instance) + which action (read, write, amend) + which purpose (care, billing, research, public health) + which context (routine, referral, emergency) + which relationship (treating clinician, covering clinician, patient-designated) + which emergency state (normal, break-glass)

That's the real point. ABAC is the mechanism. Purpose-bound, contextual authorisation is the requirement.

Policies are written in OPA Rego or Cedar, version-controlled, tested, and deployed through a controlled pipeline. Every authorisation decision is logged.

7.8 Purpose-of-use: a correction

An earlier draft proposed that every API request carry a purpose-of-use header. That is insufficient and unsafe. A header supplied by the client proves nothing about purpose. An attacker can set purpose=clinical-care and ask for anything.

Purpose has to be derived: from authenticated application identity, user role, relationship to the patient, workflow context and server-side policy. Explicit claims are allowed only from a certified application operating inside a defined context, and even then they are validated server-side against the user's role and relationship.

The architecture treats purpose as something it works out, not something anyone gets to declare.

I got that wrong the first time. The fact that I did tells you how easily good intentions turn into an attack surface.

7.9 Consent

FHIR Consent resources record patient authorisation precisely: which data, which purposes, which recipients, which time period, and which exceptions (emergency break-glass, mandatory reporting, public-health override). Consent is a first-class resource with its own lifecycle and audit trail. It can be withdrawn, and the withdrawal propagates. Emergency override exists, but it is loud: it alerts the patient's care team, the privacy officer and the audit system.

An old man presses his thumb onto an ink pad, then onto a form he cannot fully read, while his daughter stands a little apart. That is what consent often looks like on the ground: hope mixed with trust. The architecture's job is to make that trust worth having.

There is something almost metaphysical about identity.

A medical record is memory.

It is an institution's memory of a body.

It says: this happened; then this; then this — and so what is happening now is not happening in isolation.

Without that memory, every encounter starts from nothing.

The patient is born again each time she crosses an institutional boundary, and each rebirth costs her a morning, a fare, a repeated test, a little more trust.

That is absurd.

It is also expensive.

And we have mostly stopped noticing.

8. Then identify the people who are allowed to act

Patients are not the only identities that matter.

Who is the doctor?

Who is the nurse?

Who is the pharmacist, the laboratory scientist?

Who may prescribe?

Who may see a patient's HIV status?

Who may see a laboratory result, amend a record, take data for research?

Who may see the whole history, and who only what the task in front of them needs?

Here software architecture runs into power.

A national health system is, among other things, a machine for deciding who gets to know what about whom.

So access control can't be an afterthought. Get it wrong and the afterthought becomes a scandal, or quietly becomes a weapon.

The platform keeps authoritative registries of: health facilities; health professionals; professional credentials; services; equipment; licences; geographic location; facility capability; and, eventually, operational capacity.

The country should be able to ask a machine:

Who can provide this service, where are they, and are they authorised to do it?

Asked that way, the provider registry stops being an administrative directory.

It becomes a map of the country's capacity to heal.

So a referral should not mean:

Go somewhere else.

It should mean:

This patient needs this service. These facilities can provide it. This is the relevant clinical context. This is the referral trail. This facility is the appropriate destination.

The first version is how most referrals feel today: a door closing politely.

The second is a hand passed to another hand.

The system doesn't only remember.

It coordinates.

9. The Health Information Exchange

The technical centre of the architecture is a national Health Information Exchange.

Its job is not to become the biggest database in the country. Big databases become big targets and big temptations.

Its job is to let many databases talk.

That means APIs. Message routing. Identity resolution. Authentication. Authorisation. Validation. Transformation. Event handling. Audit logging. Consent management. Terminology services. Service discovery. Monitoring.

FHIR is now a major standard for exchanging healthcare information through modern APIs, and international digital-health architecture increasingly relies on FHIR implementation guides. WHO's SMART Guidelines programme explicitly promotes software-neutral, standards-based components that can interoperate across health systems.

So Zimbabwe needs a national implementation profile.

Not just:

"We use FHIR."

That sentence is not architecture. It's a lanyard.

The country has to say exactly how it uses it.

9.1 FHIR version baseline

An earlier draft said "FHIR R4 or R5." That isn't a standard. It's a shrug.

A national implementation guide has to pick a baseline. This paper proposes:

• National baseline: FHIR R5, with the national implementation guide published as an R5 IG.
• Legacy compatibility: an FHIR R4 adapter profile for systems that cannot migrate yet. Adapter profiles are documented, tested and time-limited. A system on the R4 adapter is scheduled to migrate; it has not arrived.
• Version transition mechanism: the national IG defines the mapping between the R4 and R5 resources Zimbabwe uses, and the HIE transforms at the boundary. No system has to speak both versions natively.

"We use FHIR" is a slogan. "We use FHIR R5 with a national IG, R4 adapters for legacy systems, and a documented transition mechanism" is a standard.

9.2 National implementation guide

The national IG specifies: the patient resource profile; encounter profile; observation profiles per clinical domain; medication request and dispense profiles; diagnostic report profiles; service request (referral) profile; consent profile; provenance profile; claim and coverage profiles; and the value sets, code systems and concept maps that bind them. It is published as a FHIR IG, versioned, and maintained by the national FHIR standards and terminology authorities (Section 31).

Behind every profile is a question a whole country has to answer the same way.

What counts as a patient?

What is a valid encounter?

How is a facility named? A medicine? A laboratory result?

How does a referral travel? How is consent written down? How is a claim tied to the care it paid for? How is a national indicator derived? How is a local system certified?

Together the answers are the grammar of the national health network.

Without shared grammar, everyone is speaking.

No one is communicating.

9.3 Terminology

A national terminology service serves FHIR CodeSystem, ValueSet and ConceptMap resources, drawing on SNOMED CT, LOINC, ICD-11, ATC and Zimbabwe's essential medicines list. Every clinical concept in every participating system resolves to a national terminology code. Free text isn't banned — clinical narrative is precious — but free text is not what carries interoperable clinical concepts.

A correction. An earlier draft called free text "the enemy of interoperability." That was crude. The nurse's note that says mother anxious, says child "not himself" since Sunday contains clinical intelligence that no code captures. The right proposition is:

Critical interoperable data should be represented structurally and codably where possible, while clinically necessary narrative remains supported and linked to structured concepts.

A system that is technically interoperable but clinically impoverished hasn't succeeded. It has just failed more efficiently.

9.4 Interoperability layer

The interoperability layer uses OpenHIM (the Open Health Information Mediator) for routing and orchestration, with a FHIR facade (HAPI FHIR, Medplum, or a comparable FHIR-native server) as the canonical API. OpenHIM handles message routing, protocol mediation between FHIR and legacy HL7v2/MLLP/SOAP, transaction logging and orchestration. The FHIR facade exposes R5 resources as the canonical read/write interface. Figure 3 shows the layer end to end: clients enter through one gateway, the mediator consults policy and the registries, routes to systems of record (translating for legacy ones), and publishes every exchange to the event bus.

9.5 OpenHIE: comparative rather than declarative

An earlier draft called OpenHIE "proven at scale under precisely Zimbabwean conditions." That overclaimed. OpenHIM is an established component and has been deployed in several national health information environments — Rwanda, Tanzania, Nigeria and others. But "has been deployed" is not the same as "has been proven to succeed under Zimbabwe's exact conditions." A pattern that held in Kigali has not yet met a rural clinic in Binga in the hot season.

A comparative assessment is needed. For each documented national deployment, it should record: scale (facilities, transactions, users); transaction volumes; uptime; implementation duration; staffing; security posture; financing model; governance arrangement; interoperability maturity; failure modes; and sustainability outcomes. That assessment is beyond this paper, but it must come before any full OpenHIE adoption decision. What this paper offers is the pattern. Regional precedent supports it, and Zimbabwe's pilot phase can test it.

9.6 Event bus

Every clinical and administrative event — patient registered, encounter opened, observation recorded, medication dispensed, claim submitted — is published to a durable event bus. Apache Kafka is the reference choice; Redpanda is a viable lighter alternative. The bus decouples producers from consumers and carries the event stream that drives the analytical platform, the shared record and downstream systems.

The bus is not the source of truth. The systems of record are. The bus carries a record of what they have recorded — the system's memory of its own memory.

9.7 Shared record

For selected domains — immunisation, maternal health, and wherever national reporting obligations require it — the architecture keeps a national shared record assembled from events on the bus. The shared record is not the source of truth; the facility system that created the data still is. The shared record is an assembly layer that keeps nationally significant data retrievable when source systems are down. The domains it covers are chosen deliberately, documented, and open to revision.

9.8 Health management information system bridge

DHIS2 stays the national aggregate reporting platform. The HIE publishes aggregate indicators to DHIS2 through the DHIS2 API. Facilities stop double-entering data. Clinical systems produce the aggregates automatically.

Picture what that means in practice: the last week of every month, a nurse at a desk under a dead fluorescent tube copying tallies from a register into a form while patients wait outside. Take that away and you have removed one of the largest administrative burdens in the system. Nobody will write a press release about it. The nurse will notice.

10. The longitudinal patient record and federated read semantics

The goal can be put in one sentence:

the patient's history should travel with the patient.

A patient visits a clinic. A clinician records the encounter. A referral is issued. The district hospital retrieves the relevant history. A test is ordered and the result comes back. Medication is dispensed, and the dispensing becomes part of her authorised history.

Months later she turns up somewhere else.

The clinician doesn't face a blank page.

She sees context.

None of this requires the naive design in which every piece of health information in the country is poured into one central database. That design has its own dangers: one breach, one outage, one minister with one bad idea.

The better model is:

centralised identity and standards; distributed systems of record where appropriate; controlled exchange; governed aggregation for analytics.

A facility stays authoritative for what it creates. The national platform is how that information becomes reachable where it is legitimately needed.

The difference is large.

The record stops belonging to the building.

It belongs to the patient's continuity of care.

10.1 Federated read semantics

Federated read is the heart of the proposal, and the place where distributed-systems discipline matters most. Hand-waving here gets people hurt, so the semantics are spelled out.

Query flow. A clinician queries the local system. If the local system holds the data, it answers. If not, it sends a federated query to the national HIE, which fans out to the source systems registered as authoritative for the relevant data domains, subject to the patient's consent and the clinician's authorisation.

Source availability. If a source system is offline, the HIE returns a partial response with an explicit data freshness indicator per source. The clinician sees which sources answered, which didn't, and how stale each answer is. The architecture never presents an incomplete history as complete.

Consistency model. Federated read is read-your-writes at source, eventually consistent across sources. A facility that has just written a record sees it immediately from its own system. Other facilities see it once the HIE has received and indexed the event. The freshness indicator says so.

Contradictory observations. When two sources return contradictory observations for the same clinical concept, the HIE does not quietly pick one. It returns both, with source and timestamp, and flags the conflict. Deciding between them is a clinical judgement, not a routing rule.

Identity mapping changes. When a patient's identity mapping changes (merge, split, correction), the HIE publishes an identity event. Source systems subscribe and reconcile asynchronously. In-flight federated queries use the mapping current at query time, and the HIE records which mapping it used, for audit.

Authorisation divergence. If authorisation succeeds against one registry and fails against another — say, a provider whose credential was suspended at one facility and the suspension hasn't propagated yet — the HIE fails closed and returns an authorisation error. The clinician is told. The registries are reconciled out of band.

Timeouts and partial responses. The HIE enforces a per-source timeout (default 3 seconds). A source that doesn't answer in time is marked unavailable in a partial response. A slow source never blocks the clinician.

Cache invalidation. The HIE caches federated responses at the query boundary for a short period (default 60 seconds), keyed by patient, requester and query type. Identity events and clinical write events for the same patient invalidate the cache.

Disaster recovery. In disaster recovery mode, the HIE serves from the national shared record (where one exists for the domain) and marks every response degraded. Clinicians are notified. Writes queue for later replay.

Partial-response contract. The federated read API returns a structured response containing: the assembled clinical view; a per-source status (ok, timeout, unauthorised, unavailable); a per-source freshness indicator; a list of detected conflicts; and a query-level confidence flag. The clinician's interface shows all of it honestly.

That last word is the important one. The cruellest thing a health system can do is look complete when it isn't. An empty allergy field that means we don't know looks exactly like one that means none. A patient can die in the gap between those two.

These semantics are not optional implementation details. They are the contract between the HIE and the clinicians who rely on it. Figure 4 walks through one query in which a source times out and the clinician still gets an honest answer.

11. The administrative battlefield

Not every health failure happens in a consulting room.

Some happen in the queue.

Some in procurement, in billing, in the laboratory, in the pharmacy, in the filing room.

Some happen because someone has to type the same information into three systems, and on the third system, at four in the afternoon, gets a digit wrong.

So a national health infrastructure should expose common services for: patient registration; appointments; queue management; admissions; discharges; referrals; billing; medical-aid verification; claims; payments; laboratory requests; laboratory results; imaging requests; pharmacy; medicine dispensing; inventory; procurement; staff scheduling; facility utilisation; maintenance; and emergency coordination.

And again, the answer isn't one giant application.

The platform exposes shared services.

One company builds a queue system. Another builds a pharmacy system. Another does ambulance coordination, another claims, another community-health software. All of them plug into the same infrastructure.

That is how a national digital ecosystem forms.

The government builds the road.

The ecosystem builds the vehicles.

Then people start arguing about which car to buy, instead of whether there is a road at all.

Good.

That's a healthier argument.

Technically, the shared services are exposed as FHIR APIs plus domain-specific APIs:

Scheduling — FHIR Slot, Appointment, Schedule resources. Any scheduling application can read and write against the national service.

Queue management — a lightweight event-sourced service publishing queue events (patient arrived, patient called, patient seen, patient departed) to the bus. Dashboards consume the events.

Admissions — FHIR Encounter with location and status fields. Bed management is a projection over encounter events.

Referrals — FHIR ServiceRequest with referral intent, plus a national referral workflow covering facility capability matching, transport coordination and closed-loop confirmation (the referring facility learns that the patient arrived).

Laboratory — FHIR ServiceRequest (order) and DiagnosticReport (result), with OpenELIS as the reference laboratory information system for public-sector labs, connected through the HIE.

Pharmacy — FHIR MedicationRequest, MedicationDispense, and a national medicines formulary served through the terminology service. OpenBoxes or ERPNext for inventory and supply chain.

Billing and claims — FHIR Claim, ClaimResponse, Coverage, EligibilityRequest, EligibilityResponse. Medical-aid organisations connect through the HIE instead of bespoke point-to-point integrations.

Imaging — DICOM endpoints registered in the service registry, with a national PACS strategy that starts at reference facilities and spreads outward.

Every one of these services can be replaced on its own.

Every one speaks FHIR.

Every one publishes events to the bus.

Every one is authorised by the same policy engine.

That is the difference between a platform and a pile of applications. A pile still needs a person at the bottom holding it up.

PART IV — THE EDGES

12. Start at the doorstep

Health technology has a habit of designing downward from the tertiary hospital.

Big screen. Big server. Big dashboard. Important people in air-conditioned rooms nodding at maps.

Then the village arrives.

The power is gone.

The network is gone.

The tablet is three years old and the screen has a crack running corner to corner.

The health worker has twenty households to visit before the light goes.

The patient speaks Tonga, and the form doesn't.

The phone is on 12%.

This is where an architecture lives or dies. Not in the demo. On the footpath.

Zimbabwe already has evidence that digital community-health tools can materially improve reporting. A UNICEF-supported DHIS2 pilot for Village Health Workers raised the share of monthly reports submitted on time from 43% on paper to 75% through the mobile workflow, and built-in validation improved data quality and completeness. The same experience named connectivity, power and training as real implementation constraints.

That cuts both ways.

Technology can produce gains.

Technology can also fail spectacularly when it ignores the ground it stands on.

So community applications must be: offline-first; Android-first where appropriate; lightweight; low-bandwidth; battery-conscious; capable of delayed synchronisation; resistant to interrupted connectivity; localisable into Zimbabwean languages; and simple enough to use under pressure, with a crying child in the next room.

The system should assume the internet will fail.

Because it will.

"Network yaenda," someone says, and the room laughs, the way rooms in this country laugh at the network.

We have become very good at laughing at infrastructure failure.

It's another way of getting used to being abandoned.

The right response isn't panic, and it isn't laughter.

It's architecture.

12.1 Community health platform options

The community health layer should be built on the Community Health Toolkit (CHT), the open-source framework developed by Medic Mobile and deployed at scale in Kenya, Uganda, Nepal and elsewhere. CHT is designed for exactly Zimbabwe's constraints: offline-first, Android-based, low-bandwidth, battery-conscious, with a sync protocol that tolerates weeks of disconnection and a form-definition language (XForms) that can be localised.

Alternatives and complements:

Open Data Kit (ODK) or KoboToolbox for structured data collection where CHT is too heavy.

DHIS2 Android Capture for aggregate reporting where the workflow is mainly statistical.

CommCare — an open-source platform (the web platform is BSD-licensed; the Android client is Apache 2.0) — where the workflow needs strong case management. An earlier draft said CommCare had a "proprietary backend." That was wrong. CommCare is open source. The correction matters because a paper that asks for evidence discipline has to show it, even in its smallest claims.

The community health application should support: household registration; maternal tracking; child health; immunisation; nutrition screening; chronic disease follow-up; medicine adherence; referrals; health education; outbreak reporting; and supervisory workflows.

A health worker should be able to walk through a community with a phone and know: who needs follow-up; who missed an appointment; who needs referral; which child hasn't had a vaccine; which household needs intervention; which cases are becoming urgent.

Not because the worker is being watched.

Because the worker has memory.

The system remembers what no human could possibly hold for thousands of households.

That is computing used humanely.

And the same phone should last two weeks between charges, sync over 2G when it finds a signal near the borehole, and survive being dropped in a river.

That isn't hyperbole. That is the specification.

13. Connectivity and electricity are software requirements

There's an old habit of treating connectivity and electricity as somebody else's department.

They aren't.

They're dependencies.

If a clinic needs electricity to run its digital system, electricity is a software dependency, as real as any package in a lockfile, and less reliable than most.

If a referral needs a network, network availability is a software dependency.

That changes how things get procured. Digital-health funding has to cover: local networks; secure Wi-Fi; routers; primary connectivity; backup connectivity; UPS systems; solar or generator support where appropriate; device management; local caching; synchronisation; backup procedures; and physical security.

Zimbabwe's connectivity profile makes the point for us. ITU data for 2024 reported broad basic mobile coverage but materially lower LTE and 5G coverage, with access conditions differing between urban and rural households.

A system that needs perfect broadband is not a national system.

It's an urban pilot with ambitions.

The country needs software that can survive reality.

13.1 Edge compute

Every facility deployment includes an edge server — a small form-factor machine (Intel NUC, Raspberry Pi 5 with 8GB+, or a ruggedised industrial PC) running a lightweight orchestrator (K3s), a local PostgreSQL instance, a local FHIR server and a cache of the national registries. The facility system reads from the local server, and the local server syncs with the national HIE when connectivity allows. When it doesn't, the facility carries on.

13.2 Store-and-forward

Outbound messages (referrals, lab orders, claim submissions, aggregate reports) are queued durably on the edge server and delivered when connectivity returns. The queues are PostgreSQL-backed (not in-memory), encrypted and monitored. No message is lost because the network dropped.

13.3 Synchronisation semantics

The sync protocol tolerates partial connectivity, high latency, packet loss and long disconnection windows. This is a distributed system, not a CRUD app with a REST API, and pretending otherwise is how records disappear. The architecture uses:

• Idempotent message delivery — every message carries a unique identifier, so delivering it twice does no harm.
• Append-only clinical events — clinical observations are appended, never overwritten. Conflicts in clinical narrative are surfaced, not silently resolved.
• Last-write-wins for demographics — with the losing write kept in history for audit.
• Explicit conflict surfaces — where automatic resolution isn't safe, the conflict goes to a human instead of a guess.

Whether a data domain uses CRDTs, vector clocks or a simpler timestamp-and-version model is decided per domain, documented and tested. The architecture doesn't impose one mechanism everywhere.

A nurse on a veranda at dusk holds a tablet above her head, turning slowly toward the kopje, looking for one bar. Engineers call what she's waiting for "eventual consistency." She has a less technical name for it. Figure 5 shows both branches of her evening: synced, or queued.

13.4 Low-bandwidth optimisation

Every API payload is optimised for 2G/3G: gzip or Brotli compression; images downscaled before sending; NDJSON over HTTPS for bulk data; batch operations instead of chatty REST. The system is designed for the worst network in the country, not the best one in the boardroom.

13.5 Device management

Every device is enrolled in MDM (Headwind MDM, Fleet, or a comparable open-source tool), with remote wipe, remote configuration, application whitelisting and enforced OS updates. Devices are treated as untrusted endpoints. Data at rest is encrypted. Data in transit is encrypted. A lost tablet doesn't become a data breach.

13.6 Reference profiles for power and connectivity

An earlier draft prescribed universal figures — 2 kWp solar, 10 kWh battery, 5 Mbps symmetric connectivity, a four-hour UPS. They aren't universal. They're site-specific engineering decisions that depend on workload, and treating them as universal is how a rural clinic ends up with a referral hospital's specification and a referral hospital ends up with a clinic's.

So the architecture defines reference profiles, and each deployment is sized against one:

Each profile is a starting point for site-specific sizing, not a specification. Final sizing needs a site survey covering workload, existing infrastructure and local conditions.

13.7 Power and connectivity as capital expenditure

Every facility deployment needs a minimum digital operating package:

Secure local network.

Managed devices.

Primary connectivity.

Backup connectivity.

UPS.

Solar or generator support where appropriate.

Network segmentation.

Local caching.

Offline synchronisation.

Backups.

Device replacement plans.

Physical security.

It has to be budgeted alongside the software. Not after it.

Otherwise the country will build a beautiful system that can't survive its first power cut.

And power cuts aren't software bugs.

They are architectural requirements.

PART V — THE INTELLIGENCE

14. The country must become capable of seeing itself

Once information moves through common standards, something strange happens.

The country starts to remember at scale.

The operational system can answer:

What happened to this patient?

The analytical system can ask:

What is happening to the health system?

They're different questions. The first is about a person. The second is about a people.

The analytical layer should give authorised visibility into: disease trends; maternal and neonatal outcomes; immunisation; medicine availability; laboratory workloads; hospital occupancy; referral patterns; waiting times; health-worker distribution; facility utilisation; geographic gaps; public-health events; and expenditure.

The aim is to shorten the distance between an event and understanding it.

Right now, institutions tend to live through the world first and understand it later — sometimes a quarter later, sometimes a report later, sometimes after the people it was about have stopped needing anyone to understand.

A national health intelligence layer should gradually reverse that.

Not omniscience.

Situational awareness.

The difference matters. Omniscience is a fantasy of control. Situational awareness is a discipline of humility.

A government doesn't need to know everything.

It needs to know enough, soon enough, to act.

14.1 Operational versus analytical separation

The operational system answers what happened to this patient? The analytical platform asks what is happening across the system? The two questions have different performance, privacy and architectural requirements, and the separation between them is deliberate.

14.2 Lakehouse

The analytical platform is a lakehouse: ingestion through Kafka and Debezium; storage in Apache Iceberg on object storage; processing in Flink (streaming) and Spark or dbt (batch); query through Trino; visualisation through Superset, Metabase or Grafana.

14.3 Semantic layer

Every national indicator is defined once, in code, version-controlled and tested, in a semantic layer (dbt metrics, Cube or Malloy). Dashboards read from the semantic layer.

Dashboards are disposable.

Metrics are not.

A country that defines "maternal death" three ways in three dashboards has not counted its mothers. It has argued about them.

14.4 Research enclave

The research enclave is a governed, isolated environment where approved researchers work with de-identified or synthetic data. De-identification follows a defined standard, with re-identification risk assessment. Outputs are reviewed before they leave. Access is logged and audited.

On differential privacy. An earlier draft claimed that differential privacy "guarantees that no individual's data can be inferred from published aggregates." That overstated it. Differential privacy gives formal privacy-loss guarantees — quantified, composable, robust to auxiliary information — but it doesn't make inference categorically impossible. The accurate statement: differential privacy bounds how much any one record can change the output distribution, and so bounds privacy loss. It does not make inferring an individual categorically impossible.

On k-anonymity. k-anonymity is a technique, not a solution. It is vulnerable to homogeneity attacks, background-knowledge attacks and composition attacks. Where it is used, it is used alongside other controls, with its limits stated.

15. The supply chain is a war of information

Suppose the medicine is in the country.

Nobody knows where.

One facility has more than it can use before the expiry date. Another has an empty shelf and a queue. A warehouse holds stock that expires next month, while a clinic at the other end of the system orders the same product and waits.

The medicine exists.

The patient can't reach it.

That is a coordination failure, and like most coordination failures it is not anyone's fault in particular. Which is exactly why it goes on.

The digital supply chain should eventually know: what exists; where it is; what is being consumed; what is on order; what is in transit; what is nearing expiry; what is seeing unusual demand; and what can be moved.

Recent UNICEF-supported work on Zimbabwe's health-product supply chain found stockouts, delays and technical limitations, and stressed the need for stronger evidence on causes before targeting investment.

The deeper ambition is predictive.

Not:

What is the stock level?

But:

What is likely to run short, where, and when?

That turns logistics into intelligence.

Intelligence changes what scarcity means.

Software can't abolish scarcity.

It can remove some of the stupidity around it.

That alone is worth a great deal.

Technically:

OpenBoxes, ERPNext or Odoo as the transactional supply-chain system at national and provincial warehouses, integrated with the HIE through FHIR SupplyDelivery, InventoryReport, and custom resources where FHIR doesn't yet cover the domain.

Barcode/RFID tracking at every point where stock moves. GS1 standards for product identification. Scanning at receipt, at issue, at dispensing.

Consumption-based forecasting — every dispensing event is a data point and every prescription a signal. Time-series forecasting (Prophet, NeuralProphet or a gradient-boosted model) predicts demand per facility, adjusted for seasonality, outbreaks and local patterns.

Expiry management — every stock item carries its expiry date. The system warns ahead of expiry and recommends moving stock to facilities with higher turnover.

Redistribution engine — an optimisation model (linear programming or a simpler heuristic) that matches surplus at one facility with shortage at another, accounting for transport cost, cold-chain requirements and expiry.

Cold chain monitoring — IoT temperature sensors in cold-chain equipment, reporting to the HIE. Temperature excursions raise alerts. Vaccine and insulin stock can be traced from warehouse to patient.

National stock visibility — one dashboard showing national stock by product, facility and province, updated in near-real time.

The supply chain isn't a back-office function.

It is the distance between a medicine existing and a medicine reaching a person.

Software can shorten that distance.

16. The financial network

Sooner or later, healthcare meets money.

The patient meets cost. The provider needs paying. The insurer needs claims. Government may subsidise. Medical-aid organisations need verification. The laboratory needs reimbursing. The pharmacy needs settling.

Every one of those processes generates friction when each party builds its own integration — and in the meantime a mother stands at a cashier's window with an empty purse, learning that her medical-aid card "is not coming up on the system."

A national healthcare transaction layer should eventually expose secure interfaces for: eligibility; claims; co-payments; subsidies; provider billing; payment reconciliation; and beneficiary verification.

This is where the payment-network analogy earns its place.

A healthcare ecosystem should eventually support flows such as:

Patient → Provider

Provider → Medical Aid

Provider → Government

Laboratory → Provider

Pharmacy → Medical Aid

Government → Provider

through standardised, auditable infrastructure.

Then the financial system becomes another kind of memory. It remembers what happened: who received the service, who paid, who was responsible, what is still owed.

And once money is structured data, the economics of healthcare become legible. Legible things can be argued about honestly. Illegible things just get blamed.

Technically:

FHIR Financial Module — Coverage, EligibilityRequest, EligibilityResponse, Claim, ClaimResponse, PaymentNotice, PaymentReconciliation. Every claim is a FHIR resource. Every adjudication is a FHIR resource. Every payment is a FHIR resource.

ISO 20022 for payment messaging where interoperability with the banking system is needed. Zimbabwe's payment systems (RTGS, mobile money) can connect through ISO 20022 adapters.

Mojaloop, or a comparable open-source payments interoperability layer, for low-value, high-volume transactions. Mojaloop was designed for exactly this: connecting banks, mobile money providers and government payment systems in developing countries.

Medical-aid integration — every medical-aid organisation connects through the HIE, not through bespoke point-to-point integrations. One national claims API. One national eligibility API. One national remittance API.

Fraud detection — anomaly detection on claims data (Isolation Forest, autoencoders, or a supervised model trained on confirmed fraud cases). Duplicate claims, impossible service combinations, outlier providers and phantom patients can all be detected with modern ML.

Cost transparency — every service has a published national tariff, and every claim references it. Patients can see what a service will cost before they receive it. Price opacity is a form of systemic harm. It just doesn't leave a bruise.

Universal health coverage alignment — the financial layer has to support the move to UHC: means-tested subsidies, capitation payments, results-based financing and national health insurance. The architecture must be flexible enough to run several financing models at once.

The financial layer isn't only about money.

It is about accountability, transparency and trust.

A health system that can't account for its money can't keep public confidence. And without public confidence, it can't keep the money either.

17. Create a national research capability

Good health data may be worth most years after it was collected, to people who weren't born when it was entered.

Universities could use governed datasets to study: maternal health; child health; malaria; tuberculosis; HIV; nutrition; non-communicable diseases; referral patterns; medicine availability; geographic inequality; and healthcare utilisation.

But research access has to be controlled. Researchers work inside approved environments. Identifiable information is protected. Datasets are de-identified or otherwise properly governed. Access is auditable. And findings flow back into health policy, rather than into journals the ministry never reads.

That gives a loop:

care → data → knowledge → policy → better care.

It may be the most valuable thing a national digital-health programme creates.

A country stops merely treating disease and starts learning, systematically, from what happens to its people.

Technically, the research environment is:

A governed data enclave — an isolated environment (separate Kubernetes namespace, separate network, separate storage) where approved researchers can access de-identified datasets. No internet access from the enclave. All code and data are reviewed before entry; all outputs before exit.

De-identification pipeline — automated de-identification (HIPAA Safe Harbor, Expert Determination, or a comparable standard) with re-identification risk assessment. Direct identifiers removed. Quasi-identifiers generalised. Dates shifted. Geography aggregated.

Synthetic data — Synthea, or a generative model trained on the real distribution, producing synthetic patients who keep the statistical properties without being anyone. Used for development, testing and methods work.

Differential privacy — OpenDP or Google DP for published statistics, with formal privacy-loss budgets.

Research governance — a national health data governance committee that reviews proposals, approves access, monitors compliance, and makes sure findings are published and fed back into policy.

Publication mandate — every approved project publishes its findings in an open-access venue within 12 months of completion, with a policymaker summary in a standard format.

Capacity building — training for Zimbabwean researchers in health data science, biostatistics and epidemiological methods. The goal is a generation of Zimbabwean researchers using the national platform to answer questions that matter to Zimbabwe.

Research isn't a luxury.

It is how a country learns.

And a country that doesn't learn doesn't stand still. It repeats.

PART VI — THE AI

18. Do not start with artificial intelligence

This needs saying loudly.

Every technology conversation now wants to start with AI.

Don't.

Build the foundation first.

AI doesn't turn bad data into good data.

It turns bad data into eloquent bad data.

That's worse.

A language model wired to fragmented records can produce a beautifully written lie about a patient's history, with section headings and a confident tone, and a tired doctor at the end of a night shift will believe it, because it reads better than the truth.

So a national health AI system has to sit on top of trusted infrastructure. The authoritative systems stay authoritative. The AI reaches only what it is authorised to reach. The model assists. The source systems remain the source of truth.

Then the possibilities become real.

A clinician asks:

What is the relevant history for this patient?

The system retrieves authorised records and produces a structured summary.

A doctor asks:

What changed since the last admission?

The system compares the encounters.

A pharmacist asks:

Which facilities in this district are likely to run out of this medicine?

The system analyses inventory and consumption.

An administrator asks:

Where have waiting times increased unexpectedly?

The system queries operational data.

A public-health officer asks:

Where is the current pattern materially different from the expected seasonal baseline?

The system analyses population-level data.

That is what AI should be.

Not a toy at the front door of healthcare.

An intelligence layer on top of a health system that already works.

18.1 AI architecture

Technically, the AI layer is:

Retrieval-augmented generation (RAG) — the foundation pattern. A vector database (pgvector, Qdrant, Weaviate or Milvus) indexes authorised clinical documents, guidelines and structured records. A retrieval pipeline pulls the relevant context for a query, and a language model generates a response grounded in it.

Self-hosted inference — vLLM, TGI (Text Generation Inference) or llama.cpp for serving open models. Self-hosting matters for data sovereignty, cost control and latency. A model running in Harare is faster, and more answerable to Zimbabwean law, than one running in Virginia.

Small language models at the edge — quantised 3B–8B models on facility servers, or even mobile devices, for low-latency, offline-capable tasks (clinical documentation, form-filling, decision support). A 7B model quantised to 4-bit can run on a modern phone. That is plausibly the future of clinical AI in low-resource settings — a hypothesis worth funding and measuring, not a promise.

Guardrails — NeMo Guardrails, Guardrails AI, or a custom policy layer enforcing clinical safety rules, output filtering and escalation to human review. No clinical AI output reaches a clinician without passing through guardrails.

Evaluation — Ragas, DeepEval, promptfoo, or a custom framework. Every model, prompt and retrieval pipeline is evaluated against a curated test set. No AI feature ships without evaluation results.

Observability — Langfuse, Phoenix (Arize), or a custom OpenTelemetry-based pipeline tracing every AI interaction: input, retrieved context, model output, latency, cost, user feedback.

Model governance — MLflow or a comparable model registry. Every model version is registered, documented, evaluated, approved and deployed through a controlled pipeline. No model reaches production without governance approval.

Clinical decision support — CDS Hooks and CQL (Clinical Quality Language) for guideline-based decision support. The clinical logic is written in CQL, versioned, tested and maintained independently of any model. The AI retrieves and explains the logic. The logic stays authoritative.

18.2 AI as leverage: an empirical hypothesis, not a settled fact

An earlier draft stated, as settled fact, that "a small, senior, AI-augmented engineering team can now construct in eighteen months what previously required five years and a hundred contractors," that "a senior engineer with AI tooling can do the work of three senior engineers," and that "AI-assisted development reduces the engineering headcount required by 50–70%."

Those were productivity hypotheses dressed as facts. I wanted them to be true. Wanting is not evidence.

The evidence on AI-assisted software engineering productivity is developing and mixed. METR's controlled research has produced very different findings depending on task selection, participant selection and experimental design. Its February 2026 update said explicitly that a newer experiment was giving an unreliable signal, and its earlier controlled work found experienced developers taking longer on the studied tasks with AI assistance. Other studies find substantial gains on well-scoped, well-tested, low-context tasks and weaker gains where deep system understanding is needed.

The honest position:

AI tooling demonstrably accelerates certain classes of software engineering work — code generation from clear specifications, test generation, documentation, boilerplate, translation between languages, refactoring with strong test coverage, and exploration of unfamiliar APIs. Its effects on complex, high-context, safety-critical, and novel architecture work are less certain and require measurement. The architecture and programme should therefore be designed to accommodate a range of productivity outcomes, and the actual productivity effect in the Zimbabwean context should be measured during Phase 0 and Phase 1 rather than assumed.

So this paper doesn't build national staffing or cost estimates on an assumed AI multiplier. It presents the AI-augmented staffing model as a planning hypothesis and requires it to be tested in the programme's first phase. If the effect is smaller than hoped, the programme scales more slowly or reprioritises. If it is larger, the programme accelerates.

That is the disciplined position. It is also the one that survives an international journal's reviewers.

18.3 The senior engineering requirement

There's a corollary that tends to get missed: AI-augmented development increases, not decreases, the demand for senior engineering judgement.

An AI system can generate code, tests, documentation and integration logic at volume, and correct code faster than anyone can type. What it can't reliably decide is whether the generated code is:

• safe for clinical use,
• consistent with national clinical guidelines,
• compliant with national data protection law,
• auditable in the required way,
• free of subtle security defects,
• correct in the edge cases the specification never imagined,
• maintainable by a future team that didn't write it,
• faithful to the architectural invariants that keep the system coherent over years.

Those decisions need senior engineering judgement. And because AI produces more code, tests and documentation than a team would produce unaided, the volume needing senior review goes up. The team produces more and has to review more. The bottleneck moves from production to review.

Three consequences for the staffing model:

1. Senior engineers are load-bearing. The architecture doesn't reduce the need for senior engineers; it raises the cost of not having them. Junior engineers with AI tooling and no senior supervision will produce a great deal of plausible, subtly wrong code. In a national health system, subtly wrong code is a patient-safety risk that hasn't happened yet.

2. Review capacity has to be planned. The engineering plan must set aside explicit time and headcount for reviewing AI-generated artefacts — code, tests, documentation, security, clinical safety. This isn't overhead. It is the mechanism that keeps AI-assisted development safe.

3. The senior-to-junior ratio shifts. AI lets a smaller team produce more, but a larger share of that team must be senior. The planning hypothesis in Section 29 reflects a senior-weighted team.

18.4 Remote engineering for non-sensitive components

A second corollary: not all engineering work is equally sensitive, and not all of it has to be done by the in-country core team.

A national health platform has components with very different sensitivity:

Sensitive components handle patient data, clinical logic, identity, authorisation, audit or security policy. They must be built and maintained by the in-country core team, under national jurisdiction, with security clearance and clinical-safety accountability.

Non-sensitive components don't handle patient data and don't influence clinical decisions. Examples: UI components for non-clinical workflows; documentation tooling; the developer portal front-end; test harnesses and synthetic data generators; reporting dashboards over aggregate, de-identified data; internal tooling; CI/CD pipeline components; SDKs and client libraries; localisation tooling; training simulation environments.

For the second category the architecture permits — and the budget assumes — outsourcing to remote engineering capacity, regional and international. That doesn't compromise sovereignty. It spends scarce senior in-country capacity on the work that most needs it.

The governance conditions:

• No access to patient data. Remote engineers work against synthetic data, sandbox environments and public specifications.
• No access to production systems. Remote engineers deploy only to sandbox and staging. The in-country core team deploys to production.
• No access to security policy. Remote engineers consume policy as a service; they don't write it.
• Code review by the core team. In-country senior engineers review all remote-authored code before merge.
• Contractual confidentiality and IP assignment. Standard for outsourced engineering.
• Jurisdictional clarity. Contracts specify governing law and dispute resolution.

Zimbabwe gets a wider talent pool for non-sensitive work and keeps in-country control of the parts that matter most for patient safety, data protection and national sovereignty.

19. Clinical AI is different

There is a particular arrogance in a machine that answers a medical question with confidence.

The patient pays for the confidence.

So anything that can materially influence a clinical decision has to meet a much higher bar. Clinical AI needs: provenance; source attribution; controlled medical knowledge; versioned guidelines; model evaluation; audit logging; human oversight; role-based permissions; incident reporting; safety testing; and clear limits on autonomous action.

WHO's SMART Guidelines approach matters here. It translates evidence-based recommendations into standards-based, machine-readable, adaptive and testable components that digital systems can incorporate, and WHO explicitly presents it as a way to make systems interoperable and reduce errors and vendor lock-in.

That should be the philosophy.

Clinical rules exist independently of the model.

The AI retrieves them.

Explains them.

Applies them where it is authorised to.

But the model must never quietly become clinical policy.

A machine should not wake up one morning and decide that the country now practises medicine according to whatever its weights absorbed from the internet.

That isn't intelligence.

It's an unsecured policymaker. And nobody elected it.

19.1 Regulatory classification: a correction

An earlier draft said that "clinical AI is a regulated medical device implemented in software." That shouldn't be stated as a universal rule.

WHO and IMDRF frameworks concern software as a medical device (SaMD), and whether something is SaMD depends on its intended medical purpose and its regulatory classification. WHO explicitly discusses risk–benefit assessment, evaluation and monitoring, rather than putting all clinical AI in one regulatory class.

The defensible proposition:

Some AI-enabled health software may constitute SaMD or another regulated medical technology depending on intended use and jurisdiction; therefore the architecture must incorporate risk-based clinical safety, validation, change control and post-market governance.

It is academically stronger, and it respects Zimbabwe's own regulatory pathway instead of assuming a mature foreign medical-device regime can be imported in a suitcase. The governance bodies that would own that pathway are proposed in Section 31.

19.2 Clinical AI governance requirements

Clinical AI requires:

CQL (Clinical Quality Language) — the standard for writing clinical logic in a computable, testable, versionable form. Every clinical guideline (HIV treatment protocols, TB regimens, maternal care pathways, immunisation schedules, chronic disease management) is expressed in CQL, versioned in Git, tested against synthetic patients, reviewed by clinicians and deployed through a controlled pipeline. The AI doesn't contain the logic. It retrieves and applies it.

CDS Hooks — the standard for bringing decision support into clinical workflows. A clinician opens a record, a CDS Hook fires, and the decision support service evaluates the patient against the relevant CQL rules and returns cards, suggestions and order sets. The clinician sees the recommendation, the reasoning and the evidence. The clinician decides.

FHIR PlanDefinition and ActivityDefinition — machine-readable care pathways and order sets.

Provenance — every AI-generated or AI-influenced output carries a FHIR Provenance resource linked to (not containing) AI execution metadata: model identifier, model version, prompt identifier, retrieved context identifiers, guideline version and human reviewer identity. An earlier draft implied FHIR Provenance could hold all of that itself. It can't. The architecture defines a composite: FHIR Provenance + linked AI execution metadata + immutable application telemetry + model registry + retrieval record + guideline version.

Human-in-the-loop by default — no clinical AI output is acted on without human review. The AI assists; the human decides. The only exceptions are low-risk, high-volume, well-validated tasks (coding, summarisation, translation), and even there a human reviews the output before it is finalised.

Clinical safety testing — every clinical AI feature goes through formal clinical safety assessment (hazard analysis, failure mode analysis, a clinical validation study), documented, reviewed and approved by a clinical safety board. No feature ships without it.

Incident reporting — every clinical AI incident (wrong recommendation, missed diagnosis, unsafe output) is reported, investigated and fed back into model improvement, prompt refinement or tighter guardrails. Reporting is blameless. The goal is learning, not punishment, because punishment teaches people to hide.

Model cards and datasheets — every model is documented with its intended use, training data, evaluation results, limitations and known failure modes. The documentation is public, so clinicians can see what the model can and can't do.

19.3 Explainability: a correction

An earlier draft said "every prediction comes with an explanation" and pointed to SHAP, LIME or attention visualisation. That was too strong.

An attribution method is not automatically a faithful causal explanation. The paper should distinguish:

feature attribution — which input features contributed to the output;

model interpretability — whether the model's internal logic can be inspected;

counterfactual explanation — what would have to change for the output to change;

clinical rationale — the reasoning a clinician would give;

causal explanation — the mechanism actually producing the outcome;

evidence provenance — where the knowledge the model applied came from.

They aren't interchangeable. In clinical systems, provenance and evidence traceability may matter more than pretending a SHAP plot gives the clinician a complete explanation.

So the architecture prioritises:

1. Evidence provenance — the AI cites the guideline, the study, the record entry, the CQL rule.
2. Uncertainty expression — the AI says what it doesn't know.
3. Conflict surfacing — the AI shows where sources disagree.
4. Feature attribution where appropriate — as one input among several, not as the explanation.

19.4 Clinical AI architecture summary

The doctor looks from the screen to the child, and back. His hand rests on a printed guideline booklet. Suspended between the suggestion and the decision, he is the whole safety case. Figure 6 traces the request that put the suggestion on his screen.

The AI is not the memory.

It is the librarian.

20. Build an AI layer that respects memory

There's something profound about putting AI on top of a national health record.

Human beings are terrible archivists. We forget. We simplify. We distort. We keep the emotionally important and drop the operationally important. We remember the name of the nurse who was kind, and forget the dose.

Institutions do the same, at scale, with letterheads.

A national health system can become external memory.

AI can become an interface to that memory.

Not the memory itself.

The distinction matters. The AI can say:

Here is what the record contains.

Here is what changed.

Here is where the information conflicts.

Here is what the guideline recommends.

Here is what remains uncertain.

That's far more useful than pretending the model knows everything.

The most valuable healthcare AI may not be the machine that "knows medicine."

It may be the one that helps people remember what their own health system already knows — and has forgotten that it knows.

21. The system should become predictive, carefully

Once there is enough reliable data, another possibility opens.

Prediction.

Not fortune-telling.

Operational forecasting.

Will this facility run out of a medicine? Where is demand rising? Which patients are overdue for follow-up? Where are referral queues growing? Which facilities are being overloaded? Where are unusual disease patterns appearing?

Predictions like these help people act earlier.

But prediction has to stay subordinate to governance.

A probability is not a diagnosis.

An anomaly is not proof of an outbreak.

A model's recommendation is not a clinical order.

So the system should show uncertainty, not hide it.

Intelligence without arrogance.

That may be one of the hardest things here to engineer, because arrogance is the default setting of any system that is right often enough.

Technically, prediction needs:

Time-series forecasting — Prophet, NeuralProphet or a gradient-boosted model for demand forecasting (medicine consumption, bed occupancy, laboratory workload, referral volume), trained per facility, per product, per season, and updated daily.

Anomaly detection — Isolation Forest, autoencoders or a supervised model for outbreak, fraud and system anomaly detection. Anomalies go to human reviewers. No automated action without human confirmation.

Risk stratification — gradient-boosted models or deep learning for patient risk stratification (readmission, deterioration, dropout). Risk scores prioritise follow-up. They are never used to deny care.

Causal inference — where possible, causal models (DAGs, instrumental variables, difference-in-differences) to estimate the effect of interventions. Correlation is not causation, and the system should be honest about which one it is offering.

Explainability — as in Section 19.3: attribution, interpretability, counterfactual, rationale, causal explanation and evidence provenance, kept distinct.

Fairness — regular fairness audits (demographic parity, equalised odds, calibration across groups). Models are evaluated for bias, and biased models are retrained or rejected. A model trained mostly on urban facilities will quietly misread rural ones, and nobody will notice unless someone looks.

Human oversight — every prediction is a recommendation, not a decision. The human decides and is accountable. The system is a tool, not an authority.

Prediction is not prophecy.

It is decision support.

PART VII — TRUST AND POWER

22. Privacy is where good intentions go to die

Everyone likes the phrase:

"We need a national database."

Until they picture what's in it.

Pregnancy. HIV status. Psychiatric history. Medication. Cancer. Genetics. Sexual and reproductive health. Disability.

Everything a person may badly want kept private.

A floral curtain on a rail, faded by years of sun, is the whole privacy infrastructure in many consulting rooms. Behind it, a young woman tells a nurse something in a voice too low for the bench outside. The man on that bench is waiting for her. The curtain is all that stands between what she said and what he hears.

Zimbabwe's Cyber and Data Protection Act places specific protections around health information, including requirements on professional secrecy and unique patient identifiers.

So the national architecture has to treat privacy as a property of the system.

Not a policy document filed in a cupboard.

Every access must have: an identity; a role; an authorisation decision; a legitimate purpose; an audit event; and, where applicable, a consent context.

A receptionist shouldn't see what a specialist sees.

A pharmacist shouldn't automatically see the whole clinical history.

A researcher shouldn't get identifiable records just because "research" is a respectable word.

A database administrator shouldn't hold invisible, permanent god-mode.

Privileged access has to be controlled too.

The system must be able to answer:

Who looked?

At what?

When?

From where?

Under whose authority?

For what purpose?

That isn't bureaucracy.

It's a civilisation trying to remember what it promised the individual.

22.1 Technical controls

Privacy is enforced at every layer:

Encryption in transit — TLS 1.3 everywhere; mTLS between services; no unencrypted traffic on any production path.

Encryption at rest — full-disk or volume-level encryption on every device and server. Database-level access controls. Object storage encryption.

Field-level encryption — sensitive fields (HIV status, psychiatric history, genetic data) encrypted under a separate key, accessible only to authorised roles. Even a database administrator with full database access can't read them without the key.

Tokenisation — national ID numbers, phone numbers and other direct identifiers stored as tokens, with the mapping table separately secured and audited.

Purpose-of-use enforcement — derived server-side, validated against role and relationship, logged.

Break-glass access — emergency access to restricted data is possible, but loud: it immediately alerts the patient's care team, the privacy officer and the audit system. Break-glass is a safety valve, not a backdoor.

Consent management — FHIR Consent resources recording patient preferences, with granular consent, withdrawal and emergency override.

Audit logging — every access to every record produces an immutable audit event. Audit logs are append-only, hash-chained and stored separately from the operational database. Tampering is detectable.

De-identification — research datasets are de-identified to a defined standard, with re-identification risk assessment.

Differential privacy — published statistics use differential privacy with formal privacy-loss budgets.

Access reviews — every privileged role is reviewed quarterly. Every access grant is time-limited. Dormant accounts are disabled automatically.

Penetration testing — annual third-party penetration testing, plus continuous automated security scanning.

Incident response — a documented, regularly tested incident response plan, with clear escalation paths, patient notification procedures and regulatory reporting.

22.2 A correction on PostgreSQL TDE

An earlier draft presented "PostgreSQL TDE" as a standard built-in capability on a par with the other encryption options.

That needs correcting. PostgreSQL core doesn't ship a transparent data encryption feature comparable to some commercial databases. The options are filesystem-level encryption; column-level encryption through pgcrypto (whose own documentation warns that data and keys can be exposed to someone with complete access to the database server); SSL/TLS for connections; and client-side encryption. Third-party extensions and patched forks exist, but they aren't the same as a built-in capability.

So the encryption recommendations are:

• Filesystem or volume-level encryption for data at rest on servers.
• Application-level field encryption for the most sensitive fields, with keys held outside the database.
• TLS for data in transit.
• Database-level access controls to limit what a stolen database credential can reach.

22.3 International comparators are not Zimbabwean law

The paper cites HIPAA Safe Harbor and Expert Determination, GDPR data subject rights and other international standards as comparisons. Citation doesn't make them Zimbabwean law.

Section 26 maps Zimbabwean legal requirements to technical controls and lists international comparators separately. Wherever the paper mentions a retention period or a de-identification standard, the legal basis has to come from Zimbabwean law, not be imported wholesale. Borrowing a legal framework from a country you don't live in is a quiet form of forgetting where you are.

23. Data sovereignty without technological isolation

This is another ideological battlefield.

One side says:

Everything must be built locally.

The other says:

Just buy the system from whoever already has one.

Both can end in foolishness.

A country doesn't become sovereign by reinventing every technology.

Nor does it become sovereign by depending permanently on proprietary systems whose architecture it can't see, let alone control.

The answer is open standards, strong national governance and deliberate local capability: FHIR; open interoperability patterns; open-source components where appropriate; open APIs; portable data; documented architecture; national implementation guides; independent security testing; local technical expertise.

Zimbabwe should be able to replace a vendor without taking the health system down.

That's sovereignty.

The ability to leave.

There's the word from Section 5.6 again. Exit-able. It turns out to be a political word.

Technically, sovereignty comes from:

Open standards — FHIR, HL7v2, DICOM, LOINC, SNOMED CT, ICD-11, CQL, CDS Hooks. Every interface uses a standard. No proprietary formats. No vendor-specific extensions without a national implementation guide.

Open-source core — OpenHIM, HAPI FHIR, OpenMRS, OpenELIS, DHIS2, OpenBoxes, Keycloak, Open Policy Agent, Kubernetes, PostgreSQL, Kafka, MinIO, Superset, Grafana, Prometheus. The core platform is open source. Vendors can build on top, but they can't lock the country out of its own infrastructure.

Open APIs — every service exposes a documented, versioned, standards-based API. No undocumented endpoints. No proprietary protocols. No data silos.

Portable data — every system can export its data in a standard format (FHIR NDJSON, CSV, Parquet) at any time. Data export is a routine operation, not a negotiation.

Documented architecture — every component, interface and decision is documented, and the documentation is public. A new engineer can understand the system without having to find the person who built it.

National implementation guides — FHIR Implementation Guides published by the national programme, specifying exactly how FHIR is used in Zimbabwe. Every vendor conforms, and conformance is tested automatically.

Independent security testing — annual third-party security audits. Public disclosure of critical vulnerabilities after a remediation window. A bug bounty programme.

Local technical capability — a national engineering team that owns the architecture, understands the code and can operate the platform without any vendor. Vendors are accelerators, not dependencies.

Exit clauses in every contract — every vendor contract includes a documented exit plan: data export, knowledge transfer, transition support, source code escrow where applicable. No vendor can hold the country hostage.

Remote engineering for non-sensitive components — remote engineers on non-sensitive work widen the talent pool without giving up sovereignty over the sensitive core. They don't touch patient data, production systems or security policy. They work against synthetic data, sandboxes and public specifications, and in-country senior engineers review their code.

Sovereignty isn't isolation.

Sovereignty is optionality.

The ability to choose.

The ability to leave.

The ability to build.

24. The threat model

An earlier draft talked about security at length and never presented a formal threat model. For an architecture carrying a nation's medical information, that was a serious omission. A system that hasn't imagined its attackers has simply left them to imagine it.

24.1 Threat actors

The last row belongs on the list, and it's uncomfortable. Most breaches don't need a villain. They need a tired person, a shared password and a Friday afternoon.

24.2 Threat scenarios

24.3 Threat model limitations

This threat model is a starting point. A full one for national health infrastructure needs formal attack trees for the highest-value targets; STRIDE or LINDDUN analysis per component; red-team exercises in Phase 2; and a continuous threat intelligence feed. It should be reviewed at least once a year and after every significant incident. Figure 7 shows where trust changes hands: every arrow that crosses a zone boundary is a place where identity, purpose and consent are checked again.

25. Equity is not peripheral

An earlier draft covered access, rural connectivity and language, but never seriously examined how a national health identity system can fail particular people. For a national health identity, those failures are the architecture. Every exclusion is a design decision, whether anyone meant to make it or not.

25.1 Populations at risk of exclusion

Shared mobile phones. Many households share one phone. An app that assumes one user per device won't work. The architecture must support several users on one device, with per-user authentication and per-user data separation.

Three generations lean over one cracked screen in a smoke-filled kitchen while the boy scrolls and the grandmother squints. The system designer's word for this is "device sharing." The family would just call it the phone.

SIM replacement and credential recovery. Lost SIMs, changed numbers and lost phones are common. Credential recovery can't depend on having the original device.

Disability and accessibility. Visual, auditory, motor and cognitive disabilities all affect device use. The architecture must support screen readers, voice interfaces, large-text modes and simplified workflows.

Literacy variation. Patients and health workers read at different levels. The architecture must support voice, icon-based interfaces and pictorial instructions alongside text.

Elderly patients. Older patients may have less experience with digital systems. The architecture must support assisted registration and simplified interfaces.

Minors and dependent identities. Children may not have identity documents. The architecture must support dependent identities linked to a guardian, with privacy boundaries that shift as the child grows up.

Undocumented persons. Some patients have no national identity documents. The architecture must support proofing at lower assurance levels without excluding them from care.

Migrants and refugees. Cross-border populations may have identities that don't fit the national registration system. The architecture must support temporary identities and, where the law allows, cross-border data exchange.

Gendered access to devices. In some households women have less access to devices than men. The architecture must support shared and assisted access.

Assisted digital access. Some patients need a family member, community health worker or facility staff member to help them use digital services. The architecture must support assisted access, with the patient's consent and proper audit.

Coercive access by family members. In some situations family members force access to someone's records. The architecture must have privacy controls that resist coercion — for example, not showing sensitive results on a shared device without extra authentication.

Patients who decline digital records. Some patients prefer paper, or decline digital records for privacy reasons. The architecture must support hybrid workflows for them.

Culturally sensitive data. What counts as sensitive varies by community. The architecture must support consent and access controls flexible enough to respect that.

Patients whose identity cannot be immediately verified. Emergency patients, unconscious patients and patients in crisis may not be able to confirm who they are. The architecture must support emergency registration with reconciliation later.

25.2 Equity as architecture

None of these can be dealt with after the build. They are architectural requirements, and they shape:

• Identity proofing levels and workflows.
• Authentication mechanisms (including alternatives to smartphone-based auth).
• Consent models.
• Data access controls.
• Interface design.
• Audit and privacy protections.

A national health identity system that excludes the people who most need care isn't a national system.

It's a system for the people who were already being served.

PART VIII — THE INSTITUTION

26. Zimbabwean law and technical controls

A law that exists only on paper protects about as well as a padlock painted on a door.

The Cyber and Data Protection Act provides the legal foundation. The architecture has to make it operational. The table maps Zimbabwean legal requirements to technical controls, with international comparators listed separately and marked as not binding.

Keep this table as a living document and update it as Zimbabwean law changes. The law will move. The controls have to move with it, or they become fiction.

27. Government should own the rails, not every car

The private sector has a role to play.

So do universities, researchers and independent developers.

Government shouldn't try to write every healthcare application that will ever exist. That would be expensive, slow and, oddly, hostile to innovation — a state competing with its own citizens for the privilege of building their tools.

Instead government should run the critical infrastructure and open a national developer ecosystem.

Publish:

API specifications.

SDKs.

Reference implementations.

Implementation guides.

Conformance tests.

Security requirements.

Sandbox environments.

Sample datasets.

Certification processes.

Documentation.

Then let people build.

One company makes the best pharmacy application. Another builds maternal-health software. Another a telemedicine service, another ambulance optimisation. A university develops a research platform. A startup in a back room in Harare builds an AI clinical-documentation tool on two second-hand laptops.

All of them connect to the same rails.

This matters economically.

Public infrastructure can become private-sector infrastructure.

The country doesn't just get a healthcare system.

It gets a healthcare technology market.

27.1 Developer ecosystem

Technically, the developer ecosystem rests on:

A developer portal — built on Backstage or a comparable framework: API documentation (OpenAPI, FHIR CapabilityStatement), SDKs (TypeScript, Python, Java, Kotlin, Swift), reference implementations, implementation guides, conformance tests, sandbox environments, sample datasets.

Sandbox environment — a complete, isolated instance of the national HIE with synthetic data, open to any approved developer.

Conformance testing — automated conformance tests (Inferno, Touchstone) that any system can run against the national HIE. Pass, and you get certified.

Certification programme — a formal certification process for applications that connect to the national HIE, covering FHIR conformance, security, privacy, audit, offline capability and usability. Certified applications are listed in a national registry, and procurement prefers them.

SDKs — officially maintained SDKs for the common languages, wrapping the FHIR API in idiomatic, ergonomic interfaces.

Reference applications — open-source reference applications for the most common use cases.

Documentation — comprehensive, versioned, searchable.

Community — a developer forum, a Slack or Discord workspace, regular hackathons, a public roadmap and a support team that answers.

The goal is a national health developer platform that turns government from a buyer of software into a provider of infrastructure.

That's how a country builds a technology industry.

Not by protecting it.

By giving it rails to build on.

28. Procurement must stop buying captivity

There's a pattern that needs breaking.

Government buys system A.

System A keeps its own data.

Five years later government buys system B.

System B can't understand A.

Another vendor builds an integration.

The integration goes obsolete.

A new programme arrives with a new donor and a new logo.

Another database appears.

Eventually the country has software everywhere and architecture nowhere.

That isn't digital transformation.

It's technological sediment: layer on layer of good intentions, each pressed flat by the next.

Nobody in that story is a villain. Each purchase was reasonable. Each vendor delivered what the contract said. Each official signed what was put in front of them. And the result, taken together, is a health system that can't remember what it bought.

So future procurement must require: open interfaces; data portability; national interoperability standards; security conformance; offline capability where needed; auditability; documentation; maintainability; local support; and contractual exit mechanisms.

The question should stop being:

"Can this vendor build us an application?"

It should be:

"Can this system become a responsible participant in a national digital architecture?"

That's a much harder question.

Which is exactly why it's the better one.

Technically, procurement requirements should include:

FHIR conformance — the system exposes a FHIR R5 API conforming to the national implementation guides.

OpenAPI specification — every API endpoint documented in OpenAPI 3.1.

Data export — full data export in FHIR NDJSON and CSV, at any time, on demand, without the vendor's help.

Offline capability — at least 72 hours of offline operation, syncing when connectivity returns.

Security conformance — a passed security assessment covering authentication, authorisation, encryption, audit, input validation, output encoding, session management, error handling and dependency management, based on OWASP ASVS Level 2 or higher.

Audit logging — immutable audit logs for every access to patient data.

Documentation — architecture, API, deployment, operations, user and security documentation.

Source code escrow — for proprietary systems, source code escrowed with a neutral third party.

Exit plan — a documented exit plan in the contract: data migration, knowledge transfer, transition support and a defined exit period.

Local support — local support with defined SLAs.

Total cost of ownership — evaluation over the full lifecycle cost, not just the purchase price.

Reference implementations — the system demonstrated working in a comparable environment.

Open standards — open standards on every interface.

Modularity — decomposable into independently replaceable services.

Vendor neutrality — no dependence on a specific cloud provider, database, operating system or hardware vendor.

Procurement isn't a purchasing function.

It's an architectural function.

Every procurement decision strengthens the architecture or weakens it.

There's no neutral ground.

29. Build the institution that can understand what it owns

A country can't outsource sovereignty.

It can outsource work.

Those aren't the same thing.

If a government hires a company to build a national health platform, and the only people who understand the platform work for the company, then the government doesn't have technical capability.

It has a subscription to someone else's memory.

That's dangerous, and the danger is slow. It doesn't appear on the day the contract is signed. It appears the day the contract ends.

So the national programme needs a permanent technical organisation.

29.1 Staffing: a planning hypothesis, not a settled number

An earlier draft proposed "40–60 people initially, expanding toward 70–100." Those numbers weren't properly justified. They are now presented as a planning hypothesis drawn from a specific operating model, subject to revision.

The operating model behind the hypothesis:

• Central architecture and platform team — owns the national infrastructure. This is the 40–100 figure.
• Regional implementation and support teams — deployed in provinces, embedded with facilities. Separate headcount, not in the central figure.
• Facility IT support — embedded in larger facilities. Also separate.
• Clinical informatics and clinical safety — partly central, partly seconded from clinical services.
• Vendor-provided services — implementation, integration, training. Not counted as national staff.
• Remote engineering — outsourced for non-sensitive components. Not counted as national staff. Subject to the governance conditions in Section 18.4.

A technician at a district support desk, in a headset, writes a ticket on paper by the light of a solar lantern because the power has gone again. The national platform's resilience depends on him more than on any architecture diagram. He doesn't appear in the diagram.

29.2 The senior engineering requirement for AI-augmented development

As Section 18.3 argued, AI-augmented development increases the demand for senior engineering judgement. So the staffing model has:

• Senior-weighted composition. A higher share of senior engineers than a traditional team, because the bottleneck moves from production to review.
• Explicit review capacity. Time and headcount set aside for reviewing AI-generated artefacts — code, tests, documentation, security, clinical safety.
• Senior supervision of AI tooling. AI tooling configured, monitored and governed by senior engineers, not handed out as an unsupervised productivity tool.
• Clinical safety oversight. Clinical content and clinical AI reviewed by clinical informaticians and clinicians, not by engineers alone.

The central team categories:

Enterprise architects.

Software engineers (senior-weighted).

Health informaticians.

Clinical informaticians.

Data engineers.

Cybersecurity engineers.

Cloud and infrastructure engineers.

Network engineers.

DevOps and site-reliability engineers.

QA engineers.

UX researchers.

AI engineers.

Data-governance specialists.

Privacy and legal specialists.

Programme managers.

Technical writers.

Implementation specialists.

The planning hypothesis: a central team of 40–60 at launch and 70–100 at national maturity, senior-weighted, with explicit review capacity, and with regional implementation, facility support, remote engineering for non-sensitive components and vendor services as separate, coordinated functions. The real number should come out of the final operating model in Phase 0, informed by deployment scale and by measured AI productivity effects.

This isn't bureaucracy.

It's a national engineering unit.

A country doesn't build a railway by hiring a train once.

It builds the organisation that keeps the railway alive.

29.3 AI-augmented engineering: a hypothesis to be tested

On certain classes of work, AI tooling can raise a senior team's productivity substantially. As Section 18.2 set out, how much is uncertain and depends on context.

So the programme should:

• Measure the productivity effect in Phase 0 and Phase 1.
• Adjust the staffing model based on what it measures.
• Maintain senior engineering depth regardless of AI tooling, because architecture, clinical safety and governance need experienced humans.
• Avoid assuming AI replaces senior judgement. It doesn't. It amplifies it, mistakes included.
• Allocate review capacity explicitly, because AI-generated artefacts need review.
• Outsource non-sensitive work to remote engineers under the conditions in Section 18.4, adding capacity without giving up sovereignty over the sensitive core.

The staffing model isn't "fewer people." It's more senior people doing more consequential work, with AI carrying the mechanical load and remote engineers handling the non-sensitive components.

30. The engineering organisation

The structure should be modular, like the system it maintains. Organisations end up shaped like what they build, and systems end up shaped like the organisations that build them. Better to choose that shape deliberately.

Platform Engineering

Identity.

APIs.

Interoperability.

Messaging.

Registries.

Service discovery.

Core infrastructure.

Application Engineering

Strategic government reference applications.

Patient services.

Facility services.

Community-health applications.

Data Engineering

Pipelines.

Data quality.

Analytical stores.

National indicators.

Research environments.

Cybersecurity

Security operations.

Identity security.

Threat detection.

Incident response.

Penetration testing.

Security architecture.

Reliability Engineering

Observability.

Performance.

Availability.

Backups.

Disaster recovery.

Capacity management.

Clinical Informatics

Clinical workflows.

Terminologies.

Data models.

Guideline representation.

Clinical validation.

AI Engineering

Model infrastructure.

Retrieval systems.

Evaluation.

Guardrails.

Model governance.

AI observability.

Developer Relations

Documentation.

SDKs.

Sandbox access.

Certification.

Conformance testing.

Technical support for third-party integrators.

That last function may turn out to be one of the most economically important.

A Zimbabwean developer should eventually be able to open a portal, read the specifications, get sandbox credentials, write an integration, run the conformance tests and deploy against the national health network — without knowing anyone in the ministry.

That's what it means for infrastructure to become programmable.

It's also what it means for access to stop depending on who you know.

31. Governance architecture

The technical architecture is elaborate. The institutional architecture has to be just as explicit, or the technical one ends up as an orphan. This section sets out who governs what.

A boardroom with one dead fluorescent panel and a wall air-conditioner that drips. Clinicians, officials, a lawyer, a woman from the community in a printed dress. Someone is speaking with open palms. Governance isn't a chart. It's people in a room arguing in good faith, and the chart is only there so the argument has rules.

31.1 Governance roles

31.2 Governance questions

The governance architecture has to answer:

• Who owns the patient identifier namespace? (National Health Identifier Authority)
• Who governs FHIR profiles? (National FHIR Standards Authority)
• Who can approve clinical terminology changes? (National Terminology Authority)
• Who approves new AI models? (National AI Governance Committee)
• Who handles clinical incidents? (National Clinical Safety Board)
• Who certifies vendors? (National Certification Authority)
• Who arbitrates access disputes? (National Privacy Officer, with escalation to Data Protection Authority)
• Who owns national data standards? (National FHIR Standards Authority)
• Who governs cross-border data exchange? (National Health Data Controller, with Data Protection Authority)
• Who can suspend an application? (National Certification Authority, with immediate effect for safety issues)
• Who certifies an update? (National Certification Authority, with automated conformance testing)
• Who can break the glass? (Authorised clinical roles, with immediate audit and alerting)
• Who audits the auditors? (National Audit Authority)

The last question is the oldest one in the list. It's also the one every institution is most tempted to leave unanswered.

That organisational constitution has to be made explicit. Without it, the technical architecture has no accountability structure — only a lot of very good software with nobody answerable for it.

32. Build an institution that remembers

Technology changes fast.

Institutions forget fast.

Government programmes forget faster.

A new minister arrives. A new strategy is written. A new consultant appears with a new deck. A new vendor proposes a new platform.

The previous architecture disappears into a folder on a shared drive whose password left with the person who set it.

Five years later the country repeats the same discovery exercise and is surprised by the same findings.

Guys bah. We've been here before.

We just don't remember.

That's one reason national technical governance matters. Architecture should be documented. Standards should be public. Decisions should be recorded. Interfaces should stay open. Data models should change deliberately. Technical knowledge shouldn't live in one person's head.

The national platform should become institutional memory.

Not one ministry's memory.

Not one administration's memory.

The health system's memory.

Technically, institutional memory needs:

Architecture Decision Records (ADRs) — every significant architectural decision documented in an ADR: context, decision, alternatives considered, consequences. ADRs are version-controlled, searchable and permanent.

Public documentation — every architecture diagram, interface specification, data model and security policy is public (subject to security review).

Open standards — every interface uses an open standard.

Portable data — every system can export its data in a standard format at any time.

Distributed knowledge — no critical knowledge lives in one head. At least two people understand every system.

Regular review — architecture, standards, security and governance are each reviewed annually.

Institutional memory isn't a document.

It's a practice.

And a practice, unlike a document, dies the moment people stop doing it.

PART IX — THE PROGRAMME

33. The implementation must begin with discovery, not code

The first mistake would be to assemble a development team on Monday and start writing controllers on Tuesday.

Don't.

The first phase should be almost painfully boring.

That's how you know it might be serious.

Every failed national system was exciting at the beginning.

34. Phase 0 — National discovery and architecture

Approximately 3–6 months. The range reflects uncertainty about how much documentation already exists and how available stakeholders will be. AI assistance may shorten parts of it, but discovery quality shouldn't be traded for speed.

Inventory existing systems.

Inventory facilities.

Map existing databases.

Map health workflows.

Map information flows.

Map connectivity.

Map electricity reliability.

Map identities.

Map government systems.

Map donor-supported programmes.

Map private-sector systems.

Map existing health standards.

Map legal obligations.

Identify duplication.

Identify gaps.

Document dependencies.

Define national interoperability requirements.

Define security architecture.

Define the operating model.

Define procurement requirements.

Define the implementation strategy.

Deliverables:

• Existing systems inventory and assessment.
• Reference architecture (this paper, revised and validated).
• National FHIR implementation guide (draft).
• Identity and MPI design.
• Governance architecture.
• Procurement framework.
• Threat model.
• Cost model (three scenarios).
• Maturity gate definitions.
• Pilot design.

AI-assisted elements:

LLM-based document analysis reads existing policy documents, system specifications and donor reports, and extracts structured information about systems, data flows and gaps.

Automated code scanning (where source code is available) identifies data models, APIs and integration points.

AI-generated architecture maps visualise the existing landscape from the extracted data.

AI-assisted stakeholder interviews are transcribed, summarised and structured.

Synthetic patient data (Synthea) is generated early to support design and testing.

FHIR implementation guides are drafted with AI assistance, then reviewed by clinical informaticians.

Measurement in Phase 0:

• Productivity effect of AI tooling on discovery and design work.
• Quality of AI-generated artefacts compared with human-generated ones.
• Time saved versus time spent validating AI tools.
• Review burden created by AI-generated artefacts.

At the end of Phase 0, the government should know what it already has.

More importantly, it should know what to stop buying.

35. Phase 1 — Build the rails

Approximately 6–12 months. The range reflects uncertainty about AI productivity effects and about the complexity of integrating with existing systems, Impilo included.

Build the foundational national services:

National Health Identifier.

Master Patient Index.

Provider Registry.

Facility Registry.

Terminology Registry.

Health Information Exchange.

API Gateway.

Identity and Access Management.

Consent Service.

Audit Service.

Notification Service.

Analytics Foundation.

Developer Portal.

Certification Environment.

Don't try to digitise every clinical workflow at once.

The rails come first.

Otherwise every new application keeps building its own rails.

And twenty years from now someone will still be asking why none of them connect. That person might be reading this paper. It might be me.

Integration with Impilo:

Impilo is the national EHR. The rails must integrate with Impilo, not replace it. Impilo becomes a system of record connected to the national HIE. Its data model is mapped to the national FHIR IG, and its APIs are wrapped where necessary.

AI-assisted elements:

Generating FHIR profiles and implementation guides from national requirements.

Generating API clients, SDKs and reference implementations from OpenAPI specifications.

Generating test suites, conformance tests and synthetic test data.

Generating documentation from code and specifications.

Generating infrastructure-as-code from architecture diagrams.

Generating security policies from access control requirements.

Generating CQL rules from clinical guidelines, with clinical review.

The team concentrates on architecture, clinical safety and governance. The AI carries the mechanical work. Senior engineers review every AI-generated artefact before merge. Remote engineers handle non-sensitive components — UI, tooling, documentation, test harnesses — under the conditions in Section 18.4.

Measurement in Phase 1:

• Productivity effect of AI tooling on engineering work.
• Quality of AI-generated code, tests and documentation.
• Defect rates in AI-assisted versus human-only work.
• Time saved in integration and conformance.
• Review burden created by AI-generated artefacts.
• Effectiveness of remote engineering for non-sensitive components.

36. Phase 2 — Break the system deliberately

Approximately 9–15 months. The range reflects uncertainty about field conditions and pilot scope.

Choose a representative pilot.

Not the easiest facilities.

The difficult ones.

An urban tertiary hospital. A district hospital. Urban primary care. Rural primary care. A laboratory. A pharmacy. A private provider. A community-health workflow.

Then test the ugly things.

No network.

No electricity.

Duplicate patient identity.

Lost device.

Interrupted synchronisation.

Incorrect role.

Broken referral.

Laboratory failure.

Bad data.

Conflicting records.

Emergency admission.

Out-of-date software.

User fatigue.

Incomplete training.

Treat the pilot as an engineering stress test.

The point isn't to prove the system works.

The point is to find out how it fails.

Then fix those failures before national scale, while failing is still cheap and the people it fails are still few.

AI-assisted elements:

Generating chaos engineering scenarios automatically.

Generating synthetic patient populations with realistic edge cases.

Generating load tests that simulate national-scale traffic.

Analysing pilot data to find failure patterns, usability problems and clinical safety concerns.

Generating remediation plans and test cases for each failure mode.

Measurement in Phase 2:

• System behaviour under failure conditions.
• Clinical safety incidents and near-misses.
• User experience and workflow fit.
• Data quality and completeness.
• Interoperability transaction success rate.

The pilot isn't a proof of concept.

It's a failure discovery engine.

37. Phase 3 — Scale workflows, not just facilities

Years 2–4. The range reflects how workflow scale-up is sequenced and how ready facilities really are.

National scale should arrive progressively.

Start with workflows where interoperability produces obvious value:

Patient identity.

Maternal health.

Child health.

Immunisation.

Chronic disease.

Laboratory results.

Pharmacy.

Referrals.

Emergency care.

Public-health surveillance.

A clinic doesn't need to become digitally perfect in one weekend.

Digital maturity should build up in layers:

Registration first.

Then referrals.

Then clinical records.

Then laboratory.

Then pharmacy.

Then billing.

Then analytics.

That makes implementation survivable, and it gives clinicians time to shape the system instead of having it imposed on them.

WHO's primary-care digital-transformation guidance emphasises workflow mapping, data dictionaries, decision-support logic and the direct involvement of health workers in designing and optimising point-of-service systems.

That's essential.

The developer shouldn't be guessing what the nurse does.

Ask the nurse.

Then watch.

Then build.

Then watch again — because what she told you and what she does will differ, and the difference is where the real workflow lives.

AI-assisted elements:

Generating facility-specific deployment packages automatically.

Generating training materials, videos and interactive tutorials in local languages.

Providing AI-powered helpdesk and troubleshooting for facility staff.

Analysing deployment data to find facilities that need more support.

Generating workflow-specific implementation guides for each facility type.

Scaling isn't a one-off project.

It's a continuous capability.

38. The economic model

An earlier draft gave a cost envelope of "US$17–39 million over three to five years" with no bottom-up model behind it. A number without a model is a wish with a currency sign. This section lays the model out, with its assumptions stated and its scenarios separated.

38.1 Assumptions

38.2 Three scenarios

Conservative scenario — assumes a small AI productivity effect; slower scaling; higher per-facility costs; more cautious sequencing.

Reference scenario — assumes a moderate AI productivity effect; standard scaling; market-rate costs; standard sequencing.

Accelerated scenario — assumes a large AI productivity effect; faster scaling; optimised costs; aggressive sequencing.

These figures exclude hospital construction, major clinical equipment and wider national telecommunications investment.

They are planning estimates, not tender prices. Phase 0 will revise them. They are set out openly so that the assumptions can be challenged. Please challenge them. A cost model nobody argues with is a cost model nobody read.

38.3 Sensitivity

The largest cost drivers:

1. Number of facilities — a 20% increase in facilities raises scale-up cost by roughly 20%.
2. Device replacement cycle — shortening it from 3 years to 2 raises device cost by 50%.
3. Connectivity costs — a 50% rise in monthly connectivity cost adds roughly US$2–4M over 4 years for 400 facilities.
4. AI productivity effect — if AI gives no productivity gain, the Accelerated scenario collapses into the Reference scenario.
5. Integration complexity with Impilo and existing systems — high integration complexity can add 30–50% to Phase 1 and Phase 2 costs.
6. Remote engineering proportion — outsourcing more non-sensitive work to remote engineers lowers cost but needs more senior review capacity in-country.

Phase 0 should produce a full sensitivity analysis.

39. The evaluation framework

An earlier draft promised a timeline to "national maturity" without ever saying what maturity was. That's how programmes declare victory: define the finish line after you've stopped running. This section defines it in advance.

39.1 Maturity gates

39.2 Success metrics

39.3 Evaluation methods

Baseline measurement — measure the current state before any digital intervention. Without a baseline, every later number is a story.

Continuous measurement — after deployment, measure the same metrics continuously and compare them against the baseline.

Counterfactual analysis — where randomisation isn't possible, use synthetic control methods, interrupted time series or propensity score matching.

Qualitative measurement — interviews, focus groups and observation, to understand what clinicians, patients and community health workers actually live through.

Economic evaluation — cost-effectiveness analysis (cost per DALY averted), cost-benefit analysis (net present value) and return on investment.

Equity analysis — break every metric down by geography, gender, age and socioeconomic status. An average can hide a province.

The metrics aren't the goal.

They're the feedback loop.

Without measurement there's no learning.

Without learning there's no improvement — only repetition with better branding.

PART X — THE STAKES

40. The return on investment should be measured in human capacity

Don't measure success only with dashboards.

Dashboards are easy.

They can make failure look beautifully organised.

Measure:

How much clinician time has been recovered?

How much duplicate testing has stopped?

How much faster are referrals?

How much medicine wastage has been avoided?

How many stockouts have been prevented?

How quickly can a public-health anomaly be spotted?

How much faster are claims processed?

How much has the administrative cost per encounter fallen?

How many patient records are complete enough to support continuity?

How much time does a Village Health Worker save?

How many more households can one community worker properly support?

How much financial shock does illness inflict on a family?

These are infrastructure metrics.

The true unit of value isn't the number of applications deployed.

It's the amount of human capacity recovered.

41. The health worker is the unit of optimisation

There's another mistake worth avoiding.

Automation shouldn't be designed around reducing headcount.

In a system short of health workers, the rational aim is to increase how much care each skilled person can safely deliver.

The doctor should spend less time searching.

The nurse should spend less time recording the same fact three times.

The pharmacist should spend less time finding out whether the medicine exists.

The community health worker should spend less time carrying paper.

The administrator should spend less time reconciling spreadsheets.

The public-health officer should spend less time waiting for reports.

The human being is the expensive component — expensive to train, expensive to lose, impossible to replace in a hurry.

Software should take the work software is good at.

The human should do the work that needs judgement, empathy, physical presence and responsibility.

That isn't replacing the health worker.

It's multiplying her.

AI multiplies her further by:

Drafting clinical documentation from voice or structured input, so the clinician reviews instead of writes.

Summarising history, so the clinician sees context in seconds.

Suggesting diagnoses and treatment options from guidelines and evidence, so the clinician considers instead of recalls.

Translating between languages, so clinician and patient can talk directly.

Automating administrative tasks, so the clinician can attend to care.

Every minute of clinician time recovered is a minute given back to a patient.

That's the metric that matters.

42. The system must speak Zimbabwean reality

The architecture should be international in its standards and local in its behaviour.

The data model should interoperate with the world. The user experience should work in Mutoko.

That means: local languages; local workflows; local geography; local facility structures; local referral patterns; local payment realities; local device economics; local connectivity; local power constraints; local cultural context.

Voice interfaces may become important.

USSD may have a place in carefully bounded services.

SMS may stay relevant for notifications.

Android will matter enormously.

Offline functionality will matter constantly.

A patient shouldn't have to turn into an English-speaking, broadband-connected, smartphone-owning abstraction to take part in her own country's health system.

The system must come to the patient.

Not require the patient to become more like the system.

AI makes localisation economically viable by:

Translating every user-facing string into Shona, Ndebele and other Zimbabwean languages, with human review.

Generating voice interfaces in local languages.

Adapting clinical content to local context.

Generating training materials in local languages.

Handling code-switching in conversational interfaces — because nobody in Harare speaks only one language in a sentence, and a system that insists on it is listening to nobody.

Localisation isn't a one-off project.

It's a continuous capability.

43. Build for the day everything goes wrong

National infrastructure has to assume adversity.

A database will fail.

A network will fail.

A device will disappear.

A data centre will lose power.

An account will be compromised.

A third-party system will stop answering.

A deployment will go wrong.

Someone will make a mistake.

Someone will attack the system deliberately.

At two in the morning on a ward, the monitor is dark, there's a handwritten note taped across it, and two nurses are writing in hardbound ledgers the way their predecessors did forty years ago. Moths circle the one lamp. The paper fallback isn't a failure of digital health. It's part of the architecture, and it needs designing as carefully as anything else.

So the architecture needs: redundancy; backup; disaster recovery; immutable audit logs; key management; segmented networks; least-privilege access; endpoint management; monitoring; incident response; penetration testing; vulnerability management; and tested recovery procedures.

Don't write "disaster recovery" in the architecture document and move on.

Test it.

Turn off the service.

Restore it.

Break the network.

Recover.

Lose a replica.

Recover.

Simulate ransomware.

Recover.

Resilience that has never been tested is just hope wearing technical vocabulary.

44. The national health developer platform

One of the most powerful long-term investments would be a public developer platform.

Picture a portal where an approved developer can get:

API documentation.

FHIR profiles.

SDKs.

Sandbox credentials.

Synthetic test patients.

Test facilities.

Example workflows.

Conformance suites.

Security standards.

Certification requirements.

Operational documentation.

The developer builds.

Tests.

Certifies.

Connects.

That turns government from a software buyer into an infrastructure provider.

It also opens a door for a generation of Zimbabwean developers to build products for their own country and, eventually, export them.

That matters.

A country that imports every piece of its digital infrastructure stays a consumer.

A country that can build interoperable infrastructure becomes a producer.

45. The most important API is not technical

Sooner or later every engineer learns that an API can be perfectly designed and never used.

Because the hardest integration is between institutions.

A hospital may resist changing a workflow.

A ministry may not want to give up a database.

A vendor may fear losing a customer.

A clinician may distrust an application.

A patient may fear surveillance.

A community health worker may already be overloaded.

Every one of those fears is reasonable. That's what makes them hard.

So the programme needs institutional change management taken as seriously as technical architecture.

Every interface between systems is also an interface between people.

Implementation teams have to sit with the people actually doing the work.

Watch the workflow.

Understand the workaround.

Understand why it exists.

Then redesign it.

Not every inefficiency comes from laziness.

Some of it is scar tissue.

The system has been hurt before. So have the people in it.

46. The ideological traps

46.1 Centralisation versus decentralisation

Every national technology debate turns ideological eventually.

Should everything be central? Should everything be local? Should government own it? Should companies own it? Should data stay in the facility, or go to the national platform?

The right answer is rarely ideological.

It's architectural.

Centralise what benefits from central coordination: identity; standards; registries; security policy; interoperability; national analytics; critical infrastructure.

Decentralise what benefits from local autonomy: facility workflows; application design; appropriate systems of record; innovation; provider operations; local data ownership where it's legally and operationally appropriate.

The system should be neither one giant central brain nor a crowd of disconnected ones.

It should be a nervous system.

Signals move.

Authority stays bounded.

Local reflexes still work — a hand jerks back from a flame before the brain is consulted.

The organism doesn't need every cell to be identical.

It needs them to communicate.

46.2 Government versus private sector

The private sector doesn't have to be the enemy.

Government doesn't have to become a technology monopoly.

Government's strategic role is to provide the common infrastructure and rules that markets alone won't reliably coordinate. Private enterprise innovates on top.

The country can have: reference applications; certified commercial applications; open-source implementations; specialist systems; AI services; research platforms; and new healthcare businesses.

Competition happens above the national rails.

That creates a useful asymmetry.

Government provides stability.

Companies provide variety.

Universities provide knowledge.

Civil society provides social intelligence.

Clinicians provide clinical reality.

Patients provide lived experience.

Engineers turn all of that into systems — and take responsibility for what the systems then do.

46.3 The trap of technological solutionism

One last trap to name: believing software can solve problems that aren't software problems.

Software can't manufacture doctors.

It can't build roads.

It can't guarantee electricity.

It can't eliminate scarcity.

It can't settle political conflict.

All it can do is make coordination cheaper, information more available and decisions better informed.

Where the real problem is a shortage of resources, a failure of political will or a structural inequity, software isn't the answer. It may be a useful way of making the problem visible. That's a different thing, and the difference should be said out loud.

The architecture should be honest about what it can and can't do.

I'm an engineer. I'm the person most tempted to forget this.

47. The ultimate system is not a database

This needs emphasis, because the opposite belief is so comfortable.

A national digital-health initiative shouldn't be judged by how much data it stores.

A gigantic pile of records isn't intelligence. It's a liability waiting for a use.

The ultimate system is a coordinated network that can: identify people; identify providers; move information; protect information; move money; move referrals; track resources; learn from outcomes; and help humans make better decisions.

The database is part of it.

The network is the thing.

48. The end state

Picture the system at maturity.

A person has a trusted health identity.

A clinic can recognise her.

A clinician can retrieve her authorised history.

A laboratory sends results.

A pharmacy verifies prescriptions.

A hospital receives referrals.

An insurer verifies eligibility and processes claims.

A community health worker works offline and syncs when she can.

A district can see its own health capacity.

A province can see its utilisation.

National government can see patterns forming.

Researchers can use governed datasets.

Developers can build interoperable applications.

AI can assist clinicians, administrators and analysts.

And none of it depends on one enormous monolithic application.

It all coexists on common infrastructure.

The country has become a network.

That's the vision. It's less glamorous than an app launch, and it will outlast one.

49. Why this matters to poverty

Poverty usually gets discussed as a shortage of money.

It's more complicated.

Poverty is also a shortage of margin.

A family with little room for error.

One illness.

One missed day of work.

One long trip.

One hospital bill.

One stretch without income.

And the household slides backwards — not because anyone chose it, but because there was no slack in the system to absorb the shock.

A working health system protects some of that margin.

That makes healthcare economic infrastructure.

A healthy worker produces.

A healthy child goes to school.

A healthy mother can care for her family.

A managed chronic condition doesn't become a catastrophic one.

A medicine stockout doesn't become an emergency.

A referral happens fast.

A diagnosis comes early.

A public-health intervention reaches the right place sooner.

Those aren't only health outcomes.

They're economic outcomes.

And when those effects repeat across millions of people, they become national effects.

That's where the compounding happens — the same compounding Section 1 called poverty, running in the other direction.

49.1 A note on the economic argument

That improved health infrastructure reduces poverty is plausible and supported by a substantial literature. But the paper should be honest about the causal chain.

Direct health-system effects — less friction, faster referrals, fewer duplicate tests, fewer stockouts — are measurable and should be measured.

Household financial effects — lower out-of-pocket costs, fewer lost wages, less catastrophic health expenditure — are measurable and should be measured.

Labour and productivity effects — less absenteeism, more productive time — are plausible but harder to measure, and the evidence is mixed.

Educational effects — less school absence from illness — are plausible and measurable.

Macroeconomic effects — aggregate productivity, growth — are highly uncertain and should be treated as hypothesis, not fact.

The claim is that the direct and household effects are likely to be substantial, and that the productivity and macroeconomic effects are plausible but need empirical validation. Section 39's evaluation framework includes metrics for each.

50. The deepest reason to build it

It's tempting to judge technology by what it does.

The better question is what it makes possible.

A road matters because of where people can go.

A network matters because of who can talk.

A power grid matters because of what can run once the electricity is reliable.

A health-information network matters because of what becomes possible once the health system can remember and coordinate itself.

That's the real ambition.

To make the country more capable than the sum of its institutions.

A hospital shouldn't have to be entirely self-sufficient.

A clinic shouldn't have to remember the whole patient.

A community health worker shouldn't have to carry the whole system in her head.

A government shouldn't have to wait months to find out what's happening.

The network should carry part of that weight.

51. Infrastructure must outlive the people who build it

Governments change.

Ministers change.

Permanent secretaries change.

Vendors change. Technologies change. Strategies change.

People retire.

People die.

Projects get renamed.

The patient remains.

The disease remains.

The ambulance still has to arrive.

The medicine still has to be there.

So the platform has to survive memory itself.

Architecture must be documented.

Standards must be public.

Data must be portable.

Interfaces must stay open.

Security must be tested independently.

Contracts must contain exit mechanisms.

Technical decisions must be recorded.

Knowledge must be spread around.

Critical infrastructure must never depend on one company, one consultant, one administrator, or one clever engineer who knows how the whole thing works and never wrote it down.

That isn't resilience.

It's a hostage situation.

And I've been that engineer. Most of us have.

52. What I would build

If I were asked to architect this initiative, I wouldn't start by proposing a shiny national healthcare app.

I'd start with a map.

Then a standard.

Then an identity layer.

Then registries.

Then interoperability.

Then security.

Then analytics.

Then carefully chosen applications.

Then an ecosystem.

Then AI.

In that order.

I'd build the national rails first.

I'd make them boring.

Reliable.

Observable.

Portable.

Secure.

Documented.

Then I'd open them to everyone who can contribute responsibly.

Because the system shouldn't belong, aesthetically, to one vendor.

It should belong, functionally, to the country.

And I'd build it AI-native — not because AI is fashionable, but because AI is leverage, and leverage of uncertain size is worth measuring, not assuming. A senior team with AI tooling may deliver faster than a larger team without it. That hypothesis should be tested, not asserted. The senior engineers who supervise the AI, review its output and answer for its safety are the load-bearing members of the team. AI doesn't replace them. It raises the stakes of having them.

53. The vision

I'm not describing a healthcare app.

I'm describing a Health Operating System.

A digital public infrastructure that lets a country's healthcare institutions recognise one another, talk to one another, transact with one another, learn from one another and, eventually, reason across what they collectively know.

A patient carries her identity without carrying her whole medical archive in a bread bag.

A doctor gets context instead of a blank page.

A laboratory sends information instead of paper.

A pharmacy sees demand instead of guessing.

A hospital receives a referral instead of a phone call.

A community health worker carries a system of memory in a device that still works when the network is gone.

Government sees movement instead of receiving reports about history.

Researchers see patterns without being handed the keys to people's private lives.

Developers build new services without rebuilding the national infrastructure underneath them.

AI interrogates the system without becoming its source of truth.

And the infrastructure gets more valuable with every legitimate participant who joins.

That compounding is what interests me.

Not software as a commodity.

Software as a multiplier.

Not a dashboard.

A nervous system.

Not a database.

A memory.

Not an application.

Infrastructure.

Section 1 called the world a battlefield, and it still is, whether we admit it or not.

Disease doesn't care which agency owns the database.

Poverty doesn't care which vendor won the tender.

The woman on the bench in the corridor doesn't care which architecture diagram was approved.

She cares whether someone can help her.

The job of infrastructure is to make helping her easier, faster, safer and possible at scale.

That's what this initiative should do.

Move information faster than disease.

Move medicine faster than shortage.

Move knowledge faster than ignorance.

Move referrals faster than deterioration.

Move resources toward need.

And give every person in the system a little more memory, a little more reach, a little more time.

On a battlefield like this, small advantages compound.

A better record becomes a better decision.

A better decision becomes better care.

Better care protects a household.

A protected household stays productive.

Productive households strengthen communities.

Stronger communities strengthen the country.

Over time, the country becomes able to do more with what it already has.

That's the promise of serious software engineering in the developing world.

Not that technology will save us.

Technology can't save us. It never could. Anyone who says otherwise is selling something, and I've been that salesman too.

But well-designed infrastructure can make human intelligence travel further.

It can get scarce expertise to more people.

It can help institutions remember.

It can make waste visible.

It can make coordination cheaper.

It can let systems learn.

Back in the corridor, the woman still has the creased card in her hand.

Maybe, one day, she won't need it.

I don't know if that's enough.

Sometimes, in the long war between human vulnerability and human ingenuity, it's enough to move the line.

54. Limitations

This paper doesn't demonstrate what it proposes. It proposes what should be demonstrated. That's an honest position, and also an uncomfortable one.

No empirical validation. The architecture comes from requirements and precedent, not from a controlled trial or a full-scale implementation. Its fit for Zimbabwe is argued, not proven.

No formal architecture evaluation. It hasn't been evaluated with ATAM, CBAM or a comparable formal method. Phase 0 should do that.

No comparative benchmark. It isn't compared quantitatively against alternative architectures. Phase 0 should do that too.

Uncertain productivity effects. The AI productivity claim is a hypothesis, not a fact. Its actual size in Zimbabwe will be measured in Phases 0 and 1.

Uncertain cost model. The cost model is a planning estimate with stated assumptions. It isn't a bid, and Phase 0 findings may change it substantially.

Uncertain timeline. The timeline ranges reflect real uncertainty about integration complexity, AI productivity, field conditions and stakeholder readiness.

No legal opinion. The legal analysis is a technical reading, not a legal opinion. Formal legal review is needed before implementation.

No clinical validation. Clinical content, workflows and AI are discussed architecturally, not validated clinically. Clinical validation is needed before deployment.

No stakeholder study. No stakeholder study is reported. Stakeholder engagement belongs in Phase 0.

Geographic and demographic generality. The paper treats Zimbabwe broadly. It doesn't analyse regional, provincial or district variation in enough detail.

The threat model is not exhaustive. A full threat model needs formal attack trees, STRIDE or LINDDUN analysis per component, and red-team exercises.

The equity analysis is not exhaustive. A full equity analysis needs participatory research with the populations at risk of exclusion — done with them, not about them.

The governance architecture is a proposal. It proposes roles and responsibilities. It doesn't describe existing institutional arrangements in enough detail, and it doesn't account for political economy.

The remote engineering model needs further governance work. Using remote engineers for non-sensitive components is architecturally sound, but the contractual, security and oversight arrangements are only sketched here.

The paper is a starting point for a national conversation, not the end of one.

55. Claim and evidence audit

A paper that asks the state to keep honest records should keep its own. The table below audits the paper's principal claims against their evidence. Where earlier drafts overclaimed, the row says so.

56. References

The following references support the claims in this paper. They are drawn from peer-reviewed literature, standards documents, government publications, and institutional reports.

Standards and specifications

1. HL7 International. FHIR Release 5. https://hl7.org/fhir/R5/
2. HL7 International. FHIR Release 4. https://hl7.org/fhir/R4/
3. HL7 International. Clinical Quality Language (CQL). https://cql.hl7.org/
4. HL7 International. CDS Hooks. https://cds-hooks.hl7.org/
5. HL7 International. FHIR Financial Module. https://hl7.org/fhir/R5/financial-module.html
6. IETF. RFC 9562: Universally Unique IDentifiers (UUIDs). 2024. https://www.rfc-editor.org/info/rfc9562/
7. ISO. ISO 27799: Health informatics — Information security management in health using ISO/IEC 27002. 2016.
8. ISO. ISO 27001: Information security management systems — Requirements. 2022.
9. NIST. Cybersecurity Framework. 2024.
10. OWASP. Application Security Verification Standard (ASVS). 2023.
11. SNOMED International. SNOMED CT. https://www.snomed.org/
12. Regenstrief Institute. LOINC. https://loinc.org/
13. WHO. ICD-11. https://icd.who.int/
14. WHO. ATC/DDD Index. https://www.whocc.no/atc_ddd_index/
15. GS1. GS1 Standards for Healthcare. https://www.gs1.org/industries/healthcare
16. ISO. ISO 20022: Financial services — Universal financial industry message scheme. https://www.iso20022.org/

Zimbabwe legal and policy documents

17. Government of Zimbabwe. Cyber and Data Protection Act [Chapter 12:07]. 2021.
18. Ministry of Health and Child Care, Zimbabwe. Impilo — Zimbabwe's National Health Operating System. https://impilo.mohcc.gov.zw/
19. Zimbabwe Treasury. 2026 National Budget. November 2025.
20. Ministry of Health and Child Care, Zimbabwe. National Health Strategy (current).

Zimbabwe digital health evidence

21. UNICEF. Supporting Village Health Workers with Digital Tools in Zimbabwe: DHIS2 Mobile Pilot Results. 2024.
22. UNICEF. Zimbabwe Health Product Supply Chain Assessment. 2024.
23. MedRxiv. Assessing EHR potential for adaptive learning in multimorbidity care in Sub-Saharan Africa: a mixed-methods study of Zimbabwe's Impilo system. 2026.

WHO and international digital health guidance

24. World Health Organization. Digital Health Platform Handbook: Building a Digital Information Infrastructure (Infostructure) for Health. 2020.
25. World Health Organization. SMART Guidelines. https://www.who.int/teams/digital-health-and-innovation/smart-guidelines
26. World Health Organization. Regulatory considerations on artificial intelligence for health. 2023. https://www.who.int/publications/i/item/9789240078871
27. World Health Organization. Primary health care digital transformation guidance.
28. International Medical Device Regulators Forum. Software as a Medical Device (SaMD): Key Definitions. 2013.
29. ITU. Measuring digital development: Facts and Figures 2024.

Interoperability and architecture frameworks

30. OpenHIE. OpenHIE Architecture Specification. https://ohie.org/
31. OpenHIM. Open Health Information Mediator. https://openhim.org/
32. HAPI FHIR. HAPI FHIR — Open Source FHIR Server. https://hapifhir.io/
33. Medplum. Medplum — Open Source FHIR Platform. https://www.medplum.com/
34. Inferno. Inferno — FHIR Conformance Testing. https://inferno.healthit.gov/
35. Touchstone. Touchstone — FHIR Testing Platform. https://touchstone.aegis.net/

AI and productivity evidence

36. METR. Measuring the Impact of AI on Experienced Open-Source Developer Productivity. 2024.
37. METR. We are Changing our Developer Productivity Experiment Design. February 2026. https://metr.org/blog/2026-02-24-uplift-update/
38. Peng, S., et al. The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. arXiv, 2023.
39. Barke, S., et al. Grounded Copilot: How Programmers Interact with Code-Generating Models. 2023.
40. Vaithilingam, P., et al. Expectation vs. Experience: Evaluating the Usability of Code Generation Tools. 2022.

Differential privacy and de-identification

41. Dwork, C., & Roth, A. The Algorithmic Foundations of Differential Privacy. 2014.
42. OpenDP. OpenDP Library. https://opendp.org/
43. Google. Google Differential Privacy Library. https://github.com/google/differential-privacy
44. Sweeney, L. k-anonymity: A model for protecting privacy. 2002.
45. HIPAA. Safe Harbor and Expert Determination de-identification standards. 45 CFR §164.514.

Health informatics literature

46. Shortliffe, E. H., & Cimino, J. J. Biomedical Informatics: Computer Applications in Health Care and Biomedicine. Springer.
47. Haux, R. Health information systems — past, present, future. International Journal of Medical Informatics, 2006.
48. Coiera, E. Guide to Health Informatics. CRC Press.
49. Wyatt, J., & Sullivan, F. ABC of Health Informatics. BMJ Books.

Digital public infrastructure literature

50. World Bank. Digital Public Infrastructure: A Global Perspective. 2023.
51. UNDP. Digital Public Infrastructure: A Framework for Development. 2023.
52. OECD. Digital Public Infrastructure for Health. 2024.

Design science methodology

53. Hevner, A., et al. Design Science in Information Systems Research. MIS Quarterly, 2004.
54. Peffers, K., et al. A Design Science Research Methodology for Information Systems Research. JMIS, 2007.

Governance and institutional design

55. Ostrom, E. Governing the Commons: The Evolution of Institutions for Collective Action. Cambridge University Press.
56. Fountain, J. E. Building the Virtual State: Information Technology and Institutional Change. Brookings.

Open-source components

57. OpenMRS. https://openmrs.org/
58. DHIS2. https://dhis2.org/
59. OpenELIS. https://openelis.org/
60. OpenBoxes. https://openboxes.com/
61. Keycloak. https://www.keycloak.org/
62. Open Policy Agent. https://www.openpolicyagent.org/
63. Cedar. https://www.cedarpolicy.com/
64. Kubernetes. https://kubernetes.io/
65. PostgreSQL. https://www.postgresql.org/
66. Apache Kafka. https://kafka.apache.org/
67. MinIO. https://min.io/
68. Apache Superset. https://superset.apache.org/
69. Grafana. https://grafana.com/
70. Prometheus. https://prometheus.io/
71. Community Health Toolkit. https://communityhealthtoolkit.org/
72. CommCare. https://www.commcarehq.org/ and https://commcare.dimagi.com/open-source/
73. Apache Iceberg. https://iceberg.apache.org/
74. Apache Flink. https://flink.apache.org/
75. Trino. https://trino.io/
76. Redpanda. https://redpanda.com/
77. Mojaloop. https://mojaloop.io/