Custom software for iJw messaging and accountability
iJw message traffic sends itself. What doesn't happen by itself is what comes back. A rejected claim message is not a technical notification but money that isn't coming in, and at many providers that return information ends up in a screen nobody treats as a work queue. The pile quietly grows until the annual accountability reporting.
Where the chain gets stuck in practice
iJw is the standard used to track clients throughout the entire Youth Act chain: from the municipality's allocation, through the start and end of care, to the claim. Everything runs in standardised messages with fixed numbers, including the allocation and the claim, and the Zorginstituut manages that standard.
Sending is rarely the problem. The problem is the return: a message that doesn't match the allocation, a period that is wrong, a product that has been changed. That comes back as return information with a reason, and that reason requires human assessment before it can be resubmitted.
With most providers, that screen isn't set up as a work queue. There's no owner, no deadline and no view of the outstanding amount. As a result, rejections pile up until someone discovers at year-end that nothing has been claimed for half a year, and by then correcting it costs more than the amount itself.
How we build this
Here the unit is the return, not the message. If every rejection gets an owner and an amount, message traffic becomes a process rather than a mailbox.
Which rejection reasons come back, how often and for what amount. With almost every provider, a handful of them account for most of the total.
Every return becomes an item with an owner, a reason and an amount. That changes the question from "has it been sent?" to "is there still money outstanding?".
Allocation, care delivered and claims should line up. The system shows where they don't, at the moment it happens rather than at year-end.
We take a closed quarter and check whether the figures reconcile. What doesn't add up here won't add up for the auditor either.
What the software actually does
The return register with amounts underpins everything. Which components you need depends on your size and on how many municipalities you serve.
Return information as a work queue
Every rejection becomes an item with a reason, amount, owner and deadline. As long as a return only sits in a messaging screen, nobody owns it.
Reconciling allocation, care and claims
What has been allocated, delivered, claimed and paid. These four drift apart, and the system shows where, rather than you discovering it at year-end.
Multiple municipalities side by side
Each municipality uses its own product codes, rates and agreements within the same standard. That is the main source of rejections, and it belongs in the system, not in an employee's head.
Deadlines and outstanding items monitored
The older a rejection, the smaller the chance it still gets resolved. The system shows age and amount, so attention goes to what costs the most.
Integration with your own systems
Messages run via the switch point or the data hub, and your client administration sits elsewhere. We build the layer in between through integrations; see also the iWmo and iJw integration.
Reporting that follows from the administration
The figures for the annual accountability report come from the same source as the daily work queue. Two sources mean a discrepancy you have to explain in March.
Who we build for
Your position in the chain determines where it hurts. Four situations.
Large youth care providers
Dozens of municipalities, each with its own product codes and agreements. The volume makes manual follow-up impossible, and the gap between allocated and claimed grows quickly.
Smaller providers and practices
Low volume, but no administrative department either. A single unanswered return represents a larger share of revenue here than for a large provider.
Municipalities and regional partnerships
You're on the other side and see the providers that don't reconcile. Visibility of the return flow helps you tell whether the problem lies with a provider or with your own product codes.
Subcontractors and main contractors
With subcontracting, the message runs via the main contractor and the administration sits in two organisations. That's the set-up in which most discrepancies arise. Recording the start and end happens at the client; see the Youth Act app.
Test your idea first: a working prototype in 1 day
With OneDayBuild, we make your idea tangible in a single day for €1,150, so you know whether further development is worth the investment. Decide to go ahead with the full build? Then we deduct the cost in full.
View OneDayBuild →Technology and integrations
The iStandaarden have releases in which messages and codes change. Everything related to this should be configurable and stored per version, so an old claim stays readable.
Why Appfront
A return is money, not a notification
We turn every rejection into an item with an amount and an owner. As long as it is just a line on a messaging screen, nobody does anything with it.
The differences lie between municipalities
The same standard, but different product codes and agreements. We record these per municipality rather than relying on an employee knowing them.
Accountability comes from the day-to-day administration
We build a single source for the workload and the annual figures, because two sources produce a discrepancy you cannot explain.
This concerns young people
The data is particularly sensitive and the group allowed to see it is small. We set up access per role and do not show any clinical care data in the financial view.
Security and privacy
This administration combines two things that rarely belong together: financial data and data about young people in care. An employee handling the returns flow needs the amount and the rejection reason, not the content of the care pathway. We separate these within the same system and show each role only what it needs, with every access recorded.
Retention requires an explicit choice. For accountability you need to be able to look back years, whereas data about an individual young person should not be kept longer than necessary. You solve this by retaining the financial reconciliation at a level where the person can no longer be identified, and giving the client file its own retention period. We therefore set a retention period per data type rather than a single period for everything. How we handle security ourselves is described in our information security policy; external reports go through our CVD policy.
Frequently asked questions about iJw
The iStandaard used to follow clients throughout the entire Youth Act chain, from the municipality's allocation through the start and end of care to the claim. Exchange takes place in standardised messages with fixed numbers, and the Zorginstituut Nederland manages the standard together with the chain partners.
There are two routes: the VECOZO switching point and the municipal data hub managed by the Inlichtingenbureau. Which one applies to you depends on your municipalities and your software supplier. For your administration the difference mainly matters when connecting and when looking up a specific message.
Usually because the message does not match the allocation: a period that is incorrect, a product that has changed, or a rate that differs from what the municipality applies. In practice a handful of causes make up most of the cases; mapping them is the first win and requires no software.
That integration handles sending and receiving the messages. This page is about what you do with the returns and about the reconciliation between allocation, delivery and claim. They belong together; the integration without a workload gives you just a mailbox.
Because most packages handle sending well but returns handling only minimally. We therefore do not rebuild your primary process; see Wmo and youth care software for that side. What we add is the layer that turns rejections into a workload with amounts.
Only if the day-to-day administration and the accountability reporting come from the same source. That is exactly where many providers go wrong: the figures for the accountant are compiled separately and differ from what is in the system. Explaining that difference takes more time than preventing it.
Messages or codes change. That is why we keep the message definitions as a setting and store, per message, the version it was drawn up against. Without that, you cannot account for a claim from an earlier year against the rules that applied at the time.
That depends on the number of municipalities, whether it integrates with your existing package, and whether the accountability reporting is included. The return register with amounts is usually usable quickly and brings in money straight away; the integration and the reporting cost more. We give a well-founded estimate after the discovery phase.
Want to know how much is still outstanding?
Look at how many rejected claim messages are currently in your system and add up the amount. If nobody can do that within a minute, that is the work. We build this as a standalone application and as part of a broader custom software project.