Biometric patient enrollment on DHIS2

Recognising a returning patient is the quiet prerequisite for everything else a health program does. Treatment history, adherence, follow-up, continuity of care — all of it depends on matching the person in front of you to a record created some time ago, often at a different facility, by somebody else.

Nepal’s HIV treatment registers were on paper, and they did this badly in a way that is documented rather than remembered: unique identifiers were managed inefficiently, which produced duplicate records and over-estimated coverage. A patient who transferred between treatment sites was sometimes enrolled again as a new case, because searching a paper register for an existing record was hard enough that starting a fresh one was easier. Reports as simple as how many people are currently on treatment took weeks.

A duplicate is not an untidy database row. It is a treatment history cut in half, a patient who appears to be newly diagnosed, and a national coverage figure that is wrong in the optimistic direction.

Underneath sits a problem that identification systems usually make worse. To recognise someone by their details, you have to hold their details — and here the details are the sensitive part. The program treats that exposure as a first-class risk: even its SMS reminders substitute neutral wording for clinical terms so that a message on a phone screen gives nothing away. Against that, the obvious fix — collect more identifying information, more carefully — strengthens identification by increasing exactly the exposure the program works to minimise.

One of two engineers who built the biometric enrollment and identification integration with DHIS2. I took part in the implementation and pilot work in Nepal.

To be exact about what is and is not corroborated: DHIS2’s account of the program credits the two-part biometric app to HISP India, and describes its structure and use. It does not name individuals. So the existence, design and deployment of the work are independently documented; my own part in it rests on my word until someone at HISP India or NCASC confirms it, and I would rather say so than imply the source covers more than it does.

Let a fingerprint stand in for the identifying details, and the third problem dissolves into the solution to the first two.

A fingerprint identifies without describing. It carries no name, no address, no diagnosis — nothing that means anything if it leaks, and nothing a health worker has to ask for in a waiting room. The information needed to recognise a returning patient stops being information that puts them at risk. That is the part worth understanding: privacy improved not because protections were added around the identifying data, but because the identifying data stopped needing to be collected.

The practical gains compounded on top. Enrollment got faster. Identification became one action instead of a search through near-duplicate names, which matters most to the person doing it for the fortieth time that day — and a workflow people can complete under pressure is the one that actually gets used, which does more for data quality than any amount of validation.

The integration was a two-part custom app, and the split is the whole design. The client-side half was incorporated into the DHIS2 installation itself; the server-side half ran on a dedicated fingerprint server. Readers capture a patient’s fingerprint, it is verified and stored on that server, and the result authenticates the record in DHIS2.

Keeping matching off the DHIS2 instance is what let a biometric layer be added to a national health information system without becoming part of it — DHIS2 continues to hold health records, the fingerprint server holds biometrics, and neither inherits the other’s obligations.

It also put capture and matching on infrastructure sitting in the facility rather than somewhere a health worker has to reach over the internet. That mattered then and still does: NCASC notes that internet speed at some sites continues to affect how fully the system functions.

The decision I would defend hardest, though, was accepting the error rate instead of assuming it away. We designed against a target of roughly 90% identification accuracy. Stated flatly that sounds poor, since commercial matching quotes far better. It is realistic for the conditions: fingerprints worn down by manual work, field-grade readers rather than laboratory ones, dust and moisture, devices shared between many health workers, capture done quickly in a queue. Benchmark accuracy is measured in none of those circumstances.

Which means roughly one identification in ten was expected to fail. A system that treats that as an exception strands a patient one visit in ten, and leaves the health worker with only the paper-register search the whole exercise was meant to replace.

So the fallback went into enrollment rather than onto failure: we enrolled multiple fingers per patient, not one. A failed match on the first is not a failed identification, it is a retry with an independent sample. Several attempts at ninety percent compose into something far better than ninety percent, and the cost is paid once, at enrollment, by the person who has time — instead of at every future visit by someone in a queue.

The target was never going to be met by better matching. It was met by designing for the failures matching was always going to have.

Capture ran on ZK-7500 readers with ZKTeco’s own SDK doing the comparison, rather than anything hand-rolled. Fingerprint matching is a solved problem with decades of work behind it and real consequences for getting subtly wrong; the engineering worth doing was the integration, the enrollment workflow and the failure handling, not a worse implementation of the comparison itself.

The client half was a desktop application health workers drove at the facility — capture, enrollment, identification — talking to a server application that wrapped the SDK behind two operations, enroll and identify. The DHIS2 side was extended in JavaScript and AngularJS so the biometric step appeared inside the Tracker workflow rather than beside it, which is the difference between a feature health workers use and one they work around.

What crossed that boundary was a template, never an image. A template is a derived set of measurements the matcher consumes; it is not a picture of anyone’s finger and cannot be turned back into one. That property is what the privacy argument above rests on — abstracting identity into a biometric is only an improvement if the biometric itself is not a new copy of the person.

The system is Nepal’s HIV Care and ART Tracking System, launched in 2017 by the National Centre for AIDS & STD Control at the Ministry of Health and Population. It was piloted in three HIV treatment centres in Kathmandu and then rolled out nationally, with implementation support from NCASC, AIDS Healthcare Foundation, FHI360, Save the Children International and HISP India, and funding through Global Fund programs.

NCASC’s own description of the system is the one I would point at, because it is the operator speaking in the present tense. It says the system is operational across all HIV program sites in Nepal, and that it consists of three interconnected components: DHIS2 Tracker, mHealth, and Biometrics. The biometric component is named as what streamlines duplication checks and client transfers — which is the problem the work was built to solve, described by the people running it, years later.

DHIS2 reports the proportion of people receiving antiretroviral therapy rising from 65% in 2017 to 84% by 2021. That figure belongs to the national program and its interventions as a whole, not to this integration. Nobody has measured what the biometric component contributed separately, and I am not going to borrow a number I cannot attribute. What the sources do establish is that the work went into real, national, long-running use, and that is the claim worth checking.

At the 2020 DHIS2 Annual Conference, in the Tracker and Android session’s public Q&A thread, a participant working on Nepal’s HIV information system wrote: “We’re very thankful to HISP India that we were able to integrate fingerprint scanner for HIV Care Tracker,” and went on to ask for palm and fingerprint support on Android handhelds for community workers.

That is somebody on the receiving end of the work saying it mattered, unprompted, three years after it was built — and asking for more of it. It credits HISP India rather than any individual, which is the honest shape of the evidence here and is noted as such above.

Public references, so none of the above has to be taken on my word.

• NCASC (Government of Nepal) — the system, and biometrics as one of its three components↗
• DHIS2 — Nepal employs DHIS2 Tracker in its national HIV program↗
• DHIS2 Annual Conference 2020 — community Q&A thread↗