Information for Action
Connective tissue
Chapter 11 · Digital Health and Informatics
Digital health, informatics and the architecture that ties the system together.

By the time you have read this chapter, you will be able to:
- Describe the national digital health architecture in South Africa and explain where your district fits within it.
- Explain what a Provincial Health Data Centre does and how linked patient-level data changes what a manager can see.
- Define interoperability and describe how a health information exchange lets separate systems speak one language.
- Apply the conditions of the Protection of Personal Information Act (POPIA) to the everyday handling of patient data in your facilities.
- Assess your district’s digital maturity and plan a realistic path from paper to digital.
- Use artificial intelligence (AI) as a working partner while keeping human judgement, and human accountability, in charge.
Introduction: The tissue that connects
Every chapter so far has built a part of the living body. The routine health information system (RHIS) is the sensory network. The information cycle is the impulse that travels along it. Visualisation gives the body eyes, stories give it a voice, and stewardship gives it muscle.
But a body is more than organs and nerves. Between and around every organ runs connective tissue, binding the parts into a whole, and through it all runs the circulation, carrying supplies to every cell and carrying signals to places nerves do not reach. Without connective tissue, the organs are a heap. Without circulation, each one starves alone.
Digital health infrastructure is the connective tissue and circulation of the health system. The nerves can only reach what the body connects. A clinic with no network link is like a limb with no blood supply: the nerve endings are there, but nothing flows.
This chapter is about that plumbing, and about the rules and habits that keep it safe. It is deliberately practical. You do not need to write code or configure a server. You do need to know what the pieces are, what they do for you, what the law expects of you, and how to walk the road from paper to digital without dropping the service on the way.
One warning before we begin, and it is the theme of the whole chapter: technology amplifies what is already there. Digitise a clear, simple process and you get a faster clear, simple process. Digitise a broken process and you get a faster broken process. Chapter 3 taught that every system produces exactly what it was designed to produce. That law does not soften when the system moves onto a screen.

11.1 The digital landscape a district manager actually faces
Start with what you see from your desk, because the national picture only matters through what it does there.
A typical South African district in the mid-2020s runs a hybrid of paper and digital, as Chapter 5 described. Registers and tally sheets still live at many service points. Aggregate counts flow monthly into the District Health Information Software (DHIS2), the aggregate spine of the RHIS. Alongside it run patient-level systems that grew up separately, each built for one programme: a registry for HIV care, another for tuberculosis, stock systems for medicines, laboratory results from the national laboratory service, and in some provinces a patient administration or clinical record system at hospitals and clinics.
Each of these systems works. That is not the problem. The problem is that they work alone. The nurse re-enters the same patient into three systems. The manager receives four reports that describe the same clinic and do not agree. A patient transfers to the next town and arrives as a stranger, her history locked in a system that does not travel with her.
Clinicians and managers name this pain fragmentation. In the body metaphor it is simpler: these are organs without circulation. Each is alive, but nothing flows between them.
South Africa has spent two decades building the flow. The eHealth Strategy of 2012 to 2016 laid the first foundations. The National Digital Health Strategy 2019 to 2024 set a vision of person-centred digital health, and its successor for 2025 to 2029 carries the work towards a shared national electronic health record. You do not need to memorise the strategy documents. You do need to know the direction of travel, because every new system that arrives in your district over the next decade will be a step on this road: away from programme silos, towards one connected record of care.
11.2 The national digital health architecture
An architecture is just an agreed plan for how the pieces fit. A house has one: the plumbing meets the geyser, the wiring meets the board, and a plug bought in any shop fits the socket in any wall. National digital health architecture does the same for health information. Its main pieces are worth knowing by name.
Unique identification of each patient. Everything else depends on knowing that the person in front of you is the same person who visited another clinic last month. The Health Patient Registration System (HPRS) gives each patient a single registration across public facilities, feeding a master patient index, the national list that matches records to people. In body terms, this is the blood type of the whole system: get it wrong and every transfusion of data between systems is rejected.
The aggregate spine. DHIS2 remains the workhorse for routine aggregate counts and the indicators built on them. It answers population questions: how many, how often, what coverage. It cannot answer person questions: who missed her appointment, whose treatment failed. Both kinds of question matter, and the architecture needs both kinds of system.
Patient-level systems and registries. Electronic medical records (EMRs) hold the clinical story of one person over time. Registries hold a structured slice of that story for one condition: the HIV and TB registries your programmes run today are the familiar examples. The national direction is towards a shared electronic record platform, developed under the national digital health strategy, intended to grow into the record that follows the patient. Provinces and programmes will converge on it over years, not months. Until then, the registries and local systems remain the working reality, and they remain valuable: a registry that tracks every TB patient to the end of treatment is a fine instrument, whatever replaces it later.
A caution about names belongs here. Product names change faster than books reprint. Systems are renamed, merged and retired as the architecture matures, and a registry that is familiar today may be sunset within a few years. Learn the roles, not the brand names. When a named system goes, its role remains, and the questions this chapter teaches you to ask of it remain too.
Messaging platforms. MomConnect showed the other half of the circulation: information flowing outwards to people, not only inwards to managers. A pregnant woman registered at any clinic receives stage-appropriate messages on her own phone, and can send questions back. The lesson generalises. The cheapest, most available digital device in your district is the phone in your patient’s pocket.
The rules of connection. Standing behind these systems is the Health Normative Standards Framework, the agreed set of standards that new systems must meet so that they can exchange information. We return to it under interoperability, because it is the piece managers most often overlook and vendors most often skip.
The architecture, then, is not one big computer in Pretoria. It is an agreement: one patient identity, aggregate and patient-level systems each doing their proper work, messages flowing to and from patients, and shared standards so that every new piece plugs into the whole.
11.3 The provincial health data centre: Circulation with a heart
The Western Cape’s Provincial Health Data Centre (PHDC) is the most developed South African example of what happens when the circulation is actually connected, and it is worth studying whichever province you serve in, because it shows the destination.
The idea is plain. Take the patient-level data that already flows through the province’s systems: patient administration, clinical records, laboratory results, pharmacy dispensing, disease registries. Link them, person by person, using the unique patient identity. Store the linked result in one governed environment with strict access rules. The product is a single, longitudinal view: one person, all services, over time.
What does that buy a manager? Consider three things the linked view can do that no single system can.
First, cascades. Because the PHDC sees testing, diagnosis, treatment and outcomes for the same person, it can report how many people with a condition were diagnosed, how many of those started treatment, and how many of those reached control or cure. Chapter 4 taught you to think in numerators and denominators; a linked data environment is a denominator machine.
Second, finding the missing. A list of patients who tested positive but never started treatment is a work list, not a statistic. During the COVID-19 pandemic the PHDC produced daily linked views that let managers see, within a day, who had been admitted and who was at highest risk. The same machinery now serves the quieter emergencies: the diabetic lost to follow-up, the child who missed a second vaccine dose.
Third, honest numbers. When admission data, laboratory data and pharmacy data describe the same person, errors surface. Linkage is a data-quality instrument, an extension of the immune system from Chapter 5, because contradictions between systems reveal what a single system hides.
A worked example: Cherry district reads its hypertension cascade
Cherry district, whose team you met triangulating data sources in Chapter 5, requested a hypertension cascade for its adult population of 60,000. The linked view returned five numbers.
An estimated 16,200 adults in the district have hypertension, using the provincial prevalence estimate of 27 per cent as the denominator anchor. Of these, 9,700 appear in the linked record with a documented diagnosis. Of those diagnosed, 7,100 collected treatment at least once in the past year. Of those, 4,300 collected treatment in at least four of the past six months, the district’s working definition of retention. And of the retained group, 2,150 had a blood-pressure reading under control at their last visit.
Lay the five numbers side by side and the shape of the problem changes. The team had spent two years worrying about diagnosis, running screening campaigns at clinics and community events. The cascade shows the widest step is not there. From 16,200 to 9,700 is a loss of 40 per cent, but from 9,700 diagnosed to 4,300 retained is a loss of 56 per cent of those already found. The district was pouring water into a bathtub, Chapter 4’s image, without checking the plug.
Notice what made this reading possible. No single system could produce it. The diagnosis lives in clinical records, the collection pattern in pharmacy data, the blood-pressure reading in the clinic system. Only person-by-person linkage joins them, and only the unique patient identity makes the linkage true. Notice also what the cascade does not say: it does not say why retained patients are not controlled. That question goes back to the But-why discipline of Chapter 2, to be asked in a deep dive with the facts on the table. The linked view finds the widest step. The team still has to climb it.
A caution balances the promise. Linked patient-level data is powerful, and power concentrated needs governance concentrated around it. The PHDC works because access is narrow, purposes are defined, every query is logged, and the small team that runs it treats patient trust as the asset that everything else depends on. That is stewardship, Chapter 8’s muscle, wrapped around the most sensitive tissue in the system. A data centre without that discipline would not be an achievement. It would be a liability with a server room.
11.4 Interoperability: Teaching the organs one language
Interoperability is the ability of separate systems to exchange information and to use what they exchange. The second half of the definition is the half that bites. Two systems can swap files all day; if one records dates as day-month-year and the other reads them as month-day-year, the exchange is worse than none.
The body solved this problem long ago. Organs do not send each other essays. They communicate through a shared chemical vocabulary, hormones and signals whose meaning is fixed for every tissue. The pancreas does not negotiate with the liver about what insulin means.
Health systems achieve the same through standards: agreed formats for the messages (in modern systems, typically the HL7 FHIR family), agreed code sets so that a diagnosis or a test means the same thing everywhere, and agreed identifiers so that the person, the facility and the clinician are matched correctly. A health information exchange (HIE) is the infrastructure that carries these standard messages between systems, the bloodstream through which the shared vocabulary travels.
For a district manager, interoperability is mostly something you demand rather than something you build. The moment it becomes your business is the moment anyone proposes a new system for your district: a donor-funded app, a screening tool, a clever dashboard. The question that protects you for the next decade is not “what does it do?” but “what does it speak?” Ask four things.
Does it use the national patient identifier, or does it mint its own? Does it conform to the national standards framework, and can the vendor show it, not merely say it? Can data get out as easily as in, in a standard format you could hand to the next system? And who owns the data it holds: the department, or the vendor?
A system that fails these questions is not a gift, whatever its price. It is a new organ with no blood supply, and one day you will pay staff to retype its contents into the systems that actually connect.
11.5 Records and registers: Patient-level and aggregate, side by side
Chapter 5 introduced EMRs as a data source. Here we place them in the architecture, because the relationship between patient-level and aggregate data confuses many teams, and the confusion wastes effort.
An EMR serves care first. Its unit is one person; its purpose is that the next clinician knows the story so far. A registry serves a programme: one condition tracked to outcome. DHIS2 serves management: counts, coverage and trends for a population. These are three different jobs, and no one of the three replaces the others.
The efficiency prise is to make them feed each other instead of competing. In a mature setup, the clinician records the visit once in the EMR, the registry entry is generated from that record, and the monthly aggregate counts are computed from the same source, not tallied again by hand. Each fact is captured once, at the point of care, and every report downstream is a re-use. That is the digital form of a principle you already know from Chapter 5: collect once, use many times.
Until your district reaches that maturity, the practical rule is to know, for every indicator you report, which system is the source of truth, and to stop double-capturing wherever a flow exists. Every month, ask your information officer one question: what did we retype this month that a connection could have carried? The answer is your interoperability agenda, in order of pain.
11.6 Data governance, privacy and consent: POPIA in the clinic
Digital circulation moves data faster and further than paper ever could. The same pipe that sends a result in seconds can leak a thousand records in seconds. So the connective tissue needs what the body has: a skin, and gatekeepers at every crossing. In South African law, that skin is the Protection of Personal Information Act (POPIA), in force since 2021.
POPIA is not an obstacle to data use. It is the rulebook that makes data use trustworthy enough to continue. Its heart is a set of conditions for lawful processing, and for a health manager they distil into habits your teams can practise.
Purpose and minimality. Collect personal information for a defined purpose, and collect no more than the purpose needs. This is KISS from Chapter 5 wearing a legal gown: the register with three unused columns is now not only wasteful but hard to defend.
Consent and lawful basis. Health information is special personal information, the most protected class in the Act. Processing it for the patient’s own care is provided for; using identifiable records for anything beyond care, research for example, needs a proper lawful basis, often explicit consent or approved research permission. The safe reflex: aggregated and de-identified data for management and planning, identifiable data only for care and for defined, authorised purposes.
Security safeguards. The Act requires reasonable measures against loss and unlawful access. In a facility this is concrete: passwords not shared or taped to the screen, access rights matched to roles, records not carried on personal memory sticks, patient lists not sent through personal messaging apps, paper records locked away at night. The strongest firewall in the province cannot compensate for a discharge summary photographed and forwarded on a private phone.
Openness and participation. Patients have the right to know what is held about them and to have errors corrected. A team that handles such a request respectfully is displaying the system’s trustworthiness in the most visible way it ever will.
Accountability and breach. Someone identifiable is responsible, and when things go wrong, the responsible party must notify the Information Regulator and the affected people. Hoping a breach stays quiet is both unlawful and, in the era of screenshots, naive.
Two closing thoughts anchor the section. First, governance is the skeleton, as Chapter 8 taught, and POPIA is now part of that skeleton; stewardship remains the muscle that moves it, the named people who check access lists, run the password audit, and brief new staff. Second, privacy protects the very asset the whole book depends on. Patients tell the truth to systems they trust. Lose the trust and the data quality chapter unravels with it, because frightened patients give false names, and a false name breaks the unique identity on which the entire architecture stands.
When the circulation leaks: A story from Guava
One Friday afternoon, a well-meaning facility manager in Guava subdistrict photographed the week’s list of patients who had missed antiretroviral collection and sent it to the ward-based outreach team’s group chat, so that community health workers could trace them over the weekend. The intention was good. The channel was not. The group chat ran on a free messaging app, on personal phones, and included two members who had left the outreach team months before.
By Monday, one traced patient had been asked about her treatment by a neighbour. She did not return to that clinic. She re-registered at a facility in the next subdistrict under a different surname.
Count the damage in the terms of this book. A breach of the security safeguards condition, with a duty to report. A patient lost to the very follow-up the list was meant to serve. And a false identity now sitting in the master patient index, quietly breaking the linkage on which every cascade depends. One photograph, three system injuries.
Now note what the fix was not. It was not a ban on tracing, and it was not a return to paper. Guava’s response was to move the tracing list into the approved outreach tool with named accounts, to prune the group chat, to brief every facility on the one rule that would have prevented the harm, and to handle the affected patient’s case with an apology and a corrected record. Tracing continued the following weekend, through a channel the patients could trust. Privacy done well does not slow the work. It is what keeps the work welcome.
11.7 Digital maturity: The path from paper, without dropping the service
Districts often ask for a verdict: are we behind? The better question is the one a clinician asks of a growing child: is development proceeding in the right order? Bodies mature in sequence. Bones before load, coordination before sprinting. Digital health has a similar developmental sequence, and most failed projects are failures of sequence, not of technology.
A practical maturity ladder for a district looks like this.
Reliable paper. A clean register, filled in the same way every day, with someone who checks it, outranks a neglected computer. If the paper process is chaotic, fix it first; you now know that digitising chaos yields faster chaos.
Foundations. Power that stays on, a network that reaches the service points, devices that are maintained, and staff with basic digital confidence. Foundations are unglamorous and never launch with a ribbon, but every later storey stands on them.
Digital capture at source. Data entered where care happens, once, by the person providing the care, into a system that validates as it captures. This is where the Five Cs of data quality gain their digital reinforcement: the impossible date rejected at entry, the missing field flagged on the spot, while the patient is still in the room.
Connection. Systems begin to exchange: results flow back, records follow patients, aggregates are computed rather than retyped. This is the interoperability stage, and it is where the questions of section 11.4 earn their keep.
Intelligence. Only on connected, quality-assured data does the top storey make sense: dashboards that refresh themselves, alerts that fire early, and the AI assistance of the next section. Districts that reach for this storey first, buying dashboards to sit on disconnected, doubtful data, decorate a house with no walls.
Three rules keep the climb honest. Sequence: do not start a storey until the one below carries weight. Parallel running: when a digital system replaces paper, run both only as long as a defined test needs, with a decided end date, because indefinite parallel running doubles workload and halves trust in both systems. People: budget for training and support with the same seriousness as for devices, since a tablet without a confident user is expensive paper.
A case study: Mango learns to climb in order
Mango Hospital’s subdistrict offers the cautionary tale and its correction in one story. Three years ago the subdistrict received donor funding for tablets and a dashboard licence, and took the top of the ladder first. Forty tablets were issued. A wall-mounted screen in the boardroom refreshed nightly with indicators drawn from data that was still captured on paper, retyped weekly, and full of the gaps Chapter 5 taught you to expect.
Within a year the project had the shape every experienced manager will recognise. A third of the tablets were broken or lost, with no repair budget, because the plan had bought devices but not maintenance. The dashboard displayed impossible values with total confidence, because validation had never been built into capture. Staff, asked to run paper and digital together indefinitely, trusted neither. The boardroom screen was switched off, at first for a meeting, then permanently. The evaluation called it a technology failure. It was nothing of the kind. It was a sequence failure.
The correction began when a new information officer did the unglamorous audit the project had skipped. She graded every facility on the ladder. Two of nine facilities had unreliable registers: rung one not solid. Six had no working network point at the place where care actually happened: rung two absent. Her recommendation reversed the budget: repair the registers first, then power and connectivity, then digital capture at the two facilities that were ready, with a decided end date for parallel running, then connection. Only in the third year did a modest dashboard return, now fed by validated capture at source.
The postscript matters. When the dashboard came back, nobody needed to be ordered to look at it. The teams that had built the rungs beneath it already believed the numbers, because they had made the numbers believable themselves. The lesson travels: the question is never whether your district will digitise, but whether it will digitise in an order that carries weight.
11.8 Artificial intelligence: A partner, not a replacement
The newest arrival in the district’s digital life is artificial intelligence, and it deserves a clear-eyed welcome: neither the panic that refuses it nor the awe that surrenders to it.
Start with what AI actually does well in health information work today. It summarises: long reports condensed to a page a busy manager will actually read. It drafts: a first version of the monthly narrative, the feedback letter, the presentation, for a human to correct and own. It classifies and codes: free text sorted into categories, records matched despite spelling variations, work that consumed clerk-hours now done in seconds and checked in minutes. It predicts: given good historical data, it can flag the patient at risk of missing an appointment or the facility trending towards a stockout before the human eye sees the curve bend. And it translates and simplifies, turning technical material into plain language, and into more of South Africa’s languages, than any communications budget could.
Every one of these is a form of augmentation. The pattern to hold onto is the microscope. A microscope does not replace the pathologist; it extends her sight, and the diagnosis remains hers. Used this way, AI is a tireless junior partner: fast, never bored, and always in need of review.
Now the risks, stated plainly, because they are as real as the benefits.
Bias. AI learns from the data it is given. If the historical data under-represents rural patients, or reflects years of unequal service, the model inherits the inequality and repeats it fluently. The equity lens from Chapter 4, looking beyond the average, applies to algorithms with full force.
Confident error. AI systems, especially those that generate text, can be wrong in perfect grammar. They do not know when they do not know. A fabricated figure in a fluent paragraph is more dangerous than an obvious gap in a table, because it invites belief.
Opacity. Many models cannot explain their reasoning. “The computer says this facility is high-risk” is not an explanation, and Chapter 2 taught you never to act on a number you cannot interrogate. But-why applies to algorithms too.
Privacy. Patient data pasted into a public AI tool has left your governance entirely. It is a POPIA breach with a friendly interface. Only tools approved by the department, running under its safeguards, may touch identifiable information. This rule needs to be said in every facility, once a quarter, because the public tools are in every pocket.
Deskilling and drift. A team that stops doing its own analysis loses the ability to check the machine’s. Keep the hand-drawn graph from Chapter 6 alive, not from nostalgia, but because the skill of drawing it is the skill of doubting it.
The governing principles, then, fit on one slide, and the exercise below asks you to put them there. A human remains accountable for every decision; AI advises, people decide. Anything AI produces is a draft until a person has checked it. Identifiable data goes only into approved tools. Ask the equity question of every model: who is missing from the data it learned from? And be transparent: when AI helped produce a report, say so.
What does the trade look like in practice? One district office ran the test that Exercise 6 will ask of you. The monthly narrative report, which took the information officer most of a day to draft, was given to an approved AI tool to produce a first version from the indicator tables and the deep-dive notes. The draft came back in under a minute. Checking it took forty minutes: two figures had been transposed, one facility name was wrong, and one confident sentence described a trend the data did not show. The corrected report went out half a day earlier than usual, and the officer spent the recovered time on the analysis that only she could do. The team’s verdict captured the whole section in one line: the tool writes faster than we do, and it lies more fluently too, so it drafts and we sign.
Used under these principles, AI belongs in the metaphor that runs through this book not as a new brain, but as a fine new instrument in the hands of the same clinician. The nervous system stays human. The judgement stays yours.
11.9 What district managers can do starting tomorrow
The whole chapter compresses into seven moves, none of which needs a budget line this quarter.
Draw the anatomical chart of your systems (Exercise 1) and put it on the wall beside the hand-drawn graphs. Adopt the four interoperability questions and let no new system into the district without answers in writing. Find your route into linked patient-level data, through the PHDC or its nearest equivalent, and request one cascade that matters. Do the privacy walk-through in your biggest facility and fix the cheapest leak found. Grade every facility on the maturity ladder and move budget one rung down, towards foundations. Stop one instance of double capture. And draft the one-page AI charter before an unapproved tool drafts it for you by accident.
None of these is technology procurement. All of them are stewardship, the muscle of Chapter 8, working on the newest tissue in the body.
11.10 Final thought
Every generation of health workers inherits one great connective project. A generation ago it was the district health system itself: binding clinics, hospitals and communities into one organism with one purpose. Ours is digital: binding the information those services produce into one circulation, so that the whole body knows what any part of it learns.
The temptation will be to treat this as a technical project that specialists deliver and managers receive. Resist it. The specialists will build the vessels, but what flows through them, whether it is trusted, whether it is used, whether it reaches the community and returns, is decided in the district, by the habits this book has been building since Chapter 1. A connected system that nobody questions is District A with better cables. A connected system in the hands of a curious, disciplined team is District B at a scale the first edition of this book could only imagine.
The nerves are yours. The circulation is coming. Make sure the body they serve is a learning one.
Recommended reading
To be populated.