iWmo and iJw are the national message standards Dutch municipalities and care providers use to exchange data about social support and youth care. The National Health Care Institute (Zorginstituut Nederland) maintains them. Providers send messages through VECOZO, municipalities through the Municipal Data Hub (GGk). Release 3.2 of both standards has applied since 1 April 2023.
If you build software that sells into the Dutch social care market, on either the provider or the municipal side, this messaging is a fixed build requirement. Every assignment, every start and stop, and every claim travels through the chain as an XML file, and every message gets a response. Below: how the exchange works, the messages in order, the delivery models, the current release, and what your software has to handle.
What iWmo and iJw are and who maintains them
Since 2015, Dutch municipalities have been responsible for two areas of care. The Social Support Act, Wet maatschappelijke ondersteuning (Wmo), covers support for people with a disability. The Youth Act, Jeugdwet (Jw), covers help for children and young people. Municipalities buy that care from providers and exchange a lot of data with them.
The Netherlands uses two national information standards for that exchange: iWmo for the Social Support Act and iJw for the Youth Act. Both belong to the iStandaarden family maintained by the National Health Care Institute. Each standard has three layers you need as a developer:
- Processes. Which step in the administrative process produces which message.
- Messages. The structure of each message down to element level, defined in XSD schemas.
- Rules. Business rules, completion instructions, and technical rules that decide when a message is valid.
The standards apply to all 342 municipalities the Netherlands had on 1 January 2026. A chain office, the Ketenbureau, coordinates the chain on behalf of the Association of Netherlands Municipalities (VNG) and monitors message quality. For software vendors in healthcare, that means one set of specifications for every municipality and provider.
How iWmo messages travel between municipality and provider
iWmo and iJw messages never go straight from a municipality to a provider. There are two hubs in between, one on each side.
- The care provider creates an XML file in its own system and submits it to VECOZO, the Dutch secure communication platform for healthcare. Submission works manually through the VECOZO portal or automatically from the provider's software.
- VECOZO checks the submission and the routing and passes the message to the municipal side.
- The Municipal Data Hub, Gemeentelijk Gegevensknooppunt (GGk), receives the message for the municipality. The GGk runs at BIDN, Bureau InformatieDiensten Nederland, formerly known as the Inlichtingenbureau.
- The municipality collects the message through a portal or through a direct web service integration, and sends its own messages back along the same route.
Routing relies on codes inside the message. Under the Social Support Act the standard uses dedicated AGB provider codes for this, and every message carries the client's citizen service number (BSN) as a key. If either value is wrong, routing fails or the message is rejected.
For your architecture, this means your integration talks to one channel: VECOZO or the GGk. That keeps the integration simpler. It also ties you to the availability and technical requirements of that one channel. See what an API integration is for the general principles.
The iWmo and iJw messages in order
iWmo 3.2 has 14 messages: 8 outgoing messages and 6 return messages. iJw 3.2 follows the same structure with codes starting with JW instead of WMO. The table follows the order of a typical care pathway. The request for assignment is optional: when the municipality decides on its own that an assignment is needed, it sends one directly.
| Step | iWmo | iJw | Sender | Role in the process |
|---|---|---|---|---|
| Request for assignment | WMO315 | JW315 | Provider | The provider requests an assignment when a client arrives with an open decision |
| Answer to request | WMO319 | JW319 | Municipality | The municipality grants or rejects the request |
| Assignment | WMO301 | JW301 | Municipality | The instruction to the provider to start delivering care |
| Start of care | WMO305 | JW305 | Provider | Reports the date delivery begins |
| Request for change | WMO317 | JW317 | Provider | Asks for a new assignment when the client's needs change |
| Stop of care | WMO307 | JW307 | Provider | Reports a temporary or permanent stop |
| Claim | WMO323 | JW323 | Provider | Claims the services delivered over a period |
| Claim response | WMO325 | JW325 | Municipality | Reports whether the services were submitted correctly |
Almost every outgoing message triggers a return message numbered one higher: WMO302 for the assignment, WMO306 for the start, WMO308 for the stop, WMO316 and WMO318 for the two requests, and WMO320 for the answer message. For a claim, the claim response itself is the feedback.
An assignment message always contains, for one client, every assignment for that provider that is valid on or after the creation date, plus any assignments that changed. Your software has to treat an incoming assignment message as the complete current state for that client. The standard also says parties may attach no meaning to the time or order in which messages arrive. Your processing must stay correct when a stop message turns up earlier than expected.
Three delivery models decide which messages you need
Which messages a municipality and a provider use depends on the delivery model, the uitvoeringsvariant, they agreed on. The Ketenbureau publishes a standard administrative protocol for each one.
- Effort based (inspanningsgericht). Municipality and provider agree on delivery per product, measured in time or in units. The provider claims the volume delivered.
- Output based (outputgericht). The agreement covers the output the provider has to achieve. How the provider gets there is left open. This model uses largely the same messages, with its own product codes.
- Task based (taakgericht). The municipality gives a provider a task for a group of residents, without accountability per client. No claims go through the message exchange.
For the task based model the sources don't fully agree. The information model says assignments are in principle not used and that start and stop messages can be dropped by agreement. The administrative protocol assumes the full message exchange minus the claim. For your build, that means you need to configure per municipality and per contract which messages are mandatory. Providers working with several municipalities, and vendors serving government, almost always deal with more than one model.
Which iWmo and iJw release applies now
As of September 2026, iWmo 3.2 and iJw 3.2 apply. Exchange in this format went live on 3 April 2023, with 1 April 2023 as the official start date. It was a minor release after 3.1, mostly clarifications.
No new release has gone live since. The releases prepared for 2025 were rejected by the steering group in April 2024, and the current releases remain in force. The steering group wanted municipalities and providers to align their processes first.
The next iWmo release is linked to a change in the personal contribution under the Social Support Act, which will depend on income and assets. That change has been postponed several times. According to the Dutch government's 2026 spring budget memorandum, it takes effect on 1 January 2028 at the earliest. A new iWmo release will follow that timeline. No new iJw release has been announced.
What your software needs to handle
Provider system, municipal system, or integration layer between them: these requirements keep coming back.
Validation against the standard. The standard has four levels of checks. A message that fails validation against the XSD gets an error notice and no return message. Next come checks with the XSLTs published by the institute, checks across messages, and checks against an external source. Validate against the same rules before you send, so rejections never leave your system.
Processing return messages. For every message received, the recipient has to send a return message within 3 working days. A claim gets its response within 10 working days. The sender is responsible for noticing when a return message is missing. Your software needs to track which outgoing message is waiting for an answer, map return codes per message class back to the right client, and let users correct a rejected message.
File size limits. A file sent may not exceed 25 MB. With large client numbers, your software has to be able to split a submission.
Testing outside production. The institute provides a validation module, the Decentrale Validatieservice, XSLTs, and sample messages to check test messages during development. There's also a chain test environment where municipalities, providers, and software vendors test a new release together. Build those tests into your own QA and testing approach, with the standard's example cases as a fixed test set.
Handling release switches. Keep message definitions and rules separate from your business logic. A new release then stays limited to new XSDs, new code lists, and updated validation, while the core of your application stays untouched. A separate integration layer or middleware makes that separation easier.
Configuration per municipality. Delivery model, product codes, and mandatory messages differ per contract. Store them as configuration instead of code.
Isatis builds integrations between systems that must follow an external standard. With more than 30 years of experience, 30+ engineers in Nijmegen and Sarajevo, and 100+ projects, including MRO software for aviation, a subsidy administration platform, and RFID in the supply chain, we know what fixed message formats, mandatory feedback, and a hard release date do to a schedule. Isatis is certified for ISO 9001 and ISO 27001. Read more about our approach to software integration.
Frequently asked questions
What is iWmo?
iWmo is the Dutch national information standard for messages between municipalities and care providers under the Social Support Act (Wmo). The National Health Care Institute maintains it. It defines which messages exist, how they are structured, and which rules they must meet.
What is the difference between iWmo and iJw?
iWmo covers support under the Social Support Act, iJw covers youth care under the Youth Act. The structure is the same: the same types of messages, the same order, and the same kinds of rules. Message codes start with WMO or JW, and products and code lists differ.
Which iWmo and iJw release applies in 2026?
In 2026, iWmo 3.2 and iJw 3.2 apply, in force since 1 April 2023. The releases prepared for 2025 did not go ahead. The next iWmo release is tied to the income based personal contribution, which starts on 1 January 2028 at the earliest.
How quickly must a return message be sent?
For every message received, the recipient sends a return message within 3 working days. A claim gets a claim response within 10 working days. If a response doesn't arrive, the sender has to notice and follow up.
