A health ID from birth, and every trade-off behind it

The NITDA Builders Festival publishes problems from government agencies and partners and asks builders to solve them. One of eHealth Africa’s reads, in full: fragmented patient identity across Nigeria’s public and private health facilities. The suggested solution is a lightweight infrastructure to assign and resolve unique health identifiers.

This note is about what we built in response, and more about why it is shaped the way it is. It is an experiment and a work in progress. There is a working prototype and a short demo, everyone in it is fictional, and it has not been in front of a single real clinic yet. The decisions are the useful part, so that is what this records, including the ones I expect to change.

You can try it: healthid.senpaifutures.com. Pick one of five roles (a nurse in Kano, a doctor in Lagos, two front desks, a reviewer) and use it as they would. Everyone in it is fictional, NIMC is simulated, and it resets every night, so nothing you do there is kept. Please do not enter real patient details.

The problem, the way a patient meets it

Every Nigerian who has used more than one hospital owns more than one hospital card. A woman registered at a primary health centre in Kano gets a folder number there. A year later a private clinic in Lagos gives her another. A teaching hospital writes her name slightly differently and gives her a third. Three records, mostly on paper, none of them aware of the others.

The cost is not abstract. A doctor repeats tests nobody needed to repeat, or misses an allergy or a genotype. A baby’s vaccinations are split across clinics, so nobody can say which doses were missed. The country counts one woman as three patients. Revitalised primary health centres alone record around 45 million visits a quarter, by the Minister of Health’s own figure, and every one of those visits can mint another card.

The ID is not the identity

It took me a while to see that the brief is about two different things, and that most of the design follows from keeping them apart.

The identity is the person. Aisha herself: the names she is known by and the ways they get spelled, her date of birth or her best guess at it, her mother, her phone number, and the records about her sitting in clinics across the country. Fragmentation is a problem of identity. There is one woman and several records, and nothing that says they belong together.

The health ID is one identifier for that person. It is the number we generate, and it is not the only one she has. Each clinic gives her a folder number. She may have an NHIA number. She may be able to prove her NIN. A baby is linked to her mother. All of these point at the same person. What makes the health ID different is that it is the one every facility shares. A folder number means something only inside one clinic. The health ID means the same thing in Kano and in Lagos, at a public primary health centre and at a private hospital.

So the job has two halves, and they are the two verbs in the brief. Assign gives a person the shared identifier. Resolve decides which records and identifiers belong to the same person. The ID makes that decision stick, so it never has to be made twice.

With the ID, the record opens instantly

The ID is the front door. A patient who presents their health ID at any facility using the system should see their own record immediately: no search, no list of possible matches, no questions about how their name is spelled.

That is how the app behaves. The front desk types the twelve digits from the patient’s card. The check digit is verified on the phone as they type, so a mistyped number is caught before it is ever looked up. A valid ID goes straight to the person’s record. If the facility has never treated them before, the first thing on that screen is the consent step, so the speed never comes at the cost of the patient’s say over who reads it.

Searching by name is the fallback, for when the ID is not there: left at home, never issued, or forgotten. That is where the name matching described further down earns its keep, along with a phone number or the clinic’s own folder number. It is careful because it has to be. A name search returns candidates with reasons, and a person decides. An ID returns the person.

The difference matters at scale. Every visit that starts with an ID costs one lookup and carries almost no risk of opening the wrong record. Every visit that starts with a name costs time and judgement. The more people carry and use their ID, the less often anyone has to resolve anything.

How the ID is used, day to day

• It is written on a card the patient keeps, as 2718-0493-5526: twelve digits in three groups, easy to read aloud and to type on a feature phone.
• It is the first question at the front desk. “Do you have your health ID?” comes before “What is your name?”
• A clinic attaches its own folder number to it the first time it sees the patient, with their consent. From then on, either number finds them there.
• A mother’s ID finds her children. Babies are linked to her, so her record leads to theirs even before they have a card of their own.
• Hospital software uses it too. A system that speaks FHIR can fetch a patient by health ID directly.

What happens to an ID over a lifetime

1. Issued in advance. It starts in a block of IDs sent to a clinic’s phone, unused and belonging to no one.
2. Assigned. At birth, at a first vaccination or at any visit, it is given to one person, for life. It is never reused, even if the person dies or the clinic closes.
3. Linked. Folder numbers, an NHIA number and a NIN check attach to it over the years. When the child is enrolled with NIMC, the health ID stays; the NIN check is added to it, not swapped in for it.
4. Merged, if it ever has to be. If two records turn out to be the same person, one becomes the surviving record. The other ID keeps working: it leads to the survivor, so a card printed years ago still opens the right record. And because a merge is only a pointer, it can be undone.

What the ID never holds

No name, no birthday, no sex, no facility, no state. It is twelve digits and a check digit, and nothing can be read from it. That is deliberate. It can be printed on a card, read out in a waiting room or written on a form without giving anything away. All it does is point to a record, and the record has its own protections.

What the brief asks for, and how this answers it

The brief	What we built
Assign a unique health identifier	A 12-digit ID at birth, at the first vaccination, or at any visit. Clinics receive IDs in bulk beforehand, so they can assign one with no signal.
Resolve identities	With an ID, the record opens directly. Without one, name matching that understands Nigerian spellings, plus folder numbers, NHIA numbers and a NIN check. Likely duplicates are stopped, merges are decided by a person and can be undone, and hospital software can resolve the same way through FHIR.
Across public and private facilities	One service for a public PHC in Kano and a private clinic in Lagos alike: clinics on paper through the app, hospitals with software through FHIR.
Lightweight	A small central service holding identity, a short summary and pointers to where records live. Not a national medical record.

The brief asks for identifiers. The rest of this note explains why we also added a small portable summary, on purpose: an identifier nobody has a reason to use does not get used.

The obvious answer, and why it is not enough

The first idea anyone has, including me, is a health BVN. One number, every facility links to it, done.

BVN worked for two reasons health does not have. Banks were already fully digital, so linking accounts gave instant value: your balance was in a database the moment the link existed. And the Central Bank mandated it, with a deadline. Most clinics keep paper files, and nobody is forcing them to adopt anything.

So an ID on its own deduplicates records on paper, in theory. Linking three folders tells a doctor they exist. It does not tell her what is in the one sitting in a cabinet in Kano.

That changed the scope. The ID has to carry something worth having on the first day. Not the whole medical record, but the small part every doctor needs: genotype, blood group, allergies, current conditions and medication, vaccinations, recent visits. That fits on one screen, it works even in a clinic on paper because a nurse can read it off the patient’s phone, and it gives the front desk a reason to use the ID instead of a reason to skip it.

This is the trade-off I am least sure of. A pure identity layer is easier to defend and closer to what the brief asks for. A summary makes adoption plausible but pulls us towards clinical data, which is where the real risk lives. We chose the summary and spent most of the design budget on keeping it small and controlled.

Government has already chosen the NIN

Halfway through the thinking, the most important fact turned up. In July 2026 the Coordinating Minister of Health and the Director-General of NIMC agreed to integrate digital identity into healthcare under the new NIMC Act 2025, and set up a joint technical working group to do it.

Pitching a new health number for every Nigerian would have meant competing with the Minister’s own plan. So the position became the health layer on top of the NIN, not an alternative to it.

That still leaves a gap, and it is the gap we built for. Babies do not have NINs. A child is born, vaccinated, treated for malaria and so on for years before anyone enrols them with NIMC. So the health ID is provisional: issued early, linked to the mother, carrying the exact date of birth, and linked to the child’s NIN when they are enrolled. It feeds NIMC rather than fighting it.

Where a person enters the system

The most consequential design question turned out not to be what the ID looks like but when someone gets one. Get the moment wrong and the system either misses the people who need it most or quietly duplicates them. We ended up with three doors, each there for a reason.

At birth, if the birth happens in a facility. The baby is registered on the spot, linked to the mother, with an exact date of birth rather than the estimate an adult will give years later. Every vaccine, weight check and illness from then on attaches to the same number.

This has a value well beyond the clinic. An ID issued at birth is also a record that a birth happened: where, when, and to whom. Aggregated, that is a count of births by LGA as they occur rather than months later. That is exactly the information other agencies are short of. The National Population Commission has its own challenge on the same festival, about capturing births and deaths at the last mile. Vaccine planners need to know how many children are about to come due, and where. A health ID does not replace a birth certificate, and the legal registration of a birth stays with NPC. But a system that already sees births can feed theirs instead of every agency counting separately.

I want to be careful with that claim. It only counts births at facilities that use the system, so it is partial and biased towards places that are already better served. It is a signal to build on, not a statistic to quote.

At the first vaccination, for everyone born outside a facility. Many Nigerian births happen at home, so an ID issued only in labour wards misses a great many children, and usually the children with the least contact with the health system. The first vaccination reaches more of them. So a vaccination visit is treated as a perfectly good place to be born into the system: the nurse registers the baby, links the mother, and records the birth doses in one sitting. The same birth record follows, a little later and with a date of birth the mother reports.

At any visit, for adults. Anyone without an ID can be given one at any facility. This door is where duplicates come from, so it is the one with the strictest checks: the clerk searches first, likely matches stop the registration, and anything uncertain goes to a reviewer. That is covered under matching, below.

The thread running through all three is the mother. A baby is linked to her at registration, so consent for a child’s record comes from her phone, her children appear on her record, and a family can be found even when the baby has no name yet.

Don’t centralise the medical record

The tempting version is one national database of everyone’s full history, so hospitals do not have to keep anything. I argued for it myself early on. It is the wrong call for two reasons: a single store of every Nigerian’s medical history is an enormous breach target, and hospitals with their own software are not going to give it up.

So the central service holds very little:

• the ID
• the NIN verification
• the small summary
• pointers to which facilities hold fuller records

Full records stay where they are. For a clinic with no software at all, the simple tool we built can be their record, which gets them most of the benefit without asking anyone else to centralise anything.

How it fits together. Dashed boxes are not built yet.

A portable summary, not a medical record

The summary deserves its own section, because it is the part a clinic actually feels.

It is not the hospital’s file. It is the handful of facts a clinician needs in the first five minutes with a patient they have never seen:

• blood group and genotype, with whether a lab confirmed them
• allergies
• chronic conditions, such as hypertension, diabetes or sickle cell disease
• current medication
• vaccinations, laid against the national schedule for a child
• recent visits and referrals

That is it. Detailed notes, scans and lab reports stay in the hospital’s own system, and the summary only says which facilities hold them.

Being small is what makes it portable. It travels with the ID, so a woman who gave birth in Kano arrives at a clinic in Lagos with her genotype and her penicillin allergy already known. And it is a starting record for hospitals with no records system at all. A PHC on paper does not need to buy software to benefit. The basics it would otherwise have to ask for, or never know, are already there, and anything it adds goes back into the summary for the next clinic.

Privacy is the default, not a setting. A clinic that has never treated someone sees nothing until the patient agrees, by reading out a code sent to her phone. Entries marked sensitive, HIV status for example, are visible only to the facility that recorded them and to the patient, even after she has agreed. Every view is logged where she can see it.

The direction we want to take this is two tiers: the basics a clinician needs to treat someone safely on one side, and anything beyond them on the other, released only when the patient explicitly opts in for that request. The prototype has the consent step and the sensitive flag. It does not yet let a patient release the basics while holding back the rest, and that is one of the next things to build.

The number itself

Small decisions here carry more weight than they look like they should.

Twelve digits, numbers only. It has to be typed on a feature phone keypad and over USSD, which rules out letters. It cannot be eleven digits, because the NIN and every Nigerian mobile number are eleven digits and a front desk would confuse them. It never starts with zero, for the same reason.

The last digit is a Verhoeff check digit, the scheme Aadhaar uses. It catches every single mistyped digit and every swap of two neighbouring digits, which are the two mistakes people actually make reading a number aloud. The simpler Luhn scheme misses some of those swaps. The app checks it as you type, offline, so a wrong ID is caught at the keyboard rather than matched to a stranger.

The facility is not encoded in the number. That was the obvious way to let clinics issue IDs offline: prefix every ID with the facility’s code, and two clinics can never produce the same number. But it would tell anyone holding the card where the person was born or first treated, and it would tie them for life to a clinic that might close or be re-coded.

IDs that work with no signal: issuing in bulk

So offline issuing needed another answer, and it is one of the decisions I am most pleased with. IDs are issued to facilities in bulk, before they are needed.

Whenever the clinic app has a connection, it makes sure the phone holds a pool of unused IDs: a block of a hundred, topped up whenever it falls below twenty. Every one is generated and recorded centrally at that moment, so it is unique before it ever leaves the server. When the signal drops, a nurse registering a newborn takes the next ID from the pool. The baby leaves the clinic with their real, final number written on the card, not a temporary one that has to be swapped later. When the phone reconnects, the registration is sent and the server checks that the ID belongs to that facility’s block.

The alternatives were all worse in ways that matter at a clinic. Temporary offline IDs that get renumbered on sync mean the number on the mother’s card is wrong by the time she gets home. Asking the phone to generate random IDs itself risks two phones choosing the same one, rare but not impossible at national scale. Refusing to register until there is signal means the child most likely to be missed is missed.

The trade-offs are small and known. A lost or broken phone takes its unused IDs with it. That is harmless, because the numbers were never given to anyone and are never reused, but it does waste some of the space. A block also has to be fetched before the signal goes, which is why the app tops up quietly in the background rather than waiting to run out. Which facility issued an ID lives in the database, not in the number, so the number itself still says nothing about the person.

NIN linking is a check, not a key

I assumed linking to the NIN meant storing the NIN. It does not, and it should not.

NIMC has moved to tokens. A patient dials a USSD code from the phone linked to their NIN and receives a Virtual NIN: sixteen characters, valid only for the organisation it was generated for, for 72 hours, usable once. We submit it through a licensed verification partner and get back NIMC’s name, date of birth and sex. We may not keep the token, and we do not want the raw NIN.

So what we store is the fact of verification: a flag, the date, the partner’s transaction reference, and NIMC’s official details, which make name matching much stronger. If NIMC’s record does not match ours, nothing is marked verified, and the screen says exactly which fields disagreed.

Two consequences follow. Deduplication still runs through our own matching, because a one-time token is not a permanent key. And verification is optional, never a condition of care. The patient has to dial from their NIN-linked phone, and many rural mothers share a handset or have lost that SIM. A system that refuses a vaccination because a phone is missing has its priorities backwards.

The prototype uses a mock verifier. Whether NIMC returns a stable identifier per organisation, which would make this a real link, is the first question for the working group.

Matching Nigerian names, for when there is no ID

When a patient presents their health ID, none of this section runs: the record opens directly. Matching is for everyone else: the person who left their card at home, the adult who has never been issued one, and the clinic registering someone new who must first check they are not already in the system. It is also how duplicates get caught. So it is the fallback, but a fallback that will carry a lot of traffic for years, until most people carry an ID.

This is where most of the engineering went, and where the most useful mistakes were made.

Generic matching algorithms like Soundex were built for English surnames and fall over here. The same Arabic-origin name arrives as Muhammad, Mohammed or Muhammadu. Hausa and Yoruba add endings: Aminat, Aishatu, Maryamu. Yoruba and Igbo names shorten in daily use, so Oluwaseun becomes Seun and Chukwuemeka becomes Emeka. Hadiza is a local rendering of Khadija. Tone marks come and go, so Adéṣọlá is also Adesola. And many adults know their age but not their birthday.

The matcher handles each of those deliberately, then weighs name, date of birth, sex, phone, location and the mother’s ID into a score with reasons a person can read: “aishat” ≈ “aisha”, spelling variant; ages agree within two years, date estimated. The reasons matter as much as the score. A clerk is far more likely to trust, and correctly overrule, a match they can see the logic of.

A clinic in Lagos searches for a woman registered in Kano under a different spelling, then tries to register her anyway.

The biggest trade-off in the whole system lives here. A wrong merge is worse than a duplicate. A duplicate wastes a test. A wrong merge puts one woman’s allergy on another woman’s record. So nothing is ever merged automatically. Likely matches stop a registration and ask the clerk; anything uncertain goes to a human reviewer; and a merge is only a pointer from one record to the other, so it can always be undone.

Two bugs here taught us more than the design did:

Muhammad and Mide collapsed into the same key. The consonant outline we compare names on had stripped too much, so two unrelated names looked identical. Fixed by collapsing only genuinely doubled letters and refusing to compare outlines shorter than three letters.

A search for the mother surfaced her newborn. An unnamed baby registered as Baby of Aisha Mohammed scored 63% against a search for “Aishat Muhammad”, because a shared family name was carrying the whole match. In health that is the wrong-merge risk in miniature. A search that includes a first name can no longer match someone who does not have one yet, and ages that cannot be reconciled now pull a score down hard.

Each of those now has a test that pins it, which is the only way a matcher like this stays honest as the name list grows.

Speaking FHIR without being a FHIR server

FHIR is the international standard for how health systems exchange records: agreed shapes for a patient, a vaccination, an allergy, sent as JSON over an API. Nigeria’s Digital Health Services Bill 2025 would require it, though as far as we can tell it is still a bill.

We could have run a full FHIR server. We chose not to. The data lives in plain tables we control, and the service translates to and from FHIR at the edge: a hospital asking for a patient gets a standard FHIR Patient built on the fly, and a hospital sending a vaccination has it unpacked into our own log.

The trade-off: we own the mapping work and do not get a standards-complete server for free. In return the system stays small enough for a few people to understand completely, which matters more at this stage than coverage. Hospital software can still find a patient by sending a misspelled name and get back scored candidates, the same matching the front desk sees.

Who can see what

Access is where an identity system earns or loses trust, so the rules are strict and boring on purpose:

• A facility can read a summary only if it registered the person or holds their folder number, or the patient has granted consent.
• Consent is a code sent by SMS to the patient’s phone, or the mother’s for a child, and lasts 24 hours.
• Emergency access exists for the unconscious patient. It needs a written reason, lasts two hours, is logged against the clinician’s name, and the patient is told.
• Sensitive entries, HIV status for example, are visible only to the facility that recorded them and to the patient.
• Front desk staff can record vaccinations, because at a PHC they often give them, but cannot read the clinical summary.
• Every read and write is logged, and the log is something the patient can see.

One bug belongs in this section. Writing an entry used to grant read access. The rule said a facility “knows” a patient if it had recorded anything for them, which meant any clinician could write a throwaway note and then read the whole record. A care relationship is now registering someone or holding their folder number, and nothing else.

The cost of these rules is friction: the first visit to any new facility needs a code. I think that is the right price, and the prototype keeps it to one screen.

Consent at a clinic that has never treated her, then the portable summary. In the demo the code is shown on screen; in use it would only arrive by SMS.

Offline first, because clinics are

A PHC with an unreliable signal is the normal case, not the edge case, so the clinic app was designed offline from the first line.

We built it as an installable web app rather than a native Android app. Native would handle offline more robustly. A web app was weeks faster, runs on any cheap phone, and the whole thing is about 175 KB, which matters on a weak connection. That is a bet we may reverse.

With no signal, a nurse can still register people and record vaccinations. New registrations take an ID from the phone’s pre-issued pool, described above, so they already have their final number. Every change goes into a queue on the phone and is sent in order when the signal returns: a mother before her baby, a registration before its vaccines.

A nurse in Kano records the six-week doses with no signal. When the connection comes back they send on their own.

The detail that makes this safe is that the health summary is a log that is only ever added to. A correction is a new entry that replaces an old one; nothing is edited in place. And every entry carries an ID made on the phone, so a sync that is interrupted and retried cannot create duplicates. Two clinics can never conflict, because neither ever overwrites anything.

Two deliberate omissions. Summaries are never stored on the phone, because clinic phones are shared. And a session that expires overnight pauses syncing instead of discarding what was queued.

One more bug lives here. When the server went down during testing, the proxy in front of it answered with a bare error rather than no answer, and the app marked the nurse’s queued vaccinations as rejected instead of waiting. In a real clinic that reads as data loss. The server always replies in a known format, so anything else is now treated as no connection and the work is kept.

Where it is

There is a Go service with the ID, matching, consent and the FHIR translation; an offline clinic app; and a short demo that walks a nurse in Kano through recording vaccines with no signal, and a doctor in Lagos finding the same patient under a different spelling. It all runs end to end on fictional data, and there is a public demo at healthid.senpaifutures.com that resets every night. Nothing has been tested with a real clinic, a real patient or a real NIMC response.

What is not built

• No SMS provider. Consent codes are shown on screen in demo mode.
• No real NIN verification. The verifier is a mock until a licensed partner is in place.
• The vaccine schedule is a draft. It needs confirming with NPHCDA before it goes near a child.
• No tiered consent. A patient cannot yet share the basics while holding back the rest of her summary; consent is all-or-nothing apart from sensitive entries.
• No patient channel yet. The API lets a patient see their records and who opened them; the WhatsApp front end that would make that usable is not built.
• Staff sign-in is a password. It should move to our identity service, and phone numbers are not yet encrypted at rest.
• It is not hosted in Nigeria. Real health data has to be.
• No clinic is using it. That is also what the challenge requires before anyone can apply, so it is the next piece of work rather than a footnote.
• Governance is unanswered. A national health identifier should end up owned by government, most likely the Ministry’s digital health office with NIMC alongside. How a prototype hands over to that is a question I do not have a good answer to yet.

What would help

A primary health centre or a small private clinic willing to try it for a month. Anyone at NPHCDA who can check a vaccine schedule against the real one. Anyone close to the FMoH–NIMC working group who knows what the Virtual NIN response actually returns. And people who have watched health IT projects in Nigeria fail and can tell us which of these decisions they would have made differently.