Plenty of ministries describe their flagship system as DPI. Plenty of those systems aren't.
That's not a criticism. A good ministry system can be excellent and still not be infrastructure.
The short answer: a system is DPI when it's a shared building block that many others can build on, not a solution that serves one department. It should be interoperable through open specifications, minimal and reusable, open to innovation by others, federated rather than one giant database, and private and secure by design. If only one department can use it, it's a system. If the whole country can build on it, it's infrastructure.
Key facts:
The six-question test
| Question | If yes | If no |
|---|---|---|
| Can other agencies and companies plug into it through published APIs or standards? | Interoperable | A silo |
| Is it a single building block, rather than a full end-to-end application? | Reusable | A solution |
| Can banks, start-ups or other ministries build new services on it without asking permission each time? | Open to innovation | Gatekept |
| Is data held where it belongs, shared on request, rather than copied into one central database? | Federated | Centralised |
| Were privacy, consent and security designed in from day one? | Safe by design | Risky |
| Could you change your technology supplier without rebuilding it? | Sovereign | Locked in |
The first five questions map to CDPI's principles. The sixth is mine. I've seen too many "infrastructure" systems that only one vendor can touch.
Five or six yeses and you've got DPI. Three or fewer and you've got a good system that could become DPI with work.
DPI vs digitisation: a simple example
Take birth registration.
Digitisation: the registry office replaces paper books with a database. Staff type in births. Certificates print faster. Nobody outside the office can use the data.
DPI: the same register exposes secure, consented APIs. The ID authority creates an identity at birth. The health ministry plans vaccinations. The statistics office gets live vital statistics. Social protection pays child benefits automatically.
Same data. Completely different value.
Why the label matters
It's tempting to call everything DPI, because that's where the funding and attention are. But the label comes with expectations.
If you tell a funder your system is DPI, they'll expect others to build on it. If it can't support that, you'll find out at the worst possible moment, usually when the second ministry tries to connect and can't.
My take: be honest about where your system sits. "Not DPI yet" is a perfectly good starting point. Most countries are there.
How to turn a system into DPI
You rarely need to start again. CDPI calls these "+1" upgrades: small additions that convert existing systems into DPI. Examples include adding a digitally signed QR code to an existing ID so it can be verified, or opening up APIs so a large database becomes a registry others can use (CDPI).
In practice:
- Publish APIs based on open standards
- Add consent and audit controls
- Document how others can connect
- Onboard a second user, then a third
The moment a second ministry builds on your system, it starts to become infrastructure. See choosing a first DPI use case.
Frequently asked questions
What is the difference between DPI and digitisation? Digitisation moves a process online for one organisation. DPI creates a shared building block many organisations can build on.
Does DPI have to be open source? No, but it must be interoperable and follow open specifications.
Can an existing system become DPI? Yes. Often through small upgrades, like opening APIs or adding verifiable credentials.
Sources
- The DPI Wiki, Centre for Digital Public Infrastructure
- DPG and DPI, Centre for Digital Public Infrastructure
- How much does it cost to build DPI?, Centre for Digital Public Infrastructure
Want a second opinion on whether your system is DPI yet? Let's talk.
