FACTSHEET IMPLEMENTATIE IWMO & IJW XML-RELEASE 2.1. Softwareleveranciers Gemeenten & Zorgaanbieders

Transcriptie

1 FACTSHEET IMPLEMENTATIE IWMO & IJW XML-RELEASE 2.1 Softwareleveranciers Gemeenten & Zorgaanbieders Versie juli 2016

2 Doelstelling Softwareleveranciers informeren over de overgang in berichtenverkeer iwmo & ijw van EI 2.0 naar XML-release 2.1 per 3 april Dit wordt vanuit het programma actief ondersteund door bij te dragen aan de informatiebehoeften en beschikbare kennis over te dragen middels deze factsheet. Wat verandert er in XML-release 2.1 t.o.v. EI 2.0? Bij de invoering van versie 2.1 van het iwmo en ijw-berichtenverkeer wordt naast de overgang van EI-berichten naar XML een aantal technische wijzigingen doorgevoerd. Ook zijn afspraken in de keten met betrekking tot foutafhandeling verscherpt. De belangrijkste wijzigingen voor softwareleveranciers worden hieronder besproken. Controle op technische juistheid van berichten Met ingang van de nieuwe release vereenvoudigt de wijze van het controleren en terugkoppelen van berichten. Voor alle berichten, behalve de JW321/JW322 De verzender is verantwoordelijk voor de technische correctheid van een bericht. Het onderscheid in fout- en retourberichten wordt verhelderd. Foutberichten hebben betrekking op situaties in de infrastructuur (tijdens het transport), retourberichten gaan over de inhoud van een bericht. Alle iwmo- en ijw-berichten worden door VECOZO gecontroleerd op conformiteit met de XSD (XML-schemavalidatie). Als een bericht niet voldoet aan de XSD, wordt dit teruggekoppeld met een foutbericht. Het is immers niet mogelijk om een valide retourbericht op te stellen. Er wordt geen nadere aanduiding van de fout meegegeven. Alleen voor de 303/304-berichten VECOZO controleert tevens de technische correctheid aan de hand van een XSLT. Deze XSLT is opgesteld door Vektis en wordt gepubliceerd om transparant te zijn over de controles die in de infrastructuur plaatsvinden. Deze controles hoeven niet door de ontvanger te worden herhaald. Als een fout wordt geconstateerd, genereert VECOZO net als voorheen een retourbericht met een foutaanduiding in de vorm van een of meer retourcodes. In de controleregels (RBC) van Vektis zal worden aangegeven welke controles worden uitgevoerd door VECOZO aan de hand van de XSLT, en welke controles niet in de infrastructuur plaatsvinden. Deze controles mogen worden uitgevoerd door de ontvanger; bij een geconstateerde fout stelt hij een retourbericht op met een of meer retourcodes. De XSLT van Vektis kan door leveranciers worden gebruikt bij het testen van hun eigen software. Gebruik door verzenders of ontvangers in een productiesituatie wordt niet ondersteund. Alleen voor de 301/302, 305/306, 307/308 en de 315/316 VECOZO voert geen nadere controles op de inhoud van het bericht uit, naast de beschreven XSD-schemavalidatie en validaties ten behoeve van transport. Pagina 1

3 Zorginstituut Nederland stelt XSLT s beschikbaar, die de uitvoering van een deel van de nadere controles ondersteunen. Deze XSLT s zijn gericht op gebruik door softwareleveranciers, zowel voor test- als productiedoeleinden. Gebruik van de schema s is niet verplicht, maar is een hulpmiddel bij het correct opstellen van berichten door de verzender en het uitvoeren van controles door de ontvanger. De output van een XSLT-transformatie maakt het mogelijk om programmatisch vast te stellen of er fouten zijn aangetroffen of niet. Geconstateerde fouten worden gestructureerd aangeduid, maar niet in een vorm die direct bruikbaar is in een retourbericht. Als een ontvangende partij fouten aantreft bij controles die zijn gespecificeerd in de XSLT, mag hij dit terugkoppelen met een generieke code op berichtniveau (retourcode 0001). Nadere duiding van de fout is niet nodig. De ontvangende partij kan met behulp van de XSLT de plaats en de aard van de fout achterhalen. Een gedetailleerde terugkoppeling met behulp van retourcodes is ook toegestaan, maar niet verplicht. Op dit punt zal het informatiemodel iwmo/ijw 2.1 binnenkort worden aangepast. Fouten die worden geconstateerd bij controles die niet in een XSLT zijn gespecificeerd, worden teruggekoppeld op de gebruikelijke wijze via een gedetailleerd retourbericht. Alleen voor de JW321 en JW322 De systematiek bij JW321 en JW322 blijft ongewijzigd ten opzichte van de huidige versie. Universally Unique Identifier De berichten die in de ISD-keten worden uitgewisseld zijn vanaf versie 2.1 door de gehele ISD-keten te volgen door het Inlichtingenbureau en VECOZO. Hiertoe wordt ketenbreed gebruik gemaakt van een uniek nummer dat door de verzenders van berichten wordt gegenereerd, en in de envelop wordt opgenomen. Dit unieke nummer is een Universally Unique Identifier (UUID). Dit is een ID die gestandaardiseerd is door de 'Open Software Foundation' (OSF) als onderdeel van de 'Distributed Computing Environment' (DCE). Dit nummer staat los van referentienummers zoals vermeld in het iwmo- en ijw-bericht zelf. Als de verzender van een bericht een gemeente is, is deze verantwoordelijk voor het genereren van een uniek nummer (UUID) per bericht. Dit geldt voor registratie-, declaratie-, retour- en foutberichten. Bij retourberichten en foutberichten dient door de verzender tevens aangegeven te worden wat het UUID van het bericht is waarop het bericht een antwoord is. Zie ook hieronder bij StUF-envelop. Voor zorgaanbieders kan de afhandeling van de unieke nummers op twee wijzen worden geregeld. Wordt het bericht aangemaakt via het webportaal dan hoeven de leveranciers van zorgaanbieders deze nummers niet te genereren. Als er wordt gebruikgemaakt van de webservices dan is het aanmaken door de software van de zorgaanbieder vanaf versie 2.1 verplicht. Pagina 2

4 StUF-envelop Met de invoering van versie 2.1 van de standaarden wordt ook een nieuwe versie van de StUF-envelop ingevoerd. In deze versie van de envelop is een aantal wijzigingen doorgevoerd: Het veld stuurgegevens.referentienummer dient een uniek UUID te bevatten; In een retourbericht dient in het veld stuurgegevens.crossrefnummer het UUID van het bericht waarop antwoord gegeven wordt opgenomen te worden; De velden stuurgegevens.functie en stuurgegevens.zender.applicatie zijn opgeknipt in drie losse velden waarin de functie, versie en subversie aangegeven worden. Deze velden dienen alle verplicht ingevuld te worden; Indien de payload van het bericht een iwmo- of ijw-bericht is dan dient het referentienummer van het bericht opgenomen te worden in het veld parameters.referentienummerbericht. Bij retourberichten dient het veld parameters.crossrefnummerbericht gevuld te worden met het referentienummer van het bericht waarop antwoord gegeven wordt; Door de invoering van XML is verder de verplichte waarde van het veld parameters.bericht.contenttype bij verzending van iwmo of ijw berichten van tekst/xml gewijzigd naar application/xml. Binnen de ketentestvoorziening kan alleen worden getest met de StUF-envelop versie 2.1. De definitie van de StUF-envelop van het GGk is terug te vinden op: Er bestaat ook een nieuwe header aan de Zorgaanbiederzijde. Deze staat beschreven in het Berichtuitwisselingsdocument WMO & Jeugdwet Zorgaanbieders. Deze kan via servicedesk van VECOZO door software leveranciers worden opgevraagd en wordt dan via toegestuurd. Maximale omvang van berichten De maximale omvang van de berichten, die in de keten kunnen worden uitgewisseld, wordt met de invoering van versie 2.1. aangepast naar 25MB, dit was 10MB. Welke ondersteuningsproducten worden opgeleverd? Om de overgang van EI 2.0 naar XML-release 2.1 per 3 april 2017 zo goed mogelijk te ondersteunen worden de onderstaande producten opgeleverd. Informatiemodellen iwmo & ijw, XSD s en XSLTs De specificaties, inclusief de XSD s, zijn vastgelegd in het Informatiemodel Wmo en Jeugdwet. Er staat in hoe het werkt en welke afspraken gelden. De specificaties zijn tot stand gekomen in nauwe samenwerking met alle ketenpartners. De informatiemodellen zijn op 1 juli jongstleden beschikbaar gesteld. De XSLT s worden in concept op 1 augustus opgeleverd. Eventuele bevindingen kunnen gemeld worden bij Zorginstituut Nederland danwel Vektis. Op 1 oktober worden de definitieve versies gepubliceerd. Pagina 3

5 Al deze specificaties zijn terug te vinden op en Ketentestvoorziening & gebruikerstoegang Vanuit gemeenten, aanbieders en softwareleveranciers is het verzoek gekomen om gedurende een langere periode te kunnen testen met alle ketenpartijen. Het continue kunnen testen van nieuwe releases levert zowel de softwareleveranciers, de ondersteunende diensten als ISD-Beheer voordelen op. Zo kunnen in vroegtijdig stadium fouten uit de istandaarden, infrastructuur en bèta-releases van de domeinapplicaties worden gehaald, die anders pas in een later stadium met de integrale ketentest naar boven zouden komen. Er kan hierdoor eenvoudiger release management plaatsvinden op het gehele berichtenverkeer in de ISD-keten. Er kan van medio oktober getest worden op de ketentestvoorziening. De daadwerkelijke ondersteuning door de service desks aan softwareleveranciers start vanaf medio november. Over de procedure voor de toegang tot de Ketentestomgeving volgt nadere berichtgeving. Validatiemodule De Validatiemodule biedt zorgaanbieders, gemeenten, softwareleveranciers en alle andere instanties die gebruikmaken van istandaarden berichten de mogelijkheid de testberichten die zij gebruiken te valideren op inhoudelijk correctheid. De validatiemodule is per 1 augustus te vinden op De validatiemodule is in verband met privacywet- en regelgeving met nadruk niet bedoeld voor het valideren van productiegegevens. Vanaf dit jaar ondersteunt de validatiemodule ook de declaratiemodule met de 303/304- berichten. Op 1 augustus worden de via XSLT gespecificeerde controles ondersteunt; vanaf 1 september bevat de module voor de declaratieberichten ook de uitgeprogrammeerde controles. Groene vink De Groene Vink is een kwaliteitsborging voor softwareleveranciers die werken met istandaarden. Het doel van het behalen van een Groene Vink is vast te stellen of de output van een softwarepakket en de verwerking van de input in een softwarepakket overeenkomt met de specificaties van een istandaard. Voor de nieuwe iwmo- en ijw-releases wordt een Groene Vink module aangeboden per 5 september op Noodmaatregel Bij de overgang naar de nieuwe releases van de iwmo en ijw is gekozen voor een BIG BANG scenario. Er wordt daarom geen geïntegreerde conversiemodule ontwikkeld, slechts een minimale noodmaatregel voor de conversie van IE ASCII-bericht 2.0 XML-bericht 2.1. Nadere berichtgeving hierover komt eind Pagina 4

6 Colofon Contactinformatie: Kees Steijsiger Leverancier manager mobiel: