I was sitting at my desk in a central health department office when I made the call. Peripheral facilities had been submitting delayed and incomplete data to the central repository, and part of my responsibility was to follow up. I telephoned one of the nurses responsible for data entry at a divisional facility in the district.
She answered. She did not apologise for the delay. She did not offer a technical explanation. Instead, after a brief pause, she described her situation — quietly, carefully, and with the kind of precision that comes not from training but from years of accumulated frustration that has finally found a sympathetic ear.
"I don't know why they are collecting this much data," she said. "I don't know what the benefit is. Most of the time I am confused about what to do with this. Our junior officers are facing a lot of difficulty. Once we enter data in the manual system, we calculate it, then we enter again into the digital system. But what is the output? Why are we doing this much struggle? Nobody knows."
I listened without interrupting her. Because what she had just described was not a complaint to be logged and passed up the chain. It was a clinical diagnosis of the system itself. She had identified, without a single citation or academic framework, a structural pattern in how health technology gets designed: data is extracted from the periphery without returning value to the people who generate it. Burden is imposed without benefit being offered. Systems are built for the centre, at the centre, by the centre.
I understood what she was describing because I had lived on the other side of that telephone for twenty years. At the time, I listened and understood. I did not yet know that the same pattern she was diagnosing would become the foundational risk of the next generation of health technology — artificial intelligence.
This article is not a retrospective criticism of health information systems. It is an argument about what those systems taught us — and a warning that healthcare AI is now being designed with the same assumptions, by the same logic, without having learned the same lessons. We have an opportunity, while AI integration in health is still early, to choose differently. The nurse's question — what is the output? — is the right question to ask of every AI system before it is deployed. Very few people are asking it.
The Experience Behind This Argument
From 2007 to 2026, I worked almost entirely in peripheral care settings in Trincomalee district: as a medical officer in the inward units and MICU of a general hospital, as a general practitioner in two primary medical care units, as the Medical Officer in Charge of a divisional hospital, and as a public health officer at the Regional Director of Health Services office. Each of these settings had its own relationship with data — and its own form of quiet resistance to the systems imposed from above.
At the GP clinic in Kappalthurai, I saw forty or more patients in a day. Between consultations, I was expected to maintain manual registers, complete HMIS forms, update NCD tracking cards, enter data into web portals on a connection that dropped without warning, and compile statistics for monthly reports that were due whether or not we had the time — or the electricity — to compile them accurately. The data went up. The information never came down.
No dashboard. No feedback. No indication of whether the figures we submitted bore any relationship to the patterns the district or ministry understood about our population. The data was collected. What happened to it next was invisible from where we stood.
These were not isolated frustrations. They were the consistent, predictable consequences of a particular way of designing health technology — and over two decades, they taught me three lessons that I now believe are directly relevant to the way healthcare AI is being built today.
Peripheral healthcare workers generate the raw material of every national health information system. They do this at considerable personal cost — time taken from patient care, mental bandwidth diverted from clinical judgement, administrative burden accumulated on top of an already stretched workload. In return, most peripheral facilities receive no feedback from the system they feed. They do not see district comparisons. They do not see trend analyses. They do not know whether their data changed a policy, triggered a resource reallocation, or disappeared into a central database without consequence. The system is extractive in effect.
Lesson One: Technology Designed Without Peripheral Context Cannot Serve Peripheral Reality
Health information systems were typically designed by technical teams working at the central or regional level — ministry officials, WHO advisors, software engineers, health informatics consultants. These teams were competent and well-intentioned. But they designed within the logic of their own environment: offices with reliable internet connections, dedicated data entry staff, standardised workflows, and access to output dashboards that justified the work of data collection.
The peripheral reality was structurally different. Not marginally different — structurally different.
The result of these mismatched assumptions was predictable. Peripheral healthcare workers did not refuse to enter data. They adapted. They completed forms as best they could, under the conditions they had. They batched entries. They estimated. They entered what the form asked rather than what the clinical encounter actually contained. The data arrived at the centre looking complete. The centre read it as complete. The system appeared to function.
What the central dashboard did not show was the quality of the data behind it, the human cost of producing it, or the clinical information that was lost in translation from encounter to field to row in a database.
The lesson for AI: Healthcare AI systems are now being designed with similar assumptions about peripheral settings — that connectivity is reliable, that clinical staff have time to interact with AI interfaces between patients, that the data AI will be trained on accurately represents what happens in peripheral consultations. None of these assumptions are safe without direct peripheral input at the design stage.
Lesson Two: Adding Technology Without Redesigning Workflow Creates Burden, Not Benefit
The nurse described a phenomenon that became almost universal in resource-limited health systems: double entry. Data was first recorded manually — in the register, the outpatient book, the NCD card, the maternal health record. At the end of the day, the week, or the month, someone — usually the same clinical staff member who saw the patients — had to extract figures from those manual records, calculate aggregate totals, and enter them again into the digital system.
This process was not designed to create burden. It emerged from a sequence of decisions made without adequate peripheral input. The digital system was added to a health facility that already had established manual workflows. No one assessed whether the existing manual system would be replaced or supplemented. No one asked the peripheral nurse whether the digital form's fields corresponded to what she was already recording on paper. No one built an interface that could import manual data directly. The result was a doubled workload created by digitisation rather than reduced by it.
Once we enter data in the manual system, we calculate it, then we enter again into the digital system. But what is the output? Why are we doing this much struggle?
The question "what is the output?" was not rhetorical. It reflected a genuine information vacuum. The nurse who entered the data did not know what it produced. She had never been shown a district-level analysis that used her facility's figures. She had never received a report indicating that the NCD prevalence data she submitted contributed to a resource planning decision. She had never seen the dashboard her data fed. She knew the data went somewhere. She did not know what it became when it got there. In the absence of visible purpose, the work felt purposeless — because from where she stood, it was.
The lesson for AI: An AI tool deployed to a peripheral health facility that does not visibly return value — that does not show the clinician what the AI learned, what it recommended, and what difference it made — will generate the same invisible-purpose problem. Peripheral healthcare workers will interact with it because they are asked to. They will not trust it, because they will have no evidence that it is working for them rather than extracting from them.
In peripheral settings, it is common for thirty days of patient data to be entered in the final two days before the monthly reporting deadline. This is often misread at the centre as a discipline or motivation problem. It is not. It reflects the impossibility of real-time data entry in a single-doctor facility with continuous patient flow and no dedicated data entry staff. The double-entry burden — manual registration followed by digital submission — makes concurrent entry practically unachievable. The workaround is retrospective batch entry. The data arrives on time. The data quality is compromised. The centre sees completion. The peripheral worker is exhausted.
Lesson Three: When Frontline Users Are Not in the Design Room, the System Serves Everyone Except Them
There is a governance pattern embedded in how health technology gets built that precedes and produces all the technical problems. The nurse who described her situation to me had not been asked. Not once, in the years she had been entering data into the system, had anyone from the district or ministry office invited her perspective on whether the system worked, what the barriers were, what information she needed in return, or what a better system would look like. She had never sat in a design meeting. She had never reviewed a form before it was finalised. She had never been asked to test a digital interface before it was deployed to her facility.
This was not unusual. It was the default. Health information systems were designed through a process that involved ministry planning offices, technical consultants, international advisors, and software development teams. Site visits to peripheral facilities were sometimes conducted — usually briefly, usually by senior officials who were received differently than the staff experienced their daily conditions, and usually to assess infrastructure rather than to elicit design input from frontline workers.
The consequence was a system designed around the information needs of the centre rather than the information capacity of the periphery. The centre knew what it wanted to receive. It built a system to receive it. The periphery was the source — and the periphery's constraints, knowledge, and needs were treated as implementation challenges rather than design inputs.
The lesson for AI: The governance of healthcare AI development largely follows the same logic. AI tools for clinical decision support, disease surveillance, and resource allocation are being designed by technology teams, AI researchers, and central health authorities. The peripheral nurse, the rural GP, the community health worker who will be expected to interact with these tools daily — they are rarely in the room. Their absence is not deliberate exclusion. It is the unexamined default. And it is the most predictable route to the same outcome.
What Moving to the Centre Revealed
I now work at the central level. I sit in offices with reliable internet connections. I have access to the dashboards the nurse has never seen. I attend meetings where district-level data is analysed, where graphs are drawn, where policy discussions reference statistics that peripheral healthcare workers spent exhausting hours producing.
What this transition has shown me is not incompetence at the centre. The people working in central health information offices are capable, committed, and genuinely trying to build functional systems. What I have observed is a structural absence: peripheral voices are not in the room when systems are designed. The people who understand what it costs to generate the data — what it takes, what it disrupts, what it competes with — are not present when decisions are made about what data to collect, in what format, on what timeline, through what interface.
The result was systems that were technically functional and humanly unworkable. Systems that produced dashboards at the centre and exhaustion at the periphery. Systems that measured completeness rather than quality. Systems optimised for reporting rather than for the clinical and administrative realities of the people who operated them.
When I began my training in health informatics and encountered the early literature on healthcare AI, this pattern was immediately familiar. The language had changed. The architecture had changed. But the underlying logic — technology designed at the centre, for the centre, about the periphery — had not.
Why Healthcare AI Must Learn These Lessons Now
The three lessons described above are not historical curiosities. They are active risks in the development of healthcare AI — and they are risks that are considerably more consequential at AI scale than they were at HIS scale.
The data problem. AI systems built to support clinical decision-making, disease surveillance, or resource allocation in peripheral settings will be trained on health data generated under the same constraints described in this article — data compressed into inadequate form fields, entered retrospectively after the clinical encounter, batched at month end under time pressure, by healthcare workers who were never told what the data would be used for. The AI cannot see what was omitted. It cannot know that the nurse entered the most available diagnosis code rather than the most accurate one because the accurate one required a form field that did not exist. It can only learn from what was entered. An AI trained on peripheral health data will carry the structural biases of peripheral data collection — and it will present those biases as clinical intelligence.
The workflow problem. AI tools, like digital health systems before them, are at risk of being added to existing clinical workflows rather than integrated into them. If a peripheral nurse is already completing manual registers, paper referral forms, and monthly HMIS returns, an AI interface that requires additional data input — even a few extra fields — will be experienced as another layer of burden. If the AI requires reliable internet connectivity to function, it will be unreliable in the same settings where connectivity has always been unreliable. If the AI response time is calibrated for fibre-connected central offices, it will be unusable between patients in a thirty-patient peripheral outpatient clinic. These are not edge cases. They are the conditions under which most peripheral healthcare actually occurs.
The trust problem. Perhaps most fundamentally, healthcare AI in peripheral settings will face the same trust deficit that health information systems created — unless it is designed explicitly to return value to the people who interact with it. A peripheral clinician who is asked to use an AI diagnostic support tool but who never receives feedback on whether the tool's suggestions were accurate, never sees how the tool's recommendations compare against district outcomes, and never understands what the tool is doing with the data it collects — that clinician will use the tool because they are required to. They will not trust it. They will work around it. They will document what the tool expects rather than what the patient presented. The data quality problem will reproduce itself at the next level of abstraction.
- Frontline inclusion from the first design meeting. The peripheral nurse, the rural GP, the community health worker must be present when AI tools are being specified — not consulted after prototype development, not surveyed after deployment. Their constraints define the design problem.
- Visible, local return. Every AI interaction at the peripheral level should generate visible value for that user — a summary, a local pattern, a comparison, an alert relevant to their facility. If the AI takes data and returns nothing visible, it will be experienced as extraction.
- Offline-first, low-bandwidth design. AI tools for peripheral health settings must function without reliable internet connectivity. Edge computing or mobile-first architectures are not optional features — they are prerequisites for any peripheral deployment.
- Workflow integration, not workflow addition. AI must be designed around existing clinical workflows, not placed on top of them. Every additional step an AI requires must replace an existing step — not supplement it.
- Transparent accountability. Peripheral healthcare workers must be able to understand, question, and report on AI recommendations. An AI tool that cannot be interrogated by the clinician using it is a system without governance — which is precisely what HIS was.
These recommendations are grounded in an existing evidence base. Heeks (2006), in a widely cited analysis of health information system implementation in developing countries, identified the gap between the "world as imagined" by designers and the "world as is" in practice as the primary predictor of implementation failure — a finding that directly anticipates the risks of AI deployment in low-resource peripheral settings.1 The WHO Global Strategy on Digital Health 2020–2025 explicitly requires that digital health systems be "designed with and for the people who use them," naming participatory design as a prerequisite for sustainable adoption.2 These principles apply with equal — and arguably greater — force to AI. AI systems do not just collect data. They interpret it, act on it, and shape clinical decisions based on it. The consequences of design assumptions that do not match peripheral reality are correspondingly more serious.
The Opportunity That Still Exists
Health information systems were largely designed, deployed, and entrenched before the implementation science literature had the influence it now has. The lessons took decades to accumulate. By the time the evidence was clear, the systems were already running, the workflows were already dependent on them, and the cost of redesign was prohibitive.
Healthcare AI is different. It is early. The systems are not yet entrenched. The peripheral nurse has not yet been asked to use an AI tool every day. The governance frameworks are not yet fixed. The training data pipelines are still being designed. The decisions being made now about how AI will be integrated into peripheral health systems — who is consulted, whose constraints are treated as design inputs, what value is returned to frontline workers, how trust is built before adoption is required — these decisions are still open.
This is a rare moment. The implementation science literature from twenty years of HIS experience is available. The lessons are documented. The patterns are predictable. The question is whether the teams building healthcare AI will read that literature before they deploy — or whether they will wait to learn the same lessons from a different nurse on a different telephone in a different decade, asking the same question.
What is the output? Why are we doing this much struggle?
She was not complaining. She was diagnosing. The diagnosis was correct then. It will be correct again — unless we choose differently now.
Selected References
- Heeks R. Health information systems: Failure, success and improvisation. International Journal of Medical Informatics. 2006;75(2):125–137. doi:10.1016/j.ijmedinf.2005.07.024
- World Health Organization. Global Strategy on Digital Health 2020–2025. Geneva: WHO; 2021. Available at: who.int
This article is written in the author's personal academic capacity as an MD Trainee in Health Informatics at PGIM, University of Colombo. It draws on professional experience from field postings (2007–2026) to contribute to emerging academic discourse on healthcare AI governance and implementation. It does not constitute a criticism of any current government institution, programme, or policy. All quotes from peripheral healthcare workers have been paraphrased and generalised; no personally identifying information is included. The views expressed are the author's own and do not represent the official position of any employer, institution, or government body.
