OpenCRVS • Shipped 2026
Case Study: Pacific Regional Cause-of-Death Coding Service
Product Design Lead
2026
Discovery workshops
Business analysis
Process mapping
Service design
Application design
Information architecture
Reporting and analytics design
A death certificate marks the end of a life. But when the medical cause of death is not coded consistently, the information that could prevent the next death is lost. I helped design a service, and later an integrated product, to close that gap across the Pacific.
Developed by OpenCRVS with the Pacific Community, SPC, and the Australian Bureau of Statistics, with support from Bloomberg Philanthropies’ Data for Health Initiative.
I facilitated discovery workshops and worked closely with our COO to understand the existing coding process. I then designed both the application and the supporting processes around it.
Cause of death was being recorded on paper, then largely forgotten. Forms were collected and sent for coding only once or twice a year. By the time anyone could see a pattern, it was already a year old. A rise in a particular cause of death in a country was effectively invisible until long after the moment when that insight could have made a difference.
The regional context made this harder. Small island states rarely have their own specialist mortality coder. This expertise is scarce and expensive to develop across seven countries at once. The challenge was not simply digitising a form. It was designing a shared service where a coder in one country could code records from another without seeing who those records belonged to.
Current state process flow from the workshops
Discovery: learning the language first
Before designing anything, we needed to understand how people spoke about the work. Mortality coding has a vocabulary and a rulebook that take years to master: selection rules, the logic used to determine an underlying cause, the differences between IRIS and DORIS, how each handles rejections, and what returned codes mean for reporting.
With multi-country governance added to the mix, the risk was clear: creating something that looked clean but was unusable to the few people in the region who do this work.
The workshops began with terms, not screens. We mapped the current process from beginning to end with the people who run it, continuing until we could describe a coder’s day back to them and they agreed it reflected reality.
Workshop board — terminology and process mapping
Phase one: a standalone service
We designed the portal first as a standalone application. This reduced risk by proving the regional model before connecting it to a registration system. More importantly, the countries that needed it most were not running OpenCRVS at all.
Designing it as an independent service meant the Pacific could begin using it immediately, regardless of which civil registration software was already in place.
Phase one — standalone architecture and flow
Bringing coding into registration
Once the model was proven, I helped bring the same capability into OpenCRVS. The resulting integration was simple in the best way: a registration agent indicates that a cause of death has been established, the cause of death page follows, and once the record is registered, it is automatically sent for coding.
An important design decision was what not to connect. In most countries, the cause of death does not appear on the death certificate, so coding does not need to delay registration. Families receive their certificate while coding happens in parallel. The codes are added back to the death record once they return.
These are two processes on their own timelines, joined at the end rather than blocking one another at the start.
Integrated OpenCRVS flow — registration and coding in parallel
Designing for anonymity
The regional model only works if it is genuinely safe. Coders see cause of death information and nothing else: no names and no identifiers of any kind.
This constraint shaped the interface. We designed it to provide enough clinical detail for accurate coding, while withholding anything that could identify a person or family. We also designed the return path that reattaches the codes to the correct record on the country’s side.
Turning a yearly chase into a live picture
The final piece was reporting. Previously, one person at the regional coding office spent months chasing seven countries for annual submissions, then worked through stacks of spreadsheets and paper forms to assemble insights.
I helped digitise this analysis using the data now flowing through the system. The same reports can now be produced from a single source, without the chase.
Analytics and reporting views
Where it is now
The portal is live in three countries, with coded results returning within days rather than months. Medical recorders and mortality coders from across the Pacific trained on it together in Brisbane, led by the SPC Regional Coding Group.
ICD 11 support is next, once funding is secured, allowing countries to transition at their own pace.
What made it special
I designed for a situation where the constraint was the point. Coders never see who they are coding for, no country needs to build expertise it cannot sustain, and registration is never held hostage to statistics. Yet the service produces better mortality data than those countries had before.