iWmo en iJw zijn de landelijke berichtstandaarden waarmee gemeenten en zorgaanbieders gegevens uitwisselen over ondersteuning onder de Wmo en hulp onder de Jeugdwet. Zorginstituut Nederland beheert ze. Aanbieders versturen hun berichten via VECOZO, gemeenten via het Gemeentelijk Gegevensknooppunt. Sinds 1 april 2023 geldt voor beide standaarden release 3.2.
Voor wie software bouwt of beheert aan een van beide kanten, is dat berichtenverkeer een vaste eis voor de bouw. Elke toewijzing, elke start en stop en elke declaratie gaat als bestand in XML door de keten, en elk bericht krijgt een antwoord terug. Hieronder lees je hoe dat werkt, welke berichten er zijn en in welke volgorde, welke uitvoeringsvariant welke berichten nodig heeft, welke release nu geldt en wat je software moet kunnen om goed mee te doen.
Wat iWmo en iJw zijn en wie ze beheert
Sinds 2015 regelen gemeenten de ondersteuning voor mensen met een beperking via de Wet maatschappelijke ondersteuning (Wmo) en de hulp aan jeugdigen via de Jeugdwet. Daarvoor wisselen ze veel gegevens uit met aanbieders. Om te voorkomen dat elke gemeente en elke aanbieder dat op een eigen manier doet, zijn er twee landelijke informatiestandaarden: iWmo voor de Wmo en iJw voor de Jeugdwet.
Beide standaarden horen bij de iStandaarden van Zorginstituut Nederland. Een iStandaard bestaat uit drie lagen die je als ontwikkelaar allemaal nodig hebt:
- Processen. Welke stap in het administratieve proces welk bericht oplevert.
- Berichten. De opbouw van elk bericht tot op het niveau van elementen, vastgelegd in XSD schema's.
- Regels. Bedrijfsregels, invulinstructies en technische regels die bepalen wanneer een bericht klopt.
De standaard geldt voor alle 342 gemeenten die Nederland op 1 januari 2026 telt. Het Ketenbureau voert namens de VNG regie op de keten en bewaakt de kwaliteit van het berichtenverkeer. Voor softwareleveranciers in de zorg en voor leveranciers van gemeentelijke systemen betekent dat één set specificaties, ongeacht met welke gemeente of aanbieder je klant werkt.
Hoe het iWmo berichtenverkeer loopt tussen gemeente en aanbieder
Het iWmo en iJw berichtenverkeer loopt nooit rechtstreeks van gemeente naar aanbieder. Er zitten twee knooppunten tussen, één aan elke kant.
- De zorgaanbieder maakt in zijn eigen systeem een bestand in XML en levert het aan bij VECOZO. Dat kan handmatig via het portaal van VECOZO of automatisch vanuit het softwarepakket van de aanbieder.
- VECOZO controleert de aanlevering en de routering en zet het bericht door naar de gemeentelijke kant.
- Het Gemeentelijk Gegevensknooppunt (GGk) ontvangt het bericht voor de gemeente. Het GGk draait bij BIDN, Bureau InformatieDiensten Nederland, voorheen het Inlichtingenbureau.
- De gemeente haalt het bericht op via een portaal of via een directe koppeling met een webservice, en stuurt haar eigen berichten langs dezelfde weg terug.
Routering gebeurt op codes in het bericht zelf. In de Wmo gebruikt de standaard daarvoor aparte AGB codes voor de aanbieder, en elk bericht bevat het BSN van de cliënt als sleutel. Klopt een van die gegevens niet, dan loopt de routering vast of wordt het bericht afgekeurd.
Voor je architectuur betekent dit dat je koppeling met één kanaal praat: VECOZO of het GGk. Aparte verbindingen met tientallen gemeenten of aanbieders zijn niet nodig, en dat maakt de koppeling eenvoudiger. Het maakt je ook afhankelijk van de beschikbaarheid en de technische eisen van dat ene kanaal. Hoe een API koppeling in het algemeen werkt, lees je in een apart artikel.
De berichten van iWmo en iJw op volgorde
iWmo 3.2 bevat 14 berichten: 8 heenberichten en 6 retourberichten. iJw 3.2 heeft dezelfde opbouw met codes die met JW beginnen in plaats van WMO. De tabel volgt de volgorde van een traject. Het verzoek om toewijzing is niet altijd nodig: stelt de gemeente zelf vast dat een toewijzing nodig is, dan stuurt zij die direct.
| Stap | iWmo | iJw | Afzender | Rol in het proces |
|---|---|---|---|---|
| Verzoek om toewijzing | WMO315 | JW315 | Aanbieder | De aanbieder vraagt een toewijzing aan als een cliënt zich meldt met een open beschikking |
| Antwoord op verzoek | WMO319 | JW319 | Gemeente | De gemeente honoreert of wijst het verzoek af |
| Toewijzing | WMO301 | JW301 | Gemeente | De opdracht aan de aanbieder om te gaan leveren |
| Start zorg | WMO305 | JW305 | Aanbieder | Meldt de datum waarop de levering begint |
| Verzoek om wijziging | WMO317 | JW317 | Aanbieder | Vraagt een aangepaste toewijzing als de zorgvraag verandert |
| Stop zorg | WMO307 | JW307 | Aanbieder | Meldt een tijdelijke of definitieve stop |
| Declaratie | WMO323 | JW323 | Aanbieder | Declareert de geleverde prestaties over een periode |
| Declaratieantwoord | WMO325 | JW325 | Gemeente | Geeft aan of de prestaties correct zijn ingediend |
Op bijna elk heenbericht volgt een retourbericht met een nummer dat één hoger ligt: WMO302 op de toewijzing, WMO306 op de start, WMO308 op de stop, WMO316 en WMO318 op de verzoeken en WMO320 op het antwoordbericht. Voor de declaratie is het declaratieantwoord zelf de terugkoppeling.
Een toewijzingsbericht bevat voor één cliënt altijd alle toewijzingen voor die aanbieder die op of na de aanmaakdatum geldig zijn, plus de toewijzingen die zijn gewijzigd. Je software moet een binnenkomend toewijzingsbericht dus behandelen als de volledige actuele stand voor die cliënt. Verder mag je volgens de standaard geen betekenis hechten aan het tijdstip en de volgorde waarin berichten binnenkomen. Je verwerking moet ook kloppen als een stopbericht eerder binnenkomt dan je had verwacht.
Drie uitvoeringsvarianten bepalen welke berichten je nodig hebt
Welke berichten een gemeente en een aanbieder gebruiken, hangt af van de uitvoeringsvariant die ze hebben afgesproken. Het Ketenbureau heeft voor elke variant een standaard administratieprotocol gepubliceerd.
- Inspanningsgericht. Gemeente en aanbieder spreken per product een levering af, gemeten in tijd of in stuks. De aanbieder declareert het geleverde volume.
- Outputgericht. De afspraak gaat over de output die de aanbieder moet behalen. Hoe de aanbieder dat doet, ligt niet vast. Deze variant gebruikt grotendeels dezelfde berichten, met eigen productcodes.
- Taakgericht. De gemeente geeft een aanbieder een taak voor een groep inwoners, zonder verantwoording per cliënt. Er gaat geen declaratie via het berichtenverkeer.
Bij taakgericht werken zijn de bronnen niet helemaal eensluidend. Het informatiemodel zegt dat toewijzingen hier in principe niet worden gebruikt en dat start en stop kunnen vervallen als de gemeente dat zo afspreekt. Het administratieprotocol gaat uit van het volledige berichtenverkeer zonder declaratie. Voor de bouw betekent dit dat je per gemeente en per contract moet kunnen instellen welke berichten verplicht zijn. Een aanbieder die met meerdere gemeenten werkt, heeft vrijwel altijd met meer dan één variant te maken. Voor leveranciers aan de overheid geldt hetzelfde aan de gemeentelijke kant.
Welke release van iWmo en iJw nu geldt
Per september 2026 gelden iWmo 3.2 en iJw 3.2. Het berichtenverkeer in dit formaat is op 3 april 2023 gestart, met 1 april 2023 als officiële ingangsdatum. Het was een kleine release na versie 3.1, vooral met verduidelijkingen.
Sindsdien is er geen nieuwe release ingevoerd. De releases die voor 2025 waren voorbereid, zijn in april 2024 door de stuurgroep afgewezen. De huidige releases blijven van kracht. De stuurgroep vond dat gemeenten en aanbieders eerst hun processen meer op elkaar moesten afstemmen, in plaats van steeds meer variatie in de standaard op te nemen.
De volgende iWmo release hangt samen met de eigen bijdrage in de Wmo, die afhankelijk wordt van inkomen en vermogen. Die invoering is meermaals verschoven. Volgens de Voorjaarsnota 2026 gaat de maatregel op zijn vroegst op 1 januari 2028 in. Een nieuwe iWmo release volgt die planning. Voor iJw is geen nieuwe release aangekondigd.
Een releasewissel blijft een harde datum waarop de hele keten tegelijk overgaat op een nieuw formaat.
Wat je software moet kunnen
Of je nu een systeem voor aanbieders bouwt, een gemeentelijk systeem of een koppellaag daartussen, deze eisen komen steeds terug.
Valideren tegen de standaard. De standaard kent vier controleniveaus. Een bericht dat niet valideert tegen het XSD krijgt alleen een foutmelding en geen retourbericht. Daarna volgen controles met de XSLT's van het Zorginstituut, controles die over berichten heen gaan en controles tegen een externe bron. Valideer daarom voor verzending zelf op dezelfde regels, zodat afkeur je systeem niet verlaat.
Retourberichten verwerken. Voor ieder ontvangen bericht moet de ontvanger binnen 3 werkdagen een retourbericht sturen. Op een declaratie volgt het antwoord binnen 10 werkdagen. De verzender moet zelf signaleren als een retourbericht uitblijft. Je software moet dus bijhouden welk heenbericht op antwoord wacht, retourcodes per berichtklasse terugkoppelen naar de juiste cliënt en een afgekeurd bericht corrigeerbaar maken.
Bestanden binnen de grenzen houden. Een verzonden bestand mag niet groter zijn dan 25 Mb. Bij grote aantallen cliënten moet je software de aanlevering kunnen opsplitsen.
Testen buiten productie. Het Zorginstituut biedt een validatiemodule, de Decentrale Validatieservice, XSLT's en voorbeeldberichten om testberichten tijdens de ontwikkeling te controleren. Daarnaast is er een ketentestomgeving waarin gemeenten, aanbieders en softwareleveranciers een nieuwe release samen testen. Neem die tests op in je eigen testaanpak, met berichten uit de casuïstiek van de standaard als vaste testset.
Releasewisselingen aankunnen. Houd de berichtdefinities en regels los van je bedrijfslogica. Dan blijft een nieuwe release beperkt tot nieuwe XSD's, nieuwe codelijsten en aangepaste validatie, terwijl de kern van je applicatie ongemoeid blijft. Een aparte integratielaag of middleware maakt dat scheiden eenvoudiger.
Instelbaar per gemeente. Uitvoeringsvariant, productcodes en de verplichte berichten verschillen per contract. Leg die vast als configuratie in plaats van in code.
Isatis bouwt koppelingen tussen systemen die zich aan een externe standaard moeten houden. Met ruim dertig jaar ervaring, 30+ engineers in Nijmegen en Sarajevo en meer dan 100 projecten, waaronder onderhoudssoftware voor de luchtvaart, een platform voor subsidieadministratie en RFID in de supply chain, weten we wat vaste berichtformaten, verplichte terugkoppeling en een harde releasedatum met een planning doen. Isatis is gecertificeerd voor ISO 9001 en ISO 27001. Lees meer over onze aanpak voor software integratie.
Veelgestelde vragen
Wat is iWmo?
iWmo is de landelijke informatiestandaard voor het berichtenverkeer tussen gemeenten en zorgaanbieders onder de Wet maatschappelijke ondersteuning. Zorginstituut Nederland beheert de standaard. Hij legt vast welke berichten er zijn, hoe ze zijn opgebouwd en aan welke regels ze moeten voldoen.
Wat is het verschil tussen iWmo en iJw?
iWmo geldt voor ondersteuning onder de Wmo, iJw voor jeugdhulp onder de Jeugdwet. De opbouw is gelijk: dezelfde soorten berichten, dezelfde volgorde en dezelfde soort regels. De berichtcodes beginnen met WMO of JW, en de inhoud van producten en codelijsten verschilt.
Welke release van iWmo en iJw geldt in 2026?
In 2026 gelden iWmo 3.2 en iJw 3.2, van kracht sinds 1 april 2023. De releases die voor 2025 waren voorbereid, gingen niet door. Een volgende iWmo release is gekoppeld aan de inkomensafhankelijke eigen bijdrage, die op zijn vroegst op 1 januari 2028 ingaat.
Hoe snel moet een retourbericht worden verstuurd?
Voor ieder ontvangen bericht stuurt de ontvanger binnen 3 werkdagen een retourbericht. Op een declaratie volgt binnen 10 werkdagen een declaratieantwoord. Blijft een antwoord uit, dan moet de verzender dat zelf signaleren en actie ondernemen.
