The Dutch AWBZ reform, effective 2015, was a major operation in which large groups of people transitioned from a specific form of long-term care to other arrangements. For health insurers this meant an unprecedented need for insight: who goes where, what are the financial and care-content consequences, and how do you ensure individual clients don't fall through the cracks?
For health insurers I worked in a team on an application that had to provide exactly that insight. My specific responsibility was designing and implementing the algorithm that determines per client where they're routed to — based on a detailed set of rules and current client data.
An algorithm like this is technically not rocket science, but the complexity lies in the fact that every detail counts. A wrong assumption about an age bracket or a missing exception can put dozens of people into the wrong arrangement. That is not acceptable — not for the insurer, but above all not for the client.
We therefore kept the algorithm explicit and highly readable, close to how policymakers phrased the rules. No smart shortcuts, no implicit assumptions; every rule was traceable to its source. That makes the algorithm not flashy, but auditable — and that was exactly what was essential here.
Alongside this we invested heavily in tests and in datasets with realistic edge cases. We worked with Java 7 on Spring and Tomcat, and used OpenCSV for data exchange. Not an exotic stack, but exactly the combination we needed: stable, predictable, and well equipped for heavy batch processing with provable correctness.
For me this project was an early and clear lesson that 'simple' rule-driven applications in healthcare or government have their very own kind of complexity. The code is rarely the bottleneck — the bottleneck is understanding what the rules truly mean and capturing them clearly and reliably in code without losing meaning along the way.
Outcomes
- An algorithm that decides per client which arrangement applies, with every rule traceable to its source
- Batch processing on Java 7 with Spring and Tomcat, one csv file in and one csv file out
- Test sets with realistic edge cases as a standing requirement rather than an afterthought