Five Records, a Quiet Promise, and Why SenangAI Was Born

Earlier this year, a family member spent several months in and out of hospital. Like many Malaysian families, we shared the running around: appointments, forms, counters, and the paperwork that comes with looking after someone you love.

I didn't expect that time to change what I work on. But it did.

Five records for one person

The care happened in more than one place: a hospital on Penang Island, and another on the mainland. Within the same hospital, I sometimes noticed that departments only about a hundred steps apart each kept their own file. The hospitals were partly digitised: some records were in the system, others were still on paper. When we finally looked closely, there were five separate records, all for the same person.

Every one of them had an IC number on it. They still didn't connect. Some used the old IC, some the new MyKad, and the name was spelled one way on the island and another on the mainland. To each system, these were different people.

Starting from zero, every time

There was a harder part. The discharge papers were handed to us, and at each new visit, staff asked for the family's copy. If we hadn't brought it, there wasn't a version they could pull up themselves.

So at every new visit, in a new place, we found ourselves starting again. We answered the same questions. Some tests were done again. And more than once, a piece of history that mattered was sitting in a folder at home instead of in front of the doctor who needed it.

When someone is ill, that's the moment you most want the full story in one place. It was the moment it was most scattered.

Nobody had done anything wrong. The staff were the best part of the story: helpful, patient and determined. They went back through the files with us, one record at a time, until it was sorted. And we understood why it happens. Moving decades of paper into computers while still treating patients every day is slow, hard work. The country is heading there, with the government's digital initiatives pushing in the right direction, but it takes time.

The utility company told the same story: one house that had changed hands, an account still in the old name, and five accounts tied to the same address. "Jalan" in one, "Jln" in another.

What the records looked like

Here is what we found. The name is real; the ID numbers, dates and addresses below are made up, but the kinds of differences are exactly the ones we saw.

#	Where	Name	ID	Date of birth	Address
1	Island hospital, department A (system)	Tan Ah Kau	450312-07-5521	12/03/1945	12, Jalan Sebelah
2	Island hospital, department B (system)	Tan Keng Jin	450312075521	12/03/1945	12, Jln Sebelah
3	Island hospital (old paper file, scanned)	Tan Ah Kau	Old IC B1234567	12/03/1945	12 Jln. Sebelah
4	Mainland hospital (system)	Tan Keng Jin	450312-07-5521	not recorded	Lot 12, Jalan Sebelah
5	Mainland hospital (paper)	Tan Ah Kau	Old IC B1234567	12/03/1945	not recorded

This is common among Chinese Malaysians, especially the older generation: many have two names, joined by "@" on the IC. My family member's IC reads Tan Ah Kau @ Tan Keng Jin. Both names are official, and both belong to the same person. But some records were registered as Tan Ah Kau, and others as Tan Keng Jin. To a computer, those look like two different people.

None of these is wrong on its own. Together, they describe one person five times.

Why it felt familiar

I've spent about 25 years in enterprise IT, much of it doing exactly this kind of work, just for systems instead of people. I've helped build security monitoring for large banks, where the whole job is pulling logs from many systems that each describe the same user differently, and working out which events belong together. I've worked on keeping critical data consistent across more than one site. And I've spent years building analytics and monitoring for banks, utilities and government-linked organisations, where access control and audit trails were never optional.

(I've written more about that world in monitoring vs observability.)

Standing at those counters, I recognised the pattern immediately. Different systems, different formats, the same identity hidden underneath, and someone at the end who needs the whole picture.

For most of my career, the records I matched belonged to machines: servers, logs, transactions. If two of them didn't line up, it cost time or money. This time, the records belonged to someone I love. If they didn't line up, it cost a doctor the full story of a patient.

That changed how I saw my own work. I had spent years making machines understand each other. It felt like time to turn the same skills towards people.

Somewhere between those counters, I made a quiet promise to myself: if I could help fix even a small part of this, I would.

Why SenangAI was born

And it isn't only hospitals. Inside any large company, sales, service, billing and delivery often keep their own version of the same customer. The customer feels it every day: asked for the same details again, billed at an old address, promised stock that isn't there. The cause is the same: records that never meet.

That promise is why I started Kognosys and why SenangAI was born. It does for an organisation's records what I wished someone had done for ours: it notices when records that look different probably belong together, flags the mismatch to the person looking at them, shows the records side by side with their sources, and only consolidates them when a person approves a decision that matters. It keeps the data inside the organisation's own walls and keeps a record of who did what.

I also didn't want it to become a project that only engineers can change. So SenangAI comes with no-code tools: a person, a team or a whole organisation can build their own dashboards and small apps on top of the same connected records, and start using them within minutes. Each one stays inside the same permissions and audit trail, so making something new never means losing control of who can see what. I've written up how it works, and what it does and doesn't do, in what we're building at Kognosys.

Starting small

I'm not trying to connect every hospital, agency and utility in the country. Joining records across organisations needs laws, agreements and public trust, built at the pace the country is already moving. Institutions change slowly, often for good reasons, and the staff I met weren't resisting anything. They were working hard inside systems built one piece at a time.

So I start small. We've already done it once, in a partner's business, connecting sales, service, manufacturing, deliveries and stock records that never used to meet. It caught stock and delivery mismatches early, and the sales team stopped promising stock that wasn't there. Next comes one organisation, one department, one kind of record. Even that alone is useful: the people in one department finally see that the records in front of them belong to the same customer or the same order, before a decision is made on half the picture. If it works there, it can work in the next.

Why I'm sharing this

The more I talked about it, the more I realised it wasn't only us. Many people have a version of this story, in different places and in everyday life: an agency that knows you under two names, an insurance claim stuck because two records don't match, a parent's accounts that outlive the house. And many staff behind those counters know it from the other side.

My next step is specific. With our partner, we've already seen SenangAI catch mismatched records before they turned into broken promises: flagging them, and consolidating them only when a person approved. Now I want to bring the same approach to more organisations, one department at a time. I'll measure three simple things: how many mismatches it flags, how many people confirm, and how many decisions are made with the full picture instead of half of it. As we go, I'll share what we learn here, including what didn't work.

Some days building this feels like just me and a whiteboard. But I've seen what five scattered records cost a family. That's enough to keep going.

Quick answers

Why do records with the same IC number end up separate?

Each system often creates its own record without checking the others. The IC may also be written differently, or one record may use an old IC while another uses the new MyKad.

Can an old IC be matched to a new MyKad automatically?

Not by formula. There's no mathematical link between the two numbers. They can be matched as likely the same person using date of birth, name and address, but a person should confirm.

What happens if two different people are wrongly linked?

That's why a match should only ever be a flag until a person confirms it, with a record of who linked what and why, so a mistake can be traced and corrected.