The duplicate-record problem
Ask most hospital IT teams what happens when the same patient is registered under two slightly different names, or with a phone number that changed between visits, and the honest answer is: two records get created, and nobody's history connects to the other one.
This isn't a rare edge case. It's the default outcome of systems that identify patients by name, date of birth and phone number — all of which are inconsistently entered, can change, and were never designed to be unique identifiers in the first place.
Identity as infrastructure, not a feature
The fix isn't a better search box. It's treating patient identity as its own piece of infrastructure — a stable, government-backed identifier that a patient's records attach to, independent of which hospital, clinic or system created them.
That's the problem a unique health identification system solves: not storing more data, but making sure the data that already exists can be reliably connected to the right person, every time, across every provider that touches their care.
Interoperability is not the same as digitization
A hospital can be fully digital — every record in a database, no paper charts — and still be non-interoperable, because its database can't talk to the clinic across the street. Digitization solves storage. Interoperability solves the harder problem: making that stored data usable by someone who didn't create it.
That requires shared identity, shared formats, and systems that were built assuming they'd eventually need to hand data to a system they don't control.
What this looks like in practice
In our work on UHID, the design constraint was simple to state and hard to build: a doctor seeing a patient for the first time should be able to see their relevant history, without that patient having to remember which hospital has which record. Solving that is mostly an identity and interoperability problem — the storage part was never the hard part.