Richtlijn ontwerp bedrijfsdocumenten

Transcriptie

1 JZ XML: Richtlijn ontwerp bedrijfsdocumenten Datum 18 september 2009 Onderwerp JZ XML : Richtlijn ontwerp bedrijfsdocumenten Auteur Gerrit van de Ven (In-pact) Gerrit.van.de.ven@in-pact.nl Versie 0.9 Opdrachtgever MO-groep

2 Inhoudsopgave Inhoudsopgave 2 1 Inleiding 3 2 Gangbare ontwerp uitgangspunten 3 3 Nieuwe ontwerp uitgangspunten 4 4 Generieke structuur bedrijfsdocumenten 4 5 Bedrijfsdocument profielen : de ambitie 5 6 Toepassing ambitie profielen op interacties vragenlijsten Wijziging gebruik roltypering Codeerinstructie nodig voor noodzakelijke inperking Het ruime jas principe in een nieuwe opzet Nevenvoordelen van deze nieuwe opzet Voorstel structuur in duiding bedrijfsdocumenten 10 7 Bedrijfsdocument profielen: de consequenties Error! Bookmark not defined. Datum: 18 september 2009 Pagina 2 van 10 Opdrachtgever: MO-groep

3 1 Inleiding Een belangrijke doelstelling in het kader van (het bevorderen van) de toepassing van elektronische berichtenuitwisseling binnen de jeugdzorg sector betreft het realiseren van eenheid van taal (vocabulaire voor gebruik bij uitwisseling van gegevens). Middels de introductie van verschillende producten en adviezen wordt hier op dit moment invulling aan gegeven. In beginsel zijn deze tot op heden sec gericht op het vocabulaire en de bouwstenen waaruit dit is opgebouwd (gegevensgroepen, gegevenselementen en codelijsten). Na een eerste uitwerking van een specifiek koppelvlak met betrekking tot het gebruik van vragenlijsten lijkt zich een kans voor te doen een soortgelijk beleid in te zetten op het ontwerp van de bedrijfsdocumenten (logische ontwerpspecificatie van het elektronisch uit te wisselen bericht). Deze kans doet zich op twee onderwerpen voor. Enerzijds betreft dit de structurering van de inhoud, anderzijds heeft dit betrekking op de naamgeving van bedrijfsdocumenten. In samenhang bezien lijkt zich een derde verbetering voor te doen. Om die stelling te kunnen staven zullen er echter nog verdere ervaringen moeten worden opgedaan, hoewel de kans daarop relatief groot is. Allereerst wordt stil gestaan bij de verbetermogelijkheden op het terrein van de structurering van de inhoud. 2 Gangbare ontwerp uitgangspunten Tot op heden zijn bedrijfsdocumenten ontworpen conform het uitgangspunt dat alleen de zogenaamde header-gegevens (kenmerken die elk bedrijfsdocument bevat, zoals: ID bedrijfsdocument, verzendende instantie, ontvangende instantie, datum, tijdstip, testindicator en signature) altijd vast onderdeel zijn van het ontwerp. Het resterende deel wordt geheel bepaald door de functionaliteit die binnen het betreffende ketenproces zijn vereist. Van een vaste structuur of andere richtlijn voor de inhoud is geen sprake. Vanzelfsprekend is ook hier de toepassing van generieke berichtbouwstenen die onderdeel zijn van het vocabulaire verplicht. Onderstaande afbeelding geeft een en ander weer. Datum: 18 september 2009 Pagina 3 van 10 Opdrachtgever: MO-groep

4 3 Nieuwe ontwerp uitgangspunten De analyse van het koppelvlak met betrekking tot het gebruik van de vragenlijsten bood zicht op de mogelijkheid te kiezen voor een generieke structuur die niet alleen voor deze situatie een passende uitwerking kan bieden maar ook model kan staan voor de structuur van de nog op te pakken koppelvlakken. Wanneer deze ambitie inderdaad duurzaam kan worden toegepast resulteert dit in een substantiële toename van de efficiency binnen het ontwerp- en realisatieproces met betrekking tot elektronische berichtontwikkeling in het Jeugdzorg domein. Voor het analyseproces heeft deze vernieuwing waarschijnlijk geen gevolgen. Het zoeken en vinden van de vereiste functionaliteit (procesverloop in combinatie met de bijbehorende informatiebehoefte) blijft onveranderd. 4 Generieke structuur bedrijfsdocumenten De structuur van de bedrijfsdocumenten voor het Jeugdzorg domein zoals deze thans voorzien zijn, is als volgt opgebouwd. De basisstructuur bestaat standaard uit de volgende drie onderdelen: 1. Header gegevens 2. Functioneel bepaalde inhoud 3. Niet gedefinieerde inhoud Ad 1: Is identiek als bij het onder hoofdstuk 2 genoemde gelijknamige deel. Ad 2: Is in beginsel identiek als bij het onder hoofdstuk 2 genoemde gelijknamige deel. In samenhang met de ontwikkelingen op het terrein van de naamgeving van de bedrijfsdocumenten kan hierbinnen mogelijk ook een verbetering worden doorgevoerd. Let op: binnen dit onderdeel kan ook de Bijlage als bouwsteen worden gebruikt. Ad 3: Dit betreft een geheel nieuw onderdeel voor de bedrijfsdocumenten. Het enige voorspelbare van dit onderdeel is dat het altijd (optioneel) onderdeel is van een bedrijfsdocument. Over het gebruik ervan en welke informatie dan wordt uitgewisseld worden vooraf, tijdens de analyse-, ontwerp- en realisatiefase geen afspraken gemaakt. Uit gesprekken met vertegenwoordigers uit het Jeugdzorg domein is duidelijk geworden dat deze vrije uitwissel voorziening waarschijnlijk gebruikt zal gaan worden door een reeks onderling zeer uiteenlopende gegevens. Gegevens die vooraf niet echt te bepalen zijn en ook zeker niet in alle gevallen eenduidig zullen zijn. Op zichzelf zijn de voordelen van dit onderdeel hiermee wel voldoende belicht. Het verdient aanbeveling met enige regelmaat te monitoren of en met welke invulling dit onderdeel na de ingebruikname wordt toegepast. In theorie bestaat het risico dat de functioneel bepaalde inhoud (onderdeel 2) waarin de semantische bouwstenen uit het gegevenswoordenboek niet conform de afspraak wordt gebruikt en dat dit vrije onderdeel in feite wordt misbruikt om niet aan de standaarden en de daaraan gelieerde kwaliteitafspraken te moeten voldoen. Onderstaande afbeelding geeft een en ander weer. Datum: 18 september 2009 Pagina 4 van 10 Opdrachtgever: MO-groep

5 5 Bedrijfsdocument profielen : de ambitie In de afgelopen periode is gestudeerd op de mogelijkheid voor de interactieprocessen (koppelvlakken) en de bedrijfsdocumenten binnen het Jeugdzorg domein een generiek concept te ontwikkelen dat in beginsel de maatstaf vormt voor de in de komende tijd te ontwikkelen. Deze gedachte is verder geconcretiseerd tijdens de analyse- en ontwerpactiviteiten met betrekking tot de vragenlijst. Dit document beperkt zich overigens tot de bedrijfsdocumenten. In een apart document zal nog worden ingegaan op de profielen ambitie met betrekking tot de interactieprocessen. Het concretiseren van deze ambitie kan het beste worden gedaan aan de hand van de volgende stelling: Interacties binnen het Jeugdzorg domein hebben veelal betrekking op een bepaald onderwerp, bevatten één of meer acties met betrekking tot dat onderwerp en de berichten die in dat verband worden uitgewisseld zijn qua inhoud overwegend gelijk en er lijkt een causaal verband te zijn tussen deze inhoud en het soort actie. Nog niet alle elementen uit deze stelling zijn op hun merites beschouwd. Er is al wel gekeken naar het onderwerp, de acties, de eenduidigheid van de inhoud en de onderlinge samenhang tussen deze. Dat heeft geresulteerd in het volgende. Voor de uitleg wordt gebruik gemaakt van de observaties die zijn opgedaan in het kader van het recent uitgevoerde analyse- en het ontwerptraject ten aanzien van de vragenlijsten die binnen het Jeugdzorg domein worden toegepast. Dat levert onderstaande op. Datum: 18 september 2009 Pagina 5 van 10 Opdrachtgever: MO-groep

6 6 Toepassing ambitie profielen op interacties vragenlijsten De vragenlijst vormt binnen het Jeugdzorg domein een instrument voor het verkrijgen van informatie over een jeugdige en de context waarin deze verkeert. Dergelijke vragenlijsten worden thans door externe dienstaanbieders tegen betaling beschikbaar gesteld via internet. Uit de analyse is gebleken dat de volgende activiteiten met betrekking tot de vragenlijsten kunnen voorkomen: -instellen -deactiveren -reactiveren -opvragen -bijwerken -afronden Er is sprake van een zekere logica tussen deze activiteiten. Een nog niet ingestelde vragenlijst kan niet worden gedeactiveerd, opgevraagd, bijgewerkt of afgerond. Zo zullen er nog andere afhankelijkheden zijn te duiden. Daar wordt in dit kader echter niet verder op ingegaan. Ook de exacte inhoud van de vragenlijst is hier niet relevant. De (al dan niet ingevulde) vragenlijst als voorziening blijft beschikbaar op de internetsite van de dienstenaanbieder. Zoals eerder opgemerkt lijkt er sprake te zijn van een bepaalde mate van samenhang tussen de activiteiten met betrekking tot een onderwerp (in dit geval: de vragenlijst) en de inhoud van het bedrijfsdocument. Alle reden om deze kwestie eens nader uit te diepen. Een analyse van de bedrijfsdocumenten die voor dit interactieproces zijn ontworpen levert het volgende op. De onderkende en benoemde activiteiten hebben betrekking op één of meer onderwerp(en). Nader te noemen object van handeling. In totaal voor de 8 gedefinieerde bedrijfsdocumenten betreft het hier slechts een tweetal objecten van handeling, namelijk: de natuurlijk persoon en de vragenlijst. Samengevat zijn de functionele eisen aan de inhoud van de bedrijfsdocumenten voor het gebruik binnen de interacties met betrekking tot de vragenlijst als volgt te concretiseren in termen van de vereiste bouwstenen ten behoeve van onderdeel 2 van het bedrijfsdocument (functionele inhoud): 1 Vragenlijst en 2 Natuurlijk persoon. Afgebeeld in het nieuwe structuurontwerp levert dit het volgende op. Datum: 18 september 2009 Pagina 6 van 10 Opdrachtgever: MO-groep

7 6.1 Wijziging gebruik roltypering Voor deze natuurlijk persoon zijn in de 8 bedrijfsdocumenten ten behoeve van de vragenlijst een aantal rollen (hoedanigheden) gedefinieerd. Deze roltypering is momenteel in het gegevenswoordenboek gerepresenteerd middels het gegevenselement Rol partij en de daaraan gekoppelde codelijst Rollen partij binnen de gegevensgroep Betrokkenheid. Daarbinnen zijn alle mogelijke hoedanigheden van partijen (Rechts- en Natuurlijke personen) ondergebracht. Tot op heden werd, wanneer meer dan één rol (in casu: meer dan één partij) in het bedrijfsdocument moest worden opgenomen, dit gemodelleerd door middel van een meervoudig voorkomen van de Partij met daaronder de relevante gegevensgroepen (bouwstenen) als totaalverzameling aan functionaliteit van alle mogelijke voorkomens van de partij in dat bedrijfsdocument. Ook al waren gegevensgroepen als: Naam, Geboorte, Adres en Overlijden slechts voor één roltypering noodzakelijk, deze waren daarmee expliciet onderdeel van alle andere voorkomens van een partij. Onderstaand voorbeeld ter illustratie van dit principe: Partij 1..* Financieel rekeningnummer 0..1 Identificatiecode partij 0..1 Betrokkenheid 1..1 Identificatiecode betrokkenheid 1..1 Rol partij code 0..1 Geldigheid betrokkenheid 0..1 Datum begin geldigheid 0..1 Datum einde geldigheid 0..1 Registratieve relatie partij 1..1 VIP-nummer 0..1 SKN 0..1 Verhoor verdachte 1..1 Indicatie cautie 0..1 Afgelegde verklaring 0..1 Datum eerste verhoor 0..1 Datum laatste verhoor 0..1 Adres 0..* Soort adres code 0..1 Land adres code 0..1 Bron adres code 0..1 Indicatie adres in onderzoek 0..1 Indicatie voorkeuradres 0..1 Geldigheid adres 0..1 Datum begin periode 0..1 Datum einde periode 0..1 Adres bij instantie 0..1 Instantiecode 1..1 Nederlands adres 0..1 Locatieomschrijving Nederlands adres 0..1 Postcode numeriek deel 0..1 Postcode alfabetisch deel 0..1 Plaats Nederlands adres code 0..1 Gemeente Nederlands adres code 0..1 Straatadres 0..1 Straatnaam (verkort) 0..1 Huisnummer 0..1 Huisnummertoevoeging 0..1 Datum: 18 september 2009 Pagina 7 van 10 Opdrachtgever: MO-groep

8 Woonwagenverwijzing code 0..1 Woonbootverwijzing code 0..1 Postbusadres 0..1 Postbusnummer 0..1 Antwoordadres 0..1 Antwoordnummer 0..1 Buitenlands adres gestructureerd 0..1 Locatieomschrijving buitenlands adres 0..1 Straatnaam buitenlands adres 0..1 Huisnummer buitenlands adres 0..1 Huisnummertoevoeging buitenlands adres 0..1 Postcode buitenlands adres 0..1 Plaatsnaam buitenlands adres 0..1 Staat/Regio buitenlands adres 0..1 Buitenlands adres ongestructureerd 0..1 Adresregel buitenland Adresregel buitenland Adresregel buitenland Communicatie 0..* Soort communicatiemiddel code 0..1 Communicatiemiddel nummer adres 0..1 Rechtspersoon 0..1 Naam organisatie (beperkt) 0..1 Statutaire naam 0..1 Correspondentienaam rechtspersoon 0..1 Datum oprichting rechtspersoon 0..1 Datum beeindiging rechtspersoon 0..1 Contactpersoon rechtspersoon 0..1 Rechtsvorm rechtspersoon code 0..1 Registratieve relatie rechtspersoon 0..1 KvK-nummer 0..1 Natuurlijk persoon 0..1 Naam 1..1 Significant deel van de achternaam 0..1 Voorvoegsel 0..1 Voornamen 0..1 Voorletters-n 0..1 Voorletters Niet gestructureerde naam 0..1 Soort persoonsnaam code 0..1 Geboorte 1..1 Geboortedatum 0..1 Geboortejaar 0..1 Nederlandse geboortegemeente code 0..1 Geboorteplaatsnaam 0..1 Geboorteland code 0..1 Geslacht code 0..1 Nadere aanduiding geboorteplaats 0..1 Geboortecoordinaten 0..1 Registratieve relatie natuurlijk persoon 0..1 V-nummer 0..1 Burgerservicenummer 0..1 A-nummer 0..1 Status 0..1 Nationaliteit code 0..1 Verblijfstitel 0..1 Dit voorbeeld verdient verder weinig uitleg. In beginsel is alle functionaliteit voor uitwisseling van gegevens van een partij hier samengebracht. Het laat onverlet dat voor bijvoorbeeld de invulling van bijvoorbeeld het telefoonnummer en adres van een raadsman o.i.d. slechts een miniem deel vereist is. Datum: 18 september 2009 Pagina 8 van 10 Opdrachtgever: MO-groep

9 6.2 Codeerinstructie nodig voor noodzakelijke inperking Door middel van het specificeren van uitsluitingrichtlijnen in de codeerinstructie (= gebruiksrichtlijnen voor elk onderdeel van een bedrijfsdocument) werd de beperking weer aangebracht. In praktische zin is het moeilijk zo niet onmogelijk om per roltypering een specifieke codeerinstructie op te stellen. Dat maakt de specificatie arbeidsintensief en onderhoudsintensief. Bovendien leert de ervaring dat programmeurs zich bij het bouwen van dergelijke ontwerpspecificaties primair richten op de XSD (XML schema definition). 6.3 Het ruime jas principe in een nieuwe opzet Deze generieke opzet van bedrijfsdocumenten wordt ook wel het ruime jas principe genoemd. De toepassing van dit principe kent een reeks voordelen. Er is in de hierna beschreven nieuwe opzet geenszins sprake van het loslaten van dit principe. Het nieuwe concept herbergt onverkort de voordelen ervan. De nadelen zijn echter voor een belangrijk deel weggenomen. Binnen het analyse- en ontwerptraject met betrekking tot de vragenlijsten werd duidelijk dat binnen dit koppelvlak sprake is van verschillende roltyperingen met bijbehorende afwijkingen in functionaliteit. De verwachting is dat dit ook in de nog op te pakken ketenprocessen en interacties binnen het Jeugdzorg domein een veelvoud aan roltyperingen zal voorkomen. Mede om die reden is dit nieuwe concept direct toegepast. De bedrijfsdocumenten voor het ragenlijst koppelvlak fungeren dan ook als proeftuin. Het nieuwe concept doet evenzeer recht aan het principe van Eenheid van taal en is conform de daaraan verbonden uitgangspunten. Van de duiding van de specifieke voorkomens in de vorm van de roltyperingen is ook nu niet afgeweken. Wat wel afwijkt is de wijze waarop een en ander thans in de bedrijfsdocumenten is verwerkt. Het meest kenmerkende verschil is dat elk voorkomen van een partij, met bijbehorende roltypering, als eenheid in het bedrijfsdocument is opgenomen. Alleen die gegevensgroepen zijn daarin verwerkt die bij die rol ook daadwerkelijk gebruikt worden. In eerste aanleg lijkt daarmee de bedrijfsdocument specificatie in omvang toe te nemen, de (thans nog prille) praktijk leert dat dit mogelijk op een onjuiste aanname berust. Deze nieuwe opzet heeft mogelijk consequenties voor de inhoud van het gegevenswoordenboek JZ-XML en/of de wijze waarop het gegevenswoordenboek thans is ingericht. In het document: JZ-XML Uitleg Gegevenswoordenboek wordt, zodra de exacte consequenties in kaart zijn gebracht, hier nader aandacht aan besteed. 6.4 Nevenvoordelen van deze nieuwe opzet Binnen de mondiaal toegepaste e-business concepten wordt ook gebruik gemaakt van berichtbouwstenen. Dat is geen toeval; de uitgangspunten en opzet van de koppelvlak specificaties die voor het Jeugdzorg domein worden ontwikkeld zijn daaruit onverkort overgenomen of daarvan afgeleid. De berichtbouwstenen binnen de e-business concepten onderscheiden zich in twee vormen. De eerste vorm betreft de zogenaamde CC s (corecomponents), de tweede vorm worden BIE s (business information entities) genoemd. De eerste vorm bestaat min of meer uit kant en klare generieke bouwstenen die als eenheid in het elektronisch handelsverkeer kunnen worden ingezet. Denk daarbij aan bouwstenen als een bestelling, facturering, etc. In feite betreft dit complete berichtspecificaties, vergelijkbaar met de bedrijfsdocumenten zoals in dit document beschreven. Met enige fantasie lijkt zich de kans voor te gaan doen de nieuwe generieke opzet van bedrijfsdocumenten te beschouwen als mogelijke core components voor het Jeugdzorg domein. De tweede vorm (BIE s) is wellicht met Datum: 18 september 2009 Pagina 9 van 10 Opdrachtgever: MO-groep

10 wat minder fantasie reeds in beeld. Mogelijk dat uit bouwstenen als de hiervoor beschreven en op de roltypering toegesneden eenheden voor de Jeugdzorg wel een reeks BIE s voortvloeien die door hun bijdrage aan het streven tot hergebruik. In de komende periode zal hieromtrent de nodige ervaring worden opgedaan die deze ambitie kan bevestigen dan wel ontkrachten. 6.5 Voorstel structuur in duiding bedrijfsdocumenten In hoofdstuk 6 is reeds eerder ingegaan op de activiteiten die zich met betrekking tot het koppelvlak onderwerp (in dit voorbeeld de vragenlijst) kunnen voordoen. In aansluiting op de eerdere uitgangspunten ten aanzien van de duiding van bedrijfsdocumenten, kan nu worden geconstateerd dat een verdere aanscherping van de richtlijn voor de duiding van de bedrijfsdocumenten tot de mogelijkheden behoort. Een eerste uitwerking daarvan is in dit hoofdstuk verwoord. De belangrijkste richtlijn is dat de activiteit die op het koppelvlak onderwerp betrekking heeft centraal staat in deze duiding. Vervolgens lijkt zich de situatie voor te doen dat een bedrijfsdocument doorgaans uit een verzoek en een reactie op dat verzoek bestaat. Een volgende categorie die zich duidelijk herkenbaar voordoet is het communiceren van een bepaalde toestand over of van het koppelvlak onderwerp. In de context van de vragenlijst zijn daarmee wel alle relevante varianten genoemd. Wanneer deze observaties vertaald worden naar een eerste voorstel dan leidt dit tot het volgende. Voorstel structuur duiding bedrijfsdocumenten*: [actie] [werkwoord] [koppelvlak onderwerp] *ieder beter, zuiverder alternatief is mij welkom Voorbeeld dezes: Verzoek Instellen Vragenlijst Reactie (verzoek) Instellen Vragenlijst Etc. Naast bovenstaande kan worden afgesproken dat de duiding in alle gevallen in de Nederlandse taal plaatsvindt. Datum: 18 september 2009 Pagina 10 van 10 Opdrachtgever: MO-groep