Wijzigingsverzoeken voor istandaarden. iwmo 2.2 en ijw juli 2017

Wijzigingsverzoeken voor istandaarden iwmo 2.2 en ijw 2.2 3 juli 2017 1

Inhoud RFC17003 - Commentaar toevoegen Verzoek om Toewijzing en ToegewezenProduct 3 RFC17008 - Elementen naam, product en beperking uniek 4 RFC17010 - Constraint 65 is overbodig 5 RFC17017 - Code toevoegen aan Wijziging voor Gemeentelijke Herindeling 6 RFC17019 - String Element mag niet leeg zijn 7 RFC17029 - Controle Voorletters en HuisnummerToevoeging 8 RFC17031 - LDT Eenheid en ProductCategorie String i.p.v. Integer 9 RFC17036 - Extra controle declaratie/factuur retourbericht 10 RFC17037 - Stapeling van Toewijzingen technisch uitsluiten binnen bericht 11 RFC17039 - Per niet-declaratiebericht één cliënt 12 RFC17044 - Diakrieten op alle voorletters 14 RFC17049 - Technische regel TR301 omvormen naar bedrijfsregel 15 RFC17053 - Nieuwe codelijst Beëindiging (WMO588) 16 RFC17057 - Retourcodes 304-bericht verduidelijken en uitbreiden 18 RFC17059 - Rechtmatigheid en regieberichten verder ontkoppelen 26 RFC17061 - Integreren declaratieberichten, processen en controles in informatiemodel 28 RFC17063 - Toevoegen uitgangspunt over niet-gestructureerd berichtenverkeer 30 RFC17065 - Toewijzing alleen versturen naar betreffende aanbieder 31 RFC17067 - Eenduidige technische controles in iwmo en ijw 32 RFC17068 - Klasse BeschiktProduct verwijderen 35 RFC17072 - Wmo uitgangspunt maatwerkvoorziening 36 RFC17075 - BTW verbandcontroles 37 RFC17082 - Prestatie koppelen aan toewijzing o.b.v. Toewijzingnummer 38 RFC17084 - Factureren in delen bij outputgerichte trajecten/arrangementen 39 RFC17095 - Verwijderen aanbieder uit 301, 305/307 en 315-bericht 42 RFC17096 - Versienummer in XSD en XSLT 43 RFC17097 - Codelijst Wijziging inhoudelijk gelijktrekken, technisch opsplitsen 45 RFC17100 - Controle BSN Prestatie overeenkomstig met BSN Toewijzing 46 2

Wijzigingsnr Wijzigingsverzoek istandaarden Wmo en Jeugdwet RFC17003 Commentaar toevoegen aan Verzoek om Toewijzing en ToegewezenProduct Ontvangstdatum 14-7-2016 Organisatie Gemeente Venray 1 Een element Commentaar toevoegen aan Cliënt en Product in het Verzoek om Toewijzing (VOT, 315-bericht). 2 Een element Commentaar toevoegen aan ToegewezenProduct in toewijzing, vanwege het verdwijnen van BeschiktProduct. 3 Aanbieders missen de mogelijkheid om extra informatie over een cliënt in het Verzoek om Toewijzing op te nemen. Bijvoorbeeld als vermeld moet worden dat de voogdij niet bij de ouders ligt of de reden voor de aanvraag van de zorg voor de cliënt. Bij een cliënt worden nu bsn, geboortedatum, geslacht, naam en of de gezagsdrager bekend is opgenomen. 4 Het element Commentaar ontbreekt bij ToegewezenProduct. Dit is noodzakelijk, aangezien BeschiktProduct straks niet meer in de Toewijzing is opgenomen (zie RFC17068). De aanbieder kan extra, ongestructureerde informatie verstrekken aan de gemeente m.b.v. het element Commentaar. Aanpassen van de XML basisschema s van Verzoek om Toewijzing (315-bericht) en Toewijzing (301-bericht). Niet van toepassing. Gemeenten en aanbieders. Uitvoeren. - Maakt het mogelijk om extra informatie mee te sturen met het Verzoek om Toewijzing. - Er is ervoor gekozen om dit bij Cliënt en Product te doen, zodat het commentaar goed te relateren is aan datgene waarop het betrekking heeft. - Het wordt toegevoegd bij de klassen Cliënt en Product voor maximale consistentie en relevantie. - Bij ToegewezenProduct ontbrak ten onrechte een commentaar mogelijkheid. Uitwerking - De WMO315 en JW315 krijgen bij klasse Cliënt en Product een commentaarelement. - De WMO301 en JW301 krijgen bij klasse ToegewezenProduct een commentaarelement. 3

Wijzigingsverzoek istandaarden Wmo en Jeugdwet Wijzigingsnr RFC17008 Elementen naam, product en beperking uniek Ontvangstdatum 2-8-2016 Organisatie Zorginstituut Nederland Element - Element hernoemen naar Achternaam. - Complexelement Geslachtsnaam wordt gevormd door Achternaam en Voorvoegsel. Element Product - Klasse Product hernoemen naar AangevraagdProduct. Element Beperking - Element Beperking hernoemen naar Categorie. In de istandaarden berichten zijn de namen van elementen en klassen onderscheidend van elkaar zodat de functionaliteit van het bericht in de elementnamen terugkomt. In iwmo en ijw is het niet wenselijk dat namen van het complexelement en het element gelijk zijn aan elkaar. Element Het element heeft de omschrijving De achternaam van een persoon en het voorkomen van het complexelement leidt tot hernoeming naar Achternaam. Element Product In de Verzoek om Toewijzing (315-bericht) en het bijbehorende retourbericht (316-bericht) is het niet wenselijk dat de naam van de Product klasse en het Product element gelijk aan elkaar zijn. Element Beperking In de Toewijzing aan een aanbieder (301) bericht en het retourbericht (302) is het niet wenselijk dat de naam van de Beperking klasse en het Beperking element gelijk aan elkaar zijn. Het element beperking in de klasse beperking in de toewijzing aan een aanbieder en het retourbericht moet deze naamgeving systematiek volgen. De omschrijving van het element is: Aanduiding over de categorie van de beperking. Geen. Gemeenten en aanbieders Uitvoeren. Verduidelijking en verbetering van het informatiemodel. Technische uitwerking Wijziging XSD s. 4

Wijzigingsverzoek istandaarden Wmo en Jeugdwet Wijzigingsnr RFC17010 Constraint 65 is overbodig Ontvangstdatum 1-1-2017 Organisatie Zorginstituut Nederland Verwijderen van controle CS065: Vullen met een geldig tijdstip, waarbij 00:00:00 ('000000') niet is toegestaan. De controle wordt m.b.v. een schema definitie afgedwongen en is daarom overbodig geworden. Geen. Nieuwe XSLT controles inlezen. n.v.t. Softwareleverancier gemeente en aanbieder Doorvoeren, controle is overbodig Vereenvoudiging van het informatiemodel Technische uitwerking - Verwijderen van de constraint CS065 uit de specificaties van het informatiemodel - Verwijderen van de CS065 XSLT controle. 5

Wijzigingsverzoek istandaarden Wmo en Jeugdwet Wijzigingsnr RFC17017 Code toevoegen aan Wijziging voor Gemeentelijke Herindeling Ontvangstdatum 15-8-2016 Organisatie Zorginstituut Nederland De codelijst Wijziging (WJ002) in de Toewijzing wordt uitgebreid met code 11 "Gemeentelijke herindeling". Ieder jaar vinden er gemeentelijke herindelingen plaats. Gemeentes worden samengevoegd met als gevolg dat oude gemeentes niet langer bestaan. Als gevolg hiervan worden er mutaties uitgevoerd op reeds toegewezen zorg. Het intrekken/beëindigen van zorg of ondersteuning als gevolg van een gemeentelijke herindeling is nu niet zichtbaar in het reguliere berichtenverkeer. De gemeente kan bij een wijziging van de toewijzing de reden gemeentelijke herindeling meegegeven. Uitbreiding van bestaande codelijst WJ002 (Wijziging). Geen. Gemeenten en aanbieders. Uitvoeren. Administratieve ondersteuning voor de gemeente en aanbieder. Technische uitwerking Code 11 Gemeentelijke herindeling wordt toegevoegd aan codelijst Wijziging (WJ002) (NB: Er is gekozen voor code 11, omdat code 10 vanaf iwmo/ijw 2.1 wordt gebruikt voor de beëindiging DBC met reden Overgang nieuwe bekostigingssystematiek ). 6

Wijzigingsverzoek istandaarden Wmo en Jeugdwet Wijzigingsnr RFC17019 String Element mag niet leeg zijn Ontvangstdatum 1-1-2017 Organisatie Zorginstituut Nederland Aanpassen van het basisschema zodanig dat het niet meer mogelijk is om lege string value elementen op te nemen in een bericht. Berichten met lege string elementen worden niet afgekeurd met als reden dat deze technisch onjuist zijn. String elementen met een enumeratie of een pattern kunnen nu al niet leeg zijn. Geen. Nieuw basisschema inlezen. Hoe er moet worden omgegaan met lege elementen wordt omschreven in de XML documentatie. Geen. Softwareleveranciers van gemeente en aanbieder Doorvoeren. Verbeteren eenduidige werking van string elementen in berichten Technische uitwerking XML basisschema aanpassen. 7

Wijzigingsverzoek istandaarden Wmo en Jeugdwet Wijzigingsnr RFC17029 Controle Voorletters en HuisnummerToevoeging Ontvangstdatum 1-1-2017 Organisatie Zorginstituut Nederland - Controleren opdat het 1 e karakter van het element Voorletters een Letter is. - Controleren opdat er geen spaties voorkomen in het element HuisnummerToevoeging. De elementen Voorletters en HuisnummerToevoeging staan onjuiste karakters toe. In het element Voorletters kan het 1 e karakter nu een ander teken bevatten dan een letter. In het element HuisnummerToevoeging kunnen nu spaties voorkomen. Voorbeeld is (HUIS, A, ROOD). Geen. Nieuw XML Basisschema importeren. n.v.t. Softwareleverancier van gemeente en aanbieder. Doorvoeren. Verbetering van controle. Technische uitwerking Aanpassen basisschema. 8

Wijzigingsverzoek istandaarden Wmo Wijzigingsnr RFC17031 LDT Eenheid en ProductCategorie String i.p.v. Integer Ontvangstdatum 1-1-2017 Organisatie Zorginstituut Nederland - Het logische datatype LDT_Eenheid wordt een primitief datatype String i.p.v. Integer. - Het logische datatype LDT_ProductCategorie wordt een primitief datatype String i.p.v. Integer. De logische datatypes LDT_Eenheid n LDT_ProductCategorie zijn gedefinieerd als primitief datatype Integer met de enumeratie WMO756 waarin voorloopnullen voorkomen. Het logische datatype Integer moet niet gebruikt worden als er voorloopnullen gebruikt worden als waarde. Geen Het logische datatype LDT_Eenheid wordt een primitief datatype String. Gemeenten en aanbieders Uitvoeren Een onterecht verschil tussen Wmo en Jeugdwet wordt hiermee opgelost. Technische uitwerking Wijziging basisschema XSD. 9

Wijzigingsnr Wijzigingsverzoek istandaarden Wmo en Jeugdwet RFC17036 Extra controle declaratie/factuur retourbericht Ontvangstdatum 1-1-2017 Organisatie Zorginstituut Nederland Toevoegen van een controle op het retourbericht facturatie (304-bericht). Bij gedeeltelijke goedkeuring - er is een verschil tussen ingediend bedrag en toegekend bedrag dienen altijd de afgekeurde en/of gewijzigde prestaties meegestuurd worden. Dit wordt nu niet afgedwongen. De gemeente kan in het 304-bericht een bedrag toekennen dat afwijkt van het bedrag dat de aanbieder gedeclareerd heeft in het declaratie/factuur bericht (303). Het is nu mogelijk om dit te doen zonder de afgekeurde prestaties mee te sturen. Er is geen controle gespecificeerd. Het gevolg is dat de aanbieder niet kan afleiden uit het 304-bericht welke gedeclareerde prestatie bedragen afwijken van de toegekende bedragen waardoor de afwikkeling in de administratie van de aanbieder van de declaratie/factuur niet correct en/of onvolledig is. De aanbieder kan op basis van de teruggekoppelde afwijkingen tussen de gedeclareerde en toegekende bedragen bepalen of dit correct is en welke actie er eventueel genomen moet worden. Het kan bijvoorbeeld gaan om een onjuiste toekenning of onjuiste declaratie. Ook is het soms mogelijk dat een deel van de gedeclareerde zorg verhaald wordt op de cliënt. Als het 304-bericht de retourcode 0200 bevat, en het gedeclareerde bedrag niet overeen komt met het toegekende bedrag, moeten de prestaties die dit verschil veroorzaken opgenomen zijn in het bericht. Geen Gemeenten en aanbieders Doorvoeren - Verbetering kwaliteit van de factuur retourberichten. - Lagere administratieve lasten voor de aanbieder 10

Technische uitwerking Implementeren van de volgende controle in XSLT formaat: - SOM (IngediendeBedragregel.DeclaratieFactuurBedrag - ToegekendeBedragregel.ToegekendBedrag) = Header.Retourbedragen.IngediendTotaalBedrag ToegekendTotaalBedrag) - Retourcode:???? De reden van gedeeltelijke goedkeuring kan niet volledig achterhaald worden. Geef alle afgekeurde factuurregels in het retourbericht mee met de juiste bedragen. Wijzigingsverzoek istandaarden Wmo en Jeugdwet Wijzigingsnr RFC17037 Stapeling van Toewijzingen technisch uitsluiten binnen bericht Ontvangstdatum 07-12-2016 Organisatie Qustify Implementeren van de bedrijfsregel OP259 in een XSLT controle. OP259 = Het is niet toegestaan om een product gestapeld toe te wijzen. Er is geen controle meer die afdwingt dat twee toewijzingen in een beschikking niet overlappen. Dit werd eerder ondervangen doordat er een functionele sleutel aanwezig was. Deze is vervangen door het ToewijzingNummer. Geen. Toevoegen van een XSLT controle. Geen. Softwareleveranciers. Doorvoeren. Vermindert fouten in het berichtenverkeer Uitwerking Afdwingen van de OP259 door deze op te nemen in het XSLT schema 11

Wijzigingsnr Wijzigingsverzoek istandaarden Wmo en Jeugdwet RFC17039 Per niet-declaratiebericht één cliënt Ontvangstdatum 09-12-2016 Organisatie Zorginstituut Nederland In de specificaties opnemen dat per niet-declaratiebericht (301, 305, 307, 315) er precies één cliënt kan worden meegestuurd. De declaratieberichten 303 en 304 zijn uitgezonderd. In de huidige situatie is het volgens de specificaties mogelijk om meerdere cliënten per bericht mee te sturen. In theorie geeft dit een risico dat er cliëntinformatie naar de verkeerde zorgaanbieder wordt gestuurd. Daarnaast is de foutafhandeling complexer. Geen. De XML schema s voor de heen- en retourberichten van Jeugdwet en WMO moeten worden aangepast behalve de declaratie-/factuurberichten. Geen. Softwareleveranciers. Doorvoeren. - Vereenvoudigt het berichtenverkeer v.w.b. de foutafhandeling. - Kans op versturen naar verkeerde aanbieder nog kleiner. - Voor de toewijzing is dit al de gebruikelijke werkwijze 12

Uitwerking - XSD ijw/iwmo 301/302 aanpassen - XSD ijw/iwmo 305/306 aanpassen - XSD ijw/iwmo 307/308 aanpassen - XSD ijw/iwmo 315/316 aanpassen - Informatiemodellen aanpassen 13

Wijzigingsverzoek istandaarden Jeugdwet en Wmo Wijzigingsnr RFC17044 Diakrieten op alle voorletters Ontvangstdatum 4-1-2017 Organisatie Zorginstituut Nederland Het wijzigen van de controle op de Voorletters zodat op alle voorletters diakrieten zijn toegestaan. Een voorbeeld hiervan is ČĎ. Berichten waarin op diverse voorletters diakrieten voorkomen, worden tot op heden ten onrechte afgekeurd. Geen beperking meer op het aantal diakrieten in de voorletters. De softwareleveranciers dienen het nieuwe XML basisschema te gebruiken. Geen. Gemeenten en aanbieders. Doorvoeren. Onterechte beperking op vulling van voorletters. Technische uitwerking Aanpassing in het XML basisschema van de Wmo en Jeugdwet. In OP192 is (ook al in eerdere releases) benoemd dat de bestandcodering UTF-8 is en het gebruik van Byte-Order-Mark (BOM) niet is toegestaan. 14

Wijzigingsverzoek istandaarden Wmo en Jeugdwet Wijzigingsnr RFC17049 Technische regel TR301 omvormen naar bedrijfsregel Ontvangstdatum 30-01-2017 Organisatie Zorginstituut Nederland Het deel van de technisch regel TR301 dat betrekking heeft op het 315-bericht als bedrijfsregel opnemen. Voor 305- en 307-berichten vervalt deze regel omdat BeschikkingNummer niet meer de sleutel is voor deze berichten: TR301: BeschikkingNummer moet verplicht gevuld worden indien de gemeente voor de te leveren ondersteuning een beschikking heeft afgegeven. Introductie van het toewijzingnummer als vervanging voor BeschikkingNummer als sleutel en koppelingselement. Geen Geen Geen Softwareleveranciers Doorvoeren Vereenvoudiging van de specificaties. Uitwerking De specificaties worden aangepast 15

Wijzigingsverzoek istandaarden Wmo Wijzigingsnr RFC17053 Wijziging codelijst Beëindiging (WMO588) Ontvangstdatum 09-02-2017 Organisatie Gemeente Utrecht In het StopBericht (307) veranderen de codes bij Beëindiging. Door gemeente Utrecht zijn nieuwe omschrijvingen aangeleverd, in lijn met de omschrijvingen die in de codelijst bij Jeugdwet staan. Zie het resultaat in bijlage A. De Gemeente Utrecht ziet kansen om via de Beëindiging elementaire kwalitatieve informatie te ontvangen per cliënt waarin is onderbouwd hoe de Wmo-ondersteuning is beëindigd. De indeling van de ijw codes (JW588) is als uitgangspunt gebruikt. Zorg en ondersteuning kan worden beëindigd om meerdere redenen. Om te kunnen aangeven van welke reden er sprake is, bestaan er codes voor Beëindiging. De codes die op dit moment in de iwmo worden gebruikt zijn onderling niet consistent en eenduidig: de codes sluiten elkaar niet uit. De nieuw voorgestelde codes zijn betekenisvoller en komen overeen met de codes die in ijw worden gebruikt. Extra keuze bij aanbieder voor reden beëindiging. Gewijzigde WMO588 tabel moet toegevoegd worden aan de gemeente en aanbieder software. Afhankelijk van de gekozen codering is er wel of geen sprake van conversie: o Codes toevoegen is geen probleem o Codes hergebruiken om aan te sluiten op Jeugdwet zorgt voor conversie. Gemeenten en aanbieders Uitvoeren van de wijziging zonder conversie. Verbeterde berichtenverkeer communicatie van aanbieder naar gemeente 16

BIJLAGE A Onderstaande tabel toont de huidige JW588 en de aanwezige statussen (zonder de codes deze lopen niet gelijk met de Wmo). Daarnaast is de tabel getoond met de huidige 2.1 versie van de WMO588 codetabel en de voorgestelde versie 2.2 WMO588 codetabel. Uitwerking JW588 WMO588 2.1 2.2 Overlijden 2 Overlijden 2 Overlijden Levering is volgens plan beëindigd. 19 Levering zorg of ondersteuning is beëindigd - 19 Levering volgens plan beëindigd toewijzing sluiten Levering is tijdelijk beëindigd. 20 Levering zorg of ondersteuning is beëindigd - 20 Levering is tijdelijk beëindigd toewijzing aanhouden Voortijdig afgesloten: eenzijdig door de 21 Levering is eenzijdig door cliënt beëindigd cliënt. Voortijdig afgesloten: eenzijdig door de 22 Levering is eenzijdig door aanbieder beëindigd aanbieder. Voortijdig afgesloten: in overeenstemming. 23 Levering is in overeenstemming voortijdig beëindigd Voortijdig afgesloten: wegens externe omstandigheden. 31 Verhuizing naar een andere gemeente 31 Verhuizing naar een andere gemeente 32 Voortzetting ondersteuning in sociale basisondersteuning 33 Voortzetting in Zvw 34 Voortzetting in Wlz N.B. Uit de omschrijving is het directe verband met de toewijzing weggehaald; in lijn met de scheiding tussen rechtmatigheid en regie. 17

Wijzigingsverzoek istandaarden Wmo en Jeugdwet Wijzigingsnr RFC17057 Retourcodes 304-bericht verduidelijken en uitbreiden Ontvangstdatum 1-1-2017 Organisatie Gemeente Amsterdam Alle retourcodes met een functionele omschrijving controleren op de volgende punten: Gebruik: wordt de retourcode gebruikt? Terminologie: zijn de gebruikte termen nog actueel en kloppend? Duidelijkheid: is de omschrijving in overeenstemming met de controle op het betreffende element of elementen? Reacties uit het veld dat bepaalde retourcode omschrijvingen niet duidelijk zijn hieronder twee voorbeelden: 8215 - Waarde Berekend bedrag is ongelijk aan waarde Aantal uitgevoerde producten maal Tarief product (incl. BTW). -> niet duidelijk is dat aantal uitgevoerde producten betrekking heeft op het element aantal en niet op product/prestatie. 8007 - (Begin-/eind)datum product ontbreekt of is onjuist. -> wordt niet gebruikt, of zou niet gebruikt mogen worden. 0643 TijdseenheidZorg is onjuist. 0383: de term "Jeugdhulpaanbieder" vervangen door "Aanbieder". In de omschrijvingen van codes 0435, 8004, 8181, 8184, 8187, 8223 wordt de term "verzekerde" vervangen door "cliënt". Daarnaast is in de functionele referentiegroep geconcludeerd dat de functionaliteit van de retourcodes van groot belang is. Door de codes te verduidelijken en waar nodig uit te breiden, stijgt de waarde van de retourcodes op een declaratie/facturatie. Voordelen: Fouten kunnen eenvoudiger begrepen worden waardoor minder communicatie buiten het berichtenverkeer om nodig is. Administratieve lastenverlichting. In een werkgroep van een aantal aanbieders en gemeenten is de retourcodelijst uitgebreid besproken en zijn er nieuwe voorstellen voor omschrijvingen gedaan. Daarnaast is er een aantal codes toegevoegd. Geen Geen Gemeenten en aanbieders Doorvoeren Verbeterde werking van berichtenverkeer. Administratieve lastenverlichting. 18

Uitwerking - Retourcodes verwijderen die niet gebruikt worden - Retourcode omschrijvingen aanpassen en aanvullen waar nodig Tabel: Totaal overzicht retourcodes en de omschrijvingen. In de tabel is per retourcode de uitwerking van werkgroep vastgelegd en/of de deze vervalt door XSLT controle en/of het verwijderen van het adres uit de cliënt. De status beschrijft of de retourcode is aangepast of komt te vervallen. In het retourbericht zal de code 0001 opgenomen zijn als de XSLT controle het bericht afkeurt. In het 303-bericht zijn een aantal adreselementen verwijderd en daarmee zijn een aantal regels met bijbehorende retourcodes overbodig geworden (zie RFC17061). Uit de werkgroep zijn twee nieuwe codes ontstaan maar deze komen door XSLT controle ook te vervallen. Er zal wel een conditie of constraint ontstaan. De retourcodes die ook in andere dan de 304 retourberichten gebruikt worden zijn ook opgenomen zodat alle wijzigingen in deze RFC zijn gedocumenteerd. RC Opbouw Betekenis Status 0001 Is Bericht is afgekeurd om technische redenen. gelijk 0013 Was Code servicebureau ontbreekt, is onbekend of onjuist. aangepast Code servicebureau is onjuist vermijden OF conditie 0018 Was Gemeentecode ontbreekt of is onjuist. vervallen Gelijk aan S300 0021 Was Einddatum declaratie-/factuurperiode ontbreekt of is onjuist. vervallen Gelijk aan 8175 0030 Was Factuurnummer declarant ontbreekt, is onjuist of is niet uniek (nummer is reeds gebruikt in een voorgaande factuur). Factuurnummer is niet uniek vermijden OF conditie Uitwerking Werkgroep Vervalt i.v.m. XSLT controle Vervalt i.v.m. verwijderen adres aangepast 0150 Was Totaal declaratie-/factuurbedrag ontbreekt of is onjuist. vervallen Het declaratie-/factuur totaalbedrag is niet gelijk aan de som van de ingediende prestatie bedragen De reden van afkeuring toegevoegd. 0200 Is Geen opmerking over deze berichtklasse. gelijk 0233 Is Berichtklasse is niet beoordeeld. gelijk 0383 Was Jeugdhulpaanbieder ontbreekt of is onjuist. vervallen Zie 9311 Nieuwe RC omdat de huidige betekenis niet overeenkomt met de controle 0435 Was Burgerservicenummer (BSN) verzekerde ontbreekt of is onjuist Burgerservicenummer (BSN) cliënt is onjuist vervallen 19

vermijden OF conditie 0551 Was Er is geen beschikking afgegeven. aangepast De prestatie kan niet gekoppeld worden aan een toewijzing. Op basis van het toewijzingnummer kan er geen toewijzing gevonden worden. Zie ook RFC17082 0553 Was Gedeclareerde prestatie valt buiten de gemachtigde periode. vervallen zie 9307 en 9308 Specifieke controles uitsplitsen met meerdere retourcodes 0582 Was Productcode (of artikel [AP] GPH-/DBC-declaratiecode) ontbreekt of is onjuist (niet bestaande code). Betekenis gelijk aan 1142 0611 Was Tarief product ontbreekt of is niet in overeenstemming met landelijke of contractafspraken. Het ingediende tarief komt niet overeen met het contractuele tarief. vermijden OF conditie 0638 Was Aantal uitgevoerde producten of hoeveelheid afgeleverd ontbreekt of is onjuist. zie nieuwe 9321 en 9322 Specifieke controles uitsplitsen met meerdere retourcodes 0651 Was Referentienummer voorgaande gerelateerde prestatierecord / verblijfrecord ontbreekt of is onjuist. Gelijk aan 8017 1110 Was Waarde gemeentecode (cliënt) moet gelijk zijn aan waarde gemeentecode (ontvanger). Gemeentecode cliënt is niet gelijk zijn aan gemeentecode van de gemeente Specifieker, de gemeente is de ontvanger vervallen aangepast vervallen vervallen aangepast 1112 Was PRODUCTCATEGORIE ontbreekt of is onjuist. aangepast De productcategorie in de prestatie is ongelijk aan de productcategorie in de toewijzing. Specifieker 1142 Was PRODUCTCODE ontbreekt of is onjuist. aangepast De productcode in de prestatie is ongelijk aan de productcode in de toewijzing. Specifieker 8001 Was Declaratie is volledig toegewezen aangepast Declaratie/Factuur is volledig toegewezen Ook van toepassing op de factuur 8002 Was Berichtklasse is niet beoordeeld (wegens afkeuring boven- of ondergeschikt[e] berichtklasse[n]) Gelijk aan 0233 vervallen 8004 Was Combinatie BSN en geboortedatum verzekerde is onjuist aangepast Combinatie BSN en geboortedatum cliënt is onjuist Verzekerde vervangen door Cliënt 8007 Was (Begin-/eind)datum product ontbreekt of is onjuist. vervallen Zie 8188 8017 Was Van deze creditering is geen debitering bekend. aangepast Van deze credit prestatie is geen debet prestatie bekend. Een prestatie wordt gecrediteerd 20

8021 Was Referentienummer dit prestatierecord / verblijfrecord ontbreekt of is niet uniek (reeds aangeleverd). Referentienummer prestatie is reeds aangeleverd vermijden OF conditie aangepast 8028 Was Soort bericht ontbreekt of is onjuist. vervallen m.b.v. 0001, bericht is technisch onjuist afgekeurd 8061 Was De gemeente ondersteunt het ontvangen van het declaratiebestand via VECOZO volgens de gebruikte standaard (soort EI-standaard of (sub)versienummer) niet. m.b.v. 0001, bericht is technisch onjuist afgekeurd 8062 Was Debetregel en identieke creditregel in hetzelfde bestand is niet toegestaan. Creditering van een debet prestatie in hetzelfde bericht is niet toegestaan Bestand vervangen door Bericht 8064 Was Indicaties debet/credit mogen niet verschillend zijn binnen één klasse inclusief onderliggende klasses. Indicaties prestatie debet/credit moeten gelijk zijn De genoemde klasses spelen geen rol in de controle 8166 Is Code informatiesysteem softwareleverancier + versienummer informatiesysteem softwareleverancier moeten beide voorkomen of beide niet voorkomen. Elementen zijn verwijderd 8171 Is Code servicebureau moet voorkomen indien identificatiecode betaling aan gelijk is aan 1. 8175 Was Einddatum declaratieperiode moet groter zijn dan of gelijk zijn aan de begindatum declaratieperiode. Einddatum declaratie-/factuurperiode moet gelijk zijn aan of na de begindatum declaratie-/factuurperiode liggen Het "groter dan datum" vervangen door "voor liggen datum" 8177 Was Begindatum product moet kleiner zijn dan of gelijk zijn aan factuurdatum. Begindatum prestatie moet gelijk zijn aan of voor de factuurdatum liggen Het "kleiner dan datum" vervangen door "voor liggen datum" 8178 Was Einddatum product moet kleiner zijn dan of gelijk zijn aan factuurdatum. Einddatum prestatie moet gelijk zijn aan of voor de factuurdatum liggen Het "kleiner dan datum" vervangen door "voor liggen datum" 8181 Was verzekerde (02) moet voorkomen indien naamcode/naamgebruik (02) voorkomt. De alternatieve naam moet voorkomen indien naamgebruik 02 is Specifieker 8182 Is Postcode Nederland en postcode buitenland mogen niet beiden voorkomen. 8183 Was Postcode Nederland mag niet voorkomen indien postcode buitenland voorkomt. Gelijk aan 8185 vervallen vervallen vervallen vervallen vervallen vervallen vervallen vervallen vervallen vervallen vervallen 21

8184 Was Code land verzekerde moet voorkomen indien postcode buitenland voorkomt. Gelijk aan 8186 8185 Is Postcode buitenland mag niet voorkomen indien code land is Nederland en andersom. 8186 Is Postcode Nederland mag niet voorkomen indien code land is buitenland en andersom. vervallen vervallen vervallen 8187 Was De prestatie hoort niet bij deze verzekerde. aangepast De prestatie hoort niet bij deze cliënt Indien de prestatie wel gekoppeld kan worden aan de toewijzing maar het BSN van prestatie komt niet overeen met de BSN van de toewijzing. Zie ook RFC17100 8188 Was Einddatum product moet groter zijn dan of gelijk zijn aan begindatum product. Einddatum prestatie moet gelijk zijn aan of na de begindatum prestatie liggen Het "groter dan datum" vervangen door "voor liggen datum" 8193 Is Referentienummer voorgaande gerelateerde prestatie moet voorkomen in geval van creditregel. 8194 Was Indicatie debet/credit moet de waarde D hebben indien het totaal declaratie-/factuurbedrag met nul gevuld is. Het totaalbedrag is nul en de Indicatie debet/credit heeft niet de waarde D. Verduidelijkt 8198 Was Het bestand kan niet worden doorgestuurd. De gemeente is niet aangesloten op het elektronisch declaratieportaal van VECOZO. Dit is geen istandaarden controle cq. retourcode vervallen vervallen vervallen vervallen 8206 Was BTW-identificatienummer ontbreekt of is onjuist. vervallen m.b.v. 0001, bericht is technisch onjuist afgekeurd 8207 Was Referentienummer prestatie moet uniek zijn binnen het bestand. Referentienummer prestatie moet uniek zijn binnen het bericht Bestand vervangen door Bericht 8214 Was Begindatum declaratie-/factuurperiode en einddatum declaratie-/factuurperiode komen niet overeen met de afgesproken declaratieperiode. Declaratie/Factuur periode komt niet overeen met de afgesproken declaratie/factuur periode Verduidelijkt 8215 Is Waarde Berekend bedrag is ongelijk aan waarde Aantal uitgevoerde producten maal Tarief product (incl. BTW). vervallen aangepast vervallen 8222 Was Begindatum product ligt voor toegestane datum. vervallen Zie rc 8177 8223 Was verzekerde (02) mag niet voorkomen indien naamcode/naamgebruik (02) niet voorkomt. De alternatieve naam mag niet voorkomen indien naamgebruik 02 is Verduidelijkt vervallen 22

8269 Was Referentienummer voorgaande gerelateerde prestatie moet uniek zijn binnen het bestand. Referentienummer voorgaande gerelateerde prestatie moet uniek zijn binnen het bericht Bestand vervangen door Bericht vervallen 8376 Was Cliënt is niet uniek in bestand. vervallen Cliënt is niet uniek in het bericht Bestand vervangen door Bericht 8454 Was Dagtekening retourbericht moet groter zijn dan of gelijk zijn aan factuurdatum. Dagtekening retourbericht moet gelijk zijn aan of na de factuurdatum liggen Het "groter dan datum" vervangen door "voor liggen datum" 8455 Was Indicatie debet/credit moet de waarde D hebben, indien het totaal ingediend declaratiebedrag met nul gevuld is. Het totaal ingediend bedrag is nul en de Indicatie debet/credit heeft niet de waarde D. Verduidelijkt 8456 Was Indicatie debet/credit moet de waarde D hebben indien het totaal toegekend bedrag met nul gevuld is. Het totaal toegekend bedrag is nul en de Indicatie debet/credit heeft niet de waarde D. Verduidelijkt vervallen vervallen vervallen 8817 Is Berekend bedrag mag niet voorkomen. gelijk 8835 Was Totaal BTW-bedrag ontbreekt of is onjuist. vervallen Totaal BTW-bedrag is onjuist. vermijden OF conditie 8837 Was BTW-bedrag moet voorkomen. vervallen Indien geen BTW-vrijstelling, de BTW-elementen verplicht vullen Duidelijkere foutmelding, alle BTW elementen moeten gevuld zijn indien er een BTW verplichting is 8839 Was Indicatie debet/credit moet de waarde D hebben indien het totaal BTW-bedrag met nul gevuld is. Het totaal BTW-bedrag is nul en de Indicatie debet/credit heeft niet de waarde D. Verduidelijkt 8847 Was Begindatum declaratie-/factuurperiode moet kleiner zijn dan of gelijk zijn aan systeemdatum VECOZO. Begindatum declaratie-/factuurperiode moet gelijk zijn aan of voor de systeemdatum liggen. Generieke melding, niet afhankelijk van de partij 8848 Was Dagtekening factuur moet kleiner zijn dan of gelijk zijn aan systeemdatum VECOZO. Dagtekening moet gelijk zijn aan of voor de systeemdatum liggen Generieke melding, niet afhankelijk van de partij 8849 Was Dagtekening retourbericht moet kleiner zijn dan of gelijk zijn aan systeemdatum VECOZO. vervallen aangepast aangepast aangepast 23

Dagtekening retourbericht moet gelijk zijn aan of voor de systeemdatum liggen vermijden OF conditie, niet afhankelijk van de partij 8850 Was BTW-bedrag mag niet voorkomen. vervallen Indien BTW-vrijstelling, de BTW-elementen niet vullen Duidelijkere foutmelding, alle BTW elementen moeten gevuld zijn indien er een BTW-verplichting is 8851 Was Indicatie BTW-vrijstelling moet voorkomen i.g.v. factuur. vervallen Indicatie BTW-vrijstelling is verplicht in geval van factuur. Verduidelijkt 8853 Is Creditering afgekeurde debetregel is niet toegestaan voor een 303-declaratie. Creditering van een afgekeurde prestatie is niet toegestaan in geval van een declaratie. Verduidelijkt aangepast 8854 Was Debetregel is eerder al gecrediteerd. aangepast Prestatie is al eerder gecrediteerd Verduidelijkt 9019 Was Bericht voldoet niet aan technische regel 19 aangepast Het regiebericht kan niet gekoppeld worden aan een toewijzing. Verduidelijkt 9056 Was Bericht voldoet niet aan technische regel 56 aangepast Identificatie moet per berichtsoort uniek zijn voor de verzendende partij. Verduidelijkt 9063 Was Bericht voldoet niet aan technische regel 63 aangepast Het bericht kan niet verwerkt worden omdat geen eerder bericht ontvangen is. Verduidelijkt 9069 Was Bericht voldoet niet aan technische regel 69 aangepast De Begindatum komt niet overeen met de actuele melding start ondersteuning. Verduidelijkt 9071 Was Bericht voldoet niet aan technische regel 71 aangepast Het eerdere startbericht kan niet verwijderd worden omdat de zorg al beëindigd is. Verduidelijkt 9074 Was Bericht voldoet niet aan technische regel 74 aangepast Er is al een eerder bericht ontvangen met dezelfde sleutel. Verduidelijkt 9300 Was Bericht voldoet niet aan technische regel 300 aangepast De referentie komt niet overeen met de referentie van het Verzoek om toewijzing. Verduidelijkt S064 Was Vullen met een bestaande datum die niet in de toekomst ligt. Vervallen Inhoud is gelijk aan Rc 8848 en deze is specifieker 9307 Begindatum prestatie ligt niet tussen de ingangsdatum en einddatum toewijzing Nieuw 24

9308 Einddatum prestatie ligt niet tussen de ingangsdatum en einddatum toewijzing 9311 De aanbieder komt niet overeen met de aanbieder in de toewijzing 9309 De ingediende tijdseenheid komt niet overeen met de toegewezen tijdseenheid Nieuw Nieuw Nieuw 9321 Het ingediende volume overschrijdt het toegewezen volume Nieuw 9322 De som van de ingediende volumes overschrijdt het toegewezen volume Nieuw Gedeclareerd bedrag mag niet hoger zijn dan berekend vervallen bedrag Het verschil tussen het ingediende en toegekende declaratie/factuur bedrag is niet gelijk aan de som van het verschil van de ingediende en toegekende prestatie bedragen vervallen S300 Is Gemeentecode komt niet voor in de lijst van CBS. Gelijk 25

Wijzigingsverzoek istandaarden Jeugdwet en Wmo Wijzigingsnr RFC17059 Rechtmatigheid en regieberichten verder ontkoppelen Ontvangstdatum 1-1-2017 Organisatie Programma i-sociaal Twee bedrijfsregels, OP126 en OP151 dienen te vervallen omdat deze in strijd zijn met de gewenste berichtscheiding tussen rechtmatigheid en regie. OP126: De gemeente stuurt na een stopbericht geen intrekkingsbericht naar deze aanbieder. OP151: Een toewijzing eindigt op de datum waarvan de aanbieder aangeeft dat na deze datum geen levering op de toewijzing meer plaats vindt. De Handreiking Uitvoeringsvarianten Wmo en Jeugdwet beschrijft gedetailleerd de werkwijze waar scheiding van rechtmatigheid en regie een belangrijke rol speelt. De genoemde bedrijfsregels in de huidige vorm conflicteren hiermee. De berichtscheiding tussen rechtmatigheid en regie heeft gevolgen voor het omgaan met Stopberichten. Dit wordt toegelicht uitgaande van onderstaande vier uitgangspunten: 1. De specificaties volgen de berichtscheiding tussen rechtmatigheid en regie zoals beschreven in het document Handreiking uitvoeringsvarianten iwmo en ijw. 2. Het besluit om een beschikking of toewijzing te beëindigen wordt door de gemeente genomen. 3. Een door een gemeente genomen besluit dient kenbaar gemaakt te worden aan de aanbieder. Toelichting: Indien de aanbieder hiervan niet op de hoogte wordt gesteld is de status van de toewijzing bij de aanbieder niet bekend en leidt mogelijk tot problemen. 4. Het is verplicht een bericht te sturen wanneer er nieuwe informatie bekend is die van belang is voor een goede bedrijfsvoering voor de ontvangende partij. Hieruit kan onderstaande bedrijfsregel worden afgeleid: Als een aanbieder een Stopbericht stuurt, een regiebericht, mag dit niet automatisch tot gevolg hebben dat de toewijzing wordt beëindigd. De beslissing om een toewijzing te beëindigen wordt door de gemeente genomen. Deze beslissing dient kenbaar gemaakt te worden aan de aanbieder. Aanpassen en uitbreiden van de specificaties en casuïstiek. 26

Er is geen technische conversie nodig. Echter is deze wijziging van invloed op het proces. Het is daarom van belang om bij deze wijziging veel functionele aandacht te geven aan deze verandering in het proces. Aanbieders en gemeenten dienen goed geïnformeerd te worden over de consequenties van deze ontkoppeling. Gemeenten en aanbieders Doorvoeren Consistentie met uitvoeringsvarianten. Uitwerking - Bedrijfsregels OP126 en OP151 worden verwijderd. - Procesbeschrijvingen worden bijgewerkt. 27

Wijzigingsnr Wijzigingsverzoek istandaarden Jeugdwet en Wmo RFC17061 Integreren declaratieberichten, processen en controles in informatiemodel Ontvangstdatum 1-1-2017 Organisatie VNG, i-sociaal De specificaties van de declaratie- en factuurberichten WMO303/304 en JW303/304 zoals nu opgesteld en beschikbaar gesteld door Vektis worden vertaald en geïntegreerd in de informatiemodellen Wmo en Jeugdwet en gepubliceerd op het istandaarden portaal. Dit betekent dat vanaf iwmo/ijw 2.2 alles rondom iwmo en ijw te vinden is op istandaarden.nl en niet meer op het WESP (ei.vektis.nl). Tijdens de integratie wordt kritisch gekeken naar mogelijke verbeteringen in de foutafhandeling; de controles, retourcodes en omschrijvingen. Hierbij wordt expliciet gekeken naar de huidige werkwijze tussen gemeente en aanbieder. De publicatievorm van de informatiemodellen wordt grondig herzien waarbij gebruikersgemak een van de belangrijkste pijlers is. Dit resulteert in het eenvoudig en snel kunnen opzoeken van relevante informatie ook met betrekking tot declaraties en facturen. Onder de specificaties van de declaratie- en factuurberichten WMO303/304 en JW303/304 wordt verstaan: De berichtdefinities, De beschreven controles, De XML definities, De XSLT controles, De invulinstructies, De testvoorbeelden. Dit resulteert in de volgende voordelen: 1. Eén publicatievorm; één servicedesk, één vindplaats 2. Alle berichten vallen onder één basisschema 3. Eén XSLT controle systematiek voor alle berichten 4. Traceerbaarheid van de retourcode, de controle en het object 5. Betere aansluiting van controles op werkwijze gemeente en aanbieder 6. Representatieve (realistische en praktijkgerichte) testberichten 7. Representatieve (realistische praktijkgerichte) casuïstiek Het is een nadrukkelijke wens van het veld om eenheid te brengen in vormgeving en de publicatie van de standaarden. Daarom worden alle Wmo en Jeugdwet gerelateerde berichtstandaarden ondergebracht bij de istandaarden beheerafdeling. 28

De gemeente en aanbieder zien een verbetering in kwaliteit; minder onduidelijkheid of onzekerheid omtrent de afhandeling van declaraties/facturen en duidelijke foutmeldingen. Alle gebruikers van istandaarden zien een integraal aangepakt en weergegeven proces. Ze zien een kwaliteitsverbetering omdat alle publicatie in één zit en er minder verschillen zullen zitten. Daarnaast is het simpelweg prettig om alle informatie op één portaal verzameld te zien. Het is niet meer nodig om voor de declaratiestandaarden naar het Vektis portaal te gaan. Geen. De specificaties rondom de 303/304 blijven inhoudelijk grotendeels gelijk. De XML schema definitie en het XSLT controle mechanisme zal aangepast worden zodat er een integrale weergave en werkwijze is over alle istandaardenberichten heen. Een beperkt aantal controles wordt toegevoegd of vervalt wellicht. Het integreren van de declaratieberichten heeft gevolgen voor de naamgeving van datatypes: het istandaarden onderscheid tussen complex en simpletypes opnemen in naamgeving van de datatypes d.m.v. voorvoegsel CDT_ en LDT_. Structuur van ClientGegevens: gelijk maken aan structuur van Cliënt in overige berichten. Dit betekent dat NAW-gegevens niet langer worden meegegeven in het 303-bericht. Alle enumeraties worden in het basisschema beschreven, i.p.v. gedeeltelijk in de berichtschema's (m.u.v. BerichtCode; omdat per 303 bericht twee codes zijn toegestaan, is het niet mogelijk dit in het basisschema op te nemen.) De root gaat Root heten i.p.v. Bericht Vanwege de uitlijnen met declaratiestandaarden is het element BerichtSoort en bijbehorende constraints (CS323, CS324, CS329 en CS331) uit het berichtenverkeer verwijderd. Gemeenten, aanbieders, softwareleveranciers. Doorvoeren. Alle specificaties van iwmo en ijw op één plaats en één organisatie. Uitwerking Nader te bepalen. 29

Wijzigingsverzoek istandaarden Wmo Wijzigingsnr RFC17063 Toevoegen uitgangspunt over niet-gestructureerd berichtenverkeer Ontvangstdatum 1-1-2017 Organisatie Zorginstituut Nederland Er is in de definitieve specificaties geen uitgangspunt opgenomen over niet-gestructureerd berichtenverkeer. Deze informatie wil het Zorginstituut opnemen in de uitgave Wat u moet weten over istandaarden en in de referentieprocessen. Dit wordt in een latere versie van het Informatiemodel meegenomen. In iwmo en ijw wordt middels de uitgangspunten en bedrijfsregels duidelijker gemaakt waarvoor iwmo en ijw zijn bedoeld. Concreet betekent dit de volgende wijzigingen: - Toevoegen uitgangspunt (UP): De Wmo berichtenfamilie ondersteunt uitwisseling van gestructureerde informatie. - Toevoegen uitgangspunt (UP): Wanneer niet voldaan kan worden aan de eisen van het gestructureerde berichtenverkeer moet er op alternatieve wijze contact plaatsvinden tussen partijen. - Toevoegen nieuwe uitzondering op bedrijfsregel OP191: OP191x1 Indien het gebruik van het gestandaardiseerd berichtenverkeer niet mogelijk is, wordt informatie buiten het berichtenverkeer om uitgewisseld. Er zijn situaties waarbij het gestructureerde berichtenverkeer niet geschikt is om informatie uit te wisselen, bijvoorbeeld bij het ontbreken van een BSN. In deze situaties kan in plaats van, of in aanvulling op, buiten het berichtenverkeer contact met elkaar worden opgenomen. Dit kan bijvoorbeeld telefonisch of per beveiligde mail. OP191 = Het gebruik van ongestructureerde informatie dient tot een minimum beperkt te worden. Commentaar mag in de berichten gebruikt worden om extra informatie op te nemen. Het commentaar bevat een toelichting op de betreffende berichtklasse, die niet elders in het bericht kan worden opgenomen. Er zijn geen formele afspraken gemaakt over de vulling van het commentaar. Verduidelijking van het bedoelde gebruik van de standaarden. Geen. Geen. Niet doorgevoerd in specificaties juli 2017. overstijgend aanpakken en op een later moment opnemen in referentieprocessen. Technische uitwerking 30

Wijzigingsverzoek istandaarden Wmo en Jeugdwet Wijzigingsnr RFC17065 Toewijzing alleen versturen naar betreffende aanbieder Ontvangstdatum 7-2-2017 Organisatie Zorginstituut Nederland In een toewijzing (301) alleen die zorginhoudelijke informatie opnemen die voor de ontvangende aanbieder van belang is om zijn of haar taak uit te voeren voor de betreffende cliënt. Andere toewijzingen, weliswaar behorende bij dezelfde beschikking maar voor een andere aanbieder bestemd, worden niet in de eerder genoemde toewijzing meegestuurd. Iedere aanbieder krijgt precies dat deel van de beschikking te zien welke voor haar/hem bestemd is. De volgende redenen zijn aanleiding voor dit wijzigingsvoorstel: Dataminimalisering; geen gegevens sturen die niet nodig zijn Privacy overwegingen; bijzondere zorginhoudelijke cliëntinformatie alleen naar betrokken partijen sturen. Oplossen inconsistentie; bij eerste toewijzing wordt nu alle informatie naar iedereen verstuurd, bij een update wordt alleen de nieuwe informatie naar de betreffende aanbieder gestuurd. Zie OP087 - Een toewijzingbericht bevat voor één beschikking altijd alle toewijzingen die op of na de aanmaakdatum van het bericht geldig zijn. Het bericht wordt alleen verstuurd naar de aanbieder voor wie de toewijzing nieuw of gewijzigd is. Geen; voor zowel gemeente als aanbieder verandert er in de werkwijze niets. - De manier waarop een toewijzingsbericht opgesteld wordt moet worden aangepast. - De controle op volledige dekking van de toewijzingen over de beschikkingsperiode (als deze eindig is) moet worden aangepast of moet komen te vervallen. Geen Gemeenten en aanbieders Uitvoeren - Dataminimalisering; geen gegevens sturen die niet nodig zijn - Privacy overwegingen; bijzondere zorginhoudelijke cliëntinformatie alleen naar betrokken partijen sturen - Oplossen inconsistentie; bij eerste toewijzing wordt nu alle informatie naar iedereen verstuurd, bij een update wordt alleen de nieuwe informatie naar de betreffende aanbieder gestuurd. - Functioneel geen impact Uitwerking Nader te bepalen. 31

Wijzigingsverzoek istandaarden Wmo en Jeugdwet Wijzigingsnr RFC17067 Eenduidige technische controles in iwmo en ijw Ontvangstdatum 1-1-2017 Organisatie i-sociaal In iwmo en ijw versie 2.1 wordt XML als primaire taal geïntroduceerd met daarbij de controlehulpmiddelen met XSL Transformaties (XSLT). In het kader van beter gebruik maken van de voordelen van de XML wordt voorgesteld om in iwmo en ijw versie 2.2 de werkwijze rondom de controles die je kan uitvoeren met XSLT te uniformeren. Uitleg XSD en XSLT Met behulp van een XSLT kunnen controles op de technische juistheid van een bericht worden uitgevoerd. XSD s en XSLT s worden gebruikt om berichten technisch te valideren. Zodra er een fout wordt geconstateerd t.o.v. het XSD, wordt het bericht afgekeurd. Een XSLT validatie gebeurt op dwarsverbanden en condities die niet in een XML Schema (XSD) kunnen of wenselijk zijn. Het grote voordeel van een XSLT is dat deze door de beheerder van een standaard kan worden opgesteld en op een uniforme, eenduidige en eenvoudige wijze geïmplementeerd kunnen worden door alle softwareleveranciers. Het coderen van deze controleregels door softwareleveranciers zelf is daardoor niet meer noodzakelijk. Retourcode 0001: BERICHT TECHNISCH ONJUIST Omdat het toepassen van deze controles op berichten eenvoudig is, wordt een bericht dat niet voldoet aan deze technische eisen volledig afgekeurd. Bij technische afkeur wordt alleen de header teruggestuurd met daarin het versienummer van de XSLT waartegen is gecontroleerd en de retourcode 0001 bericht is technisch onjuist. De XSLT controle bevat enkele technische fouten. De inhoud van de technische controle en terugkoppeling op de technische fout is terug te vinden in de XSLT output. Indien er zich functionele fouten aandienen, kunnen daarvoor functionele retourcodes worden gebruikt. Concreet betekent dit de volgende wijzigingen: 1. Toevoegen bedrijfsregel: Als de ontvanger een technische fout constateert, keurt hij het bericht in zijn geheel af en laat hij dit weten aan de verzender. Het bericht kan daarmee functioneel als niet-ontvangen worden beschouwd. 2. XSLTs van alle berichten verder uitbreiden, inclusief het opstellen van XSLT s voor retourberichten (indien er zinvolle controles zijn). 3. Het XSLT zal in een machine readable formaat het versienummer in de output meenemen. De output die de XSLT controle genereerd is vastgelegd in een XML Schema en wordt gepubliceerd. Dit versienummer wordt bij een geconstateerde fout gebruikt om in het retourbericht terug te geven aan de verzender 4. Retourcodes voor XSLT controles, met uitzondering van foutcode 0001, worden uit de informatiemodellen gehaald. 5. In de header van álle retourberichten wordt één extra optioneel berichtelement toegevoegd: XsltVersie. - Format wordt string, maxlength 5 en pattern [0-99].[0-99] (zodat versie 0.9 tot max 99.99 kan 32

worden ingevuld). - Dit element moet worden opgenomen wanneer het bericht op basis van de XSLT controle wordt afgekeurd. Het versienummer moet worden overgenomen uit het resultaat van de XSLT. Daarvoor is een invulinstructie opgesteld. - De bestaande invulinstructie voor retourberichten is hierop aangepast. De belangrijkste aanleiding om dit gebruik van XSLT in te voeren, is de realisatie van een grotere volwassenheid in de gegevensuitwisseling. De verantwoordelijkheid voor technische kwaliteit komt zo vroeg mogelijk in een keten, namelijk bij de verzender van een bericht, te liggen. Controles wil je zo vroeg mogelijk in een keten uitvoeren en met XML zijn er goede mogelijkheden om dat geautomatiseerd, uniform en eenvoudig plaats te laten vinden bij de verzender van een bericht. Analyse van een fout ligt bij de verzender van een bericht. XSLT controles zijn op technisch niveau en hebben geen functionele impact. Als een bericht om een technische reden wordt afgekeurd en code 0001 terugstuurt, moet het bericht door de verzender functioneel als niet-ontvangen worden beschouwd. Functioneel niet-ontvangen bij een factuur Een factuur heeft een andere status en een betalingsverplichting. Aangezien het bericht, bij constatering van een technische fout, in zijn geheel wordt teruggestuurd, geldt ook voor de factuur dat deze als niet-ontvangen kan worden beschouwd. - Retourcodes voor XSLT controles worden uit de informatiemodellen gehaald. - Vanaf iwmo en ijw versie 2.1 werken we met XSLT. De ervaringen hiermee worden pas vanaf 12 juni 2017 opgedaan. - Gegevenselement versienummer XSLT opnemen in retourberichten Geen. Gemeenten en aanbieders. Indien XSLT s worden gebruikt, wordt bij alle technische fouten retourcode 0001 meegegeven. - Vereenvoudiging van het berichtenverkeer en specificaties. - XSLT foutafhandeling kent nog slechts één werkwijze; vaste structuur en retourcode 0001. - Meer gebruik maken van mogelijkheden XML - Duidelijkere verantwoordelijkheid kwaliteit berichtenverkeer 33

Uitwerking Verwijderen retourcodes: 0150, 0435, 1110, 8062, 8064, 8166, 8171, 8175, 8177, 8178, 8181,8182, 8185, 8186, 8188, 8193, 8194, 8207, 8215, 8223, 8269, 8376, 8454, 8455, 8456, 8835, 8837, 8839, 8850, 8851, 9001, 9002, 9006, 9014, 9015, 9016, 9017, 9018, 9019, 9020, 9021, 9037, 9039, 9040, 9041, 9042, 9046, 9052, 9056, 9061, 9063, 9064, 9065, 9066, 9069, 9070, 9071, 9073, 9074, 9078, 9085, 9086, 9091, 9097, 9101, 9300, 9301, D004, D005, D007, D009, D016, D017, D018, D020,D022, D023,D025,D029, D034,D036,D038,D039, D040, D041, D042, D043, D044, D045, D046, D047, D048, S002,S003, S012, S014, S023, S035, S049, S050, S057, S058, S062, S064, S065, S067, S069, S071, S072, S073, S074, S086, S088, S089, S092, S093, S107, S108, S112, S113, S114, S115, S118, S119, S120, S121, S122, S123, S300, S317, S318. 34

Wijzigingsverzoek istandaarden Wmo en Jeugdwet Wijzigingsnr RFC17068 Klasse BeschiktProduct verwijderen Ontvangstdatum 16-03-2017 Organisatie GGZ Nederland Klasse BeschiktProduct verwijderen uit het toewijzingbericht (301). De voor de aanbieder benodigde informatie wordt al doorgegeven via de gegevens uit de ToegewezenProduct. Daarnaast wordt er functioneel gezien een toewijzing naar de aanbieder gestuurd en niet een beschikking. Geen Een nieuw XML schema voor ijw en iwmo toewijzing (301) Geen. Softwareleveranciers Doorvoeren. - Vereenvoudiging van de specificaties - Data minimalisatie Uitwerking - Verwijderen van de klasse BeschiktProduct uit het informatiemodel - Verwijderen van de klasse BeschiktProduct uit het XML schema 35