SuwiML berichtstandaard

Transcriptie

1 Rapport SuwiML berichtstandaard Auteur: Paul Vriend, Dirk Temme Datum document: Versie: v0201 Status: Datum afdruk: donderdag 3 november 2005 SuwiML berichtstandaard v0201.doc - 1 van 103

2 Documenthistorie Datum en versienummer Auteur Opmerking 0.1, 18/09/2001, Draft v0100, 20/12/2001, Definitief Astrid Hackenberg Arjan Loeffen v0200, 21/07/2005, Definitief Paul Vriend Volledige revisie, aanpassing en uitbreiding n.a.v. toetsing in de praktijk. V0201, Dirk Temme Blz 35: NB verwijderd voor optionele velden met waarde Onbekend ; In de voorbeelden het gebruik van ElementFormDefault aangepast; Goedkeuring Datum Naam Functie v0100, 20/12/2001 Domeingroep Gegevens en Vertegenwoordiging Suwi keten. Berichten (DGB). v0201,??/??/2005 Domeingroep Gegevens en Berichten (DGB). Vertegenwoordiging Suwi keten. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 2 van 103

3 Inhoudsopgave 1. Inleiding Doel Leeswijzer 7 2. SuwiML berichtstandaard Inleiding SuwiML berichtidentificatie Validatie SuwiML basisschema Inleiding Gegevenstypen Entiteiten Hiërarchie Automatisch tabellenbeheer Versienummering SuwiML berichtschema Inleiding SuwiML body 24 Structuur 24 Voorbeelden 31 Lege velden / waarden in een SuwiML bericht 35 Afleiden berichtschema uit basisschema 35 Soorten relaties 37 Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 3 van 103

4 Voorbeeld Warning binnen SuwiML body Clusters binnen SuwiML body Beknopte samenvatting modellering SuwiML berichtschema SuwiML berichtontwikkelingsmethodiek Inleiding Internationale ontwikkelingen mbt standaardisatie en berichtontwikkeling 49 UN/CEFACT Modelling Methodology 49 W3C 50 ISO ISO ebxml 51 Aanbevelingen met betrekking tot het berichtontwikkelingsproces Het berichtontwikkelingsproces 52 Analyse, ontwerp, ontwikkeling 54 Implementatie en toepassing Methodische ondersteuning van het berichtontwikkelingsproces 55 Procesmodel 55 State-transition-diagram 55 Time-sequence-diagram 55 Informatiemodel en berichthiërarchie Specificatie van elektronische ketenberichten 56 Gegevensmodel 56 Berichtmodel 56 Specificatie van een elektronisch ketenbericht 58 Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 4 van 103

5 6. Definities Referenties 68 Appendix A 71 Lijst met figuren Figuur 1: opbouw SuwiML berichtschemaset. 8 Figuur 2: opbouw SuwiML berichtschema vanuit SGR/SuwiML. 9 Figuur 3: samenhang van standaarden en schema s binnen SGR/SuwiML. 10 Figuur 4: voorbeeld van een SuwiML bericht met namespace verwijzingen. 11 Figuur 5: opbouw en onderlinge verhouding SuwiML basisschema modulen. 13 Figuur 6: voorbeeld van een onderdeel van de gegevenstypen-module. 14 Figuur 7: voorbeeld van een onderdeel van de gegevenstypen-module: Geslacht-Coded.xsd. 15 Figuur 8: voorbeeld van een onderdeel van de gegevenstypen-module: Geslacht-Typed.xsd. 16 Figuur 9: voorbeeld van een onderdeel van de entiteiten-module. 17 Figuur 10: opbouw en onderlinge verhouding SuwiML basisschema en SuwiML berichtschemaset. 17 Figuur 11: SOAP envelopeschema van een SuwiML Action berichtschema. 26 Figuur 12: SOAP envelopestructuur van een SuwiML Action berichtschema. 26 Figuur 13: SOAP envelopeschema van een SuwiML Reaction berichtschema. 28 Figuur 14: SOAP envelopestructuur van een SuwiML Reaction berichtschema. 29 Figuur 15: voorbeeld SuwiML Action bodyschema. 31 Figuur 16: voorbeeld SuwiML Reaction bodyschema. 33 Figuur 17: voorbeeld SuwiML Reaction response bericht. 34 Figuur 18: opbouw berichthiërarchie op basis van het SGR / het SuwiML basisschema. 37 Figuur 19: berichtinstantie irt SGR. 38 Figuur 20: berichtinstantie irt SGR met getypeerde relatie. 38 Figuur 21: berichtinstantie irt SGR met overerving van abstract datatype (eenvoudig). 38 Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 5 van 103

6 Figuur 22: berichtinstantie irt SGR met overerving van abstract datatype (complex). 39 Figuur 23: berichtinstantie irt SGR, getypeerde relatie met overerving van abstract datatype. 40 Figuur 24: berichtinstantie irt SGR met abstracte subtypes. 41 Figuur 25: voorbeeld Entiteit-Relatie diagram voor ClientSuwi. 42 Figuur 26: SuwiML Reaction bodyschema met een verbijzondering van het XML complextype voor ClientSuwi. 43 Figuur 27: voorbeeld SuwiML Reaction response bericht met een warning. 45 Figuur 28: modelleren van clusters binnen SuwiML body. 47 Figuur 29: berichtontwikkelingsproces. 49 Figuur 30: ISO development of messages. 50 Figuur 31: berichtontwikkelingsproces. 53 Figuur 32: schematisch voorbeeld van een gegevensmodel. 57 Figuur 33: voorbeeld van een berichtmodel op basis van het gegevensmodel in Figuur Figuur 34: voorbeeld van een berichtmodel op basis van het gegevensmodel in Figuur Figuur 35: voorbeeld van een berichtmodel op basis van het gegevensmodel in Figuur Figuur 36: voorbeeld van een berichtmodel op basis van het gegevensmodel in Figuur Figuur 37: voorbeeld van een berichtmodel op basis van het gegevensmodel in Figuur Figuur 38: berichtmodel voor ReintegratieadviesCwiUwv zoals vastgelegd in EC-Design. 71 Lijst met tabellen Tabel 1: opbouw SuwiML namespace. 11 Tabel 2: voorbeeldscenario van een aantal wijzigingen en de consequenties daarvan irt versienummers. 22 Tabel 3: opbouw SuwiML berichtschemaset. 25 Tabel 4: mogelijke combinaties van subelementen binnen het SuwiMLBody rootelement (onvermelde combinaties zijn niet mogelijk). 31 Tabel 5: beperkingen tav het gebruik van lege velden / waarden in een SuwiML bericht. 35 Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 6 van 103

7 1. Inleiding 1.1. Doel SGR/SuwiML heeft tot doel de (elektronische) gegevensuitwisseling tussen partijen in de Suwi keten te faciliteren. Dit betreft zowel het faciliteren van de ontwikkeling van de gegevensuitwisseling (het zo eenvoudig mogelijk maken van het definiëren en realiseren van de gegevensuitwisseling, in de vorm van berichten) als de ondersteuning van de operationele gegevensuitwisseling (het run-time gebruik van SGR/SuwiML). Voor de definitie van de inhoud van berichten en de codering van de uit te wisselen gegevens wordt gebruik gemaakt van SGR/SuwiML, in de vorm van het Suwi Gegevensregister en extensies hierop voor uitwisseling in XML-formaat. SGR/SuwiML faciliteert het snel en eenduidig definiëren van de berichtinhoud (middels betekenis van gegevens, te gebruiken gegevenselementen, entiteiten en relaties), de berichtstructuur en de berichtnotatie (middels XML-tags, SuwiML basisschema, SuwiML berichtschema s). Dit document beschrijft de functionele en technische richtlijnen voor het definiëren en uitwisselen van SuwiML berichten met betrekking tot de inhoudelijke structuur van de gegevens die moeten worden verstuurd. Dit document beschrijft de opzet en het gebruik van het SuwiML basisschema voor het definiëren van de body van SuwiML berichten. Daarmee biedt dit document een beschrijving voor het samenstellen van SuwiML berichtschema s alsook toepassingsonafhankelijke richtlijnen voor het realiseren van gegevensuitwisseling tussen de partijen in de Suwi keten. De SuwiML berichtstandaard is bedoeld voor zowel informatieanalisten als software-engineers en is zowel gericht op het ontwikkelen van berichten als op de wijze waarop applicaties operationeel met berichten moeten omgaan Leeswijzer Hoofdstuk 2 geeft een algemene introductie op SGR/SuwiML en geeft een inleidende beschrijving van de SuwiML berichtstandaard. Hoofdstuk 3 geeft een detail beschrijving van de opbouw en structuur van het SuwiML basisschema. Hoofdstuk 4 geeft een detail beschrijving van de opbouw en structuur van een SuwiML berichtschema. Hoofdstuk 5 geeft een detail beschrijving van de SuwiML berichtontwikkelingsmethodiek. Hoofdstuk 6 geeft een beknopt overzicht van de gehanteerde definities. NB. dit document veronderstelt dat de lezer een redelijke kennis van de XML en XML Schema standaard heeft. Voor meer informatie over deze en andere XML gerelateerde standaarden wordt verwezen naar de website van de W3C: Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 7 van 103

8 2. SuwiML berichtstandaard 2.1. Inleiding Alle betrokken partijen binnen de Suwi keten wisselen gegevens uit op basis van het Suwi Gegevensregister (SGR). Het SGR is het gegevensmodel met alle voor gemeenschappelijk gegevensgebruik in de Suwi keten relevante attributen, entiteiten en relaties. Zie het document Suwi Gegevensregister deel 1 en 2 ( voor de inrichting van het SGR. SuwiML berichten, zoals deze worden verzonden tussen de betrokken partijen in de Suwi keten, worden afgeleid van het SGR. Entiteiten en attributen in het SGR keren terug als XML elementen in een SuwiML bericht. Een SuwiML bericht is opgemaakt als een hiërarchische reeks van XML gecodeerde gegevens. Berichten die behoren tot één berichttype, zijn te verdelen in twee groepen: het initiërende bericht, de Action, en het reagerende bericht, de Reaction. De structuur en inhoud van een SuwiML bericht wordt gevalideerd aan de hand van het SuwiML berichtschema dat eraan ten grondslag ligt. In SuwiML wordt de definitie van een logisch berichttype vastgelegd in twee SuwiML berichtschema s met elk drie afzonderlijke XML Schema s (een envelope-, header- en bodyschema voor het Action berichtschema en een envelope-, header- en bodyschema voor het Reaction berichtschema). Het Action berichtschema en het Reaction berichtschema samen vormen de SuwiML berichtschemaset voor het betreffende berichttype. Figuur 1 geeft hier een voorbeeld van. SuwiML berichtschemaset action UwvDossierPersoon-EnvelopeAction.xsd import SuwiML-Header.xsd import reaction UwvDossierPersoon-EnvelopeReaction.xsd import import UwvDossierPersoon-BodyAction.xsd UwvDossierPersoon-BodyReaction.xsd Figuur 1: opbouw SuwiML berichtschemaset. Een op deze wijze gemodelleerd berichttype is onderdeel van een generieke methode voor het uitwisselen van berichten. Deze methode omvat de technische richtlijnen voor het definiëren en uitwisselen van SuwiML berichten met betrekking tot de envelopestructuur (het transportmiddel) en de wijze van verzending (het transport). De envelopestructuur wordt verplicht gebaseerd op de SOAP standaard. Zie het document SuwiML transactiestandaard voor een beschrijving van deze generieke methode voor het uitwisselen van berichten. De SuwiML berichtstandaard beschrijft de wijze waarop de SuwiML body moet worden vormgegeven op basis van de bouwstenen vastgelegd in het SuwiML basisschema. De SuwiML berichtstandaard maakt deel uit van SGR/SuwiML. SGR/SuwiML bestaat uit de volgende onderdelen: Suwi Gegevensregister (aangeduid als SGR: het gegevensmodel met alle voor gemeenschappelijk gegevensgebruik in de Suwi keten relevante attributen, entiteiten en relaties); Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 8 van 103

9 SuwiML basisschema (een XML Schema via welke de datatype informatie voor alle entiteiten en gegevenstypen uit het SGR in XML Schema formaat beschikbaar wordt gesteld); SuwiML transactiestandaard (technische richtlijnen voor het definiëren en uitwisselen van SuwiML berichten met betrekking tot de envelopestructuur (het transportmiddel) en de wijze van verzending (het transport)); SuwiML berichtstandaard (functionele en technische richtlijnen voor het definiëren en uitwisselen van SuwiML berichten met betrekking tot de inhoudelijke structuur van de gegevens die moeten worden verstuurd). In Figuur 2 worden de relaties tussen de verschillende onderdelen van SGR/SuwiML, noodzakelijk voor de opbouw van een SuwiML bericht, schematisch weergegeven. Het SuwiML basisschema is het XML synoniem voor het Suwi Gegevensregister en is van invloed op alle onderdelen van een SuwiML bericht. De SuwiML transactiestandaard schrijft de SOAP envelopestructuur voor, alsmede de stuurgegevens binnen de SuwiML header. De SuwiML berichtstandaard schrijft de opbouw van de SuwiML body voor. Suwi Gegevensregister SuwiML basisschema SuwiML berichtschema SOAP envelope SOAP header SuwiML header SOAP body SuwiML transactiestandaard SuwiML body SuwiML berichtstandaard Figuur 2: opbouw SuwiML berichtschema vanuit SGR/SuwiML. Een SuwiML bericht bestaat altijd uit een envelope die een header (de stuurgegevens) en een body (de berichtgegevens) bevat. De opbouw van een bericht door envelope, header en body staat beschreven in de SuwiML transactiestandaard en is gebaseerd op de SOAP standaard. Dit document, de SuwiML berichtstandaard, beschrijft de vormgeving van de body (de feitelijke berichtinhoud) van een SuwiML bericht. In Figuur 3 wordt de samenhang van de binnen SGR/SuwiML gebruikte standaarden en schema s ten opzichte van elkaar weergegeven. Aan de linkerkant worden de gebruikte standaarden weergegeven en benoemd. De standaarden gezamenlijk beschrijven een generiek SuwiML bericht. De rechterkant toont een voorbeeld van een SuwiML bericht. De SuwiML transactiestandaard maakt gebruik van de standaard SOAP envelopestructuur en specificeert voor een bericht het headerschema met daarin de stuurgegevens. De SuwiML berichtstandaard specificeert de wijze waarop het bodyschema moet worden vormgegeven met behulp van het SuwiML basisschema. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 9 van 103

10 Een SuwiML berichtschemaset wordt ontwikkeld door de ontwikkelaars binnen een project en is geënt op de formele richtlijnen zoals vastgesteld door SGR/SuwiML. Bij het samenstellen van een SuwiML berichtschemaset wordt gebruik gemaakt van het SuwiML basisschema, welke als grondslag dient voor alle SuwiML berichtschema s. De berichtschemaset moet voordat het in gebruik kan worden genomen, worden getoetst aan de voorgeschreven SGR/SuwiML standaard. Deze toetsing wordt uitgevoerd door de beheerder/uitvoerder van SGR/SuwiML, i.e. het BKWI. W3C standaard SOAP SOAP - ENV: Envelope SGR / SuwiML SuwiML header BerichtIdentificatie RouteInformatie BerichtType IndTestbericht etc. Transactie SuwiML body Request Gegevens - Response uitwisseling Redirect functionele Fault, Warning inhoud Acknowledgement SuwiML basisschema entiteiten gegevenstypen module module Generiek bericht Header Body Voorbeeld berichtinstantie ( request ) <? xml version ="1.0" encoding ="UTF - 8"?> <SOAP - ENV: Envelope xmlns :SOAP - ENV=" http :// schemas. xmlsoap. org /soap/ envelope /" xmlns : smlb =" http :// www. suwi. nl / SuwiML / BodyAction / UwvDossierPersoon - v0302" xmlns : smlh =" http :// www. suwi. nl / SuwiML / Header - v0200" xmlns : xsi =" http :// org /2001/ XMLSchema - instance " xsi : schemalocation =" http :// schemas. xmlsoap. org /soap/ envelope / UwvDossierPersoon - v b07 - EnvelopeAction. xsd "> <SOAP - ENV: Header > <smlh:suwimlheader> <RouteInformatie> </RouteInformatie> <BerichtIdentificatie> </BerichtIdentificatie> <Transactie> </Transactie> </smlh:suwimlheader> </SOAP - ENV: Header > <SOAP - ENV:Body> <smlb:suwimlbody> < : > < smlb <Request> : Request > </Request> smlb : Request > </ smlb : SuwiMLBody > </smlb:suwimlbody> </SOAP - ENV:Body> </SOAP - ENV: Envelope > Figuur 3: samenhang van standaarden en schema s binnen SGR/SuwiML SuwiML berichtidentificatie SuwiML berichten worden beschreven in verscheidene schema s: een envelope-schema, een header-schema en een body-schema. De berichtschema's die de Action en Reaction beschrijven, vormen samen een SuwiML berichtschemaset, die hoort bij een bepaald berichttype. Om de verschillende schema s te onderscheiden wordt gebruik gemaakt van namespaces. Een namespace is een unieke naam die een specifiek definitiegebied aanduidt. Door een schema te definiëren binnen een eigen namespace worden conflicten voorkomen in naamgeving en kan eenduidigheid worden gewaarborgd van XML elementen type definities. Bij het vaststellen van een namespace moet rekening worden gehouden met de BerichtNaam, VersieMajor en VersieMinor (onderdeel van BerichtType) en het interactietype (Action of Reaction). De namespaces binnen SuwiML worden als volgt opgebouwd: Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 10 van 103

11 Schema Namespace Prefix Basisschema sml bijv.: Body smlb bijv.: bijv.: Header smlh bijv.: Envelope SOAP- ENV Tabel 1: opbouw SuwiML namespace. Ieder SuwiML bericht wordt in de vorm van een SOAP envelope verstuurd. Dit betekent dat de SuwiML header en de SuwiML body in de SOAP envelope worden geïntegreerd. De koppeling tussen namespace en URL (locatie) wordt gemaakt met behulp van een XML Schema instance constructie, getoond in het XML voorbeeld in Figuur 4. <?xml version="1.0" encoding="utf-8"?> <SOAP-ENV:Envelope xmlns:soap-env = " xmlns:smlh = " xmlns:smlb = " xmlns:xsi = " xsi:schemalocation = " UwvDossierPersoon-v0302-b07-EnvelopeAction.xsd"> <SOAP-ENV:Header> <smlh:suwimlheader> <RouteInformatie> <Bron>... </Bron> <Bestemming>... </Bestemming> <Tussenstation>... </Tussenstation> </RouteInformatie> <BerichtIdentificatie>... </BerichtIdentificatie> <Transactie>... </Transactie> </smlh:suwimlheader> </SOAP-ENV:Header> <SOAP-ENV:Body> <smlb:suwimlbody> <Request>... </Request> </smlb:suwimlbody> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Figuur 4: voorbeeld van een SuwiML bericht met namespace verwijzingen. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 11 van 103

12 2.3. Validatie Een SuwiML berichtschema is een formele beschrijving van een bericht conform SGR/SuwiML. De zendende partij heeft de verplichting om een, volgens het vastgestelde SuwiML berichtschema, valide bericht te versturen. De ontvanger moet ieder binnenkomend bericht valideren tegen het bijbehorende vastgestelde SuwiML berichtschema alvorens het intern verder te verwerken. NB. binnen een bericht wordt middels het statement xsi:schemalocation verwezen naar de locatie van het gerelateerde SuwiML berichtschema waar automatisch tegen gevalideerd kan worden. Om nu te voorkomen dat de verzender van het bericht de vrijheid heeft te verwijzen naar een willekeurig XML Schema op een willekeurige locatie, is het verplicht om bij de implementatie van iedere afzonderlijke gegevensuitwisseling ervoor te zorgen dat tegen een vooraf vastgesteld en op een specifieke locatie geplaatst SuwiML berichtschema wordt gevalideerd. Dit ongeacht de verwijzing in het xsi:schemalocation statement in het bericht. Parsers die inkomende berichten automatisch verwerken moeten de verwijzing in het xsi:schemalocation statement dus feitelijk negeren, en gebruik maken van het vooraf vastgestelde en op een specifieke locatie geplaatste SuwiML berichtschema. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 12 van 103

13 3. SuwiML basisschema 3.1. Inleiding Het SuwiML basisschema wordt direct afgeleid uit het SGR en bestaat uit een verzameling 'standaard componenten' op basis waarvan SuwiML berichtschema s worden gedefinieerd. Het SuwiML basisschema bestaat uit twee modulen: de gegevenstypen-module en de entiteiten-module (zie Figuur 5). Hierin worden alle SGR-attributen zoals Sofi-nummer en SGR-entiteiten zoals ClientSuwi gedefinieerd. De relaties tussen entiteiten worden niet in het SuwiML basisschema gedefinieerd, deze worden (met het SGR als uitgangspunt) voor ieder afzonderlijk berichttype vastgelegd in de Action en Reaction SuwiML berichtschema s. SuwiML basisschema Entiteiten-module SGRentiteiten-v0200-b01.xsd SuwiML-v0200-b01-Include-Coded.xsd SuwiML-v0200-b01-Include-Typed.xsd include Gegevenstypen-module SGRgegevenstypen-v0200-b01.xsd include CdAoKlasse-v0200-b01-Coded.xsd include include Coded or Typed per <type> CdAoKlasse-v0200-b01-Typed.xsd include Figuur 5: opbouw en onderlinge verhouding SuwiML basisschema modulen Gegevenstypen Het SGR is een gegevensmodel welke alle voor gemeenschappelijk gegevensgebruik in de Suwi keten relevante attributen, entiteiten en relaties bevat. Iedere entiteit in het SGR bevat een aantal attributen, ieder attribuut verwijst naar een domeindefinitie voor het waardenbereik. In de gegevenstypen-module zijn alle SGR domeindefinities als verzameling samengebracht. Ieder SGRattribuut uit de entiteiten-module verwijst naar een SGR domeindefinitie uit de gegevenstypenmodule. Dit type is simpel (een tekenreeks zoals SofiNr of een gecodeerd waardebereik zoals Geslacht) of complex (een structuur zoals StandaardBedr), al naar gelang de aard van de SGR domeindefinitie die eraan ten grondslag ligt. Simpele typen worden als XML simpletype in het basisschema opgenomen; complexe typen worden als XML complextype gedefinieerd. De entiteiten-module en de gegevenstypen-module vormen samen het SuwiML basisschema. De entiteiten-module maakt gebruik van de SGR domeindefinities vastgelegd in de gegevenstypenmodule. Zowel de entiteiten-module als de gegevenstypen-module worden beiden in één en dezelfde namespace gedefinieerd: Vanuit een SuwiML berichtschema wordt het SuwiML basisschema geïntegreerd met behulp van een Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 13 van 103

14 SuwiML basisschema-include-bestand: <BerichtNaam>-v<VersieMajor><VersieMinor>-b<Buildnr>- Include.xsd. Het SuwiML basisschema -include-bestand incorporeert de entiteiten-module en de gegevenstypen-module. Bij het opstellen van een SuwiML berichtschema mag het SuwiML basisschema (de entiteiten-module en de gegevenstypen-module) niet worden aangepast. Zie ook Figuur 5 en Figuur 10. Alle SGR domeindefinities in de gegevenstypen-module zijn direct of indirect gebaseerd op XML Schema datatypen (built-in types), zoals string, integer, decimal, date etc. De XML Schema datatypen (built-in types) zijn gedefinieerd in de XML Schema standaard. Deze worden niet apart gedefinieerd binnen de SuwiML schema s. <?xml version="1.0" encoding="utf-8"?>  <schema targetnamespace = " xmlns = " xmlns:sml = "  <simpletype name="aantaln2"> <restriction base="nonnegativeinteger"> <mininclusive value="0"/> <maxinclusive value="99"/> <totaldigits value="2"/> </restriction> </simpletype> <simpletype name="aantsvdagenarbeidsverleden"> <restriction base="nonnegativeinteger"> <mininclusive value="0"/> <maxinclusive value="52"/> <totaldigits value="2"/> </restriction> </simpletype> <simpletype name="abonneenr"> <restriction base="string"> <maxlength value="10"/> <pattern value="\d*"/> </restriction> </simpletype> <simpletype name="netnr"> <restriction base="string"> <maxlength value="5"/> <pattern value="\d*"/> </restriction> </simpletype> </schema> Figuur 6: voorbeeld van een onderdeel van de gegevenstypen-module. Figuur 6 toont een onderdeel van de gegevenstypen-module, waarin een aantal SGR domeindefinities worden gedefinieerd welke geen gecodeerd waardebereik hebben. De SGR domeindefinities Abonneenr en Netnr worden vastgelegd met behulp van XML simpletype definities, Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 14 van 103

15 welke worden gedefinieerd als built-in datatype string met pattern \d* en maxlength 10 respectievelijk 5. De SGR domeindefinities AantSvDagenArbeidsverleden en AantalN2 worden vastgelegd met behulp van XML simpletype definities, welke worden gedefinieerd als built-in datatype nonnegativeinteger met totaldigits 2, mininclusive 0 en maxinclusive 52 respectievelijk 99. <?xml version="1.0" encoding="utf-8"?>  <schema targetnamespace = " xmlns = " xmlns:sml = "  <simpletype name="geslacht"> <restriction base="string"> <enumeration value="0"> <annotation><documentation>onbekend</documentation></annotation> </enumeration> <enumeration value="1"> <annotation><documentation>mannelijk</documentation></annotation> </enumeration> <enumeration value="2"> <annotation><documentation>vrouwelijk</documentation></annotation> </enumeration> <enumeration value="9"> <annotation><documentation>niet gespecificeerd (het gegevenselement wordt niet gevoerd in de administratie)</documentation></annotation> </enumeration> </restriction> </simpletype> </schema> Figuur 7: voorbeeld van een onderdeel van de gegevenstypen-module: Geslacht-Coded.xsd. Figuur 7 toont een onderdeel van de gegevenstypen-module, waarin de SGR domeindefinitie voor Geslacht wordt gedefinieerd met een gecodeerd waardebereik. Geslacht wordt vastgelegd met behulp van een XML simpletype definitie, welke wordt gedefinieerd als built-in datatype string met daarop een restriction van enumerations 0, 1, 2 en 9, inclusief bijbehorende annotations. <?xml version="1.0" encoding="utf-8"?>  <schema targetnamespace = " xmlns = " xmlns:sml = "  <simpletype name="geslacht"> <restriction base="string"> <length value="1"/> <pattern value="\d*"/> </restriction> </simpletype> </schema> Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 15 van 103

16 Figuur 8: voorbeeld van een onderdeel van de gegevenstypen-module: Geslacht-Typed.xsd. Figuur 8 toont een alternatieve SGR domeindefinitie voor Geslacht, waarbij het gecodeerde waardebereik bewust achterwege is gelaten. Ook deze SGR domeindefinitie is onderdeel van de gegevenstypen-module. Bij gebruik van het SuwiML basisschema wordt steeds precies één van de twee SGR domeindefinities (Coded of Typed) gebruikt voor validatie. De Coded validatie laat exact en alleen het vooraf gedefinieerde gecodeerde waardebereik toe voor de betreffende SGR domeindefinitie. De Typed validatie is milder van aard en laat alle mogelijke waarden toe die voldoen aan de XML simpletype definitie voor de betreffende SGR domeindefinitie; hierbij zijn dus ook waarden toegestaan die niet noodzakelijk in het gecodeerde waardebereik vallen. In het voorbeeld hierboven voor Geslacht, zou bij gebruik van de Typed definitie ook de waarde 6 zijn toegestaan, hoewel deze niet voorkomt in het gecodeerde waardebereik Entiteiten In de entiteiten-module wordt iedere SGR-entiteit gedefinieerd als een complex type (XML complextype). De SGR-attributen behorend bij een SGR-entiteit worden als een XML sequence van optionele elementen binnen het desbetreffende XML complextype gedefinieerd. Zoals gezegd verwijst ieder SGR-attribuut daarbij naar een SGR domeindefinitie uit de gegevenstypen-module. In de entiteiten-module worden geen SGR-relaties vastgelegd. De entiteiten-module is dus feitelijk een opsomming van losse SGR-entiteiten. Relaties tussen entiteiten worden (met het SGR als uitgangspunt) op berichtniveau vastgelegd, i.e. relaties worden in de Action en Reaction SuwiML berichtschema s vastgelegd. Figuur 9 toont een onderdeel van de entiteiten-module, waarin de entiteiten Vreemdelingendocument en Ziektekostenverzekering middels XML complextypes zijn gedefinieerd. Te zien is hoe de entiteit Vreemdelingendocument feitelijk een uitbreiding (XML extension) is van de entiteit VisDocument. Verder is te zien dat het attribuut NrVreemdelingendocument gebruik maakt van de SGR domeindefinitie NummerAN30 uit de gegevenstypen-module. <?xml version="1.0" encoding="utf-8"?>  <schema targetnamespace = " xmlns = " xmlns:sml = "  <complextype name="visdocument"> <sequence> <element name="cdsrtvisdocument" type="sml:cdsrtvisdocument" minoccurs="0"/> <element name="cdlandvanuitgiftevisdocument" type="sml:landencdisoa2" minoccurs="0"/> </sequence> </complextype> <complextype name="vreemdelingendocument"> <complexcontent> <extension base="sml:visdocument"> Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 16 van 103

17 <sequence> <element name="cdsrtvreemdelingendocument" type="sml:cdsrtvreemdelingendocument" minoccurs="0"/> <element name="nrvreemdelingendocument" type="sml:nummeran30" minoccurs="0"/> <element name="dategeldigvreemdelingendocument" type="sml:datum" minoccurs="0"/> <element name="indarbeidtoegestaan" type="sml:stdindjn" minoccurs="0"/> <element name="indtewerkstelvergunningvereist" type="sml:stdindjn" minoccurs="0"/> <element name="indverlengingaangevraagd" type="sml:stdindnvt" minoccurs="0"/> </sequence> </extension> </complexcontent> </complextype> <complextype name="ziektekostenverzekering"> <sequence> <element name="verzekerdennr" type="sml:verzekerdennr" minoccurs="0"/> <element name="bedrpremieziektekostenverz" type="sml:standaardbedr" minoccurs="0"/> <element name="indaanvullendverzekerd" type="sml:stdindonb" minoccurs="0"/> <element name="bedrpremieaanvulziektekostenverz" type="sml:standaardbedr" minoccurs="0"/> </sequence> </complextype> </schema> Figuur 9: voorbeeld van een onderdeel van de entiteiten-module Hiërarchie De gegevenstypen-module en entiteiten-module bestaan uit een aantal XML Schema's. In Figuur 10 staat aangegeven hoe deze zich tot elkaar verhouden, en op welke wijze een berichtschema er gebruik van maakt. De entiteiten-module komt overeen met precies één XML Schema, te weten SGRentiteiten-v<VersieMajor><VersieMinor>-b<Buildnr>.xsd. Bij de gegevenstypen-module ligt de zaak complexer. action import UwvDossierPersoon-v0302-b07-EnvelopeAction.xsd SuwiML berichtschemaset SuwiML-v0200-Header.xsd reaction import UwvDossierPersoon-v0302-b07-EnvelopeReaction.xsd import UwvDossierPersoon-v0302-b07-BodyAction.xsd import UwvDossierPersoon-v0302-b07-Include.xsd import import UwvDossierPersoon-v0302-b07-BodyReaction.xsd SuwiML basisschema Entiteiten-module SGRentiteiten-v0200-b01.xsd include Gegevenstypen-module SGRgegevenstypen-v0200-b01.xsd include CdAoKlasse-v0200-b01-Coded.xsd include include Coded or Typed per <type> CdAoKlasse-v0200-b01-Typed.xsd include Figuur 10: opbouw en onderlinge verhouding SuwiML basisschema en SuwiML berichtschemaset. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 17 van 103

18 Gegevens kunnen naar diverse soorten SGR domeindefinities verwijzen. Naast de ongecodeerde domeindefinities gebaseerd op string, date, etc., al dan niet voorzien van een beperkend pattern, maxlength, etc., zijn er ook de gecodeerde domeindefinities op basis van XML enumerations. Deze XML enumerations beschrijven een lijst met specifieke codes (waarden) eventueel gecombineerd met een omschrijving. Een eenvoudig voorbeeld is de enumeration voor Geslacht, bestaande uit de codes 0, 1, 2 en 9, overeenkomend met de omschrijvingen Onbekend, Mannelijk, Vrouwelijk en Niet Gespecificeerd, zie Figuur 7. In dit voorbeeld is de lijst met codes statisch, i.e. hij wijzigt niet of nauwelijks. Er zijn echter ook dynamische codelijsten die vaak wijzigen. De structuur van de gegevenstypen-module is zodanig gekozen, dat codes kunnen wijzigen zonder de bijbehorende programmatuur te moeten herprogrammeren of herconfigureren. Het eenvoudigweg uploaden van de nieuwe codelijst moet volstaan om de programmatuur weer up-to-date te brengen. Iedere SGR domeindefinitie waarvoor een codelijst beschikbaar is, wordt vastgelegd in twee verschillende XML Schema varianten, een Coded en een Typed schema. De Coded variant beschrijft de domeindefinitie als een specifieke XML enumeration van codewaarden en codeomschrijvingen, waardoor een "strenge" validatie mogelijk is; Figuur 7 geeft een voorbeeld. De Typed variant beschrijft dezelfde domeindefinitie slechts als een pattern, waardoor een milde validatie mogelijk is, waarbij niet bestaande codes die wel binnen de type- en patterndefinitie passen, geen foutmelding opleveren; Figuur 8 geeft een voorbeeld. De keus voor Coded of Typed is afhankelijk van de toepassing, en wordt per SuwiML berichtschema vastgelegd in een apart <BerichtNaam>-v<VersieMajor><VersieMinor>-b<Buildnr>-Include.xsd schema, welke wordt afgeleid van één van de template schema s: SuwiML-v<VersieMajor><VersieMinor>-b<Buildnr>-Include-Coded.xsd of SuwiML-v<VersieMajor><VersieMinor>-b<Buildnr>-Include-Typed.xsd. Binnen het afgeleide berichtspecifieke include schema kan voor elke afzonderlijke domeindefinitie (waarvoor een codelijst beschikbaar is), gekozen worden of er gebruik wordt gemaakt van de Coded of Typed variant. De keuze voor het gebruik van Coded en/of Typed kan dus per berichttype verschillen. In het meest extreme geval wordt voor het ene berichttype alleen gebruik gemaakt van Coded en voor het andere berichttype alleen van Typed. Wat betreft de keuze voor Coded en/of Typed zijn twee strategieën denkbaar: 1. Zoveel mogelijk gebruik maken van de Coded variant; het berichtschema dwingt bij de validatie van berichten door de verzendende/ontvangende adapter de specifieke codewaarden af conform het SGR. Hiermee wordt de verwerking in de verzendende/ontvangende applicatie feitelijk ontlast, omdat daar dan zonder verdere controle mag worden aangenomen dat aan het vereiste codewaardebereik is voldaan. Voordeel van deze strategie is, dat er alleen gegarandeerd goede berichten worden verzonden/ontvangen en dat deze garantie reeds op adapternivo wordt afgedwongen. Nadeel van deze strategie is, dat bij aanpassingen van de aan het berichttype gerelateerde codelijsten, het berichtschema ook moet worden aangepast en in een nieuwe versie moet worden gepubliceerd en geïmplementeerd. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 18 van 103

19 2. Zoveel mogelijk gebruik maken van de Typed variant; het berichtschema dwingt bij de validatie van berichten door de verzendende/ontvangende adapter slechts het formaat af conform het SGR. Hiermee kan dus niet worden gegarandeerd dat ieder verzonden/ontvangen bericht alleen geldige codewaarden conform het SGR bevat. Hiermee wordt de verwerking in de verzendende/ontvangende applicatie feitelijk extra belast, omdat daar dan moet worden gecontroleerd of aan het vereiste codewaardebereik is voldaan. Voordeel van deze strategie is, dat bij aanpassingen van de aan het berichttype gerelateerde codelijsten, het berichtschema niet noodzakelijk hoeft te worden aangepast. Nadeel van deze strategie is, dat de applicaties zodanig moeten worden geconfigureerd, dat ze altijd aan de meest actuele set van codewaardebereiken voldoen. Bij de samenstelling en/of verwerking van berichten door de applicatie moet het codewaardebereik worden afgedwongen. Naar verwachting vindt in de toekomst de berichtuitwisseling plaats op basis van de Typed variant (strategie 2) en vindt de validatie tegen het codewaardebereik plaats in de diverse applicaties. Hiermee wordt de stabiliteit van de (operationele) elektronische ketenberichten bevorderd, hetgeen voordelen oplevert voor de beheerlast en implementatielast van berichtspecificaties. Het actueel houden van de codewaardebereiken binnen de applicaties vindt zoveel als mogelijk automatisch plaats door het inlezen van de nieuwste versie van het SuwiML basisschema Automatisch tabellenbeheer Omdat in de praktijk de gecodeerde waardebereiken van bepaalde SGR domeindefinities regelmatig wijzigen, moet ook het SuwiML basisschema hierop regelmatig worden aangepast. Voor het vastleggen van het SuwiML basisschema is een structuur bedacht, die het mogelijk maakt om volledig geautomatiseerd het SuwiML basisschema (of gerichte delen daarvan) te updaten. Deze structuur staat in sectie 3.4 beschreven en wordt vastgelegd in meerdere losse b estanden: SGRentiteiten-v<VersieMajor><VersieMinor>-b<Buildnr>.xsd Een alfabetische opsomming van alle SGR entiteiten en gegevenselementen (attributen), vastgelegd in een XML Schema. SGRgegevenstypen-v<VersieMajor><VersieMinor>-b<Buildnr>.xsd Een alfabetische opsomming van alle SGR domeindefinities waarvoor géén gecodeerd waardebereik bestaat, vastgelegd in een XML Schema. <Domeintag>-v<VersieMajor><VersieMinor>-b<Buildnr>-Coded.xsd Een apart XML Schema voor iedere SGR domeindefinitie waarvoor een gecodeerd waardebereik bestaat. Alle geldige codes zijn als XML enumerations gespecificeerd inclusief bijbehorende omschrijving. <Domeintag>-v<VersieMajor><VersieMinor>-b<Buildnr>-Typed.xsd Een apart XML Schema voor iedere SGR domeindefinitie waarvoor een gecodeerd waardebereik bestaat. Er wordt geen gebruik gemaakt van XML enumerations voor alle geldige codes, maar slechts van een beperkte formaatdefinitie waarin de toegestane lengte en karakters worden vastgelegd. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 19 van 103

20 <Domeintag>-v<VersieMajor><VersieMinor>-b<Buildnr>.xml Een aparte XML instance voor iedere SGR domeindefinitie waarvoor een gecodeerd waardebereik bestaat. Alle geldige codes zijn als waarden gespecificeerd inclusief bijbehorende omschrijving. Bovendien wordt hier per code vastgelegd wat de datum begin geldigheid en datum einde geldigheid is. Zoals gezegd worden alle onderdelen van het SuwiML basisschema vastgelegd in één en dezelfde namespace. Met behulp van het include bestand worden de afzonderlijke XML Schema onderdelen middels XML include statements ingelezen. Daarbij wordt voor iedere SGR domeindefinitie waarvoor een gecodeerd waardebereik bestaat, steeds een keuze gemaakt of er gebruik wordt gemaakt van Coded.xsd (strikte validatie tegen de feitelijk toegestane codes) of van Typed.xsd (slechts beperkte/milde validatie tegen de formaatdefinitie). Bovendien kan de verzameling XML instances, voor SGR domeindefinities met een gecodeerd waardebereik, met behulp van een tabelindex (SGRtabelindex-v<VersieMajor><VersieMinor>b<Buildnr>.xml), met verwijzingen naar de actuele bestandsnamen van deze XML instances, geautomatiseerd ingelezen worden door een applicatie. Op deze wijze is een applicatie dus altijd verzekerd van de meest actuele verzameling SGR tabellen/codelijsten. In combinatie met de hier beschreven tabelindex is ook een overzicht van SGR domeinverwijzingen (SGRdomeinverwijzingen-v<VersieMajor><VersieMinor>-b<Buildnr>.xml) beschikbaar. Het SGR domeinverwijzingen overzicht geeft per SGR gegevenselement (attribuut) aan van welke SGR domeindefinitie, inclusief aanduiding <VersieMajor><VersieMinor>, gebruik wordt gemaakt. In de beschreven structuur, leidt de toevoeging van een code aan het gecodeerde waardebereik van een SGR domeindefinitie dus slechts tot een nieuwe versie van het bijbehorende Coded.xsd bestand, de bijbehorende XML instance en het include bestand. De tabelindex wordt in lijn hiermee geactualiseerd en de domeinverwijzingen eventueel ook als de wijziging tot een nieuwe <VersieMajor><VersieMinor> leidt. SuwiML berichtschema s kunnen op een vergelijkbare manier als applicaties gebruik maken van de beschreven structuur van het SuwiML basisschema. Het idee hierbij is dat een bepaalde versie van een SuwiML berichtschema gebruik maakt van een bepaalde versie (freeze) van het SuwiML basisschema. Eventuele aanpassingen in het SuwiML basisschema worden dus pas in een volgende versie van het SuwiML berichtschema toegepast/gebruikt. De hier beschreven structuur voor het SuwiML basisschema moet er toe leiden dat de meest actuele set van bestanden waarin het SuwiML basisschema is vastgelegd, steeds on-line beschikbaar is. Alle (applicatiebeheerders van) ketenpartners kunnen nu op ieder gewenst moment het SuwiML basisschema of gerichte onderdelen daarvan, downloaden en binnen de eigen operationele omgeving implementeren. Hiermee kan het proces van het publiceren van SuwiML basisschema updates door het BKWI en het controleren, downloaden en installeren van deze updates door ketenpartners geautomatiseerd worden. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 20 van 103

21 3.6. Versienummering Indien voor een SGR domeindefinitie een code wordt toegevoegd, of een andere wijziging wordt doorgevoerd, dan heeft dit gevolgen voor de versienummering van het SuwiML basisschema. Tabel 2 geeft een overzicht van alle mogelijke wijzigingen en de consequenties voor de versienummering van het SuwiML basisschema. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 21 van 103

22 Soort wijziging SuwiML basisschema SuwiML-Include-Typed SuwiML-Include-Coded SGRentiteiten SGRgegevenstypen TypeX-Typed TypeX-Coded TypeY-Typed TypeY-Coded Initieel v0100-b01 v0100-b01 v0100-b01 v0100-b01 v0100-b01 v0100-b01 v0100-b01 v0100-b01 v0100-b01 Er wordt een code toegevoegd aan TypeX v0100-b02 v0100-b01 v0100-b02 v0100-b01 v0100-b01 v0100-b01 v0100-b02 v0100-b01 v0100-b01 Er wordt een code toegevoegd aan TypeY v0100-b03 v0100-b01 v0100-b03 v0100-b01 v0100-b01 v0100-b01 v0100-b02 v0100-b01 v0100-b03 Pattern [a-z] in TypeY wordt [a-z0-9] v0100-b04 v0100-b04 v0100-b03 v0100-b01 v0100-b01 v0100-b01 v0100-b02 v0100-b04 v0100-b03 Maximale lengte van TypeX wordt teruggebracht van 2 naar 1 positie v0101-b01 v0101-b01 v0101-b01 v0101-b01 v0101-b01 v0101-b01 v0101-b01 v0101-b01 v0101-b01 Er wordt een code toegevoegd aan TypeX v0101-b02 v0101-b01 v0101-b02 v0101-b01 v0101-b01 v0101-b01 v0101-b02 v0101-b01 v0101-b01 Pattern [a-z0-9] in TypeY wordt [a-z] v0102-b01 v0102-b01 v0102-b01 v0102-b01 v0102-b01 v0102-b01 v0102-b01 v0102-b01 v0102-b01 Er wordt een code toegevoegd aan TypeX v0102-b02 v0102-b01 v0102-b02 v0102-b01 v0102-b01 v0102-b01 v0102-b02 v0102-b01 v0102-b01 Grote structurele wijziging in Entiteiten/Attributen v0200-b01 v0200-b01 v0200-b01 v0200-b01 v0200-b01 v0200-b01 v0200-b01 v0200-b01 v0200-b01 Tabel 2: voorbeeldscenario van een aantal wijzigingen en de consequenties daarvan irt versienummers. De regels zijn in het kort als volgt. Als een domeindefinitie, attribuut of entiteit wordt gewijzigd, dan verandert ook het versienummer (versie major, versie minor en/of buildnummer) van het basisschema; Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 22 van 103

23 Als het waardebereik van de domeindefinities in het nieuwe basisschema (na het doorvoeren van de wijziging) het waardebereik van de domeindefinities in het oude basisschema (voor het doorvoeren van de wijziging) volledig bevat, dan wordt het buildnummer van het basisschema met één opgehoogd en wordt het buildnummer van het subschema waarin de betreffende domeindefinitie is opgenomen gelijkgesteld aan die van het basisschema. Alle andere subschema s blijven ongewijzigd en behouden het reeds geldende buildnummer. Voorbeelden zijn het toevoegen van een code, het beëindigen van de geldigheid van een code (waarbij de code dus niet wordt verwijderd), het uitbreiden van een pattern, het vergroten van de maxlength, het verlagen van de minoccurs en het verhogen van de maxoccurs. Ook het aanpassen van de omschrijving behorend bij een reeds bestaande code, resulteert in het ophogen van het buildnummer (mits de aangepaste omschrijving qua betekenis gelijk blijft aan de oorspronkelijke omschrijving); Als het waardebereik van de domeindefinities in het nieuwe basisschema (na het doorvoeren van de wijziging) het waardebereik van de domeindefinities in het oude basisschema (voor het doorvoeren van de wijziging) niet volledig bevat, dan verandert de versie minor van alle files. Alle buildnummers worden dan op 01 teruggezet. Voorbeelden zijn het verkleinen van de maxlength, het verlagen van de maxoccurs, het verhogen van de minoccurs, het beperken van een pattern, het wijzigen van de length, het verwijderen van een code of het aanpassen van de betekenis (omschrijving) van een code. Ook het veranderen van de naam van een entiteit of attribuut resulteert in het ophogen van de versie minor en het resetten van het buildnummer naar 01 ; Grote wijzigingen, zoals het qua betekenis en opbouw herdefiniëren van entiteiten en attributen, leiden tot een wijziging van de versie major. Alle versie minor en buildnummers worden dan op 01 teruggezet. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 23 van 103

24 4. SuwiML berichtschema 4.1. Inleiding Een SuwiML bericht wordt in een SOAP envelope verstuurd. Onderdeel van deze SOAP envelope zijn een header en een body. De header legt de stuurgegevens vast die van belang zijn voor de routering en de logistieke verwerking van het bericht. De body bevat de functionele inhoud die moet worden uitgewisseld. De SOAP envelope en SuwiML header worden beschreven in de SuwiML transactiestandaard. De SuwiML body wordt hier beschreven. Voor de theoretische onderbouwing van de berichtontwikkelingsmethodiek biedt hoofdstuk 5 uitkomst, in het bijzonder sectie SuwiML body Structuur Ieder SuwiML bericht dat wordt verzonden, is gerelateerd aan een SuwiML berichtschemaset. Een SuwiML berichtschemaset bestaat uit een SuwiML berichtschema voor het Action bericht en een SuwiML berichtschema voor het Reaction bericht. Een SuwiML berichtschema bestaat uit een SOAP envelopeschema dat een SuwiML headerschema en een SuwiML bodyschema importeert; zie Figuur 1, Figuur 11 en Figuur 13. Een SuwiML bodyschema beschrijft exact hoe de body van een specifiek berichttype wordt opgebouwd; zie Tabel 3, Figuur 12 en Figuur 14. Schema Bestand, Tag en Namespace SOAP envelope Action <BerichtNaam>-v<VersieMajor><VersieMinor>-b<Buildnr>-Envelope<Interaction>.xsd bijv.: UwvDossierPersoon-v0302-b07-EnvelopeAction.xsd <SOAP-ENV:Envelope> Reaction <BerichtNaam>-v<VersieMajor><VersieMinor>-b<Buildnr>-Envelope<Interaction>.xsd bijv.: UwvDossierPersoon-v0302-b07-EnvelopeReaction.xsd <SOAP-ENV:Envelope> SuwiML header Action SuwiML-v<VersieMajor><VersieMinor>-Header.xsd Reaction bijv.: SuwiML-v0200-Header.xsd <SOAP-ENV:Envelope> <SOAP-ENV:Header> <smlh:suwimlheader> bijv.: Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 24 van 103

25 Schema SuwiML body Action Bestand, Tag en Namespace <BerichtNaam>-v<VersieMajor><VersieMinor>-b<Buildnr>-Body<Interaction>.xsd bijv.: UwvDossierPersoon-v0302-b07-BodyAction.xsd <BerichtNaam>-v<VersieMajor><VersieMinor>-b<Buildnr>-Include.xsd bijv.: UwvDossierPersoon-v0302-b07-Include.xsd <SOAP-ENV:Envelope> <SOAP-ENV:Body> <smlb:suwimlbody> bijv.: Reaction <BerichtNaam>-v<VersieMajor><VersieMinor>-b<Buildnr>-Body<Interaction>.xsd bijv.: UwvDossierPersoon-v0302-b07-BodyReaction.xsd <BerichtNaam>-v<VersieMajor><VersieMinor>-b<Buildnr>-Include.xsd bijv.: UwvDossierPersoon-v0302-b07-Include.xsd <SOAP-ENV:Envelope> <SOAP-ENV:Body> <smlb:suwimlbody> bijv.: Tabel 3: opbouw SuwiML berichtschemaset. Gedurende het ontwikkelingstraject van een berichttype wordt de VersieMajor en de VersieMinor van de betreffende berichtschemaset zoveel mogelijk ongemoeid gelaten. Dit heeft als voordeel dat de namespaces voor de betreffende berichtschemaset ook stabiel blijven. Wijzigingen in de berichtspecificatie, i.e. in de berichtschemaset, worden opgevangen met behulp van het Buildnr; deze hoogt bij iedere wijziging steeds met één op. Zodra een berichtschemaset in productie wordt genomen, wordt de VersieMajor, de VersieMinor en het Buildnr gefixeerd ( bevroren ). Eventuele aanpassingen die daarna volgen, maken automatisch deel uit van een nieuw ontwikkelingstraject waaraan een nieuwe combinatie VersieMajor, VersieMinor wordt gerelateerd. In het algemeen geldt dus dat iedere functionele wijziging in de specificatie van een berichttype, die leidt tot een aanpassing van één of meer van de XML Schema s waaruit de berichtschemaset is opgebouwd, ook automatisch leidt tot een nieuwe build-/versieaanduiding voor de gehele berichtschemaset. Dus zelfs als bijvoorbeeld alleen het Action deel van een berichtschemaset moet worden aangepast, dan krijgt toch de gehele berichtschemaset een nieuwe build-/versieaanduiding. <?xml version="1.0" encoding="utf-8"?> <schema targetnamespace = " xmlns = " xmlns:smlb = " xmlns:smlh = " xmlns:soap-env = " elementformdefault = "qualified">  <import namespace=" schemalocation="suwiml-v0200-header.xsd"/>  Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 25 van 103

26 <import namespace=" schemalocation="uwvdossierpersoon-v0302-b07-bodyaction.xsd"/>  <element name="envelope" type="soap-env:envelope"/> <complextype name="envelope"> <sequence> <element name="header" type="soap-env:header"/> <element name="body" type="soap-env:body"/> </sequence> </complextype> <complextype name="header"> <sequence> <element ref="smlh:suwimlheader">  </element> </sequence> </complextype> <complextype name="body"> <sequence> <element ref="smlb:suwimlbody">  </element> </sequence> </complextype> </schema> Figuur 11: SOAP envelopeschema van een SuwiML Action berichtschema. Een XML Schema definieert een rootelement en haar subelementen. Het rootelement van het SuwiML bodyschema is altijd <SuwiMLBody>. Figuur 12, Figuur 14 en Tabel 4 tonen welke subelementen binnen het <SuwiMLBody> rootelement kunnen voorkomen. Welk subelement in een bepaalde situatie voor mag komen hangt af van en correspondeert met het interactietype (Action of Reaction) en het CommunicatieType en het CommunicatieElement in de SuwiML header. Figuur 12: SOAP envelopestructuur van een SuwiML Action berichtschema. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 26 van 103

27 <?xml version="1.0" encoding="utf-8"?> <schema targetnamespace = " xmlns = " xmlns:smlb = " xmlns:smlh = " xmlns:soap-env = " elementformdefault = "qualified">  <import namespace=" schemalocation="suwiml-v0200-header.xsd"/>  <import namespace=" schemalocation="uwvdossierpersoon-v0302-b07-bodyreaction.xsd"/>  <element name="envelope" type="soap-env:envelope"/> <complextype name="envelope"> <sequence> <element name="header" type="soap-env:header"/> <element name="body" type="soap-env:body"/> </sequence> </complextype> <complextype name="header"> <sequence> <element ref="smlh:suwimlheader">  </element> </sequence> </complextype> <complextype name="body"> <choice> <element name="fault" type="soap-env:fault">  </element> <element ref="smlb:suwimlbody">  </element> </choice> </complextype>  <complextype name="fault" final="extension"> <sequence> <element name="faultcode" type="qname"/> <element name="faultstring" type="string"/> <element name="faultactor" type="anyuri" minoccurs="0"/> <element name="detail" type="soap-env:detail" minoccurs="0"/> </sequence> </complextype> <complextype name="detail"> <sequence> Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 27 van 103

28 <element ref="smlb:fout" maxoccurs="unbounded">  </element> </sequence> </complextype> </schema> Figuur 13: SOAP envelopeschema van een SuwiML Reaction berichtschema. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 28 van 103

29 Figuur 14: SOAP envelopestructuur van een SuwiML Reaction berichtschema. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 29 van 103

30 CommunicatieType CommunicatieElement SuwiMLBody Opmerking Inkijk Melding (Action) Request Request Een Request betreft een verzoek om gegevens dan wel een verzoek tot verwerking van gegevens. In het geval van een verzoek om gegevens, bevat een Request de sleutelinformatie die benodigd is om een bepaalde vraag te kunnen beantwoorden. Bijvoorbeeld: een sofi-nummer indien er gevraagd wordt om het dossier van een client. Inkijk (Reaction) Response Response Warning Een Response bevat de middels een Request opgevraagde gegevens. Bijvoorbeeld: een ClientSuwi met alle daaraan gerelateerde gegevens, indien er gevraagd werd om het dossier van een client. Wanneer zich, bij de verwerking van een Request, een bijzondere vermeldenswaardige situatie in de applicatielaag voordoet, wordt een Warning verstuurd. NB. bij een Warning gaat het niet om een foutsituatie in de applicatielaag, maar om een foutloze verwerking van een Request, waarbij de geleverde gegevens in de Response op zich juist zijn, maar vergezeld worden van een waarschuwing. Bijvoorbeeld dat de persoon in kwestie is overleden of geëmigreerd. NB. een Warning wordt altijd verstuurd in combinatie met een Response. Het opnemen van een Warning bij de Response is optioneel. Inkijk (Reaction) Fout Response Fault Warning Wanneer zich, bij de verwerking van een Request, een functionele fout in de applicatielaag voordoet, wordt een Fault verstuurd. NB. het gaat hier niet om foutmeldingen uit de berichtlaag of transportlaag, want die worden middels SOAP en/of HTTP afgehandeld (zie ook de SuwiML transactiestandaard). NB. een Fault wordt altijd verstuurd in combinatie met een lege/gedeeltelijke Response. Het opnemen van een Warning bij de Fault en lege/gedeeltelijke Response is optioneel. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 30 van 103

31 CommunicatieType CommunicatieElement SuwiMLBody Opmerking Inkijk Melding (Reaction) Redirect Redirect Een Redirect bevat een verwijzing naar één of meer alternatieve diensten welke in staat zijn de oorspronkelijke Request te beantwoorden. Melding (Reaction) Voorbeelden Acknowledgement Acknowledge ment Is vooral bruikbaar indien er sprake is van gegevensuitwisseling over een asynchrone transportlaag. Tabel 4: mogelijke combinaties van subelementen binnen het SuwiMLBody rootelement (onvermelde combinaties zijn niet mogelijk). Figuur 15 geeft een voorbeeld SuwiML bodyschema voor de Action. Het schema importeert eerst het SuwiML basisschema, middels het berichtspecifieke include schema. Vervolgens wordt het rootelement SuwiMLBody gedefinieerd, dat bestaat uit een Request. <?xml version="1.0" encoding="utf-8"?> <schema targetnamespace = " xmlns = " xmlns:sml = " xmlns:smlb = "  <import namespace=" schemalocation="uwvdossierpersoon-v0302-b07-include.xsd"/>  <element name="suwimlbody" type="smlb:suwimlbody"/> <complextype name="suwimlbody"> <sequence> <element name="request" type="smlb:request"/> </sequence> </complextype>  <complextype name="request"> <sequence> <element name="sofinr" type="sml:sofinr"/> </sequence> </complextype> </schema> Figuur 15: voorbeeld SuwiML Action bodyschema. Figuur 16 geeft een voorbeeld SuwiML bodyschema voor de Reaction. Het schema importeert eerst het SuwiML basisschema, middels het berichtspecifieke include schema. Vervolgens wordt het rootelement SuwiMLBody gedefinieerd, dat bestaat uit een keuze (XML choice) tussen een Redirect een Response of een Acknowledgement, waarbij een Response eventueel vergezeld kan gaan door een Fault en/of Warning. De Response bestaat uit precies één optioneel subelement ClientSuwi. Dit Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 31 van 103

32 element heeft (verplicht) dezelfde naam als de SGR-entiteit (XML complextype) waaraan het refereert. Het subelement ClientSuwi heeft vervolgens hiërarchische relaties met TelefoonnrClient en Ziektekostenverzekering. <?xml version="1.0" encoding="utf-8"?> <schema targetnamespace = " xmlns = " xmlns:sml = " xmlns:smlb = "  <import namespace=" schemalocation="uwvdossierpersoon-v0302-b07-include.xsd"/>  <element name="suwimlbody" type="smlb:suwimlbody"/> <complextype name="suwimlbody"> <choice> <element name="redirect" type="smlb:redirect"/> <sequence> <element name="response" type="smlb:response"/> <element name="fault" type="smlb:fault" minoccurs="0"/> <element name="warning" type="smlb:warning" minoccurs="0"/> </sequence> <element name="acknowledgement" type="smlb:acknowledgement"/> </choice> </complextype>  <complextype name="redirect"> <sequence> <element name="expiresafterseconds" type="nonnegativeinteger" minoccurs="0"/> <choice> <element name="compoundservice" type="smlb:compoundservice"/> <element name="alternativeserviceset" type="smlb:alternativeserviceset"/> <element name="service" type="smlb:service"/> </choice> </sequence> </complextype> <complextype name="alternativeserviceset">... </complextype> <complextype name="compoundservice">... </complextype> <complextype name="service">... </complextype>  <complextype name="response"> <sequence> <element name="clientsuwi" minoccurs="0"> <complextype><complexcontent> <extension base="sml:clientsuwi"> <sequence> <element name="telefoonnrclient" type="sml:standaardtelefoonnr" minoccurs="0" maxoccurs="unbounded"/> Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 32 van 103

33 <element name="ziektekostenverzekering" type="sml:ziektekostenverzekering" minoccurs="0"/> </sequence> </extension> </complexcontent></complextype> </element> </sequence> </complextype>  <complextype name="fault"> <sequence> <element name="fout" type="smlb:fout" maxoccurs="unbounded"/> </sequence> </complextype> <element name="fout" type="smlb:fout"/> <complextype name="fout">... </complextype>  <complextype name="warning"> <sequence> <element name="waarschuwing" type="smlb:waarschuwing" maxoccurs="unbounded"/> </sequence> </complextype> <complextype name="waarschuwing">... </complextype>  <complextype name="acknowledgement"> <sequence/> </complextype> </schema> Figuur 16: voorbeeld SuwiML Reaction bodyschema. Figuur 17 geeft een uitgewerkt voorbeeld van het body gedeelte van een SuwiML bericht. Het betreft een response, waarin gegevens zijn opgenomen aangaande een enkele ClientSuwi. Dit omvat onder meer een sofinummer, geslacht, telefoonnummer en een ziektekostenverzekering. Alle data zijn fictief. <?xml version="1.0" encoding="utf-8"?> <SOAP-ENV:Envelope xmlns:soap-env = " xmlns:smlh = " xmlns:smlb = " xmlns:xsi = " xsi:schemalocation = " UwvDossierPersoon-v0302-b07-EnvelopeReaction.xsd"> <SOAP-ENV:Header> <smlh:suwimlheader>... </smlh:suwimlheader> </SOAP-ENV:Header> <SOAP-ENV:Body> Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 33 van 103

34 <smlb:suwimlbody> <Response> <ClientSuwi> <SofiNr> </SofiNr> <Voornamen>Jan</Voornamen> <Voorletters>J</Voorletters> <SignificantDeelVanDeAchternaam>Jansen</SignificantDeelVanDeAchternaam> <Geboortedat> </Geboortedat> <Geslacht>1</Geslacht> <CdNationaliteit>0001</CdNationaliteit> <TelefoonnrClient> <Netnr>020</Netnr> <Abonneenr> </Abonneenr> </TelefoonnrClient> <Ziektekostenverzekering> <Zorgverzekeraar> <NaamZorgverzekeraarVerkort>Amicon</NaamZorgverzekeraarVerkort> <CdSrtZorgverzekeraar>0</CdSrtZorgverzekeraar> </Zorgverzekeraar> </Ziektekostenverzekering> </ClientSuwi> </Response> </smlb:suwimlbody> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Figuur 17: voorbeeld SuwiML Reaction response bericht. Een SuwiML bericht voldoet altijd aan een SuwiML berichtschema, waarnaar wordt verwezen vanuit het rootelement <SOAP-ENV:Envelope>. Een SuwiML berichtschema bestaat uit entiteiten, attributen en domeindefinities zoals vastgelegd in het SuwiML basisschema, en berichtspecifieke relaties tussen entiteiten, die waar mogelijk gebaseerd worden op de relaties zoals vastgelegd in het SGR. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 34 van 103

35 Lege velden / waarden in een SuwiML bericht In het geval de verzender van een SuwiML berichtinstantie voor bepaalde velden in het bericht geen waarde beschikbaar heeft, kunnen zich de volgende situaties voordoen: SuwiML berichtschema veld is optioneel veld is verplicht SuwiML berichtinstantie waarde beschikbaar In het geval een veld optioneel is volgens het SuwiML berichtschema en er is een waarde beschikbaar, dan moet dit veld in het bericht opgenomen worden met een geldige waarde. Het veld mag dan dus niet achterwege blijven. NB. een ongeldige waarde zal vanzelfsprekend tot een foutmelding leiden bij de samenstelling en validatie van het bericht. In het geval een veld verplicht is volgens het SuwiML berichtschem a, dan moet dit veld altijd in het bericht opgenomen worden met een geldige waarde. Het veld mag dan dus in geen geval achterwege blijven. NB. een ongeldige waarde zal vanzelfsprekend tot een foutmelding leiden bij de samenstelling en validatie van het bericht. SuwiML berichtinstantie geen waarde beschikbaar In het geval een veld optioneel is volgens het SuwiML berichtschema en er is geen waarde beschikbaar, dan moet dit veld in het bericht achterwege blijven. Het veld mag dan dus niet met een open- en close-tag worden opgenomen zonder feitelijke waarde. In het geval een veld verplicht is volgens het SuwiML berichtschema, dan moet dit veld altijd in het bericht opgenomen worden met een geldige waarde. Het veld mag dan dus in geen geval achterwege blijven. NB. het ontbreken (niet beschikbaar zijn) van een geldige waarde zal vanzelfsprekend tot een foutmelding leiden bij de samenstelling en validatie van het bericht. NB. als voor dit veld in het SGR een waarde is gedefinieerd die aangeeft dat het veld leeg/onbekend is, dan dient bij het ontbreken (niet beschikbaar zijn) van een geldige waarde, deze indicatie "leeg/onbekend" te worden gebruikt in het bericht, bijvoorbeeld bij "Geslacht" de waarde "0" indien "onbekend". Tabel 5: beperkingen tav het gebruik van lege velden / waarden in een SuwiML bericht. In het algemeen geldt dat wat ook in een SuwiML berichtinstantie wordt gestopt, het altijd, ook bij foutsituaties, moet voldoen aan het bijbehorende SuwiML berichtschema. De zender heeft de verplichting dit te garanderen, de ontvanger moet dit controleren. Afleiden berichtschema uit basisschema Een SuwiML berichtschema is samengesteld uit drie gerelateerde XML Schema s: een SOAP envelopeschema, een SuwiML headerschema en een SuwiML bodyschema. Het SuwiML bodyschema maakt via het berichtspecifieke include schema direct gebruik van de XML Schema's van het SuwiML basisschema. De SGR-entiteiten (XML complextype) in het SuwiML basisschema Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 35 van 103

36 vormen dus op deze wijze de basis voor het samenstellen van een SuwiML berichtschema. Zie Figuur 10. Het SuwiML basisschema vormt het uitgangspunt voor de definitie van SuwiML berichtschema s. Dat wil niet zeggen dat wanneer in een bericht gegevens worden opgenomen over bijvoorbeeld een Partner, verplicht de complete definitie van Partner uit het SuwiML basisschema moet worden overgenomen. Alleen die gegevens die binnen het SuwiML basisschema over een Partner zijn vastgelegd én werkelijk van belang zijn voor het bericht, worden in het SuwiML berichtschema opgenomen. Dit geldt voor de entiteiten, de attributen en de relaties uit het SGR. Figuur 18 geeft aan op welke wijze de berichthiërarchie voor een SuwiML berichtschema wordt opgebouwd aan de hand van het SGR en het SuwiML basisschema. Ieder SuwiML berichtschema gebruikt het SGR en het SuwiML basisschema als uitgangspunt. Iedere relatie, entiteit of attribuut uit het SGR / het SuwiML basisschema wordt in een SuwiML berichtschema 1-op-1 overgenomen door middel van een directe referentie naar het SuwiML basisschema, of wordt verbijzonderd voor het betreffende berichttype. Verbijzonderen betekent dat: optionele entiteiten of attributen in het SGR / het SuwiML basisschema, in het SuwiML berichtschema verplicht mogen worden gemaakt of mogen worden weggelaten; verplichte entiteiten of attributen in het SGR / het SuwiML basisschema, in het SuwiML berichtschema niet mogen worden weggelaten en niet optioneel mogen worden gemaakt; herhaalbare entiteiten (1:n relaties) mogen worden beperkt in hun herhaalbaarheid, bijvoorbeeld maxoccurs= unbounded beperken tot maxoccurs= 10 of maxoccurs= 1 ; entiteiten (relaties) niet mogen worden uitgebreid in hun herhaalbaarheid, dus niet van maxoccurs= 1 naar maxoccurs= 10 ; het waardebereik van attributen mag worden beperkt tot een subset van het toegestane waardebereik zoals is gedefinieerd in het SGR; geen nieuwe attributen, entiteiten of hiërarchische relaties mogen worden toegevoegd, dus geen uitbreidingen ten opzichte van het SGR en het SuwiML basisschema. NB. mocht er tijdens het berichtontwikkelingstraject de functionele behoefte bestaan om nieuwe entiteiten of attributen op te nemen welke nog niet gedefinieerd en vastgelegd zijn in het SGR, dan wordt dit (in bepaalde gevallen) toegestaan, onder het voorbehoud dat deze entiteiten/attributen via een CMK (Centraal Meldpunt Ketenwijzigingen) wijzigingsverzoek worden aangemeld voor definitie en vastlegging in het SGR en het SuwiML baisschema. Een dergelijk CMK wijzigingsverzoek wordt behandeld door de Werkgroep Gegevensbeheer (WGB). Het opnemen van de nieuwe entiteiten of attributen gebeurt dus onder het voorbehoud van goedkeuring door de WGB. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 36 van 103

37 veralgemeniseren Suwi Gegevensregister SuwiML basisschema afleiden Transactie hiërarchie afleiden Bericht hiërarchie verbijzonderen Figuur 18: opbouw berichthiërarchie op basis van het SGR / het SuwiML basisschema. In principe wordt in een SuwiML berichtschema dus altijd verwezen naar de XML complextype definities uit het SuwiML basisschema. In het geval dat voor een specifiek berichttype een XML complextype definitie wordt verbijzonderd (uitbreiden mag niet!) dan wordt de betreffende XML complextype definitie uit het SuwiML basisschema gekopieerd naar de berichtspecifieke body en daar aangepast. Zie Figuur 26. Bij het vaststellen van een SuwiML berichtschema worden de entiteiten op basis van de relaties uit het SGR, in een hiërarchische structuur aan elkaar gerelateerd. Hierbij wordt iedere relatie als een XML element gedefinieerd binnen een bestaande XML complextype definitie voor een SGR-entiteit. Dit gebeurt met behulp van het XML extension statement. Een relatie in het gegevensregister tussen entiteit A en B wordt, afhankelijk van het "gezichtspunt" van de relatie, in het bericht opgenomen, door een element B op te nemen als child van element A. Er zijn een aantal varianten te onderscheiden, welke worden beschreven in de volgende sectie. Soorten relaties Er zijn drie soorten relaties, te weten de "gewone" relatie tussen fundamentele entiteiten, de getypeerde relatie, en de afleiding (subclass) van een abstracte entiteit (superclass). Hoe deze verschillende relaties tot een bericht leiden, wordt aan de hand van een aantal voorbeelden uitgelegd. In de voorbeelden staat aan de linkerzijde een stukje entity-relation diagram, en aan de rechter zijde een voorbeeld van een berichttype dat past bij het diagram. Er wordt een berichtinstantie getoond in plaats van een XML Schema om de leesbaarheid te verbeteren. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 37 van 103

38 Gegevensmodel SGR Berichtinstantie A attribuuta1 attribuuta2 <A> <attribuuta1/> <attribuuta2/> <B> <attribuutb1/> <attribuutb2/> </B> B </A> attribuutb1 attribuutb2 Figuur 19: berichtinstantie irt SGR. In Figuur 19 staat een eenvoudige relatie uitgewerkt. Een praktijkvoorbeeld is een ClientSuwi die een Uitkering krijgt. A komt dan overeen met ClientSuwi en B komt dan overeen met Uitkering. In de berichtinstantie wordt entiteit Uitkering als child element opgenomen binnen element ClientSuwi. De attributen van ClientSuwi zijn Achternaam, Geboortedatum, etc.; die van Uitkering zijn Bedrag, Periode, etc. Zowel A als B kunnen uiteraard meerdere relaties met andere entiteiten hebben. Gegevensmodel SGR Berichtinstantie A <A> <attribuuta1/> attribuuta1 attribuuta2 <attribuuta2/> <X> <attribuutb1/> X Y <attribuutb2/> </X> <Y> <attribuutb1/> <attribuutb2/> B </Y> attribuutb1 </A> attribuutb2 Figuur 20: berichtinstantie irt SGR met getypeerde relatie. Een bijzondere situatie ontstaat als er meer dan één relatie tussen twee entiteiten bestaat. Om deze relaties te kunnen onderscheiden, krijgen ze een naam; met andere woorden, de relaties worden getypeerd. Figuur 20 schetst een dergelijke situatie. In de praktijk gaat het bijvoorbeeld om Adres (B), die een relatie heeft met ClientSuwi (A) als DomicilieAdres (X) en als PostAdres (Y). abstract Gegevensmodel SGR A attribuuta1 attribuuta2 B attribuutb1 attribuutb2 Berichtinstantie <A> <attribuuta1/> <attribuuta2/> <C1> <attribuutb1/> <attribuutb2/> <attribuutc11/> <attribuutc12/> </C1> </A> of <A> <attribuuta1/> <attribuuta2/> <C2> <attribuutb1/> <attribuutb2/> C1 C2 subclass <attribuutc21/> attribuutc11 attribuutc21 <attribuutc22/> attribuutc12 attribuutc22 </C2> </A> Figuur 21: berichtinstantie irt SGR met overerving van abstract datatype (eenvoudig). Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 38 van 103

39 Vanuit het object georiënteerd modelleren, is in de entity-relation wereld ook het abstracte datatype doorgedrongen. Een abstracte entiteit (superclass) komt nooit zelfstandig voor, maar dient als basis, of als bouwsteen voor een andere entiteit. In Figuur 21 is een dergelijke relatie weergegeven. Een praktijkvoorbeeld is een ClientSuwi (A) met een Uitkering (B). Er zijn echter meerdere soorten uitkeringen, zoals Wwb (C1) en Ww (C2). Deze uitkeringen hebben gemeenschappelijke attributen van de entiteit Uitkering (B), zoals Bedrag, Periode, etc. Deze gemeenschappelijke attributen zijn gemodelleerd in de abstracte entiteit (superclass) Uitkering (B), terwijl specifieke kenmerken zijn gemodelleerd in de subclass. Zo zou Ww (C2) als attribuut NaamLaatsteWerkgever kunnen hebben, de naam van de laatste Werkgever waar de ClientSuwi werkzaam was. In het bericht zal binnen element ClientSuwi (A) nooit element Uitkering (B) voorkomen, maar altijd Wwb (C1) en/of Ww (C2). De attributen uit de abstracte entiteit (superclass) Uitkering (B) worden door de subclassen Wwb (C1) en/of Ww (C2) overerft. NB. het is niet mogelijk dat een subclass attributen overerft uit meer dan één abstracte entiteit (superclass). Deze zogenaamde multiple inheritance wordt niet ondersteund. Gegevensmodel SGR Berichtinstantie A <A> <attribuuta1/> attribuuta1 <attribuuta2/> attribuuta2 <C1> <attribuutb1/> <attribuutb2/> <attribuutc11/> <attribuutc12/> <D> <attribuutd1/> B <attribuutd2/> abstract attribuutb1 </D> attribuutb2 </C1> </A> of <A> <attribuuta1/> <attribuuta2/> D C1 C2 <C2> subclass <attribuutb1/> attribuutd1 attribuutc11 attribuutc21 attribuutd2 attribuutc12 attribuutc22 <attribuutb2/> <attribuutc21/> <attribuutc22/> <D> <attribuutd1/> <attribuutd2/> </D> <E> E <attribuute1/> attribuutd1 <attribuute2/> attribuutd2 </E> </C2> </A> Figuur 22: berichtinstantie irt SGR met overerving van abstract datatype (complex). In Figuur 22 is een meer complex voorbeeld gegeven, waarin wordt aangegeven dat ook de relaties van de abstracte entiteit worden overgeërfd door de subclass, en dat subclasses ook specifieke relaties kunnen hebben. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 39 van 103

40 Gegevensmodel SGR Berichtinstantie A <A> attribuuta1 <attribuuta1/> <attribuuta2/> attribuuta2 <X> <C1> <attribuutb1/> X Y Z <attribuutb2/> <attribuutc11/> <attribuutc12/> </C1> B </X> abstract attribuutb1 <Y> attribuutb2 <C1> <attribuutb1/> <attribuutb2/> <attribuutc11/> <attribuutc12/> </C1> subclass attribuutc12 attribuutc22 <attribuutb1/> <attribuutb2/> <attribuutc21/> <attribuutc22/> <D> <attribuutd1/> <attribuutd2/> </D> D </C2> attribuutd1 </Z> attribuutd2 </A> Let op: voor zowel X, Y als Z zou subclass C1 of C2 gemodelleerd kunnen zijn. Er zijn dus 8 verschillende instantie vormen mogelijk. Hierboven is er slechts één uitgewerkt. C1 C2 </Y> <Z> attribuutc11 attribuutc21 <C2> Figuur 23: berichtinstantie irt SGR, getypeerde relatie met overerving van abstract datatype. Uiteraard kan ook een afgeleide entiteit (subclass) onderdeel zijn van een getypeerde relatie. In Figuur 23 is een voorbeeld uitgewerkt. In wezen is dit niet meer dan een combinatie van de voorbeelden uit Figuur 20 en Figuur 21. Ook hier geldt dat de abstracte entiteit (B) niet in het bericht is terug te vinden, maar wel de typering van de relatie (X, Y, Z). Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 40 van 103

41 Gegevensmodel SGR Berichtinstantie A attribuuta1 attribuuta2 <A> <attribuuta1/> <attribuuta2/> <D1> <attribuutb1/> <attribuutb2/> <attribuutc11/> <attribuutc12/> <attribuutd11/> abstract <attribuutd12/> B <E> attribuutb1 <attribuute1/> attribuutb2 <attribuute2/> </E> </D1> subclass </A> of abstract subclass C1 C2 <A> <attribuuta1/> attribuutc11 attribuutc21 <attribuuta2/> attribuutc12 attribuutc22 <D2> D1 D2 E <attribuutb1/> <attribuutb2/> <attribuutc11/> <attribuutc12/> <attribuutd21/> <attribuutd22/> <E> subclass attribuutd11 attribuutd21 attribuute1 <attribuute1/> attribuutd12 attribuutd22 attribuute2 <attribuute2/> </E> </D2> </A> of <A> <attribuuta1/> <attribuuta2/> <C2> <attribuutb1/> <attribuutb2/> <attribuutc11/> <attribuutc12/> </C2> </A> Figuur 24: berichtinstantie irt SGR met abstracte subtypes. Abstracte entiteiten kunnen uit meerdere niveaus zijn opgebouwd. Doel is minimaliseren van definities van dezelfde objecten en eigenschappen. In Figuur 24 is een voorbeeld met twee niveaus weergegeven, maar in de werkelijkheid kunnen ook meer dan twee niveaus voorkomen. Voorbeeld Figuur 26 geeft een voorbeeld van een SuwiML bodyschema met getypeerde relaties (Domicilieadres en FeitelijkAdres) met een abstracte entiteit (Adres). Hierin is bovendien binnen de Response een verbijzondering opgenomen van de SGR-entiteit ClientSuwi, waarnaar wordt gerefereerd middels de namespace-prefix smlb in smlb:clientsuwi. Feitelijk is in het SuwiML bodyschema een kopie opgenomen van de oorspronkelijke XML complextype definitie van ClientSuwi uit het SuwiML basisschema en is deze kopie vervolgens aangepast (verbijzonderd) voor het SuwiML berichtschema waarvan dit SuwiML bodyschema deel uitmaakt. Figuur 25 en Figuur 26 tonen de verbijzondering van ClientSuwi en laten bovendien zien hoe, middels het XML extension statement, de getypeerde SGR-relaties vanuit ClientSuwi naar FeitelijkAdres en DomicilieAdres zijn opgenomen. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 41 van 103

42 ClientSuwi SofiNr Domicilieadres FeitelijkAdres abstract Adres subclass Straatadres Straatadres Buitenland Figuur 25: voorbeeld Entiteit-Relatie diagram voor ClientSuwi. <?xml version="1.0" encoding="utf-8"?> <schema targetnamespace = " xmlns = " xmlns:sml = " xmlns:smlb = "  <import namespace=" schemalocation="uwvdossierpersoon-v0302-b07-include.xsd"/>  <element name="suwimlbody" type="smlb:suwimlbody"/> <complextype name="suwimlbody"> <choice> <element name="redirect" type="smlb:redirect"/> <sequence> <element name="response" type="smlb:response"/> <element name="fault" type="smlb:fault" minoccurs="0"/> <element name="warning" type="smlb:warning" minoccurs="0"/> </sequence> <element name="acknowledgement" type="smlb:acknowledgement"/> </choice> </complextype>  <complextype name="redirect"> <sequence> <element name="expiresafterseconds" type="nonnegativeinteger" minoccurs="0"/> <choice> <element name="compoundservice" type="smlb:compoundservice"/> <element name="alternativeserviceset" type="smlb:alternativeserviceset"/> <element name="service" type="smlb:service"/> </choice> </sequence> </complextype> <complextype name="alternativeserviceset">... </complextype> <complextype name="compoundservice">... </complextype> <complextype name="service">... </complextype> Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 42 van 103

43  <complextype name="response"> <sequence> <element name="clientsuwi" minoccurs="0"> <complextype><complexcontent> <extension base="smlb:clientsuwi"> <sequence> <element name="feitelijkadres" type="smlb:adres" minoccurs="0"/> <element name="domicilieadres" type="smlb:adres"/> </sequence> </extension> </complexcontent></complextype> </element> </sequence> </complextype> <complextype name="adres"> <choice> <element name="straatadres" type="sml:straatadres"/> <element name="straatadresbuitenland" type="sml:straatadresbuitenland"/> </choice> </complextype> <complextype name="clientsuwi"> <sequence> <element name="sofinr" type="sml:sofinr"/> </sequence> </complextype>  <complextype name="fault"> <sequence> <element name="fout" type="smlb:fout" maxoccurs="unbounded"/> </sequence> </complextype> <element name="fout" type="smlb:fout"/> <complextype name="fout">... </complextype>  <complextype name="warning"> <sequence> <element name="waarschuwing" type="smlb:waarschuwing" maxoccurs="unbounded"/> </sequence> </complextype> <complextype name="waarschuwing">... </complextype>  <complextype name="acknowledgement"> <sequence/> </complextype> </schema> Figuur 26: SuwiML Reaction bodyschema met een verbijzondering van het XML complextype voor ClientSuwi. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 43 van 103

44 4.3. Warning binnen SuwiML body Aanvullend op een bericht kan er behoefte zijn aan de toevoeging van extra "achtergrondinformatie", als motivatie bij de geleverde gegevens. Bij het beantwoorden van een request bericht middels een response, bestaat de mogelijkheid voor de server om naast de opgevraagde gegevens, middels een warning, deze aanvullende informatie aan het response bericht toe te voegen. Figuur 14 toont de XML choice constructie voor de SuwiML body, waarin het warning element opgenomen is. De warning mag alleen bij uitzondering worden gebruikt. Met andere woorden, het moet een aanvulling zijn, en mag alleen informatie bevatten die niet is af te leiden uit de response. Niet alle gegevens mogen worden verwerkt in een warning, dit om te voorkomen dat onterecht gegevens worden overgedragen. Als bepaalde gegevens bijvoorbeeld om redenen van privacy niet in een bericht verzonden mogen worden, dan zullen ze niet in de schema's zijn gemodelleerd. Dan is het natuurlijk niet de bedoeling om ze alsnog als warning te versturen. Voorafgaand aan de implementatie, moeten bij de toetsing van de berichtstructuur door de SuwiML beheerorganisatie (BKWI), ook de mogelijk te versturen warnings worden getoetst. Het initiatief voor het vastleggen en toetsen van de warnings ligt bij de leverancier van de gegevens. Zo kan de leverancier de set warnings op ieder moment zelf uitbreiden (mits getoetst en ok). Binnen de SuwiML berichtstandaard is er voor gekozen geen gebruik te maken van een vooraf gedefinieerde algemene lijst met mogelijke warnings. De leverende partij is verantwoordelijk voor duidelijke en zinvolle warnings, de SuwiML beheerorganisatie toetst op zinvolheid en toepasbaarheid van de door de leverancier voorgestelde warnings. De motivatie voor deze keuze is analoog aan de motivatie voor het gebruik van foutcodes zoals beschreven in sectie Foutcodes: centraal vastgelegd versus vrij invulbaar van de SuwiML transactiestandaard. <?xml version="1.0" encoding="utf-8"?> <SOAP-ENV:Envelope xmlns:soap-env = " xmlns:smlh = " xmlns:smlb = " xmlns:xsi = " xsi:schemalocation = " UwvDossierPersoon-v0302-b07-EnvelopeReaction.xsd"> <SOAP-ENV:Header> <smlh:suwimlheader> <RouteInformatie>... </RouteInformatie> <BerichtIdentificatie>... </BerichtIdentificatie> <Transactie>... </Transactie> </smlh:suwimlheader> </SOAP-ENV:Header> <SOAP-ENV:Body> <smlb:suwimlbody> <Response>... </Response> <Warning> <Waarschuwing> <WaarschuwingCode>23</WaarschuwingCode> <WaarschuwingTekst>Persoon is overleden.</waarschuwingtekst> Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 44 van 103

45 <WaarschuwingBron> <CdKolomSuwi>5</CdKolomSuwi> <CdPartijSuwi>3090</CdPartijSuwi> <CdVestigingSuwi>3090</CdVestigingSuwi> <ApplicatieNaam>Persoonsregistratie</ApplicatieNaam> </WaarschuwingBron> </Waarschuwing> </Warning> </smlb:suwimlbody> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Figuur 27: voorbeeld SuwiML Reaction response bericht met een warning. Figuur 27 toont een voorbeeld van een warning. Stel dat er een berichtuitwisseling is, waarbij persoonsgegevens worden opgevraagd. Deze gegevens worden gebruikt voor het versturen van post, etc. DatumOverlijden is niet in elke berichtuitwisseling gemodelleerd, en het is niet ongebruikelijk dat er geen adres bekend is van een overleden persoon. Om nu in een bericht de afwezigheid van bijvoorbeeld de adresgegevens te verklaren, kan de warning Persoon is overleden worden toegevoegd aan het bericht. Nogmaals, dit is een voorbeeld, en geen algemene regel, de SuwiML beheerorganisatie dient hierover een uitspraak te doen Clusters binnen SuwiML body Het vormgeven van een SuwiML berichtschema kan worden vereenvoudigd door gebruik te maken van clusterdefinities binnen de SuwiML body. Een clusterdefinitie beschrijft een (verbijzonderde) hiërarchie van entiteiten die in zijn geheel op identieke wijze en op meerdere plaatsen in de berichthiërarchie voorkomt. Door een cluster apart te definiëren kan hij vervolgens door middel van referentie onbeperkt gebruikt worden in de berichthiërarchie en is hij bovendien beter onderhoudbaar doordat eventuele wijzigingen slechts op één plek in de SuwiML body hoeven te worden doorgevoerd. Een clusterdefinitie wordt altijd vastgelegd met behulp van een XML complextype definitie binnen de SuwiML body. De clusterdefinitie kan vervolgens gebruikt worden binnen de SuwiML body door een XML element te definiëren welke als type een verwijzing naar de XML complextype clusterdefinitie bevat. Op deze manier leidt het gebruik van clusterdefinities in een berichtinstantie niet tot extra XML tags, alleen de volgens het SGR noodzakelijke en toegestane tags worden gebruikt voor de opbouw van een berichtinstantie. Figuur 28 geeft een voorbeeld van een SuwiML body waarin een clusterdefinitie voor ContactpersoonInformatie is opgenomen. Deze clusterdefinitie beschrijft een XML complextype met een geneste XML sequence waarbij de gegevens behorend bij een contactpersoon altijd bestaan uit de SGR/SuwiML entiteitdefinitie van Contactpersoon, uitgebreid met getypeerde relaties naar DomicilieAdres en PostAdres. Het DomicilieAdres is een straatadres in Nederland of het buitenland, het PostAdres is een postbusadres in Nederland. De Response definitie binnen de SuwiML body, Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 45 van 103

46 refereert aan de SGR/SuwiML entiteitdefinitie voor ClientSuwi en voegt daar met behulp van XML extension twee getypeerde relaties aan toe voor respectievelijk: ConsulentSuwi en WoordvoerderClientSuwi. Beide getypeerde relaties worden vervolgens door referentie gelijkgesteld aan de clusterdefinitie voor ContactpersoonInformatie. <?xml version="1.0" encoding="utf-8"?> <schema targetnamespace = " xmlns = " xmlns:sml = " xmlns:smlb = " <import namespace=" schemalocation="uwvdossierpersoon-v0302-b07-include.xsd"/> <element name="suwimlbody" type="smlb:suwimlbody"/> <complextype name="suwimlbody"> <choice> <element name="redirect" type="smlb:redirect"/> <sequence> <element name="response" type="smlb:response"/> <element name="fault" type="smlb:fault" minoccurs="0"/> <element name="warning" type="smlb:warning" minoccurs="0"/> </sequence> </choice> </complextype> <complextype name="response"> <sequence> <element name="clientsuwi"> <complextype> <complexcontent> <extension base="sml:clientsuwi"> <sequence> <element name="consulentsuwi" type="smlb:contactpersooninformatie"/> <element name="woordvoerderclientsuwi" type="smlb:contactpersooninformatie"/> </sequence> </extension> </complexcontent> </complextype> </element> </sequence> </complextype> <complextype name="contactpersooninformatie"> <complexcontent> <extension base="sml:contactpersoon"> <sequence> <element name="domicilieadres" minoccurs="0"> <complextype> <choice> <element name="straatadres" type="sml:straatadres"/> Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 46 van 103

47 <element name="straatadresbuitenland" type="sml:straatadresbuitenland"/> </choice> </complextype> </element> <element name="postadres" type="sml:postbusadres"/> </sequence> </extension> </complexcontent> </complextype> </schema> Figuur 28: modelleren van clusters binnen SuwiML body Beknopte samenvatting modellering SuwiML berichtschema Ieder SuwiML berichtschema moet gebruik maken van de constructies die SGR/SuwiML biedt of ondersteunt. Men moet zich dus houden aan het principe dat iedere berichtspecificatie alleen binnen de kaders van het SGR kan worden opgesteld. Er kunnen geen nieuwe gegevenselementen, entiteiten of relaties worden bijgemaakt, noch bestaande worden uitgebreid. Kortom: de speelruimte wordt volledig bepaald door het SGR. Verder gelden puntsgewijs de volgende vuistregels: De SuwiML body voor een specifiek bericht bestaat uit een Request (Action) of een keuze (XML choice) tussen een Redirect of Response (Reaction), waarbij een Response eventueel vergezeld kan gaan door een Fault en/of Warning. Ieder SuwiML berichtschema gebruikt het SGR / het SuwiML basisschema als uitgangspunt. Iedere relatie, entiteit of attribuut uit het SGR / het SuwiML basisschema wordt in een SuwiML berichtschema 1-op-1 overgenomen door middel van een directe referentie naar het SuwiML basisschema, of wordt verbijzonderd voor het betreffende berichttype (het SuwiML berichtschema). In geval een entiteit uit het SGR / het SuwiML basisschema in een SuwiML berichtschema wordt verbijzonderd, gebeurt dit door de XML complextype definitie uit het SuwiML basisschema te kopiëren naar het SuwiML bodyschema, en binnen dit bodyschema aan te passen volgens de berichtspecifieke eisen. Relaties uit het SGR / het SuwiML basisschema worden middels XML extension aan (verbijzonderde) entiteitdefinities toegevoegd. Binnen de SuwiML body kunnen clusterdefinities worden opgenomen waarnaar elders in de berichthiërarchie (herhaald) kan worden verwezen. De XML Schema aanbeveling is erg complex. Niet alle constructies zijn nodig om een werkbaar XML Schema op te stellen. In de SuwiML berichtschema's zijn de volgende regels toegepast: SuwiML drukt SGR gegevenselementen uit met behulp van XML element, niet met behulp van XML attribute. Het SGR is dus omgezet naar een pure XML element verzameling. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 47 van 103

48 SuwiML definieert XML complextypes en XML simpletypes op topniveau. XML complextypes leggen met name SGR entiteitdefinities vast, en worden gevuld met XML element definities voor de SGR gegevenselementen van de betreffende SGR entiteit. XML simpletypes leggen de SGR domeindefinities vast waaraan wordt gerefereerd door de SGR gegevenselementen. SuwiML definieert een apart type voor iedere SGR domeindefinitie (bijvoorbeeld het type sml:sofinr voor de SGR domeindefinitie gerelateerd aan het SGR gegevenselement SofiNr van SGR entiteit ClientSuwi). De typenaam is gelijk aan de naam van de SGR domeindefinitie. Ongetypeerde relaties tussen SGR entiteiten A en B worden gedefinieerd als een XML element B onder A. Het XML element heeft dus dezelfde naam als de SGR entiteit, i.e. de XML complextype, waarnaar de relatie verwijst. Getypeerde relaties R tussen SGR entiteiten A en B worden gedefinieerd als een XML element R onder A, waarbij R van het XML complextype B is. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 48 van 103

49 5. SuwiML berichtontwikkelingsmethodiek 5.1. Inleiding Standaardisatie- en berichtontwikkelingsmethoden richten zich op de scheiding tussen functioneleen technische vraagstukken. Daarbij is niet slechts de gegevensuitwisseling, maar de integratie van applicaties de feitelijke uitdaging. Een methodiek (combinatie van methoden) die het gehele applicatie-integratie traject ondersteunt, leidt tot een consequente werkwijze/benadering van de functioneleen technische vraagstukken en een consistente oplossing daarvan. Een definitie van het standaardisatie- en berichtontwikkelingsproces is afgeleid van nationale en internationale richtlijnen en aanbevelingen, en valt uiteen in vier logische fasen: analyse, ontwerp/ontwikkeling, implementatie en toepassing. De binnen SGR/SuwiML gehanteerde methodiek volgt deze definitie van het standaardisatie- en berichtontwikkelingsproces. analyse ontwerp/ ontwikkeling implementatie toepassing feedback Figuur 29: berichtontwikkelingsproces Internationale ontwikkelingen mbt standaardisatie en berichtontwikkeling UN/CEFACT Modelling Methodology De United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) Modelling Methodology (UMM) beschrijft een methode voor de modellering van bedrijfsprocessen en geeft ondersteuning bij de ontwikkeling van bestaande en nieuwe vormen van elektronische gegevensuitwisseling (Electronic Data Interchange EDI) tussen organisaties en/of applicaties. De UMM bedrijfsproces- en informatiemodelleringstechniek is gebaseerd op de Unified Modelling Language (UML) afkomstig van de Open Management Group (OMG). De UMM methode is deels afgeleid van de Rational Unified Process methodology (RUP) afkomstig van IBM Rational Rose. De UMM methode richt zich op de specificatie van afzonderlijke bedrijfsprocessen en informatieobjecten, alsmede de interactie scenario s die tussen de verschillende bedrijfsprocessen plaatsvinden. Belangrijk aspect van deze specificaties is het feit dat ze functioneel van aard zijn, en los staan / onafhankelijk zijn van de onderliggende technische implementatie. Het doel is te komen tot modulaire en herbruikbare functionele specificaties, welke consistent zijn qua opbouw en inhoud. De UMM methode is dus feitelijk een formele techniek om open-edi scenario s te beschrijven, zoals in ISO/IEC IS wordt onderkend als een formele specificatie van een verzameling bedrijfstransacties met een gemeenschappelijk doel. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 49 van 103

50 De RUP methode stelt dat softwareontwikkelingsprojecten een aantal fasen doorlopen, te weten: initiatie, uitwerking, constructie en transitie. Elk van deze fasen heeft een specifieke rol binnen het UN/CEFACT ontwikkelingsproces voor standaarden. Binnen het ebxml initiatief helpt UN/CEFACT bij de vastlegging van een standaard ontwikkelingsproces voor de levensloop (lifecycle) van elektronische berichten. W3C Het World Wide Web Consortium (W3C) ontwikkelt interoperabele technologieën (specificaties, richtlijnen, software en tools) met als doel het potentieel van het World Wide Web ten volle te benutten. Het W3C is een forum voor informatie, handel, communicatie en gezamenlijke kennisdeling en -ontwikkeling. Het W3C richt zich onder meer op de ontwikkeling van XML gerelateerde standaarden zoals XML Schema, XPointer, DOM, XSL, XSLT, etc. Mijlpalen daarbij zijn de vaststelling van XML 1.0 (10 februari 1998) en XML Schema 1.0 (2 mei 2001). ISO ISO Development of messages. stelt dat alle organisaties die zich bezig houden met de ontwikkeling van standaarden voor gegevensuitwisseling, deze gegevensuitwisseling moeten baseren op een Reference Information Model (RIM). De RIM vormt het fundament voor alle specificaties van gegevensuitwisselingen binnen de specifieke bedrijfscontext/keten/branche waarvoor de RIM is vastgesteld. Vanuit de RIM wordt een Refined Message Information Model (R- MIM) afgeleid, als subset van de RIM, welke de specificatie van (gerelateerde) Hierarchical Message Definitions (HMDs) ondersteunt. Een HMD is een hiërarchische specificatie van een set berichttypen gebaseerd op informatieobjecten die zijn vastgelegd in de bijbehorende R-MIM. Een specifiek berichttype is altijd gerelateerd aan precies één HMD. Volgens ISO worden alle specificaties vastgelegd in UML. veralgemeniseren Reference Information Model (RIM) Suwi Gegevensregister SuwiML basisschema subset Refined Message Information Model (R-MIM) afleiden hierarchical subset Transactie hiërarchie afleiden Hierarchic Message Definition (HMD) subset Bericht hiërarchie Message types Figuur 30: ISO development of messages. verbijzonderen Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 50 van 103

51 ISO ISO/IEC beschrijft de voor gegevensmodellering noodzakelijke metadata naar soort en kwaliteit, en definieert de vastlegging en het beheer van deze metadata in een metadata register (MDR). Het is van toepassing op de specificaties van gegevensrepresentaties, -concepten, - betekenissen en -relaties welke gedeeld worden tussen mensen en machines, onafhankelijk van de organisatie welke de gegevens feitelijk produceert. Het is niet van toepassing op de fysieke representatie van gegevens in termen van bits en bytes. ebxml Electronic Business using extensible Markup Language (ebxml) stelt zichzelf tot doel om organisaties, ongeacht omvang of geografische locatie, vrijelijk met elkaar zaken te laten doen met behulp van het World Wide Web, het Internet. ebxml is een modulaire verzameling van specificaties die organisaties in staat stelt om middels een standaard methode elektronische XML berichten uit te wisselen, (handels)relaties te onderhouden, gegevensdefinities onderling af te stemmen en bedrijfsprocessen te definiëren en te registreren. ebxml is een gezamenlijk initiatief van UN/CEFACT en OASIS. ebxml stelt dat voor het modelleren van bedrijfsprocessen en informatieobjecten gebruik gemaakt moet worden van UMM en UML. Hoewel de bedrijfsactiviteiten per organisatie sterk zullen verschillen, kunnen de meeste activiteiten ontleed worden in meer generieke bedrijfsprocessen voor de betreffende branche/keten. De modulaire opbouw die op deze wijze tot stand komt, en de generieke bedrijfsprocessen en informatieobjecten die daarmee onderkend worden, komen in aanmerking voor standaardisatie binnen de betreffende branche/keten. ebxml zoekt naar dit soort standaard herbruikbare componenten voor welke interoperabele (componenten van) applicaties gemaakt kunnen worden. In UMM worden twee specificatieniveaus onderscheiden: de Business Operational View (BOV) en de Functional Service View (FSV). Zie ook de Open-EDI Reference Model Standard ISO/IEC Deze specificatieniveaus worden ook in ebxml onderkend, met de volgende betekenis: De BOV beschrijft de semantiek van bedrijfsgegevens in bedrijfstransacties en aanverwante gegevensuitwisselingen. Het adresseert de architectuur van bedrijfstransacties inclusief de operationele conventies, afspraken en verplichtingen. De BOV geeft een compleet beeld van alle bedrijfstransacties met betrekking tot het vastleggen van de beslissingen en afspraken omtrent deze bedrijfstransacties. De FSV beschrijft de inrichting van diensten rondom en ter ondersteuning van de bedrijfstransacties. Het concentreert zich daarbij op de Informatie Technologie (IT) aspecten van open-edi transacties, in het bijzonder: de vereiste functionaliteit van de diensten; de interfacing tussen de diensten; protocol- en berichtuitwisselingsdiensten. Aanbevelingen met betrekking tot het berichtontwikkelingsproces Op basis van de internationale standaarden zoals hierboven beschreven, worden de volgende aanbevelingen overgenomen: Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 51 van 103

52 3. De UN/CEFACT Modelling Methodology wordt toegepast voor de modellering van bedrijfsprocessen en geeft ondersteuning bij de ontwikkeling van bestaande en nieuwe vormen van elektronische gegevensuitwisseling. 4. De modellering van bedrijfsprocessen, bedrijfstransacties, alsmede de aanverwante gegevensuitwisselingen, wordt gespecificeerd met behulp van de Unified Modelling Language. Dit is conform de formele specificatie techniek voor open-edi scenario s zoals vastgelegd in ISO/IEC Een Reference Information Model Suwi Gegevensregister zal de basis vormen voor alle te specificeren gegevensuitwisselingen. Standaardisatie van terminologie, definities, codelijsten, etc. kan op deze wijze worden gerealiseerd en afgedwongen. 6. Een subset van het Reference Information Model, genoemd het Refined Message Information Model, ligt ten grondslag aan de specificatie van één of meer Hierarchical Message Definitions. Elke afzonderlijke Hierarchical Message Definition ondersteunt de specificatie van één of meer berichttypen. Specificaties worden opgesteld in de Unified Modelling Language. 7. Analyse en ontwerp/ontwikkeling vinden zuiver en alleen plaats vanuit een functioneel perspectief. Ten behoeve van implementatie en toepassing wordt gekozen voor een bepaald uitwisselingsformaat; XML (SuwiML) in de Suwi keten Het berichtontwikkelingsproces Het berichtontwikkelingsproces start met de analyse van alle (mogelijke) proces- en informatiestromen die tussen verschillende organisaties kunnen plaatsvinden. Vervolgens wordt bepaald welke van deze stromen in aanmerking komen voor (elektronische) berichtuitwisseling, i.e. de berichttypen worden bepaald. Nu volgt het ontwerp / de ontwikkeling van de functionele en technische specificaties van de onderkende berichttypen, gevolgd door de implementatie en feitelijke toepassing/ingebruikname. Figuur 29 en Figuur 31 geven een schematisch beeld van het berichtontwikkelingsproces. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 52 van 103

53 Analyse 1. Analyseer proces-en informatiestromen a. Identificeer proces en processtappen b. Identificeer informatiestromen binnen proces en tussen processtappen c. Identificeer doel van informatiestromen d. Identificeer globale inhoud van informatiestromen e. Identificeer rollen en communicatiepartners f. Relateer rollen aan proces en processtappen 2. Optimaliseer informatieuitwisseling tussen communicatiepartners a. Probleem analyse b. Identificeer bestaande oplossingen c. Definieer medium per informatiestroom 3. Identificeer nieuwe informatiestromen a. Bepaal prioriteit per (nieuwe) informatiestroom b. Plan de realisatie van ( nieuwe) informatiestromen 4. Creëer analyserapport a. Analyserapport vormt de input voor het ontwikkelingsproces b. Ontwikkelingsproces kan door een ander team worden uitgevoerd op basis van het analyserapport Ontwerp / ontwikkeling 5. Definieer het communicatieproces a. Specificeer informatieuitwisseling tussen communicatiepartners berichtscenario s, volgorde en afhankelijkheid berichttypen b. Specificeer communicatiepartners 6. Definieer de functionele inhoud van berichten a. Specificeer entiteiten en attributen b. Identificeer bestaande (delen van) berichten binnen registers c. Specificeer de berichthiërarchie d. Specificeer de berichtspecifieke functionele validatie regels 7. Creëer overzicht van functionele berichtspecificaties a. Specificeer functionele berichtspecificaties 8. Kies uitwisselingssyntax per berichttype a. Kies een uitwisselingssyntax 9a. Creëer technische XML specificatie a. Definieer XML tags en XML Schema b. Valideer XML tags en XML Schema choice 9b. Creëer technische Edifact specificatie a. Definieer mapping naar Edifact UNSM b. Valideer Edifact mapping 9c. Creëer technische flat-file specificatie a. Definieer flat-file specificatie b. Valideer flat-file structuur Implementatie 10. Creëer adapter voor informatiesysteem a. Verwerk inkomende berichten b. Genereer uitgaande berichten c. Implementeer triggers om verwerking en aanmaken van berichten te initiëren 11. Configureer vertaler a. Converteer intern bestandsformaat naar uitwisselingsformaat (afhankelijk van berichttype en communicatiepartner) b. Converteer uitwisselingsformaat naar intern bestandsformaat 12. Creëer verbinding met netwerk infrastructuur a. Definieer en configureer de communicatieprotocollen 13. Test berichtuitwisseling a. Test ontvangst en inlezen/valideren inkomende berichten b. Test samenstellen en versturen uitgaande berichten c. Test triggers voor verwerking en aanmaken van berichten d. Creëer testrapport 14. Setup beheersomgeving a. Monitor status van berichten b. Monitor status van communicatiesessies c. Setup (automatische) error-handling in het geval zich een probleem voordoet 15. Certificering van de implemenatie door Trusted ThirdParty a. Afsprakendocument inclusief detailspecificaties als contract vastleggen (SLA, SNO) Toepassing parallel 16. Zenden en ontvangen van berichten 17. Vertalen en valideren van berichten 18. Operationeel beheer a. Routeren a. Vertaal van/naar Edifact, XML a. Uitrol van implementatie b. Adresseren en intern bestandsformaat b. Monitor de operationele gang van zaken b. Valideer conform Message Implementation Guidelines (MIG) Figuur 31: berichtontwikkelingsproces. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 53 van 103

54 Analyse, ontwerp, ontwikkeling Doel van de analyse fase is het vaststellen van de aanleiding, de primaire doelstellingen en de randvoorwaarden van de proces- en informatiestromen, alsmede het inventariseren van de te verwachten vraagstukken bij het ontwerp / de ontwikkeling van de proces- en informatiestromen. De resultaten uit de analyse fase vormen de grondslag voor de ontwerp/ontwikkeling fase. Doel van de ontwerp/ontwikkeling fase is om bericht implementatie richtlijnen op te stellen waarin het proces, de functionele inhoud, de syntax en de mapping van functionele inhoud op syntax en uitwisselingsformaat wordt gespecificeerd. Bericht implementatie richtlijnen worden opgesteld per berichttype, waarbij gerelateerde berichttypen liefst gelijktijdig ontworpen/ontwikkeld worden. De combinatie van functionele berichtspecificatie en technische berichtspecificatie samen vormt de bericht implementatie richtlijn voor een bepaald berichttype. Figuur 31 toont de analyse-, ontwerp/ontwikkeling-, implementatie- en toepassingsfase op hoofdlijnen. De analyse fase en de ontwerp/ontwikkeling fase worden beide uitgevoerd met gebruik van UML, zoals binnen de eerder genoemde internationale standaarden ook wordt aangeraden. Implementatie en toepassing Doel van de implementatie fase is de feitelijke realisatie van de bericht implementatie richtlijnen, welke voortkomen uit de ontwerp/ontwikkeling fase. Dit betekent dat de bedrijfsapplicaties worden uitgebreid met een adapter waarin functionaliteit wordt opgenomen voor het verzenden en ontvangen van elektronische berichten. De bedrijfsapplicatie en de adapter werken hierbij nauw samen om de aangeleverde functionele (bericht)inhoud te converteren naar het vastgestelde uitwisselingsformaat (SGR, XML, SOAP, SuwiML). Uitgaande berichten worden verzonden via het Suwinet, inkomende berichten worden ontvangen via het Suwinet. De implementatie fase behelst daarom ook het realiseren van de connectiviteit van alle betrokken communicatie-actoren (Suwi partijen) met dit netwerk. De adapter, de conversie en de connectiviteit dienen uitgebreid getest te worden en indien mogelijk gecertificeerd te worden door een onafhankelijke derde partij (trusted third party). Doel van de toepassingsfase is het operationeel gebruik van de geïmplementeerde en geconfigureerde operationele componenten, zodanig dat uitgaande berichten conform de specificaties worden gegenereerd en inkomende berichten conform de specificaties worden gevalideerd en verwerkt. Een en ander vindt plaats in een volledig geautomatiseerde en geïntegreerde omgeving waarbinnen geen verdere (handmatige) acties noodzakelijk zijn. Het operationeel beheer in de toepassingsfase bestaat uit het uitrollen en configureren van de operationele componenten, versie beheer, het monitoren van berichtuitwisselingen en de berichtuitwisselingsomgeving in het algemeen, het inrichten en uitvoeren van de exceptie- en foutafhandelingsprocedures, communicatie-actor/account beheer (logins, passwords, etc.) en registreren van statistische gegevens. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 54 van 103

55 5.4. Methodische ondersteuning van het berichtontwikkelingsproces Procesmodel Om de dynamiek van de omgeving goed te kunnen doorgronden is inzicht in het bedrijfsproces gewenst. Een bedrijfsprocesmodel welke de interactie en de gegevensuitwisseling tussen interne en externe systemen en/of communicatie-actoren in beeld brengt, moet hiertoe dienen. Met het gewenste inzicht in het bedrijfsproces, kan vervolgens de discussie worden gevoerd over mogelijke verbeteringen en/of optimalisaties in het bedrijfsproces. Uiteindelijk resulteert dit in een inzicht in het bestaande én gewenste bedrijfsproces. De onderkende interacties en gegevensuitwisselingen in het bedrijfsproces kunnen met behulp van verschillende media gerealiseerd worden, bijvoorbeeld telefoon, fax, brief, voice-response, webservice, elektronisch bericht. Afhankelijk van de noodzaak van een interactie of gegevensuitwisseling en de kosten en nadelen/voordelen verbonden aan een bepaald medium, wordt vastgesteld welke interactie of gegevensuitwisseling wanneer en middels welk medium gerealiseerd wordt. Modellering van het bedrijfsproces en de daarmee verband houdende interacties en gegevensuitwisselingen vindt met name plaats in de analyse- en ontwerp/ontwikkeling fase. Vaak worden voor de reeds bekende interacties en gegevensuitwisselingen elektronische berichtuitwisselingen gespecificeerd en gerealiseerd om op die manier het bestaande bedrijfsproces efficiënter te laten verlopen. Beter is het echter om eerst te streven naar een verbetering en/of optimalisatie van het bestaande bedrijfsproces, alvorens de dan onderkende interacties en gegevensuitwisselingen middels elektronische berichtuitwisseling te automatiseren. Met andere woorden: eerst streven naar een verbetering van de effectiviteit alvorens te streven naar een verbetering van de efficiëntie. State-transition-diagram Een state-transition-diagram (STD) beschrijft de wijze waarop de interacties of gegevensuitwisselingen tussen twee systemen en/of communicatie-actoren, de toestand waarin het gehele bedrijfsproces zich bevindt, veranderen. Een compleet state-transition-diagram beschrijft alle mogelijke toestanden waarin het bedrijfsproces zich kan bevinden inclusief de wijze waarop iedere toestand bereikt kan worden. Compleet in deze, betekent dat alle mogelijke toestanden worden beschreven en iedere beschreven toestand ook daadwerkelijk bereikbaar is. Een state-transitiondiagram heeft altijd één starttoestand en één eindtoestand. Een state-transition-diagram beschrijft dus in feite de dynamiek van het bedrijfsproces en de wijze waarop het bedrijfsproces op bepaalde situaties reageert. Time-sequence-diagram Een time-sequence-diagram (TSD) beschrijft bepaalde scenario s (use cases) die zich binnen het bedrijfsproces kunnen voordoen. Een time-sequence-diagram beschrijft een specifieke chronologische aaneenschakeling van processtappen welke, aangevangen vanuit de starttoestand, uiteindelijk leiden tot de eindtoestand in het state-transition-diagram. Meerdere verschillende time- Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 55 van 103

56 sequence-diagrammen kunnen leiden tot de eindtoestand in het state-transition-diagram. Iedere toestand in het state-transition-diagram is bereikbaar via minimaal één time-sequence-diagram. Informatiemodel en berichthiërarchie Voor iedere interactie of gegevensuitwisseling binnen het bedrijfsproces moet bepaald worden welke functionele inhoud daarbij een rol speelt. Met andere woorden: welke gegevens worden uitgewisseld en wat is daar de betekenis van? Om de uitgewisselde gegevens op consistente en complete wijze te kunnen definiëren wordt gebruik gemaakt van een gemeenschappelijk gegevensregister/informatiemodel waarin alle gegevens uit alle interacties of gegevensuitwisselingen worden gemodelleerd. Op basis van het gegevensregister/informatiemodel wordt vervolgens voor elk afzonderlijk berichttype de berichthiërarchie opgebouwd. Berichttypen die qua betekenis en toepassing sterk met elkaar verbonden zijn, kunnen in de praktijk het beste gebruik maken van één gemeenschappelijke transactiehiërarchie waaruit de afzonderlijke specifieke berichthiërarchieën worden afgeleid. Nadat de functionele berichtspecificaties op deze wijze zijn vastgesteld, moet worden bepaald op welke technische wijze de berichttypen uitgewisseld moeten worden, i.e. volgens welke uitwisselingssyntax. Binnen de Suwi keten wordt hiervoor gebruik gemaakt van XML (SuwiML) Specificatie van elektronische ketenberichten Gegevensmodel Een gegevensmodel, zoals het Suwi Gegevensregister, kan worden beschouwd als een verzameling standaard bouwstenen. Iedere bouwsteen representeert de exacte definitie (formaat, waardebereik, betekenis, etc.) van een functioneel informatie-object dat wordt onderkend binnen het bedrijfsproces en op enig moment voor interactie of gegevensuitwisseling wordt gebruikt. Iedere bouwsteen (informatie-object) wordt precies één keer vastgelegd in het gegevensmodel. Het gegevensmodel bevat ook de verzameling van algemeen geldende relaties tussen deze informatie-objecten. Berichtmodel Een berichtmodel beschrijft een hiërarchie. Een berichtmodel maakt gebruik van de informatieobjecten uit een gegevensmodel en voegt hieraan specifieke (contextuele) informatie toe. De informatie-objecten uit het gegevensmodel kunnen herhaald en op verschillende plaatsen in het berichtmodel worden gebruikt. De definitie van de informatie-objecten kan binnen de context van het berichtmodel worden aangescherpt en kan bovendien per voorkomen binnen het berichtmodel verschillen. Relaties uit het gegevensmodel kunnen binnen de context van het berichtmodel eveneens worden aangescherpt. Dit kan leiden tot nieuwe relaties welke alleen binnen de context van het berichtmodel geldig en van toepassing zijn. Figuur 32 geeft een schematisch voorbeeld van een gegevensmodel welke als basis fungeert voor een aantal verschillende berichtmodellen. Het afleiden van de berichtmodellen uit een gegevensmodel komt overeen met de methode zoals verbeeld in Figuur 18 en Figuur 30. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 56 van 103

57 A B C D Figuur 32: schematisch voorbeeld van een gegevensmodel. Figuur 33, Figuur 34, Figuur 35, Figuur 36 en Figuur 37zijn allemaal afgeleid van één en hetzelfde gegevensmodel. Op deze wijze is dus gegarandeerd dat al deze berichtmodellen consequent en consistent gebruik maken van de informatie-object definities zoals die zijn vastgelegd in het gegevensmodel. A B D C Figuur 33: voorbeeld van een berichtmodel op basis van het gegevensmodel in Figuur 32. C A D B Figuur 34: voorbeeld van een berichtmodel op basis van het gegevensmodel in Figuur 32. A B D C Figuur 35: voorbeeld van een berichtmodel op basis van het gegevensmodel in Figuur 32. A B D C C Figuur 36: voorbeeld van een berichtmodel op basis van het gegevensmodel in Figuur 32. NB. in het berichtmodel in Figuur 36 komt informatie-object C tweemaal voor, waarbij de definities van C mogelijk aangescherpt zijn ten opzichte van het gegevensmodel en ten opzichte van elkaar kunnen verschillen. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 57 van 103

58 A Figuur 37: voorbeeld van een berichtmodel op basis van het gegevensmodel in Figuur 32. C D NB. in het berichtmodel in Figuur 37 komt informatie-object D direct onder informatie-object A voor, hetgeen een aanscherping is van de relaties in het gegevensmodel. Specificatie van een elektronisch ketenbericht Onderdeel van een volledige en eenduidige beschrijving van een elektronisch ketenbericht zijn de volgende componenten: 1. functionele berichtspecificatie; 2. technische berichtspecificatie (SuwiML berichtschemaset); 3. functioneel applicatieontwerp; 4. transactiestandaard implementatiedocument. Functionele berichtspecificatie De functionele specificatie van een berichttype kent twee onderdelen: 1. hiërarchisch entiteiten-relaties overzicht (het berichtmodel / de berichthiërarchie); 2. hiërarchisch entiteiten-attributen overzicht. 1. Hiërarchisch entiteiten-relaties overzicht (het berichtmodel / de berichthiërarchie). Het hiërarchisch entiteiten-relaties overzicht wordt vastgesteld per berichttype en geeft een opsomming van alle entiteit-instanties die binnen het betreffende berichttype voorkomen inclusief de relaties waarin de entiteit-instanties zich tot elkaar verhouden. Per relatie is bovendien aangegeven welke cardinaliteit (herhaalbaarheid) deze heeft en welke status (optional/optioneel (O), dependent/afhankelijk (D), required/verplicht (R), choice/keuze (X)) deze bezit. In geval de status van de relatie afhankelijk is, moet er in ieder geval een business rule worden gespecificeerd die beschrijft op welke wijze de betreffende relatie afhankelijk is. NB. bij het vaststellen van de berichthiërarchie voor een bepaald berichttype, is het van belang om niet alleen sec naar dit berichttype te kijken, maar vooral ook naar andere gelijkgeaarde berichttypen. Door de berichthiërarchieën van verschillende gelijkgeaarde berichttypen zoveel als mogelijk op elkaar af te stemmen (gelijkwaardig te maken) kan een aanzienlijk synergie voordeel optreden voor het beheer en de implementatie van deze elektronische ketenberichten. In onderstaand voorbeeld moet de entiteit-instantie ClientSuwi verplicht 1x voorkomen. Voor deze ClientSuwi moet bovendien een DomicilieAdres opgegeven worden, hetgeen een keuze betekent tussen een Straatadres en een StraatadresBuitenland. Voor deze ClientSuwi kunnen daarnaast tot maximaal 99 Arbeidsverhoudingen onderscheiden worden, echter een Arbeidsverhouding is niet verplicht. Verder in de hiërarchie blijkt dat voor een Partner en een Onderhoudsplichtige ook Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 58 van 103

59 een DomicilieAdres (inclusief keuze tussen Straatadres en StraatadresBuitenland ) kan worden opgegeven, echter in deze gevallen is het DomicilieAdres niet verplicht. NB. het gaat hier feitelijk om verschillende instanties van de entiteit DomicilieAdres, hetgeen tot uitdrukking kan komen in de status van de attributen die per entiteit-instantie van DomicilieAdres kan worden gespecificeerd (dit wordt verder uitgelegd in het hiërarchisch entiteiten-attributen overzicht). Tot slot blijkt dat ook voor een Kind een DomicilieAdres (inclusief keuze tussen Straatadres en StraatadresBuitenland ) kan worden opgegeven, echter deze entiteit-instantie van DomicilieAdres is afhankelijk van een business rule (br) die luidt: Voor kinderen jonger dan 18 jaar moet het DomicilieAdres verplicht ingevuld worden, in alle andere gevallen is het DomicilieAdres niet noodzakelijk en kan het achterwege blijven. ClientSuwi 1x R DomicilieAdres 1x R Straatadres 1x X StraatadresBuitenland 1x X Arbeidsverhouding 99x O Uitkeringsverhouding 99x O Huwelijk 9x O Partner 1x R DomicilieAdres 1x O Straatadres 1x X StraatadresBuitenland 1x X Onderhoudsplicht 1x O Onderhoudsplichtige 1x R DomicilieAdres 1x O Straatadres 1x X StraatadresBuitenland 1x X Kind 99x O DomicilieAdres 1x D br01 Straatadres 1x X StraatadresBuitenland 1x X br01: Voor kinderen jonger dan 18 jaar moet het DomicilieAdres verplicht ingevuld worden, in alle andere gevallen is het DomicilieAdres niet noodzakelijk en kan het achterwege blijven. 2. Hiërarchisch entiteiten-attributen overzicht. Per berichttype wordt naast een berichthiërarchisch entiteiten-relaties overzicht ook een hiërarchisch entiteiten-attributen overzicht vastgelegd. In het hiërarchisch entiteiten-attributen overzicht wordt per entiteit-instantie uit het hiërarchisch entiteiten-relaties overzicht de status van de attributen gespecificeerd die in de betreffende entiteit-instantie voorkomen. Dit betekent dat een entiteit, die in zijn geheel éénmaal wordt gespecificeerd in het Suwi Gegevensregister (SGR), per entiteit-instantie in het hiërarchisch entiteiten-relaties overzicht apart wordt gespecificeerd zodanig dat alleen de voor die entiteit-instantie beschikbare attributen worden vastgelegd met een status (optional/optioneel (O), dependent/afhankelijk (D), required/verplicht (R)) en een (eventueel aangepast) waardebereik. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 59 van 103

60 Attributen kennen geen cardinaliteit, elk attribuut mag maximaal één keer voorkomen binnen een entiteit-instantie. NB. iedere afhankelijkheid moet aanvullend beschreven worden met een business rule. In onderstaand voorbeeld worden alle entiteit-instanties uit het hiërarchisch entiteiten-relaties overzicht opgesomd en wordt per attribuut behorend bij een entiteit-instantie de status en het waardebereik beschreven: ClientSuwi wordt in dit berichttype geïdentificeerd met behulp van een verplicht Sofinummer en een optionele Voornaam en Achternaam. Alle andere attributen van ClientSuwi die in het SGR zijn gespecificeerd, zijn voor dit berichttype niet relevant en worden achterwege gelaten. DomicilieAdres van ClientSuwi moet, in het geval het een Straatadres betreft, verplicht een Straatnaam, Huisnummer, Postcode en Woonplaats bevatten. GemeenteCode is optioneel en bovendien, ten opzichte van alle mogelijke gemeentecodes vastgelegd in het SGR, voor dit berichttype beperkt tot de codes AA, AB en AC. DomicilieAdres van ClientSuwi moet, in het geval het een StraatadresBuitenland betreft, verplicht een StraatnaamBuitenland, HuisnrBuitenland, WoonplaatsnaamBuitenland en LandencdIso bevatten. LandencdIso is bovendien, ten opzichte van alle mogelijke landencodes vastgelegd in het SGR, voor dit berichttype beperkt tot de codes BE, VS en FR. PostcdBuitenland, LocatieomsBuitenland, RegionaamBuitenland en Landsnaam zijn optioneel. DomicilieAdres van Partner moet, in het geval het een Straatadres betreft, verplicht een Postcode bevatten. DomicilieAdres van Partner moet, in het geval het een StraatadresBuitenland betreft, verplicht een PostcdBuitenland bevatten. DomicilieAdres van Onderhoudsplichtige moet, in het geval het een Straatadres betreft, verplicht een Woonplaats bevatten. DomicilieAdres van Onderhoudsplichtige moet, in het geval het een StraatadresBuitenland betreft, verplicht een WoonplaatsnaamBuitenland bevatten. DomicilieAdres van Kind moet, in het geval het een Straatadres betreft, een Postcode bevatten en kan, afhankelijk van een business rule, een WoningType bevatten. Deze business rule luidt: Voor kinderen ouder dan 4 jaar en jonger dan 18 jaar moet het WoningType verplicht ingevuld worden, in alle andere gevallen is het WoningType niet noodzakelijk en kan het achterwege blijven. DomicilieAdres van Kind moet, in het geval het een StraatadresBuitenland betreft, verplicht een PostcdBuitenland bevatten. In het voorbeeld wordt de meest rechter kolom met datatype-formaatdefinities (bijvoorbeeld an..140 of n8) direct afgeleid uit het SGR, deze is niet aanpasbaar op berichttype niveau. De datatype-formaatdefinities zijn alleen ter informatie en verduidelijking opgenomen. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 60 van 103

61 ClientSuwi Sofinummer R an11 Voornaam O an..140 Achternaam O an..140 ClientSuwi DomicilieAdres - Straatadres Straatnaam R an..140 Huisnummer R an..35 Postcode R an6 Woonplaats R an..70 GemeenteCode O a2 AA AB AC Aalsmeer Abcoude Achterberg ClientSuwi DomicilieAdres - StraatadresBuitenland StraatnaamBuitenland R an..140 HuisnrBuitenland R an..35 PostcdBuitenland O an..9 WoonplaatsnaamBuitenland R an..70 LocatieomsBuitenland O an..70 RegionaamBuitenland O an..70 LandencdIso R a2 BE VS België Verenigde Staten FR Frankrijk Landsnaam O an..70 ClientSuwi - Arbeidsverhouding DatBArbeidsverhouding R n8 DatEArbeidsverhouding O n8 OmsRedenEindeArbeidsverhouding D an..280 br02 br02: OmsRedenEindeArbeidsverhouding moet verplicht gevuld worden als DatEArbeidsverhouding gevuld is, in alle andere gevallen mag OmsRedenEindeArbeidsverhouding niet gevuld worden. ClientSuwi - Uitkeringsverhouding DatBUitkeringsverhouding R n8 DatEUitkeringsverhouding O n8 OmsRedenEindeUitkeringsverh D an..280 br03 br03: OmsRedenEindeUitkeringsverh moet verplicht gevuld worden als DatEUitkeringsverhouding gevuld is, in alle andere gevallen mag OmsRedenEindeUitkeringsverh niet gevuld worden. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 61 van 103

62 ClientSuwi - Huwelijk Huwelijksdatum R n8 HuwelijksGemeenteCode O a2 AA CA Aalsmeer Catzand DO Domburg TN Terneuzen ClientSuwi - Huwelijk - Partner Sofinummer R an11 Geboortedatum R n8 ClientSuwi - Huwelijk - Partner DomicilieAdres - Straatadres Postcode R an6 ClientSuwi - Huwelijk - Partner DomicilieAdres - StraatadresBuitenland PostcdBuitenland R an..9 ClientSuwi - Huwelijk - Onderhoudsplicht OnderhoudsplichtCode R n1 1 Financieel 2 Onderdak 3 Voeding 4 Scholing ClientSuwi - Huwelijk - Onderhoudsplicht - Onderhoudsplichtige Sofinummer R an11 Geboortedatum O n8 ClientSuwi - Huwelijk - Onderhoudsplicht - Onderhoudsplichtige DomicilieAdres - Straatadres Woonplaats R an..70 ClientSuwi - Huwelijk - Onderhoudsplicht - Onderhoudsplichtige DomicilieAdres - StraatadresBuitenland WoonplaatsnaamBuitenland R an..70 ClientSuwi - Kind Sofinummer R an11 Geboortedatum R n8 Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 62 van 103

63 ClientSuwi - Kind DomicilieAdres - Straatadres Postcode R an6 WoningType D a2 WB Woonboot WW Woonwagen ET Etage RH Rijtjeshuis VH Vrijstaand huis br04 br04: Voor kinderen ouder dan 4 jaar en jonger dan 18 jaar moet het WoningType verplicht ingevuld worden, in alle andere gevallen is het WoningType niet noodzakelijk en kan het achterwege blijven. ClientSuwi - Kind DomicilieAdres - StraatadresBuitenland PostcdBuitenland R an..9 Samenvattend moeten de volgende stappen doorlopen worden om te komen tot een functionele berichtspecificatie: Leg de definitie van alle benodigde informatie-objecten vast in het gegevensmodel, met behulp van entiteiten, attributen, domeinen, codelijsten en relaties. Selecteer een gezichtspunt (hoofdonderwerp) op basis waarvan de berichthiërarchie (het berichtmodel) zal worden opgebouwd. Stel het gekozen gezichtspunt (hoofdonderwerp) als root van de berichthiërarchie (het berichtmodel) en bepaal welke relaties tussen entiteiten voor dit berichtmodel van toepassing zijn. Bepaal daarbij ook de cardinaliteit (herhaalbaarheid) en status (optional/optioneel (O), dependent/afhankelijk (D), required/verplicht (R), choice/keuze (X)) van iedere hiërarchische entiteit-instantie. NB. houd rekening met andere gelijkgeaarde berichttypen en probeer de berichthiërarchieën zoveel als mogelijk op elkaar af te stemmen (gelijkwaardig te maken). Bepaal per hiërarchische entiteit-instantie welke attributen uit de oorspronkelijke informatieobject definitie in het gegevensmodel, voor dit berichtmodel van toepassing zijn en bepaal bovendien de status (optional/optioneel (O), dependent/afhankelijk (D), required/verplicht (R)) van ieder attribuut. Bepaal per hiërarchische entiteit-instantie, voor alle attributen waarvan de onderliggende domeindefinitie (het waardebereik) in het gegevensmodel gecodeerd is, welke codes toegestaan zijn en welke niet. Met andere woorden: bepaal de code-subsets per hiërarchisch voorkomen van een gecodeerd attribuut. Stel alle business rules in het berichtmodel op. In de business rules worden de eisen verwoord die gelden voor dit specifieke berichtmodel ten aanzien van vulling, waardebereik, afhankelijkheden, etc. Business rules worden alleen apart opgesteld voor zover het eisen betreft die niet tot uitdrukking kunnen worden gebracht binnen een van de voorgaande stappen. Appendix A geeft aan op welke wijze een functionele berichtspecificatie met behulp van het berichtmodelleertool EC-Design wordt vastgelegd. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 63 van 103

64 Technische berichtspecificatie (SuwiML berichtschemaset) De wijze waarop de technische berichtspecificatie wordt opgebouwd, wordt beschreven in hoofdstuk 4. Belangrijk voordeel bij het vastleggen van de functionele berichtspecificatie in het berichtmodelleertool EC-Design, is dat de technische berichtspecificatie, i.e. de SuwiML body van de SuwiML berichtschemaset, voor het merendeel direct gegenereerd kan worden vanuit EC- Design. Functioneel applicatieontwerp Het functioneel applicatieontwerp binnen de specificatie van een elektronisch ketenbericht, bevat een gedetailleerde beschrijving van de wijze waarop elektronische ketenberichten worden gevuld danwel verwerkt door de bedrijfsapplicatie / het bedrijfsproces van de verzender respectievelijk ontvanger. Het functioneel applicatieontwerp beschrijft zeer exact de wijze waarop de interne structuur van een communicatie-actor (ketenpartij) wordt gemapt (inclusief eventueel noodzakelijk veldwaarde-transformaties) op de beoogde communicatiestructuur/uitwisselingsformaat. Transactiestandaard implementatiedocument Het transactiestandaard implementatiedocument beschrijft op welke manier de vrijheidsgraden binnen de SuwiML transactiestandaard zijn geïmplementeerd binnen de operationele omgeving van het elektronische ketenbericht. Het transactiestandaard implementatiedocument beschrijft welke specifieke keuzes zijn gemaakt tav time-out, herhalingspogingnummer, transactiemanagement, etc. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 64 van 103

65 6. Definities Binnen SGR/SuwiML worden een aantal specifieke begrippen gebruikt. Onderstaand volgt een beknopte lijst van begrippen met een beschrijving van de betekenis binnen SGR/SuwiML. berichttype Een berichttype is de aanduiding voor een logische proceskoppeling waarin gegevens middels een bericht worden uitgewisseld. Bijvoorbeeld het berichttype Reïntegratieadvies, UwvDossierPersoon of AanvraagWwb. business operational view Business Operational View (BOV): a perspective of business transactions limited to those aspects regarding the making of business decisions and commitments among organizations, which are needed for the description of a business transaction. (Open-EDI Reference Model Standard ISO/IEC 14662). cluster Een cluster is een herbruikbare (verbijzonderde) hiërarchische berichtcomponent. Een cluster bevat definities van entiteiten inclusief relaties naar andere entiteiten. In een cluster wordt ook de cardinaliteit van de aanwezige relaties vastgelegd. Binnen de berichtdefinitie kan door middel van type-referentie gebruik worden gemaakt van clusters. complextype Een XML complextype is een XML type dat de structuur van een XML element definieert. Een XML complextype kan gebaseerd zijn op een ander XML complextype en daarop beperkingen (restriction) of uitbreidingen (extension) bevatten. Een XML complextype omvat een set elementen, waarvan elk element afzonderlijk gebaseerd is op een built-in datatype, simpletype of complextype. datatype (in XML Schema) Een datatype is een getypeerde tekenreeks of string die aan specifieke constraints moet voldoen. Er zijn standaard built-in XML datatypen, zoals string, integer, etc. die worden gebruikt. De constraints van deze datatypen liggen vast in de XML Schema standaard. SuwiML kent ook haar eigen datatypen, nummers, datums, alfanumerieke tekenreeksen, zoals deze in het SGR zijn gedefineerd. Bijvoorbeeld de minimale en maximale waarde van een getal of een enumeratie, zoals in ja/nee. domeindefinitie Een domeindefinitie is van toepassing op een attribuut binnen een entiteit, en beschrijft exact het toegestane waardebereik voor dit attribuut. In een domeindefinitie wordt vastgelegd welke karakters zijn toegestaan binnen het waardebereik, wat het maximaal aantal karakters is en wat het minimum, of er sprake is van een vaste lengte of juist een variabele, of het een numerieke waarde is of een string, of er een codelijst met codes van kracht is, etc. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 65 van 103

66 edi message EDI message: an approved, published, and maintained formal description of how to structure the data required to perform a specific business function, in such a way as to allow for the transfer and handling of this data by electronic means. electronic business Electronic Business: a generic term covering information definition and exchange requirements within and between enterprises, including customers. electronic data interchange Electronic Data Interchange (EDI): the automated exchange of any predefined and structured data for business among information systems of two or more organizations. (Open-EDI Reference Model Standard ISO/IEC 14662). entiteit Een entiteit is een verzameling van logisch bij elkaar horende gegevenselementen die elk afzonderlijk binnen de entiteit maximaal één keer voorkomen. Entiteiten binnen SGR/SuwiML liggen vast in het Suwi Gegevensregister. Een entiteit wordt in een schema vastgelegd in de vorm van een XML complextype. abstracte entiteit Een abstracte entiteit komt zelf nooit voor als instantie in een bericht. De eigenschappen van de entiteit (attributen) en relaties met andere entiteiten, worden gebruikt om afgeleide entiteiten (subclasses) vorm te geven. afhankelijke entiteit Een afhankelijke entiteit is een entiteit die alleen in combinatie met één of enkele andere entiteiten kan bestaan. fundamentele entiteit Een fundamentele entiteit is een entiteit die zelfstandig kan bestaan. relatie entiteit Een relatie entiteit is een afhankelijke entiteit die twee fundamentele entiteiten aan elkaar koppelt. Relatie entiteiten vertegenwoordigen veel-op-veel relaties en/of relaties die nog eigen gegevenselementen bevatten. functional service view Functional Service View (FSV): a perspective of business transactions limited to those information technology interoperability aspects of IT Systems needed to support the execution of open-edi transactions. gegevenstype Een gegevenstype komt overeen met een SGR domeindefinitie welke wordt gebruikt door één of meer SGR gegevenselementen. Een gegevenstype is altijd gebaseerd op een built-in XML Schema datatype maar kan daarop nog constraints bevatten zoals het beperken van de lengte, bijvoorbeeld Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 66 van 103

67 'een string van 10 karakters'. Een gegevenstype is een simpletype of een complextype en vormt de basis voor een XML element definitie in een XML Schema. open-edi Open-EDI: electronic data interchange among multiple autonomous organizations to accomplish an explicit shared business goal according to open-edi standards (i.e. that comply with the Open-EDI Reference Model Standard ISO/IEC 14662). simpletype Een XML simpletype is een XML type dat de inhoud van een XML element of een XML attribute definieert. Een XML simpletype kan gebaseerd zijn op een ander XML simpletype of op een built-in XML Schema datatype en kan daarop nadere beperkingen bevatten. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 67 van 103

68 7. Referenties [ebxml] Electronic Business using extensible Markup Language (ebxml) [ec-design] Softwaretool dat de methodische ontwikkeling van elektronische berichten op basis van een gemeenschappelijk gegevensmodel ondersteunt. Berichtspecificaties worden opgesteld vanuit een logisch/functioneel gezichtspunt; de functionaliteit van een bericht is leidend en pas als deze volledig en eenduidig is vastgesteld, wordt vanuit de functionele berichtspecificatie het bijbehorende XML Schema gegenereerd. [iso] International Organization for Standardization (ISO) Development of messages ISO/NP Information technology - Metadata registries - ISO/IEC Open-EDI Reference Model ISO/IEC [oasis] Organization for the Advancement of Structured Information Standards (OASIS) [protocols] W3C Protocols [rup] IBM Rational Rose Rational Unified Process methodology (RUP) [soap] Simple Object Access Protocol SOAP/1.1, W3C Note 08 May 2000 Authors: Don Box (DevelopMentor), David Ehnebuske (IBM), Gopal Kakivaya (Microsoft), Andrew Layman (Microsoft), Noah Mendelsohn (Lotus Development Corp.), Henrik Frystyk Nielsen (Microsoft), Satish Thatte (Microsoft), Dave Winer (UserLand Software, Inc.) Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 68 van 103

69 [uml] Object Management Group (OMG) Unified Modelling Language (UML) [umm] United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) Modelling Methodology (UMM) [w3c] World Wide Web Consortium (W3C) [web services] [xml] Extensible Markup Language (XML) 1.0 (Third Edition), W3C Recommendation 04 February 2004 Editors: Tim Bray (Textuality and Netscape Jean Paoli (Microsoft C. M. Sperberg-McQueen (W3C Eve Maler (Sun Microsystems, Inc. François Yergeau [xml-namespaces] Namespaces in XML, W3C Recommendation 14 January 1999 Editors: Tim Bray (Textuality Dave Hollander (Hewlett-Packard Company Andrew Layman (Microsoft [xml-schema] XML Schema (Second Edition), W3C Recommendation 28 October 2004 Editors (Part 0: Primer): David C. Fallside (IBM Priscilla Walmsley (Part 0: Primer) Editors (Part 1: Structures): Henry S. Thompson (University of Edinburgh David Beech (Oracle Corporation Murray Maloney (for Commerce One Noah Mendelsohn (Lotus Development Corporation (Part 1: Structures) Editors (Part 2: Datatypes): Paul V. Biron (Kaiser Permanente, for Health Level Seven Ashok Malhotra (Microsoft (formerly of IBM) (Part 2: Datatypes) Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 69 van 103

70 [xslt] XSL Transformations (XSLT) Version 1.0, W3C Recommendation 16 November 1999 Editor: James Clark Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 70 van 103

71 Appendix A Figuur 38: berichtmodel voor ReintegratieadviesCwiUwv zoals vastgelegd in EC-Design. Auteur: Paul Vriend SuwiML berichtstandaard v0201.doc - 71 van 103

72 Functionele berichtspecificatie zoals vastgelegd in EC-Design. Business chain: SUWI Gegevensregister 2.01 Transaction type: Reintegratieadvies Functional message: Reintegratieadvies CWI-UWV v0102-b09 Actor group: Standard Messages XML Tag Set: SuwiML tagset Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 72 van 103

73 Summary Opdracht verzending melding Contactpersoon/-afdeling (Bron) Telefoonnummer Contactpersoon Afdeling adres Contactpersoon/-afdeling Vestiging SUWI Partij SUWI Kolom SUWI Reintegratieadvies Client SUWI Straatadres Straatadres buitenland Telefoonnummer Client adres client Nationaliteit Kwalificerende intake Uitkeringsverhouding SZ wet Partij SUWI Kolom SUWI Sollicitatie Wijze van solliciteren Reintegratieactiviteit Situatie client arbeidsinpassing Belemmering arbeidsinpassing Beroepsperspectief en realiteitszin Bijzonderheid werkaanvaarding Beschikbaarheid client voor arbeid Beroep Beroepsnaam ongecodeerd Motivatie client Zelfredzaamheid op de arbeidsplaats Arbeidsmarktorientatie Arbeidsmarktkwalificaties 1..1, R 1..1, R 1..1, R 1..1, R 1..1, R 1..1, R 1..1, R 1..1, R 1..1, R 1..1, X 1..1, X 0..2, O 0..1, O 1..1, R 1..1, R 1..*, R 1..1, R 1..1, R 1..1, R 1..1, R 0..*, O 1..*, R 1..1, R 1..*, R 1..1, R 0..*, O 1..1, R 0..4, O 1..1, R 1..1, R 1..1, R 1..1, R 1..1, R Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 73 van 103

74 OPDRACHT VERZENDING MELDING OPDRACHT VERZENDING MELDING xml tag: OpdrachtVerzendingMelding 1..1, R Applied Transaction Rules TR-01 Status omschrijving versus code Datum opdracht tot verzending bericht R n8 domain: Standaarddatum xml tag: DatOpdrachtTotVerzendingBericht Tijdstip opdracht tot verzending bericht R n8 domain: Tijdstip xml tag: TijdOpdrachtTotVerzendingBericht CONTACTPERSOON/-AFDELING (BRON) 1..1, R opdracht verzending melding - CONTACTPERSOON/ -AFDELING (BRON) xml tag: Bron Naam contactpersoon/-afdeling R an..35 domain: Omschrijving AN..35 xml tag: NaamContactpersoonAfd TELEFOONNUMMER CONTACTPERSOON AFDELING 1..1, R opdracht verzending melding - contactpersoon/ -afdeling (bron) - TELEFOONNUMMER CONTACTPERSOON AFDELING xml tag: TelefoonnrContactpersoonAfd Netnummer R n..5 domain: Netnummer xml tag: Netnr Abonneenummer R n..10 domain: Abonneenummer N..10 xml tag: Abonneenr ADRES CONTACTPERSOON/-AFDELING 1..1, R opdracht verzending melding - contactpersoon/ -afdeling (bron) - ADRES CONTACTPERSOON/ -AFDELING xml tag: AdresContactpersoonAfd adres R an..320 domain: adres Applied Functional Message Rules FM-RL01 Waardebereik adres Bron xml tag: Adres VESTIGING SUWI 1..1, R opdracht verzending melding - contactpersoon/ -afdeling (bron) - VESTIGING SUWI xml tag: VestigingSuwi Code vestiging SUWI R n4 domain: Code vestiging SUWI xml tag: CdVestigingSuwi Naam vestiging SUWI R an..70 domain: Naam AN..70 xml tag: NaamVestigingSuwi Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 74 van 103

75 PARTIJ SUWI 1..1, R opdracht verzending melding - contactpersoon/ -afdeling (bron) - vestiging suwi - PARTIJ SUWI xml tag: PartijSuwi Code partij SUWI R n4 domain: Code partij SUWI Applied Functional Message Rules FM-RL03 Standaardwaarde partij Suwi Bron xml tag: CdPartijSuwi Naam partij SUWI R an..70 domain: Naam AN..70 Applied Functional Message Rules FM-RL03 Standaardwaarde partij Suwi Bron xml tag: NaamPartijSuwi KOLOM SUWI 1..1, R opdracht verzending melding - contactpersoon/ -afdeling (bron) - vestiging suwi - partij suwi - KOLOM SUWI xml tag: KolomSuwi Code kolom SUWI R n1 domain: Code kolom SUWI xml tag: CdKolomSuwi code list: Code kolom SUWI (subset selected) 6 CWI Naam kolom SUWI R an..35 domain: Omschrijving AN..35 Applied Functional Message Rules FM-RL02 Standaardwaarde naam kolom Suwi Bron xml tag: NaamKolomSuwi REINTEGRATIEADVIES opdracht verzending melding - REINTEGRATIEADVIES xml tag: Reintegratieadvies 1..1, R Applied Functional Message Rules FM-RL24 Waardebereik uitkeringsverhouding Datum ondertekening reintegratieadvies R n8 domain: Standaarddatum xml tag: DatOndertekReintegratieadvies Toelichting reintegratieadvies R an domain: Toelichting AN xml tag: ToelReintegratieadvies Datum vermoedelijke eerste werkloosheidsdag R n8 domain: Standaarddatum xml tag: DatVermoedEersteWerkloosheidsdag Code uitkeringssituatie R n1 domain: Code uitkeringssituatie xml tag: CdUitkeringssituatie code list: Codelijst uitkeringssituatie (subset selected) 1 Ontvangt uitkering Omschrijving uitkeringssituatie R an..80 domain: Omschrijving AN..80 xml tag: OmsUitkeringssituatie Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 75 van 103

76 Toelichting uitkeringssituatie O an domain: Toelichting AN xml tag: ToelUitkeringssituatie CLIENT SUWI 1..1, R opdracht verzending melding - reintegratieadvies - CLIENT SUWI xml tag: ClientSuwi Sofi-nummer R n9 domain: Sofinummer Applied Datamodel Rules DM-RL01 Elfproef sofinummer xml tag: SofiNr Voornamen O a..200 domain: Naam persoon A..200 xml tag: Voornamen Voorletters R a..6 domain: Voorletters xml tag: Voorletters Voorvoegsel O a..10 domain: Voorvoegsels xml tag: Voorvoegsel code list:voorvoegsels (all selected) The codes of this codelist are documented in a separate document Significant deel van de achternaam R a..200 domain: Naam persoon A..200 xml tag: SignificantDeelVanDeAchternaam Geslacht R n1 domain: Geslacht xml tag: Geslacht code list: Geslacht (subset selected) 1 mannelijk 2 vrouwelijk Geboortedatum R n8 domain: Standaarddatum xml tag: Geboortedat Code fictieve geboortedatum R n1 domain: Code fictieve geboortedatum Applied Functional Message Rules FM-RL04 Vulling code fictieve geboortedatum xml tag: CdFictieveGeboortedat code list: Code fictieve geboortedatum (all selected) 0 geen enkel datumdeel is fictief geen enkel datumdeel is fictief 1 dag is fictief dag is fictief 2 maand is fictief maand is fictief 3 dag en maand zijn fictief dag en maand zijn fictief 4 jaar is fictief jaar is fictief 5 dag en jaar zijn fictief dag en jaar zijn fictief Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 76 van 103

77 6 maand en jaar zijn fictief maand en jaar zijn fictief 7 dag, maand en jaar zijn fictief dag, maand en jaar zijn fictief 8 onbekend welke datumdelen fictief zijn onbekend welke datumdelen fictief zijn Omschrijving fictieve geboortedatum R an..80 domain: Omschrijving AN..80 xml tag: OmsFictieveGeboortedat STRAATADRES 1..1, X opdracht verzending melding - reintegratieadvies - client suwi - STRAATADRES xml tag: Straatadres Postcode R an6 domain: Postcode xml tag: Postcd Woonplaatsnaam R an..24 domain: Naam adres Ned AN..24 xml tag: Woonplaatsnaam Gemeentenaam O an..24 domain: Naam adres Ned AN..24 xml tag: Gemeentenaam Straatnaam R an..24 domain: Naam adres Ned AN..24 xml tag: Straatnaam Huisnummer R n..5 domain: Nummer adres Ned N..5 xml tag: Huisnr Huisnummertoevoeging O an..6 domain: Nummer adres Ned AN..6 xml tag: Huisnrtoevoeging STRAATADRES BUITENLAND 1..1, X opdracht verzending melding - reintegratieadvies - client suwi - STRAATADRES BUITENLAND xml tag: StraatadresBuitenland Postcode buitenland R an..9 domain: Nummer adres Buitenl AN..9 xml tag: PostcdBuitenland Woonplaatsnaam buitenland R an..24 domain: Naam adres Buitenl AN..24 xml tag: WoonplaatsnaamBuitenland Landencode ISO R a2 domain: Landencode ISO A2 xml tag: LandencdIso code list:landencode ISO A2 (all selected) The codes of this codelist are documented in a separate document Landsnaam R an..40 domain: Naam adres Buitenl AN..40 xml tag: Landsnaam Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 77 van 103

78 Straatnaam buitenland R an..24 domain: Naam adres Buitenl AN..24 xml tag: StraatnaamBuitenland Huisnummer buitenland R an..9 domain: Nummer adres Buitenl AN..9 xml tag: HuisnrBuitenland TELEFOONNUMMER CLIENT 0..2, O opdracht verzending melding - reintegratieadvies - client suwi - TELEFOONNUMMER CLIENT xml tag: TelefoonnrClient Netnummer R n..5 domain: Netnummer xml tag: Netnr Abonneenummer R n..10 domain: Abonneenummer N..10 xml tag: Abonneenr ADRES CLIENT 0..1, O opdracht verzending melding - reintegratieadvies - client suwi - ADRES CLIENT xml tag: AdresClient adres R an..320 domain: adres xml tag: Adres NATIONALITEIT 1..1, R opdracht verzending melding - reintegratieadvies - client suwi - NATIONALITEIT xml tag: Nationaliteit Code nationaliteit R n4 domain: Tabel nationaliteiten xml tag: CdNationaliteit code list:tabel nationaliteiten (all selected) The codes of this codelist are documented in a separate document Omschrijving nationaliteit R an..80 domain: Omschrijving AN..80 xml tag: OmsNationaliteit KWALIFICERENDE INTAKE 1..1, R opdracht verzending melding - reintegratieadvies - client suwi - KWALIFICERENDE INTAKE xml tag: KwalificerendeIntake Datum einde kwalificerende intake R n8 domain: Standaarddatum xml tag: DatEKwalificerendeIntake Code fase-indeling R n1 domain: Code fase-indeling xml tag: CdFaseIndeling code list: Code fase-indeling (subset selected) 2 fase 2: na kort arbeidsinpassingstraject bemiddelbaar fase 2: na kort arbeidsinpassingstraject bemiddelbaar 3 fase 3: na lang arbeidsinpassingstraject bemiddelbaar fase 3: na lang arbeidsinpassingstraject bemiddelbaar Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 78 van 103

79 Omschrijving fase-indeling R an..80 domain: Omschrijving AN..80 xml tag: OmsFaseIndeling Code aanleiding kwalificerende intake R n2 domain: Code aanleiding kwalificerende intake xml tag: CdAanleidingKwalificerendeIntake code list: Aanleiding Kwalificerende Intake (all selected) 01 verzoek uitkerende instantie 02 einde bemiddelingsactiviteiten 03 op verzoek WIW-organisatie 04 einde inburgering 05 op verzoek klant 06 indicatie bij inschrijving/werkintake Omschrijving aanleiding kwalificerende intake R an..80 domain: Omschrijving AN..80 xml tag: OmsAanlKwalificerendeIntake UITKERINGSVERHOUDING opdracht verzending melding - reintegratieadvies - client suwi - UITKERINGSVERHOUDING xml tag: Uitkeringsverhouding Applied Functional Message Rules FM-RL24 Waardebereik uitkeringsverhouding 1..*, R SZ WET 1..1, R opdracht verzending melding - reintegratieadvies - client suwi - uitkeringsverhouding - SZ WET xml tag: SzWet Code SZ wet R a..5 domain: Tabel SZ-wetten Applied Functional Message Rules FM-RL05 Waardebereik code partij Suwi uitkering FM-RL06 Waardebereik naam partij Suwi uitkering FM-RL08 Waardebereik naam kolom Suwi uitkering FM-RL07 Waardebereik code kolom Suwi uitkering FM-RL24 Waardebereik uitkeringsverhouding xml tag: CdSzWet code list: Tabel SZ-wetten (subset selected) WW Werkloosheidswet Omschrijving SZ wet R an..80 domain: Omschrijving AN..80 xml tag: OmsSzWet PARTIJ SUWI 1..1, R opdracht verzending melding - reintegratieadvies - client suwi - uitkeringsverhouding - PARTIJ SUWI xml tag: PartijSuwi Code partij SUWI R n4 domain: Code partij SUWI Applied Functional Message Rules FM-RL05 Waardebereik code partij Suwi uitkering xml tag: CdPartijSuwi Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 79 van 103

80 Naam partij SUWI R an..70 domain: Naam AN..70 Applied Functional Message Rules FM-RL06 Waardebereik naam partij Suwi uitkering xml tag: NaamPartijSuwi KOLOM SUWI 1..1, R opdracht verzending melding - reintegratieadvies - client suwi - uitkeringsverhouding - partij suwi - KOLOM SUWI xml tag: KolomSuwi Code kolom SUWI R n1 domain: Code kolom SUWI Applied Functional Message Rules FM-RL07 Waardebereik code kolom Suwi uitkering xml tag: CdKolomSuwi code list: Code kolom SUWI (subset selected) 5 UWV Naam kolom SUWI R an..35 domain: Omschrijving AN..35 Applied Functional Message Rules FM-RL08 Waardebereik naam kolom Suwi uitkering xml tag: NaamKolomSuwi SOLLICITATIE 1..1, R opdracht verzending melding - reintegratieadvies - client suwi - SOLLICITATIE xml tag: Sollicitatie Indicatie sollicitaties R n1 domain: Code JaNee Applied Functional Message Rules FM-RL11 Status wijze van solliciteren FM-RL12 Status respons op sollicitaties FM-RL13 Status code gebruik informatiekanalen xml tag: IndSollicitaties code list: Code JaNee (all selected) 1 Ja Ja 2 Nee Nee Code respons op sollicitaties O n1 domain: Code respons op sollicitaties Applied Functional Message Rules FM-RL12 Status respons op sollicitaties xml tag: CdResponsOpSollicitaties code list: Codelijst respons op sollicitaties (all selected) 1 Vaak 2 Soms 3 Niet Omschrijving respons op sollicitaties O an..80 domain: Omschrijving AN..80 Applied Functional Message Rules FM-RL12 Status respons op sollicitaties xml tag: OmsResponsOpSollicitaties Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 80 van 103

81 Toelichting respons op sollicitaties O an..800 domain: Toelichting AN..800 Applied Functional Message Rules FM-RL12 Status respons op sollicitaties xml tag: ToelResponsOpSollicitaties Code beoordeling persoonlijke presentatie R n1 domain: Code beoordeling persoonlijke presentatie xml tag: CdOordeelPersoonlPresentatie code list: Code beoordeling persoonlijke presentatie (all selected) 1 Voor verbetering vatbaar 2 Goed Omschrijving beoordeling persoonlijke presentatie R an..80 domain: Omschrijving AN..80 xml tag: OmsOordeelPersoonlPresentatie Toelichting beoordeling persoonlijke presentatie O an..800 domain: Toelichting AN..800 xml tag: ToelOordeelPersoonlPresentatie Conclusie solliciteren R an domain: Toelichting AN xml tag: ConclSolliciteren WIJZE VAN SOLLICITEREN opdracht verzending melding - reintegratieadvies - client suwi - sollicitatie - WIJZE VAN SOLLICITEREN xml tag: WijzeVanSolliciteren 0..*, O Applied Functional Message Rules FM-RL11 Status wijze van solliciteren Code wijze van solliciteren R n1 domain: Code wijze van solliciteren Applied Functional Message Rules FM-RL14 Status toelichting wijze van solliciteren xml tag: CdWijzeVanSolliciteren code list: Codelijst wijze van solliciteren (all selected) 1 Schriftelijk 2 Telefonisch 3 Open 4 Persoonlijk 9 Anders Omschrijving wijze van solliciteren R an..50 domain: Omschrijving AN..50 xml tag: OmsWijzeVanSolliciteren Toelichting wijze van solliciteren O an..800 domain: Toelichting AN..800 Applied Functional Message Rules FM-RL14 Status toelichting wijze van solliciteren xml tag: ToelWijzeVanSolliciteren Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 81 van 103

82 REINTEGRATIEACTIVITEIT 1..*, R opdracht verzending melding - reintegratieadvies - REINTEGRATIEACTIVITEIT xml tag: Reintegratieactiviteit Code reintegratieactiviteit R n2 domain: Code reintegratieactiviteit Applied Functional Message Rules FM-RL17 Status toelichting reintegratieactiviteit xml tag: CdReintegratieactiviteit code list: Reintegratieactiviteiten (all selected) 01 specifieke bemiddeling 02 werkervaring/wiw 03 een WSW-dienstverband 04 orientatietraject 05 training 06 scholing 07 specifieke hulpverlening 08 REA 09 anders Omschrijving reintegratieactiviteit R an..50 domain: Omschrijving AN..50 xml tag: OmsReintegratieactiviteit Toelichting reintegratieactiviteit O an..800 domain: Toelichting AN..800 Applied Functional Message Rules FM-RL17 Status toelichting reintegratieactiviteit xml tag: ToelReintegratieactiviteit SITUATIE CLIENT ARBEIDSINPASSING 1..1, R opdracht verzending melding - reintegratieadvies - SITUATIE CLIENT ARBEIDSINPASSING xml tag: SituatieClientArbeidsinpassing Toelichting persoonlijke situatie O an domain: Toelichting AN xml tag: ToelPersoonlijkeSituatie Conclusie persoonlijke situatie R an domain: Toelichting AN xml tag: ConclPersoonlijkeSituatie BELEMMERING ARBEIDSINPASSING 1..*, R opdracht verzending melding - reintegratieadvies - situatie client arbeidsinpassing - BELEMMERING ARBEIDSINPASSING xml tag: BelemmeringArbeidsinpassing Code belemmering arbeidsinpassing R n2 domain: Code belemmering arbeidsinpassing Applied Functional Message Rules FM-RL09 Vulling omschr.andere belemmering arbeidsinpassing xml tag: CdBelemmeringArbeidsinpassing code list: Belemmering Arbeidsinpassing (all selected) 00 Geen 01 Gezondheid - lichamelijk 02 Gezondheid - psychisch 03 Sociaal-maatschappelijk - financieel 04 Sociaal-maatschappelijk - huisvesting 05 Sociaal-maatschappelijk - justitieel Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 82 van 103

83 06 Sociaal-maatschappelijk - invloed persoonlijke omgeving/persoonlijke overtuiging 07 Socia al-maatschappelijk - verslaving 08 Sociaal-maatschappelijk - zorgtaken 99 Anders Omschrijving belemmering arbeidsinpassing R an..80 domain: Omschrijving AN..80 xml tag: OmsBelemmeringArbeidsinpassing Omschrijving andere belemmering arbeidsinpassing O an..80 domain: Omschrijving AN..80 Applied Functional Message Rules FM-RL09 Vulling omschr.andere belemmering arbeidsinpassing xml tag: OmsAndereBelemmeringArbeidsinpas BEROEPSPERSPECTIEF EN REALITEITSZIN 1..1, R opdracht verzending melding - reintegratieadvies - BEROEPSPERSPECTIEF EN REALITEITSZIN xml tag: BeroepsperspectiefRealiteitszin Conclusie beroepsperspectief en realiteitszin R an domain: Toelichting AN xml tag: ConclBeroepsperspectief Toelichting vastgestelde bemiddelingsberoepen O an..320 domain: Toelichting AN..320 xml tag: ToelVastgesteldeBeroepen BIJZONDERHEID WERKAANVAARDING 0..*, O opdracht verzending melding - reintegratieadvies - beroepsperspectief en realiteitszin - BIJZONDERHEID WERKAANVAARDING xml tag: BijzonderheidWerkaanvaarding Code bijzonderheid werkaanvaarding R n2 domain: Code bijzonderheid werkaanvaarding xml tag: CdBijzonderheidWerkaanvaarding code list: Codelijst bijzonderheid werkaanvaarding (subset selected) 01 Arbeidsvoorwaarden 02 Werktijden 03 Vervoer 04 Beschikbaarheid 05 Reistijd Omschrijving bijzonderheid werkaanvaarding R an..80 domain: Omschrijving AN..80 xml tag: OmsBijzonderheidWerkaanvaarding Toelichting bijzonderheid werkaanvaarding R an domain: Toelichting AN xml tag: ToelBijzonderheidWerkaanvaarding BESCHIKBAARHEID CLIENT VOOR ARBEID 1..1, R opdracht verzending melding - reintegratieadvies - beroepsperspectief en realiteitszin - BESCHIKBAARHEID CLIENT VOOR ARBEID xml tag: BeschikbaarheidClientVoorArbeid Aantal uren per week beschikbaar voor arbeid R n4 domain: Aantal uren N4 xml tag: AantUrenWeekBeschikbVoorArbeid Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 83 van 103

84 Indicatie beschikbaarheid conform richtlijn passende ar R n1 domain: Code JaNeeNVT Applied Functional Message Rules FM-RL10 Status toelichting beschikbaarheid voor arbeid xml tag: IndBeschikbheidConformRichtlijn code list: Code JaNeeNVT (all selected) 1 Ja Ja 2 Nee Nee 8 Niet van toepassing Niet van toepassing Toelichting beschikbaarheid voor arbeid O an..320 domain: Toelichting AN..320 Applied Functional Message Rules FM-RL10 Status toelichting beschikbaarheid voor arbeid xml tag: ToelBeschikbaarheidVoorArbeid BEROEP opdracht verzending melding - reintegratieadvies - BEROEPsperspectief en realiteitszin - BEROEP xml tag: Bemiddelingsberoep 0..4, O BEROEPSNAAM ONGECODEERD 1..1, R opdracht verzending melding - reintegratieadvies - beroepsperspectief en realiteitszin - beroep - BEROEPSNAAM ONGECODEERD xml tag: BeroepsnaamOngecodeerd Applied Functional Message Rules FM-RL18 Status aansl. werkervaring op bemiddelingsberoep FM-RL19 Status aansl. werkervaring op arbeidsmarkt FM-RL20 Status aansl. opleiding op bemiddelingsberoep FM-RL21 Status aansl. opleiding op arbeidsmarkt FM-RL22 Status aansl. competentie op bemiddelingsberoep FM-RL23 Status aansl. competentie op arbeidsmarkt Naam beroep ongecodeerd R an..120 domain: Omschrijving AN..120 xml tag: NaamBeroepOngecodeerd MOTIVATIE CLIENT 1..1, R opdracht verzending melding - reintegratieadvies - MOTIVATIE CLIENT xml tag: MotivatieClient Code beoordeling aantal sollicitaties O n1 domain: Code beoordeling aantal sollicitaties xml tag: CdBeoordAantSollicitaties code list: Beoordeling aantal sollicitaties (all selected) 1 Goed 2 Voldoende 3 Onvoldoende 4 Niet 9 Niet van toepassing Omschrijving beoordeling aantal sollicitaties O an..80 domain: Omschrijving AN..80 xml tag: OmsBeoordAantSollicitaties Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 84 van 103

85 Toelichting beoordeling aantal sollicitaties O an..800 domain: Toelichting AN..800 xml tag: ToelBeoordAantSollicitaties Code bereidheid thvv reintegratieactiviteiten R n1 domain: Code bereidheid thvv reintegratieactiviteiten xml tag: CdBereidheidReintegratie code list: Bereidheid tot het volgen van reintegratieactiviteiten (all selected) 2 Voldoende 3 Onvoldoende 4 Niet Omschrijving bereidheid thvv reintegratieactiviteiten R an..80 domain: Omschrijving AN..80 xml tag: OmsBereidheidReintegratie Toelichting bereidheid thvv reintegratieactiviteiten O an..800 domain: Toelichting AN..800 xml tag: ToelBereidheidReintegratie Conclusie sollicitatiegedrag en bereidheid reintegratie R an domain: Toelichting AN xml tag: ConclSollicitatiegedrag ZELFREDZAAMHEID OP DE ARBEIDSPLAATS 1..1, R opdracht verzending melding - reintegratieadvies - ZELFREDZAAMHEID OP DE ARBEIDSPLAATS xml tag: ZelfredzaamheidOpDeArbeidsplaats Code belemmering taalbeheersing R n1 domain: Code belemmering taalbeheersing Applied Functional Message Rules FM-RL15 Status toelichting belemmering taalbeheersing xml tag: CdBelemmeringTaalbeheersing code list: Code belemmering door taalbeheersing (all selected) 1 Niet 2 Enigszins 3 Mogelijk 4 Zeker Omschrijving belemmering taalbeheersing R an..80 domain: Omschrijving AN..80 xml tag: OmsBelemmeringTaalbeheersing Toelichting belemmering taalbeheersing O an..800 domain: Toelichting AN..800 Applied Functional Message Rules FM-RL15 Status toelichting belemmering taalbeheersing xml tag: ToelBelemmeringTaalbeheersing Indicatie aandachtspunten houding-gedrag-verantwoordeli R n1 domain: Code JaNee Applied Functional Message Rules FM-RL16 Status toelichting aandachtspunten houding gedrag xml tag: IndAandachtspuntenHouding code list: Code JaNee (all selected) 1 Ja Ja 2 Nee Nee Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 85 van 103

86 Toelichting aandachtspunten houding-gedrag-verantwoorde O an..800 domain: Toelichting AN..800 Applied Functional Message Rules FM-RL16 Status toelichting aandachtspunten houding gedrag xml tag: ToelAandachtspuntenHouding Conclusie zelfredzaamheid op de arbeidsplaats R an domain: Toelichting AN xml tag: ConclZelfredzaamhArbeidsplaats ARBEIDSMARKTORIENTATIE 1..1, R opdracht verzending melding - reintegratieadvies - ARBEIDSMARKTORIENTATIE xml tag: Arbeidsmarktorientatie Code realiteitszin werkgerichtheid R n1 domain: Code onvoldoende voldoende goed xml tag: CdRealiteitszinWerkgerichtheid code list: CodeOnvoldVoldGoed (all selected) 1 Goed Goed 2 Voldoende Voldoende 3 Onvoldoende Onvoldoende Omschrijving realiteitszin werkgerichtheid R an..80 domain: Omschrijving AN..80 xml tag: OmsRealiteitszinWerkgerichtheid Toelichting realiteitszin werkgerichtheid O an..800 domain: Toelichting AN..800 xml tag: ToelRealiteitszinWerkgerichtheid Code gebruik informatiekanalen O n1 domain: Code onvoldoende voldoende goed Applied Functional Message Rules FM-RL13 Status code gebruik informatiekanalen xml tag: CdGebruikInformatiekanalen code list: CodeOnvoldVoldGoed (all selected) 1 Goed Goed 2 Voldoende Voldoende 3 Onvoldoende Onvoldoende Omschrijving gebruik informatiekanalen O an..80 domain: Omschrijving AN..80 xml tag: OmsGebruikInformatiekanalen Toelichting gebruik informatiekanalen O an..800 domain: Toelichting AN..800 xml tag: ToelGebruikInformatiekanalen Conclusie arbeidsmarktorientatie R an domain: Toelichting AN xml tag: ConclArbeidsmarktorientatie Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 86 van 103

87 ARBEIDSMARKTKWALIFICATIES 1..1, R opdracht verzending melding - reintegratieadvies - ARBEIDSMARKTKWALIFICATIES xml tag: Arbeidsmarktkwalificaties Code aansluiting werkervaring op bemiddelingsberoep O n1 domain: Code onvoldoende voldoende goed Applied Functional Message Rules FM-RL18 Status aansl. werkervaring op bemiddelingsberoep xml tag: CdAanslWerkervaringOpBeroep code list: CodeOnvoldVoldGoed (all selected) 1 Goed Goed 2 Voldoende Voldoende 3 Onvoldoende Onvoldoende Omschrijving aansluiting werkervaring op bemiddelingsbe O an..80 domain: Omschrijving AN..80 xml tag: OmsAanslWerkervaringOpBeroep Toelichting aansluiting werkervaring op bemiddelingsber O an..800 domain: Toelichting AN..800 xml tag: ToelAanslWerkervaringOpBeroep Code aansluiting werkervaring op arbeidsmarkt O n1 domain: Code onvoldoende voldoende goed Applied Functional Message Rules FM-RL19 Status aansl. werkervaring op arbeidsmarkt xml tag: CdAanslWerkervaringOpArbeid code list: CodeOnvoldVoldGoed (all selected) 1 Goed Goed 2 Voldoende Voldoende 3 Onvoldoende Onvoldoende Omschrijving aansluiting werkervaring op arbeidsmarkt O an..80 domain: Omschrijving AN..80 xml tag: OmsAanslWerkervaringOpArbeid Toelichting aansluiting werkervaring op arbeidsmarkt O an..800 domain: Toelichting AN..800 xml tag: ToelAanslWerkervaringOpArbeid Code aansluiting opleiding op bemiddelingsberoep O n1 domain: Code onvoldoende voldoende goed Applied Functional Message Rules FM-RL20 Status aansl. opleiding op bemiddelingsberoep xml tag: CdAanslOpleidingOpBeroep code list: CodeOnvoldVoldGoed (all selected) 1 Goed Goed 2 Voldoende Voldoende 3 Onvoldoende Onvoldoende Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 87 van 103

88 Omschrijving aansluiting opleiding op bemiddelingsberoe O an..80 domain: Omschrijving AN..80 xml tag: OmsAanslOpleidingOpBeroep Toelichting aansluiting opleiding op bemiddelingsberoep O an..800 domain: Toelichting AN..800 xml tag: ToelAanslOpleidingOpBeroep Code aansluiting opleiding op arbeidsmarkt O n1 domain: Code onvoldoende voldoende goed Applied Functional Message Rules FM-RL21 Status aansl. opleiding op arbeidsmarkt xml tag: CdAanslOpleidingOpArbeid code list: CodeOnvoldVoldGoed (all selected) 1 Goed Goed 2 Voldoende Voldoende 3 Onvoldoende Onvoldoende Omschrijving aansluiting opleiding op arbeidsmarkt O an..80 domain: Omschrijving AN..80 xml tag: OmsAanslOpleidingOpArbeid Toelichting aansluiting opleiding op arbeidsmarkt O an..800 domain: Toelichting AN..800 xml tag: ToelAanslOpleidingOpArbeid Code aansluiting competentie op bemiddelingsberoep O n1 domain: Code onvoldoende voldoende goed Applied Functional Message Rules FM-RL22 Status aansl. competentie op bemiddelingsberoep xml tag: CdAanslCompetentieOpBeroep code list: CodeOnvoldVoldGoed (all selected) 1 Goed Goed 2 Voldoende Voldoende 3 Onvoldoende Onvoldoende Omschrijving aansluiting competentie op bemiddelingsber O an..80 domain: Omschrijving AN..80 xml tag: OmsAanslCompetentieOpBeroep Toelichting aansluiting competentie op bemiddelingsbero O an..800 domain: Toelichting AN..800 xml tag: ToelAanslCompetentieOpBeroep Code aansluiting competentie op arbeidsmarkt O n1 domain: Code onvoldoende voldoende goed Applied Functional Message Rules FM-RL23 Status aansl. competentie op arbeidsmarkt xml tag: CdAanslCompetentieOpArbeid code list: CodeOnvoldVoldGoed (all selected) 1 Goed Goed 2 Voldoende Voldoende 3 Onvoldoende Onvoldoende Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 88 van 103

89 Omschrijving aansluiting competentie op arbeidsmarkt O an..80 domain: Omschrijving AN..80 xml tag: OmsAanslCompetentieOpArbeid Toelichting aansluiting competentie op arbeidsmarkt O an..800 domain: Toelichting AN..800 xml tag: ToelAanslCompetentieOpArbeid Conclusie arbeidsmarktkwalificaties R an domain: Toelichting AN xml tag: ConclArbeidsmarktkwalificaties Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 89 van 103

90 Domain specifications A Name : Aantal uren N4 Datatype : Alpha Numeric, length 4 (fixed length) Format : n4 Pattern : \d{2}[0-5]\d Description : HHMM : HH = 00 tm 99 : MM = 00 tm 59 Name : Abonneenummer N..10 Datatype : Alpha Numeric, length 10 (variable length) Format : n..10 Pattern : [0-9]* C Name : Code JaNee Datatype : Alpha Numeric, length 1 (fixed length) Format : n1 Pattern : [0-9]* Code lists : Code JaNee : 1 Ja : 2 Nee Name : Code JaNeeNVT Datatype : Alpha Numeric, length 1 (fixed length) Format : n1 Pattern : [0-9]* Code lists : Code JaNeeNVT : 1 Ja : 2 Nee : 8 Niet van toepassing Name : Code aanleiding kwalificerende intake Datatype : Alpha Numeric, length 2 (fixed length) Format : n2 Pattern : [0-9]* Code lists : Aanleiding Kwalificerende Intake : 01 verzoek uitkerende instantie : 02 einde bemiddelingsactiviteiten : 03 op verzoek WIW-organisatie : 04 einde inburgering : 05 op verzoek klant : 06 indicatie bij inschrijving/werkintake Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 90 van 103

91 Name : Code belemmering arbeidsinpassing Datatype : Alpha Numeric, length 2 (fixed length) Format : n2 Pattern : [0-9]* Code lists : Belemmering Arbeidsinpassing : 00 Geen : 01 Gezondheid - lichamelijk : 02 Gezondheid - psychisch : 03 Sociaal-maatschappelijk - financieel : 04 Sociaal-maatschappelijk - huisvesting : 05 Sociaal-maatschappelijk - justitieel : 06 Sociaal-maatschappelijk - invloed persoonlijke omgeving/persoonlijke overtuiging : 07 Sociaal-maatschappelijk - verslaving : 08 Sociaal-maatschappelijk - zorgtaken : 99 Anders Name : Code belemmering taalbeheersing Datatype : Alpha Numeric, length 1 (fixed length) Format : n1 Pattern : [0-9]* Code lists : Code belemmering door taalbeheersing : 1 Niet : 2 Enigszins : 3 Mogelijk : 4 Zeker Name : Code beoordeling aantal sollicitaties Datatype : Alpha Numeric, length 1 (fixed length) Format : n1 Pattern : [0-9]* Code lists : Beoordeling aantal sollicitaties : 1 Goed : 2 Voldoende : 3 Onvoldoende : 4 Niet : 9 Niet van toepassing Name : Code beoordeling persoonlijke presentatie Datatype : Alpha Numeric, length 1 (fixed length) Format : n1 Pattern : [0-9]* Code lists : Code beoordeling persoonlijke presentatie : 1 Voor verbetering vatbaar : 2 Goed Name : Code bereidheid thvv reintegratieactiviteiten Datatype : Alpha Numeric, length 1 (fixed length) Format : n1 Pattern : [0-9]* Code lists : Bereidheid tot het volgen van reintegratieactiviteiten : 2 Voldoende : 3 Onvoldoende : 4 Niet Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 91 van 103

92 Name : Code bijzonderheid werkaanvaarding Datatype : Alpha Numeric, length 2 (fixed length) Format : n2 Pattern : [0-9]* Code lists : Codelijst bijzonderheid werkaanvaarding : 00 Geen : 01 Arbeidsvoorwaarden : 02 Werktijden : 03 Vervoer : 04 Beschikbaarheid : 05 Reistijd : 99 Anders Name : Code fase-indeling Datatype : Alpha Numeric, length 1 (fixed length) Format : n1 Pattern : [0-9]* Code lists : Code fase-indeling : 0 onbekend : 1 fase 1: direct bemiddelbaar : 2 fase 2: na kort arbeidsinpassingstraject bemiddelbaar : 3 fase 3: na lang arbeidsinpassingstraject bemiddelbaar : 4 fase 4: (nog) niet bemiddelbaar : 5 fase nog nader te bepalen Name : Code fictieve geboortedatum Datatype : Alpha Numeric, length 1 (fixed length) Format : n1 Pattern : [0-9]* Code lists : Code fictieve geboortedatum : 0 geen enkel datumdeel is fictief : 1 dag is fictief : 2 maand is fictief : 3 dag en maand zijn fictief : 4 jaar is fictief : 5 dag en jaar zijn fictief : 6 maand en jaar zijn fictief : 7 dag, maand en jaar zijn fictief : 8 onbekend welke datumdelen fictief zijn Name : Code kolom SUWI Datatype : Alpha Numeric, length 1 (fixed length) Format : n1 Pattern : [0-9]* Code lists : Code kolom SUWI : 0 Communicatie-actor : 1 SV : 2 Arbvo : 3 GSD : 4 SWI : 5 UWV : 6 CWI : 7 Gemeenten : 8 RIB : 9 SIOD Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 92 van 103

93 Name : Code onvoldoende voldoende goed Datatype : Alpha Numeric, length 1 (fixed length) Format : n1 Pattern : [0-9]* Code lists : CodeOnvoldVoldGoed : 1 Goed : 2 Voldoende : 3 Onvoldoende Name : Code partij SUWI Datatype : Alpha Numeric, length 4 (fixed length) Format : n4 Pattern : [0-9]* Name : Code reintegratieactiviteit Datatype : Alpha Numeric, length 2 (fixed length) Format : n2 Pattern : [0-9]* Code lists : Reintegratieactiviteiten : 01 specifieke bemiddeling : 02 werkervaring/wiw : 03 een WSW-dienstverband : 04 orientatietraject : 05 training : 06 scholing : 07 specifieke hulpverlening : 08 REA : 09 anders Name : Code respons op sollicitaties Datatype : Alpha Numeric, length 1 (fixed length) Format : n1 Pattern : [0-9]* Code lists : Codelijst respons op sollicitaties : 1 Vaak : 2 Soms : 3 Niet Name : Code uitkeringssituatie Datatype : Alpha Numeric, length 1 (fixed length) Format : n1 Pattern : [0-9]* Code lists : Codelijst uitkeringssituatie : 1 Ontvangt uitkering : 2 Uitkering aangevraagd : 3 Meerdere uitkeringen aangevraagd : 4 Geen uitkering (aangevraagd) Name : Code vestiging SUWI Datatype : Alpha Numeric, length 4 (fixed length) Format : n4 Pattern : [0-9]* Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 93 van 103

94 Name : Code wijze van solliciteren Datatype : Alpha Numeric, length 1 (fixed length) Format : n1 Pattern : [0-9]* Code lists : Codelijst wijze van solliciteren : 1 Schriftelijk : 2 Telefonisch : 3 Open : 4 Persoonlijk : 9 Anders E Name : adres Datatype : Alpha Numeric, length 320 (variable length) Format : an..320 G Name : Geslacht Datatype : Alpha Numeric, length 1 (fixed length) Format : n1 Pattern : [0-9]* Code lists : Geslacht : 0 onbekend : 1 mannelijk : 2 vrouwelijk : 9 niet gespecificeerd (het gegevenselement wordt niet gevoerd in de administratie) L Name : Landencode ISO A2 Datatype : Alpha, length 2 (fixed length) Format : a2 Code lists : Landencode ISO A2 : The codes of this codelist are documented in an appendix N Name : Naam AN..70 Datatype : Alpha Numeric, length 70 (variable length) Format : an..70 Name : Naam adres Buitenl AN..24 Datatype : Alpha Numeric, length 24 (variable length) Format : an..24 Name : Naam adres Buitenl AN..40 Datatype : Alpha Numeric, length 40 (variable length) Format : an..40 Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 94 van 103

95 Name : Naam adres Ned AN..24 Datatype : Alpha Numeric, length 24 (variable length) Format : an..24 Name : Naam persoon A..200 Datatype : Alpha, length 200 (variable length) Format : a..200 Name : Netnummer Datatype : Alpha Numeric, length 5 (variable length) Format : n..5 Pattern : [0-9]* Name : Nummer adres Buitenl AN..9 Datatype : Alpha Numeric, length 9 (variable length) Format : an..9 Name : Nummer adres Ned AN..6 Datatype : Alpha Numeric, length 6 (variable length) Format : an..6 Name : Nummer adres Ned N..5 Datatype : Alpha Numeric, length 5 (variable length) Format : n..5 Pattern : [0-9]* O Name : Omschrijving AN..120 Datatype : Alpha Numeric, length 120 (variable length) Format : an..120 Name : Omschrijving AN..35 Datatype : Alpha Numeric, length 35 (variable length) Format : an..35 Name : Omschrijving AN..50 Datatype : Alpha Numeric, length 50 (variable length) Format : an..50 Name : Omschrijving AN..80 Datatype : Alpha Numeric, length 80 (variable length) Format : an..80 P Name : Postcode Datatype : Alpha Numeric, length 6 (fixed length) Format : an6 Pattern : [1-9][0-9]{3}([a-z] [A-Z]){2} Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 95 van 103

96 S Name : Sofinummer Datatype : Alpha Numeric, length 9 (fixed length) Format : n9 Pattern : [0-9]* Name : Standaarddatum Datatype : Alpha Numeric, length 8 (fixed length) Format : n8 Pattern : (([0]{8}) ([0]{4}((0[1-9]) (1[0-2]))((0[1-9]) ([1-2][0-9]) (3[0-1]))) (([1-9][0-9]{3}) (0[1-9][0-9]{2}) (00[1-9][0-9]) (000[1-9]))((0[0-9]) (1[0-2]))((0[0-9]) ([1-2][0-9]) (3[0-1]))) Description : EEJJMMDD : EE = 00 tm 99 : JJ = 00 tm 99 : MM = 00 indien DD, EE en JJ ook 00 zijn, anders 01 tm 12 : DD = 00 indien MM, EE en JJ ook 00 zijn, anders 01 tm 31 T Name : Tabel SZ-wetten Datatype : Alpha, length 5 (variable length) Format : a..5 Code lists : Tabel SZ-wetten : AAW (voormalige) Algemene Arbeidsongeschiktheidswet : ABW Algemene Bijstandswet : AKW Algemene Kinderbijslagwet : ANW Algemene Nabestaandenwet : AOW Algemene Ouderdomswet : AWBZ Algemene Wet Bijzondere Ziektekosten : AWW (voormalige) Algemene Weduwen en Wezenwet : BBZ Besluit Bijstandverlening Zelfstandigen : CSV Coördinatiewet Sociale Verzekering : INTW Internationale wetten : IOAW Wet Inkomensvoorz. Oudere en gedeeltelijk Arbeidsongesch. Werkloze Werknemers : IOAZ Wet Inkomensvoorz. Oudere en gedeeltelijk Arbeidsongesch. gewezen Zelfstandigen : KB Koninklijk besluit en aanverwante regelingen : OSV Organisatiewet Sociale Verzekering : PVW pensioenwetten : REA Wet op de (RE)integratie Arbeidsgehandicapten : RWW (voormalige) Rijksgroepregeling Werkloze Werknemers : TW Toeslagenwet : VUT VUT-regeling : WAJ Wet Arbeidsongeschiktheidsvoorziening Jonggehandicapten (WAJONG) : WAMIL Wet Arbeidsongeschiktheidsvoorziening Militairen : WAO Wet op de Arbeidsongeschiktheidsverzekering : WAZ Wet Arbeidsongeschiktheidsverzekering Zelfstandigen : WBIA (Tijdelijke Wet) Beperking Inkomensgevolgen Arbeidsongeschiktheidscriteria : WVG Wet Voorzieningen Gehandicapten : WW Werkloosheidswet : WWB Wet Werk en Bijstand Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 96 van 103

97 : WWIK Wet Werk en Inkomen Kunstenaars : ZFW Ziekenfondswet : ZW Ziektewet Name : Tabel nationaliteiten Datatype : Alpha Numeric, length 4 (fixed length) Format : n4 Pattern : [0-9]* Code lists : Tabel nationaliteiten : The codes of this codelist are documented in an appendix Name : Tijdstip Datatype : Alpha Numeric, length 8 (fixed length) Format : n8 Pattern : (([0-1][0-9]) (2[0-3]))([0-5][0-9]){2}[0-9]{2} Description : HHMMSSDD : HH = 00 tm 23 : MM = 00 tm 59 : SS = 00 tm 59 : DD = 00 tm 99 Name : Toelichting AN Datatype : Alpha Numeric, length 1200 (variable length) Format : an Name : Toelichting AN..320 Datatype : Alpha Numeric, length 320 (variable length) Format : an..320 Name : Toelichting AN..800 Datatype : Alpha Numeric, length 800 (variable length) Format : an..800 V Name : Voorletters Datatype : Alpha, length 6 (variable length) Format : a..6 Pattern : ([A-Z]{1,6}) [.] Name : Voorvoegsels Datatype : Alpha, length 10 (variable length) Format : a..10 Code lists : Voorvoegsels : The codes of this codelist are documented in an appendix Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 97 van 103

98 Rule specifications DM-RL01 Scope: Description: FM-RL01 Elfproef sofinummer Datamodel Het Persoon.Sofi-nummer moet voldoen aan de elfproef. Waardebereik adres Bron Scope: Functional Message Description: opdracht verzending melding - contactpersoon/-afdeling (bron) - E- MAIL ADRES CONTACTPERSOON/-AFDELING. adres eindigt altijd op '@CWINET.NL'. FM-RL02 Standaardwaarde naam kolom Suwi Bron Scope: Functional Message Description: opdracht verzending melding - contactpersoon/-afdeling (bron) - vestiging suwi - partij suwi - KOLOM SUWI.Naam kolom SUWI heeft standaard de waarde Code kolom SUWI.Code kolom SUWI.6 (CWI) FM-RL03 Standaardwaarde partij Suwi Bron Scope: Functional Message Description: opdracht verzending melding - contactpersoon/-afdeling (bron) - vestiging suwi - PARTIJ SUWI.Code partij SUWI heeft standaard de waarde '0001' en opdracht verzending melding - contactpersoon/- afdeling (bron) - vestiging suwi - PARTIJ SUWI.Naam partij SUWI heeft standaard de waarde 'CWI'. FM-RL04 Scope: Description: FM-RL05 Vulling code fictieve geboortedatum Functional Message Als opdracht verzending melding - reintegratieadvies - CLIENT SUWI.Code fictieve geboortedatum niet door het CWI wordt geregistreerd, dan moet het standaard met de waarde Code fictieve geboortedatum.code fictieve geboortedatum.8 (onbekend welke datumdelen fictief zijn) gevuld worden. Waardebereik code partij Suwi uitkering Scope: Functional Message Description: Indien opdracht verzending melding - reintegratieadvies - client suwi - uitkeringsverhouding - SZ WET.Code SZ wet gelijk is aan Tabel SZwetten.Tabel SZ-wetten.WW (Werkloosheidswet), dan moet opdracht verzending melding - reintegratieadvies - client suwi - uitkeringsverhouding - PARTIJ SUWI.Code partij SUWI de waarde '0002', '0003', '0004', '0005' of '0006' hebben. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 98 van 103

99 FM-RL06 Waardebereik naam partij Suwi uitkering Scope: Functional Message Description: Indien opdracht verzending melding - reintegratieadvies - client suwi - uitkeringsverhouding - SZ WET.Code SZ wet gelijk is aan Tabel SZwetten.Tabel SZ-wetten.WW (Werkloosheidswet), dan moet opdracht verzending melding - reintegratieadvies - client suwi - uitkeringsverhouding - PARTIJ SUWI.Naam partij SUWI de waarde 'UWV-GAK', 'UWV-Cadans', 'UWV-USZO', 'UWV-Bouwnijverheid' of 'UWV-GUO' hebben. FM-RL07 Waardebereik code kolom Suwi uitkering Scope: Functional Message Description: Indien opdracht verzending melding - reintegratieadvies - client suwi - uitkeringsverhouding - SZ WET.Code SZ wet gelijk is aan Tabel SZwetten.Tabel SZ-wetten.WW (Werkloosheidswet), dan moet opdracht verzending melding - reintegratieadvies - client suwi - uitkeringsverhouding - partij suwi - KOLOM SUWI.Code kolom SUWI de waarde Code kolom SUWI.Code kolom SUWI.5 (UWV) hebben. FM-RL08 Waardebereik naam kolom Suwi uitkering Scope: Functional Message Description: Indien opdracht verzending melding - reintegratieadvies - client suwi - uitkeringsverhouding - SZ WET.Code SZ wet gelijk is aan Tabel SZwetten.Tabel SZ-wetten.WW (Werkloosheidswet), dan moet opdracht verzending melding - reintegratieadvies - client suwi - uitkeringsverhouding - partij suwi - KOLOM SUWI.Naam kolom SUWI de waarde Code kolom SUWI.Code kolom SUWI.5 (UWV) hebben. FM-RL09 Scope: Description: Vulling omschr.andere belemmering arbeidsinpassing Functional Message opdracht verzending melding - reintegratieadvies - situatie client arbeidsinpassing - BELEMMERING ARBEIDSINPASSING.Omschrijving andere belemmering arbeidsinpassing wordt alleen gebruikt indien opdracht verzending melding - reintegratieadvies - situatie client arbeidsinpassing - BELEMMERING ARBEIDSINPASSING.Code belemmering arbeidsinpassing gelijk is aan Code belemmering arbeidsinpassing.belemmering Arbeidsinpassing.99 (Anders) Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc - 99 van 103

100 FM-RL10 Status toelichting beschikbaarheid voor arbeid Scope: Functional Message Description: opdracht verzending melding - reintegratieadvies - beroepsperspectief en realiteitszin - BESCHIKBAARHEID CLIENT VOOR ARBEID.Toelichting beschikbaarheid voor arbeid moet verplicht gevuld worden indien opdracht verzending melding - reintegratieadvies - beroepsperspectief en realiteitszin - BESCHIKBAARHEID CLIENT VOOR ARBEID.Indicatie beschikbaarheid conform richtlijn passende ar gelijk is aan Code JaNeeNVT.Code JaNeeNVT.2 (Nee) FM-RL11 Status wijze van solliciteren Scope: Functional Message Description: Indien opdracht verzending melding - reintegratieadvies - client suwi - SOLLICITATIE.Indicatie sollicitaties gelijk is aan Code JaNee.Code JaNee.2 (Nee) dan wordt opdracht verzending melding - reintegratieadvies - client suwi - sollicitatie - WIJZE VAN SOLLICITEREN in zijn geheel niet gevuld. FM-RL12 Status respons op sollicitaties Scope: Functional Message Description: Indien opdracht verzending melding - reintegratieadvies - client suwi - SOLLICITATIE.Indicatie sollicitaties gelijk is aan Code JaNee.Code JaNee.2 (Nee) dan worden opdracht verzending melding - reintegratieadvies - client suwi - SOLLICITATIE.Code respons op sollicitaties, opdracht verzending melding - reintegratieadvies - client suwi - SOLLICITATIE.Omschrijving respons op sollicitaties en opdracht verzending melding - reintegratieadvies - client suwi - SOLLICITATIE.Toelichting respons op sollicitaties niet gevuld. FM-RL13 Status code gebruik informatiekanalen Scope: Functional Message Description: opdracht verzending melding - reintegratieadvies - ARBEIDSMARKTORIENTATIE.Code gebruik informatiekanalen moet verplicht gevuld worden indien opdracht verzending melding - reintegratieadvies - client suwi - SOLLICITATIE.Indicatie sollicitaties gelijk is aan Code JaNee.Code JaNee.1 (Ja) FM-RL14 Status toelichting wijze van solliciteren Scope: Functional Message Description: Indien opdracht verzending melding - reintegratieadvies - client suwi - sollicitatie - WIJZE VAN SOLLICITEREN.Code wijze van solliciteren gelijk is aan Code wijze van solliciteren.codelijst wijze van solliciteren.9 (Anders) dan moet opdracht verzending melding - reintegratieadvies - client suwi - sollicitatie - WIJZE VAN SOLLICITEREN.Toelichting wijze van solliciteren verplicht gevuld worden. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc van 103

101 FM-RL15 Status toelichting belemmering taalbeheersing Scope: Functional Message Description: opdracht verzending melding - reintegratieadvies - ZELFREDZAAMHEID OP DE ARBEIDSPLAATS.Toelichting belemmering taalbeheersing wordt alleen gevuld indien opdracht verzending melding - reintegratieadvies - ZELFREDZAAMHEID OP DE ARBEIDSPLAATS.Code belemmering taalbeheersing ongelijk is aan Code belemmering taalbeheersing.code belemmering door taalbeheersing.1 (Niet) FM-RL16 Status toelichting aandachtspunten houding gedrag Scope: Functional Message Description: opdracht verzending melding - reintegratieadvies - ZELFREDZAAMHEID OP DE ARBEIDSPLAATS.Toelichting aandachtspunten houding-gedrag-verantwoorde wordt verplicht gevuld indien opdracht verzending melding - reintegratieadvies - ZELFREDZAAMHEID OP DE ARBEIDSPLAATS.Indicatie aandachtspunten houding-gedrag-verantwoordeli gelijk is aan Code JaNee.Code JaNee.1 (Ja) FM-RL17 Status toelichting reintegratieactiviteit Scope: Functional Message Description: opdracht verzending melding - reintegratieadvies - REINTEGRATIEACTIVITEIT.Toelichting reintegratieactiviteit wordt verplicht gevuld indien opdracht verzending melding - reintegratieadvies - REINTEGRATIEACTIVITEIT.Code reintegratieactiviteit gelijk is aan Code reintegratieactiviteit.reintegratieactiviteiten.09 (anders) FM-RL18 Status aansl. werkervaring op bemiddelingsberoep Scope: Functional Message Description: opdracht verzending melding - reintegratieadvies - ARBEIDSMARKTKWALIFICATIES.Code aansluiting werkervaring op bemiddelingsberoep moet verplicht gevuld worden indien opdracht verzending melding - reintegratieadvies - beroepsperspectief en realiteitszin - beroep - BEROEPSNAAM ONGECODEERD gevuld is. FM-RL19 Status aansl. werkervaring op arbeidsmarkt Scope: Functional Message Description: opdracht verzending melding - reintegratieadvies - ARBEIDSMARKTKWALIFICATIES.Code aansluiting werkervaring op arbeidsmarkt moet verplicht gevuld worden indien opdracht verzending melding - reintegratieadvies - beroepsperspectief en realiteitszin - beroep - BEROEPSNAAM ONGECODEERD NIET gevuld is. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc van 103

102 FM-RL20 Status aansl. opleiding op bemiddelingsberoep Scope: Functional Message Description: opdracht verzending melding - reintegratieadvies - ARBEIDSMARKTKWALIFICATIES.Code aansluiting opleiding op bemiddelingsberoep moet verplicht gevuld worden indien opdracht verzending melding - reintegratieadvies - beroepsperspectief en realiteitszin - beroep - BEROEPSNAAM ONGECODEERD gevuld is. FM-RL21 Status aansl. opleiding op arbeidsmarkt Scope: Functional Message Description: opdracht verzending melding - reintegratieadvies - ARBEIDSMARKTKWALIFICATIES.Code aansluiting opleiding op arbeidsmarkt moet verplicht gevuld worden indien opdracht verzending melding - reintegratieadvies - beroepsperspectief en realiteitszin - beroep - BEROEPSNAAM ONGECODEERD NIET gevuld is. FM-RL22 Status aansl. competentie op bemiddelingsberoep Scope: Functional Message Description: opdracht verzending melding - reintegratieadvies - ARBEIDSMARKTKWALIFICATIES.Code aansluiting competentie op bemiddelingsberoep moet verplicht gevuld worden indien opdracht verzending melding - reintegratieadvies - beroepsperspectief en realiteitszin - beroep - BEROEPSNAAM ONGECODEERD gevuld is. FM-RL23 Status aansl. competentie op arbeidsmarkt Scope: Functional Message Description: opdracht verzending melding - reintegratieadvies - ARBEIDSMARKTKWALIFICATIES.Code aansluiting competentie op arbeidsmarkt moet verplicht gevuld worden indien opdracht verzending melding - reintegratieadvies - beroepsperspectief en realiteitszin - beroep - BEROEPSNAAM ONGECODEERD NIET gevuld is. FM-RL24 Scope: Description: Waardebereik uitkeringsverhouding Functional Message Het opdracht verzending melding - REINTEGRATIEADVIES dient minimaal één opdracht verzending melding - reintegratieadvies - client suwi - UITKERINGSVERHOUDING te bevatten waarvoor opdracht verzending melding - reintegratieadvies - client suwi - uitkeringsverhouding - SZ WET.Code SZ wet gelijk is aan Tabel SZwetten.Tabel SZ-wetten.WW (Werkloosheidswet) Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc van 103

103 TR-01 Scope: Description: Status omschrijving versus code Transaction In het algmeen geldt dat indien een bepaald code-veld gevuld is, het bijbehorende omschrijving-veld ook gevuld moet zijn conform de vastgestelde codelijst. Dit geldt voor OPDRACHT VERZENDING MELDING en alle hiërarchisch gerelateerde entiteiten. Bijvoorbeeld als 'Code besluit naar aanleiding van kennisgeving' gevuld is met code 400, dan moet 'Omschrijving besluit naar aanleiding van kennisgeving' gevuld worden met 'Boete/maatregel opgelegd'. Auteur: Paul Vriend, Dirk Temme SuwiML berichtstandaard v0201.doc van 103

Nog meer weergeven