SPECIFICATIES Privacy- en Verzendmodule DBC Informatie Systeem (DIS 5.3)

SPECIFICATIES Privacy- en Verzendmodule DBC Informatie Systeem (DIS 5.3)

Project: Title:

ZorgTTP – DBC Informatie Systeem

SPECIFICATIES Privacy- en Verzendmodule DBC Informatie Systeem (DIS 5.3) Reference: Specificaties_pvm_dis_53_20151223.docx Author: ZorgTTP Version: 1.1 Date: 23-12-2015 Status: Definitief

VERSIEBEHEER Versie 1.0

datum 17-12-2015

Author I. Sanders

Status Definitief

1.1

23-12-2015

I. Sanders

Definitief

Opmerking Ondersteunde GA’s en adresgegevens aangepast. Aanpassingen na opmerkingen DIS

REVIEWS ReviewVersie 1.0 1.1

Reviewdatum 17-12-2015 23-12-2015

Reviewer

Partij

E. van Leer E. van Leer

ZorgTTP ZorgTTP

Opmerking verwerkt in versie

DOCUMENTVERWIJZINGEN Referentie FO Webservice GA SZ 7.0 GA SZ 2.0 OHW

GA FZ 2.0 GA GBG 1.0 GA_GGZ_7.0

Document Titel DIS00865 Functioneel Ontwerp Webservice Standaard voor DIS gegevensaanlevering DBC door aanbieders ziekenhuiszorg en geriatrische revalidatiezorg Aanleverstandaard en retourspecificaties onderhanden werk voor aanbieders ziekenhuiszorg en geriatrische revalidatiezorg Standaard voor DIS gegevensaanlevering DBC door FZ zorgaanbieders Standaard voor DIS gegevensaanlevering TRJ door GBG zorgaanbieders Standaard voor DIS gegevensaanlevering DBC door GGZ zorgaanbieders

Specificaties DIS 5.3 Versie 1.1 © ZorgTTP

Versie v. 1.0 (11-08-2010) v.1.4 (01-12-2013) v. 1.5 (01-01-2013)

v.1.4 (01-01-2013) v 1.0 (01-01-2014) v 1.1 (01-08-2014)

Pagina 2 van 58

INHOUDSOPGAVE 1.

INLEIDING .................................................................................................................. 4 1.1 1.2 1.3 1.4

DOELGROEP .............................................................................................................. 4 DOEL ......................................................................................................................... 4 ZORGTTP PSEUDONIMISATIEPLATFORM ...................................................................... 4 DE 3 STAPPEN VAN DE VERSLEUTELING ....................................................................... 5

2.

PSEUDONIMISERING IN DE PVM-DIS ...................................................................... 6

3.

DE WERKING VAN PRIVACY- EN VERZEND MODULE ........................................... 7

4.

INPUT BESTANDEN PVM-DIS ..................................................................................11

5.

VALIDATIES ..............................................................................................................13

6.

OUTPUT BESTANDEN PVM-DIS ..............................................................................17 6.1

7.

PSEUDONIMISATIE PATIENT.TXT NAAR PATIENT-S1.TXT ................................................17 VALIDATIE VAN DE BESTANDEN ...........................................................................20 VALIDATIES ‘PATIENT.TXT’ EN OUTPUT BESTANDEN ......................................................22

7.1 8.

FOUTCODES .............................................................................................................29 8.1

TOELICHTING OP VALIDATIES ......................................................................................34

9.

MELDINGEN EN VERSLAG VERWERKING PVM-DIS .............................................37

10.

WERKING DRM-DIS ..................................................................................................43

10.1 10.2 10.3 10.4 10.5

ALGEMEEN ............................................................................................................43 OUTPUTBESTANDEN DRM-DIS ...............................................................................43 ID 1: AFSPLITSEN VERWERKINGSRAPPORT BIJ ANONIEME AANLEVERING ....................43 ID 1: TWEEDE CERTIFICAAT ONDERSTEUNING ..........................................................44 HET VERWERKINGSPROCES ....................................................................................44

APPENDIX A

CONVERSIE ASCII TEKENS .....................................................................45

APPENDIX B

‘11-PROEF’ ................................................................................................51

APPENDIX C

INSTALLATIE EN DEINSTALLATIE..........................................................52

APPENDIX D

ADDITIONELE SPECIFICATIES GEREALISEERD IN VERSIE 5.3...........54

APPENDIX E

ACTUELE PRODUCTIEVERSIES PVM DIS ..............................................55

APPENDIX F

ONTWERP WEBSERVICE AANLEVERPLANNING ..................................56

APPENDIX G

VOORBEELDEN AFHANDELING BSN PER GA ......................................58


Pagina 3 van 58

1. 1.1

Inleiding Doelgroep

Dit document is bestemd voor de Nederlandse Zorgautoriteit (opdrachtgever) en Chess (softwareleverancier).

1.2

Doel

ZorgTTP heeft in opdracht van aanvankelijk het ministerie van VWS en later DBC Onderhoud (nu Nederlandse Zorgautoriteit) een drietal programma’s ontwikkeld voor het pseudonimiseren van persoonsgegevens. De programma’s vormen gezamenlijk het ZorgTTP pseudonimisatieplatform. Dit specificatiedocument beschrijft de input en output van het pseudonimisatieproces, de uitgevoerde controles en foutmeldingen die het gevolg kunnen zijn van deze controles.

1.3

ZorgTTP pseudonimisatieplatform

De programma’s waaruit het platform bestaat zorgen ervoor dat een aantal identificerende gegevens behorende bij een bepaalde patiënt/cliënt worden omgezet naar een voor die cliënt unieke code (pseudoniem). Onderdeel van dit procedé is het inschakelen van een te vertrouwen derde partij, oftewel een Trusted Third Party (TTP). De TTP voert een “geheime “ handeling uit waarmee de relatie tussen een persoonsgegeven en het bijbehorende pseudoniem wordt verbroken. Het is na deze handeling niet meer mogelijk om op basis van het pseudoniem terug te gaan naar het oorspronkelijke persoonsgegeven. Er worden op grond van diverse (combinaties van) persoonsgegevens drie verschillende pseudoniemen aangemaakt. Door de pseudonimisatie van deze gegevens is het mogelijk om een (groep van) cliënt(en) op landelijk niveau te volgen over de instellingen en sectoren heen zonder de anonimiteit in gevaar te brengen. Het is ook mogelijk om een correctie te plegen voor dubbeltellingen. De drie modules die gezamenlijk het pseudonimisatieplatform vormen zijn: 1. Privacy- en Verzend Module (PVM) 2. Centrale Module TTP (CMT) 3. Doel- en retourmodule (DRM) De wijze waarop deze modules in samenhang opereren wordt in detail beschreven in het document: Pseudonimisatie van Persoonsgegevens bij ZorgTTP (juni 2011). Voor dit document is het van belang om vast te stellen dat de PVM bij een zorgaanbieder draait, CMT onder de verantwoordelijkheid van de TTP draait en de DRM bij de ontvanger van gepseudonimiseerde gegevens draait.


Pagina 4 van 58

1.4

De 3 stappen van de versleuteling

Het versleutelingsproces bestaat uit meerdere stappen, waarbij de TTP een cruciale rol speelt bij het omzetten van persoonsgegevens naar niet herleidbare gegevens in de vorm van pseudoniemen. Dit proces ziet er als volgt uit: Stap 1: een eerste versleuteling op instellingsniveau De Privacy- en Verzend Module draait op instellingsniveau. De PVM splitst de gegevens in een datadeel en een sleuteldeel. Identificerende gegevens in het datadeel worden verwijderd. Het sleuteldeel bevat identificerende gegevens die omgezet worden in pseudoniemen. Na de bewerking wordt het bewerkte sleuteldeel beveiligd met het publieke certificaat van de TTP. Het datadeel wordt beveiligd met het publieke certificaat van DIS. Data en sleutels worden via een beveiligde verbinding (SSL) opgestuurd naar de TTP. Door het gebruik van digitale certificaten heeft de TTP alleen toegang heeft tot het sleuteldeel. Stap 2: de tweede versleuteling bij de TTP De Centrale Module TTP (CMT) draait bij de TTP. De gegevens worden door CMT in behandeling genomen. Eerst wordt het sleuteldeel uitgepakt, waarna een tweede, geheime versleuteling wordt toegepast. Deze versleuteling kent voor elke afnemer van ZorgTTP een andere geheime waarde. Het proces verloopt voor iedere afnemer verder identiek. Het resultaat van de verwerking wordt gecomprimeerd en samen met de data doorgestuurd naar de ontvangende organisatie (doelorganisatie). Stap 3: Samenvoegen van datadeel en sleuteldeel bij de doelorganisatie De Doel- en Retour Module (DRM) is verantwoordelijk voor de communicatie met CMT. De DRM draait lokaal bij de ontvangende organisatie. Binnenkomende zipfiles worden uitgepakt, waarna het data- en het sleuteldeel worden samengevoegd tot een bestand in het afgesproken outputformaat. Fig. Het pseudonimisatieproces

PVM

CMT

DRM

(privacy verzend module)

(centrale module TTP)

(doel retour module)

PVM

Intake

Processing

Outtake

DRM

Web service aanleverplanning


Pagina 5 van 58

2.

Pseudonimisering in de PVM-DIS

Een aangeboden brondocument wordt in een aantal gecontroleerd en vervolgens gepseudonimiseerd. Het outputbestand dient als input voor de volgende stappen in de keten; verwerking binnen CMT en vervolgens ontvangst via de DRM. Het proces van pseudonimiseren in de PVM-DIS wordt in de onderstaande figuur geïllustreerd.

Het proces dat een bestand doorloopt vanaf input tot aan het opleveren van een outputbestand wordt aangeduid als het verwerkingsproces binnen de PVM. Het verwerkingsproces en de daarbij geldende randvoorwaarden worden in het vervolg van dit document meer in detail beschreven.


Pagina 6 van 58

3.

De werking van Privacy- en Verzend Module

Randvoorwaarden gebruik PVM DIS 1. De PVM DIS is gebaseerd op Java. Java dient aanwezig te zijn op het systeem waarop de PVM wordt geïnstalleerd. 2. De PVM DIS heeft voldoende lees- en schrijfrechten in de omgeving waarin de module is geïnstalleerd. 3. De PVM DIS moet verbinding kunnen maken via SSL met de domeinen www.zorgttp.nl en www.disportal.nl. 4. De PVM biedt (beperkte) ondersteuning voor het gebruik van proxy servers. 5. Gebruikers dienen de PVM DIS te koppelen aan het op naam van de organisatie verstrekte digitale certificaat (PKCS 12). 6. Vanaf PVM versie 5.1 bestaat de mogelijkheid om binnen de PVM een certificaat te genereren. Hiervoor is een activatiecode nodig die door ZorgTTP verstrekt kan worden. 7. DIS aanlevering moeten voldoen aan een van de DIS standaarden voor gegevensaanlevering (GA): GGZ 7.0, SZ7.0, FZ2.0, SZ 2.0 OHW of GBG 1.0. Deze standaarden gelden als uitgangspunt voor het pseudonimisatieproces. De PVM verwacht een zip bestand met een naamgeving die voldoet aan een van deze DIS standaarden. Installatieproces De PVM kan worden gebruikt op Windows, MacOS en Linux. Voor ieder type besturingssysteem wordt een aparte installer opgeleverd. Hiervoor wordt het pakket Install4j gebruikt. Voor Windows wordt onderscheid gemaakt in een versie voor 32 en een versie voor 64 bits Java. Vanaf versie 5.0 wordt onderscheid gemaakt in de locatie waar het programma wordt geïnstalleerd en de locatie waar het programma bewerkingen mag uitvoeren. Dit onderscheid is in lijn met de opzet die de ondersteunde besturingssystemen kennen voor het installeren en gebruiken van programmatuur. De verwachting bestaat dat door deze opzet beter rekening gehouden kan worden met omgevingen waar onderscheid wordt gemaakt in rechten voor het installeren van software en het gebruiken van software. Tijdens de installatie zijn de volgende parameters instelbaar: 1. Indien van toepassing; upgrade installatie of nieuwe installatie 2. Pad waar de programmatuur wordt opgeslagen 3. Pad waar de werkomgeving wordt gecreëerd 4. Wel of niet aanmaken van snelkoppelingen Voor parameter 1 geldt dat alleen bij aanwezigheid van een eerdere versie deze optie wordt geboden. De locatie van de bestaande installatie is opvraagbaar middels een knop. Voor de parameters 2, 3 en 4 geldt dat er een default locatie wordt gegeven waarvan desgewenst kan worden afgeweken.


Pagina 7 van 58

Uitgangspunten werking PVM DIS 1. De PVM kan via de GUI of via de command line worden aangestuurd. Hiertoe zijn in de programmafolder diverse opties aanwezig (pvm.exe en .bat en .sh scripts voor command line gebruik). 2. Het programma begint bij iedere run met het creëren van een nieuwe run-specifieke werkomgeving (c:\users\local user\ZorgTTP\DIS\run-xxx). 3. Bij het opstarten worden de volgende controles uitgevoerd: a. Versiecontrole. Het programma begint met de controle of met de meest actuele versie (zie Appendix E ) van de PVM DIS wordt gewerkt. Hiertoe wordt verbinding gemaakt met www.zorgttp.nl. Bij een afwijkend versienummer wordt gemeld: “U gebruikt niet de meest recente versie van de PVM DIS. Raadpleeg voor meer informatie het DIS portal. Door op Ok te klikken zal de PVM DIS alsnog opstarten”. De PVM zal daarna gewoon doorstarten en de gebruiker heeft de mogelijkheid om de applicatie af te sluiten of met een eventuele niet recente versie het bericht te verwerken en te verzenden. Indien er geen verbinding met de www.zorgttp.nl server gemaakt kan worden om de versie te controleren zal de volgende melding verschijnen: “Er kon niet worden vastgesteld of u de meest recente versie van de PVM DIS gebruikt. Raadpleeg voor meer informatie het DIS portal. Door op Ok te klikken zal de PVM DIS alsnog opstarten”. b. Certificaatcontroles i. Aanwezigheid certificaat. Indien nog geen certificaat aanwezig is, dan zal de PVM hiervan melding maken in het beginscherm. De gebruiker kan kiezen om een bestaand certificaat te koppelen of om een nieuw certificaat te genereren. Via het tabblad ‘Instellingen/certificaat’ kan een bestaand certificaat worden gekoppeld. Via het tabblad ‘Instellingen/certificaat aanmaken’ kan een certificaat worden aangemaakt. Hiervoor is een activatiecode vereist die kan worden aangevraagd via het Service en Informatiecentrum DIS (SIDIS). ii. Verlopen Certificaat Het aan de PVM gekoppelde certificaat wordt gecontroleerd op expiratie. Op het moment dat certificaten dreigen te verlopen wordt hiervan melding gemaakt in de GUI. Daarbij zijn instelbaar via configuratie items; a. het moment waarop de melding verschijnt gerekend in dagen tot het verlopen van het certificaat en b. de inhoud van de melding. Als standaard instelling van het aantal dagen tot het verlopen van het certificaat wordt 4 maanden (122 dagen) genomen. Uitgaande van een maandelijkse aanlevering kan de module dan nog eenmaal gebruikt worden nadat de melding is getoond en voordat het certificaat verloopt. De standaard melding die aan de gebruiker wordt getoond is: “Uw certificaat is nog […] dagen geldig. Voor meer informatie kunt u contact opnemen met Service en Informatiecentrum DIS” iii. Bruikbaarheid certificaat. Indien een certificaat voor aan de PVM wordt gekoppeld dan wordt de combinatie certificaat en wachtwoord gecontroleerd. Indien het certificaat niet kan worden geopend dan wordt een foutmelding getoond aan de gebruiker iv. Backup certificaat Indien een nieuw certificaat aan de PVM wordt gekoppeld dan wordt een kopie van het certificaat opgeslagen in de map local


Pagina 8 van 58

users/[user]/ZorgTTP/certificate. In geval van problemen met de bruikbaarheid van het certificaat onder i en ii wordt in de logging de locatie van eventuele vervangende back-ups weergegeven. v. Indien een certificaat is gekoppeld aan de PVM, maar het certificaat later wordt verwijderd of niet langer bereikbaar is voor de PVM, dan wordt bij het opstarten hiervan melding gemaakt aan de gebruiker onder vermelding van de laatst bekende locatie. 4. Vervolgens wordt de aangeboden zipfile uitgepakt. 5. Het programma controleert op grond van het aangeboden type en versie GA of alle verwachte deelbestanden aanwezig zijn. Het type en de versie GA kan worden afgeleid uit twee elementen in de bestandsnaam van de zipfile. 6. Er volgt een technische en inhoudelijke controle van patient.txt en pakbon.txt. 7. Op grond van de DIS portal gebruikersnaam wordt gecontroleerd of de aangeboden zipfile geaccepteerd wordt volgens de DIS aanleverplanning. De controle wordt uitgevoerd met behulp van een webservice call naar het domein www.disportal.nl. Het programma stopt de verwerking als het aangeboden bestand niet wordt verwacht volgens de DIS aanleverplanning. De gebruiker krijgt in het scherm de melding dat het bestand niet wordt verwacht . Indien de Aanleverplanning niet geraadpleegd kan worden en de PVM ontvangt geen resultaat (VERWACHT/NIET VERWACHT) dan zal het aangeboden bestand wel verwerkt worden. In Appendix F is het ontwerp van de webservice nader beschreven. 8. Het programma gaat niet door met het genereren van codes als er een fout wordt gevonden. De ter verwerking aangeboden zipfile wordt niet gewijzigd. Het programma genereert een HTML foutenverslag met dezelfde bestandsnaam als het aangeboden zip bestand. De tijdelijke bestanden worden verwijderd. 9. Indien er geen fouten zijn aangetroffen zal het programma het bestand patient.txt splitsen in een datadeel en een sleuteldeel. De pseudoniemen worden opgeslagen in het sleuteldeel. 10. Het sleuteldeel wordt aangemaakt en gevuld. Naam sleuteldeel: ‘patient_s1.txt’. 11. Het datadeel wordt aangemaakt en gevuld. Waar relevant worden variabelen naar een hoger aggregatieniveau gebracht (bijvoorbeeld postcode NNNNAA naar NNNN). Naam datadeel: ‘Patient-s0.txt’. 12. Het oorspronkelijke bestand ‘patient.txt’ wordt verwijderd. 13. Het sleuteldeel en het datadeel worden gezipt en beveiligd met een certificaat. Alleen CMT heeft toegang tot het sleuteldeel. Alleen de DRM heeft toegang tot het datadeel. De zip heeft als naam: [idz].zorgttp. IDZ staat daarbij voor ‘IDentificatie van de Zending”. Dit is een unieke code die wordt aangemaakt op basis van een kenmerken als de systeemdatum, bestandsnaam en systeemtijd. 14. Er wordt melding gedaan over de uitkomst van de verwerking (wel/niet verzonden). 15. Voor iedere verwerking wordt in de map waaruit het aangeboden bestand afkomstig is een verwerkingsverslag aangemaakt. Bij gebruik via de GUI is dit altijd een HTML bestand. Bij headless gebruik kan worden gekozen voor een XML bestand. De inhoud van de rapportage wordt beschreven in hoofdstuk 9. 16. Bij het afsluiten van de applicatie wordt de run-xxx map leeggemaakt. Distributie De PVM DIS wordt in verschillende versies opgeleverd. 1. PVM DIS voor Windows (.exe) 2. PVM DIS voor Windows 64-bits (.exe) 3. PVM DIS voor Mac (.dmg) 4. PVM DIS voor Linux (.sh)


Pagina 9 van 58

Aansturing via de command line (headless) De module kan zoals hiervoor reeds aangegeven, naast via het pvm.exe bestand ook vanaf de command line worden opgestart Bijvoorbeeld: PVM ./DIS_CZG_DBC_TEST_050_47471221_0_20090601.zip

Aanleveren voor meerdere zorgaanbieders Er worden twee scenario’s ondersteund voor het in gang zetten van de verwerking voor meerdere zorgaanbieders tegelijkertijd: 1. Alternatief configuratiebestand per zorgaanbieder als parameter (PVM -C) Middels de parameter alt.config kan een alternatieve locatie van het configuratiebestand worden aangeroepen. Op die wijze kan voor meerdere zorgaanbieders in een run worden aangeleverd. Hierbij wordt steeds een compleet configuratiebestand per zorgaanbieder aangeroepen. Voor iedere zorgaanbieder dient zowel een certificaat als DIS portal user name in het configuratiebestand user.properties aanwezig te zijn. Voorbeeld PVM -C:\DIS\USER123\user.properties ./DIS_CZG_DBC_TEST_050_47471221_0_20090601.zip

2. DIS portal username als parameter (run4user.bat) Indien alleen de gebruikersnaam voor het raadplegen van de aanleverplanning varieert kan vanaf versie 4.0 gebruik worden gemaakt van een overkoepelend run script waarin de portal user name in combinatie met het te verwerken bestand kunnen worden opgegeven (run4user.bat [username] [bestandsnaam.zip]). De overige configuratie items zoals het digitale certificaat kunnen in dit geval gelijk blijven. Deze optie is met name bedoeld voor situaties waar een intermediair de aanlevering namens een aantal zorgaanbieders verzorgt. Voorbeeld C:\DIS\DIS-PVM-4.0\pvm\run4user.bat ZORGTTP C:\Datamap\/DIS_CZG_DBC_TEST_050_47471221_0_20090601.zip


Pagina 10 van 58

4.

Input bestanden PVM-DIS

De bestanden pakbon.txt en patient.txt worden gebruikt als input voor het pseudonimisatieproces. Deze bestanden zijn onderdeel van een DBC aanlevering zoals voorgeschreven in de standaarden voor gegevensaanlevering DBC gegevens die door DBCOnderhoud zijn opgesteld. De DBC aanlevering wordt herkend op grond van de bestandsnaam van het aanboden zip bestand. Ondersteunde Minimale Dataset versies De PVM DIS 5.3 ondersteunt de datasets: GA SZ

Dataset DBC

Versie 7.0

FZ

DBC

2.0

SZ

OHW

2.0

GBG

TRJ

1.0

GGZ

DBC

7.0

Bestandsnaam van de Zipfile DIS_SZG_DBC_<soortlevering>_070____.zip DIS_FZG_DBC_<soortlevering>_020____.zip DIS_SZG_OHW_<soortlevering>_020____.zip DIS_GBG_TRJ_<soortlevering>_010____.zip DIS_GGZ_DBC_<soortlevering>_070____.zip

Zie ook de referentie GA documenten op pagina 2.


Pagina 11 van 58

pakbon.txt De opbouw van pakbon bestand wordt beschreven in de betreffende formaatbeschrijvingen [GGZ 7.0], [SZ7.0], [FZ2.0], [SZ 2.0 OHW] en [GBG 1.0]. Voor de PVM is alleen relevant;  Het aantal regels waaruit de pakbon bestaat;  De positie van het veld ‘Aantal Patient’ binnen de regel. Op grond van het veld ‘Aantal Patient’ in de pakbon wordt een controle uitgevoerd op het aantal patiënten in het bestand patient.txt. Onderstaande tabel geeft de exacte positie aan waar het veld ‘Aantal Patient’ zich binnen pakbon.txt bevindt in de te ondersteunen standaarden voor gegevensaanlevering (GA). GA + versie CZ 7.0 FZ 2.0 SZ 2.0 OHW GBG 1.0 GGZ 7.0

Type N N N N N

Lengte 7 7 7 7 7

Begin 118 118 118 118 118

Eind 124 124 124 124 124

patient.txt De opbouw van patient bestand wordt beschreven in de betreffende formaatbeschrijvingen [GGZ 7.0], [SZ7.0], [FZ2.0], [SZ 2.0 OHW] en [GBG 1.0]. De afhandeling van het bestand wordt beschreven in de vervolg hoofdstukken.


Pagina 12 van 58

5.

Validaties

Uitgangspunt bij het valideren van de input is dat de PVM programmatuur aangeboden bestanden controleert op:  Technische verwerkbaarheid (kan het bestand benaderd worden vanuit de module) en volledigheid (o.a. zijn alle relevante bestanden aanwezig);  Inhoudelijke juistheid (o.a. zijn de aangeboden gegevens valide). De laatste categorie controles wordt beperkt tot de aangeboden persoonsgegevens die na pseudonimisatie niet langer in de oorspronkelijke vorm beschikbaar zijn. Een voorbeeld van een dergelijke controle is de 11-proef op het veld BurgerServiceNummer. Alle validaties moeten worden uitgevoerd voordat het programma doorgaat met pseudonimiseren. Er zijn 3 typen validaties: Type

Code range 10001999

Foutomschrijving

Foutafhandeling

technische controles op werkomgeving en bestanden

2

20002999

inhoudelijke controles op de data

3

30003999

meldingen

De PVM zal het aangeboden bestand niet verwerken (geen inhoudelijke controle en geen verzending van het DISbestand). De foutmelding is zichtbaar in de applicatie zodra de fout optreedt. De verwerking kan slechts worden hervat door een aanpassing te doen. De PVM heeft het aangeboden bestand inhoudelijk gecontroleerd en fatale fouten gevonden waardoor er geen output bestand wordt aangemaakt. Er wordt geen DISbestand verzonden. De foutmeldingen kunnen worden ingezien door het na de verwerking aangemaakte verslag in te zien. De PVM heeft het aangeboden bestand inhoudelijk gecontroleerd, waarschuwingen (niet fatale fouten) gevonden en het output bestand wordt aangemaakt. Er wordt een DISbestand verzonden. De foutmeldingen kunnen worden ingezien door het na de verwerking aangemaakte verslag in te zien.

1

De eerste controles die door de PVM uitgevoerd worden zijn controles (type 1) waarvan de resultaten kunnen worden teruggekoppeld via de schermen van PVM. Vervolgens worden de controles uitgevoerd die via een validatie rapport worden teruggekoppeld (type 2 en 3). In het proces waarin het patient.txt bestand wordt gemuteerd naar patient-s0.txt wordt de inhoud van de aangeleverde bestanden gevalideerd alvorens de pseudoniemen worden aangemaakt. Hoewel DIS streeft naar consistentie in de definitie van de patient.txt bestanden komt het voor dat er verschillen zijn, zoals bijvoorbeeld in FZ, waar een extra veld aanwezig is welke gepseudonimiseerd moet worden. De PVM software dient rekening te houden met deze verschillen. In hoofdstuk 7 zijn van de in productie zijnde gegevensstromen de definities opgenomen. Hoofdstuk 8 geeft een overzicht van alle relevante foutcodes.


Pagina 13 van 58

Afhandeling foutsituaties Foutsituaties kunnen op verschillende wijze worden teruggekoppeld aan de gebruiker:  Een systeemmelding van het besturingssysteem waarop de PVM draait.  Een melding in een van de PVM schermen  Een (fout)melding in het verwerkingsverslag Foutmeldingen ten gevolge van validaties op het aangeboden bestand kunnen na afloop van de verwerking in het verslag “[bestandsnaam van het aangeboden zip bestand]_DIS_PVM.HTML” worden ingezien. Indien er sprake is van validatiefouten vindt verzending van het bestand NIET plaats. Bij de afhandeling van foutsituaties wordt onderstaand schema gehanteerd ALS Aanleverplanning niet verwacht DAN Melding: Het bestand wordt niet verwacht volgens de DIS aanleverplanning. De gegevens zijn niet gecontroleerd. ANDERS (aanleverplanning wel verwacht) ALS geen validatiefouten DAN Melding: Geen validatiefouten geconstateerd Melding: Het bestand wordt verwacht volgens de DIS aanleverplanning….. ALS bestand kan niet verzonden worden DAN Melding: Bestand kan niet worden verzonden ANDERS Melding: Bestand is verzonden ANDERS (wel validatiefouten) Melding: Er zijn validatiefouten geconstateerd Fouten uit de 3000 range hebben het karakter van een waarschuwing . Er is geen sprake van een blokkerende fout, maar wel sprake van een bijzondere situatie die gelogd dient te worden.


Pagina 14 van 58

Afhandeling van het veld Naam In Patient.txt bevinden zich 2 gegevensvelden met als inhoud de naam van de patiënt, te weten (za_)naam_1 en (za_)naam_2. Twee andere gegevensvelden, te weten (za_)naamcode_1 en (za_)naamcode_2, bepalen of de betreffende naam de achternaam of de geboortenaam is. De volgende beslisboom bepaalt welke naam wordt gebruikt voor de pseudonimisering en derhalve ook onderworpen wordt aan de validaties (2001, 2002, 2003 en 2004).

Met code 1 wordt bedoeld dat het naamveld de achternaam bevat. Met code 2 wordt bedoeld dat het naamveld de geboortenaam bevat Afhandeling veld voornaam en achternaam en de conversie van ascii tekens In Appendix A wordt de normalisatie beschreven die binnen de PVM plaatsvindt op aangeboden gegevens. Afhandeling van het veld Burger Service Nummer (BSN) In eerdere versies van de PVM DIS was het uitgangspunt dat er in geen geval lege pseudoniemen worden opgeleverd. Een leeg pseudoniem is een pseudoniem dat bestaat uit de zogenaamde handtekening gevolgd door 28 spaties. Uitgangspunt voor validatie van GA’s GGZ, SZ en FZ; 1. Een valide BSN wordt gepseudonimiseerd. Onder valide wordt verstaan: i. Lengte gelijk aan 8 of 9 posities numeriek; ii. 11-proef; 2. Een niet valide BSN wordt afgekeurd. 3. Uitzonderingen: i. Een BSN met 9x0 wordt afhankelijk van de GA gezien als ‘anoniem’ of ‘onbekend’ Zie voor de exacte afhandeling per GA versie hoofdstuk 7. ii. Een leeg BSN (9xspatie) wordt omgezet naar 9x0 en als zodanig afgehandeld. Zie voor de exacte afhandeling per GA versie hoofdstuk 8.1.8.


Pagina 15 van 58

Vanaf PVM versie 5.0 is het voor de GA’s OHW 2.0 en GBG 1.0 mogelijk om lege pseudoniemen op te leveren. Rekening houdend met deze situatie wordt het veld BSN als volgt afgehandeld: Input VALIDE BSN 9*9 9*0 9*spatie Voldoet niet aan 11proef Lengte niet goed Ongeldig teken

Output Pseudoniem Default pseudoniem voor 9*9 DS2B[28xspatie] DS2B[28xspatie] DS2B[28xspatie]

PVM melding Geen Geen WRN 3003 Geen WRN 3126 voldoet niet aan de 11-proef

DS2B[28xspatie] DS2B[28xspatie]

WRN 3122 ongeldige lengte WRN 3123 ongeldig teken

Appendix H bevat een lijst met voorbeeld afhandelingen voor het veld Burger Service Nummer voor verschillende inputwaarden.


Pagina 16 van 58

6.

Output bestanden PVM-DIS

De bestanden Patient-s0.txt (datadeel) en patient_s1.txt (sleuteldeel) zijn het resultaat het pseudonimisatieproces van de PVM-DIS. Zie hoofdstuk 3, Uitgangspunten werking PVM DIS. Deze bestanden zijn onderdeel van een DBC aanlevering zoals voorgeschreven in de standaarden voor gegevensaanlevering DBC gegevens die door DBC-Onderhoud zijn opgesteld. De DBC aanlevering wordt herkend op grond van de bestandsnaam van het aanboden zip bestand. Voor de specificaties van de output bestanden per GA versie zie hoofdstuk 7.1.

6.1

Pseudonimisatie patient.txt naar patient-s1.txt

Het sleuteldeel patiënt_s1.txt, na eerste versleuteling door de PVM DIS, kent de volgende indeling: Nr

Attribuut

Type

Constraint

Begin

Lengte

1

Opmerking

IDZ

A

V

1

12

2

Regelnummer

N

V

13

8

3

Pseudoniem Naam

A

V

21

32

Links uitvullen met spaties OS1N

4

Pseudoniem CBS

A

V

53

32

OS1C

5

Pseudoniem BSN

A

V

85

32

OS1B

6

Pseudoniem SKnummer (FZ)

A

V

117

32

OS1S

1. IDZ geeft de identificatie van de zending aan en is gebaseerd op de naam van de zipfile, de systeemdatum en systeemtijd (de systeemtijd van het moment dat de IDZ wordt aangemaakt). Een MD5 algoritme wordt gedraaid over deze gegevens en de IDZ wordt bepaald door de laatste 12 tekens.


Pagina 17 van 58

2. Het regelnummer correspondeert met het regelnummer van het datadeel. Het is de basis om het datadeel en het sleuteldeel te kunnen samenvoegen. 3. Het pseudoniem Naam bestaat uit de ‘handtekening naam’ en het ‘sleuteldeel naam’. De handtekening naam is een code die aangeeft welk pseudoniem type het betreft. Standaard waarde: OS1N. (= Originele Sleutel, 1 keer bewerkt, gebaseerd op Naamgegevens). Het sleuteldeel naam is gebaseerd op de versleuteling van:  de eerste 8 tekens van de achternaam. Het programma kiest uit ‘(za )naam_1’ of ‘ (za )naam_2’. Het 2e en volgende teken mag een spatie zijn.  het eerste teken van de voorletters.  de geboortedatum.  het geslacht, waarbij 1 = mannelijk; 2 = vrouwelijk; 0 = onbekend; 9 = niet gespecificeerd. Pseudoniem formule: ‘OS1N’ + ENCRYPT28( TRIM(achternaam) + SPATIES(10) )

4. Het pseudoniem CBS bestaat uit de ‘handtekening CBS’ en het ‘sleuteldeel CBS’. De handtekening heeft betrekking op het pseudoniem CBS en kent standaard de waarde OS1C (C van CBS). Het sleuteldeel bestaat uit:   

de volledige postcode. Bij een leeg gegevensveld wordt er ook een pseudoniem gemaakt (postcode is alleen verplicht als de landcode NL is). Geboortedatum Geslacht, waarbij 1 = mannelijk; 2 = vrouwelijk; 0 = onbekend; 9 = niet gespecificeerd.

Pseudoniem formule: ‘OS1C’ + ENCRYPT28( UPPERCASE(TRIM(postcode)) + TRIM(geboortedatum) + TRIM(geslacht) + SPATIES(10) )

5. Het pseudoniem BSN bestaat uit de ‘handtekening BSN’ en het ‘sleuteldeel BSN’. De handtekening BSN heeft betrekking op het pseudoniem BSN en kent standaard de waarde OS1B (B van BSN). Het sleuteldeel BSN is gebaseerd op het Burger Service Nummer (BSN). Standaard waarde is OS1B. Pseudoniem formule: ‘OS1B’ + ENCRYPT28(bsn + SPATIES(10) )

6. Het pseudoniem SK-nummer (alleen van toepassing voor [FZ1.0]) bestaat uit de ‘handtekening SK-nummer’ en het ‘sleuteldeel SK-nummer’. De handtekening SKnummer heeft betrekking op het pseudoniem SK-nummer en kent standaard de waarde OS1S (S van SK). Het sleuteldeel SK-nummer is gebaseerd op het Strafrecht Keten nummer (SK). Standaard waarde is OS1S. Pseudoniem formule: ‘OS1S’ + ENCRYPT28( TRIM(SK-nummer) + SPATIES(10) )


Pagina 18 van 58

Problemen en bijzonderheden De volgende bijzonderheden zijn vermeldenswaardig. 1. De postcode is niet verplicht indien sprake is van een woonadres in het buitenland. Er wordt wel een pseudoniem CBS aangemaakt, maar de code is onbetrouwbaar. 2. Het SK nummer pseudoniem is verplicht voor de [FZ1.0] en [FZ 2.0] GA versies en mag voor alle andere versies niet voorkomen. Default waarden voor pseudoniemen Voor een aantal velden zijn default waarden van toepassing als input of output voor pseudonimisatie. In de volgende situaties kunnen default waarden van toepassing zijn: 1. Optioneel karakter te pseudonimiseren velden 2. Verplicht karakter te pseudonimiseren velden (voorschrift anoniem aanleveren) 3. Lege pseudoniemen ongewenst in de ouput De default waarden zijn hierbij: Pseudoniem Veld OS1N

OS1C

OS1B

Naam Voorletters Geboortedatum Postcode Geboortedatum Geslacht BSN

Default input voor pseudonimisatie [8*x] XX 01012000 9999AA 01012000 0 [9*0]

Verklaring Anonieme waarde Anonieme waarde Anonieme waarde Anonieme waarde Anonieme waarde Anonieme waarde Anoniem / Onbekend

Voor OS1B geldt dat voor oudere GA’s de waarde 9x0 gold als default voor anoniem. Later is anoniem aanleveren komen te vervallen en is 9x0 in gebruik genomen als default waarde voor BSN onbekend.


Pagina 19 van 58

7.

Validatie van de bestanden

Als eerste wordt de naam van het zip-bestand gevalideerd. De naam van het zip-bestand verschilt per GA. GA SZ 7.0 FZ 2.0 SZ 2.0 OHW GBG 1.0 GGZ 7.0

Validatie 1008 Controle op bestandsnaam DIS_SZG_DBC_<soortlevering>_070____.zip DIS_FZG_DBC_<soortlevering>_020____.zip DIS_SZG_OHW_<soortlevering>_020____.zip DIS_GBG_TRJ_<soortlevering>_010____.zip DIS_GGZ_DBC <soortlevering>_070____.zip

De PVM moet controleren of het zip bestand alle .txt bestanden, behorende tot de GA versie bevat. Dit betreft een exacte match : een bestand dat niet in de GA gedefinieerd is en voorkomt in de zip wordt als fout aangemerkt. Voor details zie hoofdstuk 8, validatie melding nr.1021. Let op! de bestandsnamen dienen case insensitive verwerkt te worden. FZ 2.0

SZ 7.0

SZ 2.0 OHW

SZ 7.0

GBG 1.0

GGZ 7.0

Patient.txt Zorgtraject.txt Aard_delict.txt Dbc_traject.txt Diagnose.txt Gevaar.txt Geleverd_zorgprofiel_tijdschrijven.txt Geleverd_zorgprofiel_dagbesteding.txt Geleverd_zorgprofiel_verblijfsdagen.txt Geleverd_zorgprofiel_verrichtingen.txt Overige_verrichting.txt Pakbon.txt

Declaratiedataset.txt geleverd_zorgprofiel.txt honorarium.txt nevendiagnose.txt overige_verrichting pakbon.txt patient.txt subtraject.txt zorgtraject.txt

Patient.txt Zorgtraject.txt Subtraject.txt Geleverd_zorgprofiel.txt Nevendiagnose.txt Honorarium.txt Overige_verrichting.txt Declaratiedataset.txt Pakbon.txt

Patient.txt Zorgtraject.txt Subtraject.txt Geleverd_zorgprofiel.txt Nevendiagnose.txt Honorarium.txt Overige_verrichting.txt Declaratiedataset.txt Pakbon.txt

Patient.txt Diagnose.txt Geleverd Zorgprofiel.txt Overige verrichtingen/Producten.txt Pakbon.txt ROM.txt ROM_ITEM.txt

Patient.txt Zorgtraject.txt Dbc_traject.txt Diagnose.txt Geleverd_zorgprofiel_tijdschrijven.txt Geleverd_zorgprofiel_dagbesteding.txt Geleverd_zorgprofiel_verblijfsdagen.txt Geleverd_zorgprofiel_verrichtingen.txt Overige_verrichting.txt Pakbon.txt ROM.txt (O) ROM_ITEM.txt (O)

Voor GGZ 7.0 is het toegestaan om optionele bestanden aan te bieden. Deze bestanden zijn met (O) gemarkeerd in bovenstaand overzicht.


Pagina 20 van 58

Naast de controle op de binnen de zip aanwezige bestanden wordt er ook een aantal technische validaties uitgevoerd met betrekking tot pakbon.txt en patient.txt. Deze zijn van toepassing op alle GA’s. NR 1017 1018 1022 2021

Validatie tussen patient.txt en pakbon.txt pakbon.txt moet een regel bevatten pakbon.txt mag niet meer dan een regel bevatten patient.txt bevat een regel met verkeerde lengte. Het aantal patiënten in de pakbon komt niet overeen met het aantal patiënten in patient.txt

Voor validatie 1022 wordt uitgegaan van de onderstaande verwachte regellengtes binnen het bestand patient.txt per GA. GA + versie CZ 5.0 GGZ 6.0 SZ 7.0 FZ 2.0 SZ 2.0 OHW GBG 1.0 GGZ 7.0

PVM 3.0.2 137 -


PVM 4.0 137 150 170 165 170 -

Lengte PVM 5.1 137 150 170 165 170 173 -

PVM 5.2 137 150 170 165 170 173 170

PVM 5.3 170 165 170 173 170

Pagina 21 van 58

7.1

Validaties ‘patient.txt’ en output bestanden

Onderstaande tabellen bevat de kolom ‘Verplicht’. Deze bevat een code. De verschillende codes betekenen het volgende: V= Verplicht, O=Optioneel, CV= Conditioneel Verplicht. Het patient.txt bestand wordt uiteindelijk aan de ontvangende partij opgeleverd middels een patient-s0.txt (de data) en een patient_s2.txt (de pseudoniemen) en deze 2 bestanden worden verder beschreven middels de kolommen Patient-s0 en Patient-s2. Patient-s0 beschrijft de uiteindelijke formattering van data terwijl Patient-s2 aangeeft welke velden van invloed zijn tot de totstandkoming van de pseudoniemen. De beschrijving betreft steeds de binnen patient-S0.txt aanwezige data. Dit betekent dat ten opzicht van patient.txt steeds de velden ‘ IDZ’ en ‘Regelnummer’ aan het begin van de regel is toegevoegd. Zie voor de exacte beschrijving van patient.txt steeds de door DIS gepubliceerde standaarden voor gegevensaanlevering (GA).

7.1.1 SZ 7.0 Variabele IDZ Regelnummer Declarerende instelling Instelling volgnr DIS Koppelnummer Naam_1

Verplicht V V V V V V

Type AN N AN AN AN AN

Lengte 12 8 8 2 15 25

Begin 1 13 21 29 31 46

Eind 12 20 28 30 45 70

Naam voorvoegsel_1 Naamcode_1 Naam_2 Naam voorvoegsel_2 Naamcode_2

O V O O CV

AN AN AN AN AN

10 1 25 10 1

71 81 82 107 117

80 81 106 116 117

Voorletters

V

AN

6

118

123


Validaties

Patient-s0

Patient-s2

2028 2029 2030 2001 2003 2004 2031 2002 2031 2034 2002 2005 2006 2032

Leeg

Leeg Leeg Leeg Leeg Leeg

DS2N

DS2N

DS2N

Pagina 22 van 58

Postcode

CV

AN

6

124

129

Huisnummer Huisnummer toevoeging Landcode Geboortedatum

O O V V

N AN AN D

5 4 2 8

130 135 139 141

134 138 140 148

Geslacht

V

AN

1

149

149

Variabele Burger Service Nummer

Verplicht V

Type AN

Lengte 9

Begin 150

Eind 158

Patient_ID

O

AN

32

159

190

Variabele IDZ Regelnummer Declarerende instelling Instelling volgnr DIS Koppelnummer Naam_1

Verplicht V V V

Type AN N AN

Lengte 12 8 8

Begin 1 13 21

V V V

AN AN AN

2 15 25

Naam voorvoegsel_1

O

AN

10

2009 2010

Substr(ZA Postcode,1,4), DS2C rechts uitvullen met spaties Leeg Leeg

2008 2011 2012 2013 2014 2015

To_char(ZA DS2N, DS2C Geboortedatum, ‘yyyy’), rechts uitvullen met spaties DS2N, DS2C

Validaties 2022 2023 2026 2033 2039

Patient-s0 Leeg

Patient-s2 DS2B

Eind 12 20 28

Validaties

Patient-s0

Patient-s2

29 31 46

30 45 70

2029 2030 2001 2003 2004 2031

Leeg

DS2N

71

80

7.1.2 FZ 2.0


2028

Leeg

Pagina 23 van 58

Variabele Naamcode_1 Naam_2 Naam voorvoegsel_2 Naamcode_2

Verplicht V O O CV

Type AN AN AN AN

Lengte 1 25 10 1

Begin 81 82 107 117

Eind 81 106 116 117

Voorletters

V

AN

6

118

123

Postcode

CV

AN

6

124

129


O O V V

N AN AN D

5 4 2 8

130 135 139 141

134 138 140 148

Geslacht

V

N

1

149

149

Burger Service Nummer

V

AN

9

150

158

SK-nummer

V

AN

15

159

173

Eerste inschrijfdatum Laatste uitschrijfdatum

O O

D D

6 6

174 180

179 185


Validaties 2002 2031 2034 2002 2005 2006 2032 2009 2010

2008 2011 2012 2013 2014 2015 2022 2023 2026 2033 2039 2035 2036 2037 2038 2041 2042

Patient-s0 Leeg Leeg Leeg Leeg

Patient-s2

Leeg

DS2N

DS2N

Substr(ZA Postcode,1,4), DS2C rechts uitvullen met spaties Leeg Leeg To_char(ZA DS2N, DS2C Geboortedatum, ‘yyyy’), rechts uitvullen met spaties DS2N, DS2C Leeg

DS2B

Leeg

DS2S

Pagina 24 van 58

7.1.3 SZ 2.0 OHW Variabele IDZ Regelnummer Declarerende instelling Instelling volgnr DIS Koppelnummer Naam_1

Verplicht V V V V V O


Lengte 12 8 8 2 15 25

Begin 1 13 21 29 31 46

Eind 12 20 28 30 45 70

Naam voorvoegsel_1 Naamcode_1 Naam_2 Naam voorvoegsel_2 Naamcode_2 Voorletters

O O O O O O

AN AN AN AN AN AN

10 1 25 10 1 6

71 81 82 107 117 118

80 81 106 116 117 123

Postcode

O

AN

6

124

129


O O O O

N AN AN D

5 4 2 8

130 135 139 141

134 138 140 148

Geslacht

V

AN

1

149

149


O

AN

9

150

158

Patient_ID

O

AN

32

159

190


Validaties

Patient-s0

Patient-s2

2028 2029 2030 3001 3103 3104 3102 3001 3102 3002 3106 3110

3112 3113 2014 2015 3003 3122 3123 3126

Leeg

Leeg Leeg Leeg Leeg Leeg Substr(ZA Postcode,1,4), rechts uitvullen met spaties Leeg Leeg To_char(ZA Geboortedatum, ‘yyyy’), rechts uitvullen met spaties

Leeg

Pagina 25 van 58

7.1.4 GBG 1.0 Variabele IDZ Regelnummer Declarerende instelling Instelling volgnr DIS Koppelnummer Naam_1



Lengte 12 8 8 2 15 25

Begin 1 13 21 29 31 46

Eind 12 20 28 30 45 70


O O O O O O

AN AN AN AN AN AN

10 1 25 10 1 6

71 81 82 107 117 118

80 81 106 116 117 123

Postcode

O

AN

6

124

129


O O O O

N AN AN D

5 4 2 8

130 135 139 141

134 138 140 148

Geslacht

V

AN

1

149

149


O

AN

9

150

158

Geboortemaand Geboorteland patiënt /

O O

AN AN

2 2

159 161

160 162


Validaties

Patient-s0

Patient-s2

2028 2029 2030 3001 3103 3104 3102 3001 3102 3002 3106 3110

3112 3113 2014 2015 3003 3122 3123 3126

Leeg

DS2N


DS2N

DS2N

Substr (ZA Postcode,1,4), rechts uitvullen met spaties Leeg Leeg

DS2C

To_char (ZA Geboortedatum, ‘yyyy’), rechts uitvullen met spaties

DS2N, DS2C

DS2N, DS2C Leeg

DS2B

Pagina 26 van 58

Variabele

Verplicht

Type

Lengte

Begin

Eind

herkomst Geboorteland vader Geboorteland moeder Leefsituatie Opleidingsniveau Burgerlijke staat Werksituatie Reserve

O O O O O O O

AN AN AN AN AN AN AN

2 2 2 2 1 2 20

163 165 167 169 171 172 174

164 166 168 170 171 173 193

Variabele IDZ Regelnummer Declarerende instelling Instelling volgnr DIS Koppelnummer Naam_1



Lengte 12 8 8 2 15 25

Begin 1 13 21 29 31 46

Eind 12 20 28 30 45 70


O O O O O O

AN AN AN AN AN AN

10 1 25 10 1 6

71 81 82 107 117 118

80 81 106 116 117 123

Postcode

O

AN

6

124

129

Huisnummer Huisnummer toevoeging Landcode

O O O

N AN AN

5 4 2

130 135 139

134 138 140

Validaties

Patient-s0

Patient-s2

Leeg

7.1.5 GGZ 7.0


Validaties

Patient-s0

Patient-s2

2028 2029 2030 3001 3103 3104 3102 3001 3102 3002 3106 3110

Leeg

DS2N


DS2N

DS2N

Substr (ZA Postcode,1,4), rechts uitvullen met spaties Leeg Leeg

DS2C

Pagina 27 van 58

Variabele Geboortedatum

Verplicht O

Type D

Lengte 8

Begin 141

Eind 148

Validaties 3112 3113

Geslacht

V

AN

1

149

149


O

AN

9

150

158

Eerste inschrijfdatum Laatste uitschrijfdatum Geboortemaand Geboorteland patiënt / herkomst Geboorteland vader Geboorteland moeder Leefsituatie Opleidingsniveau Reserve

O O O O

AN AN AN AN

6 6 2 2

159 165 171 173

164 170 172 174

2014 2015 3003 3122 3123 3126 2041 2042

O O O O O

AN AN AN AN AN

2 2 2 2 20

175 177 179 181 183

176 178 180 182 202


Patient-s0 To_char (ZA Geboortedatum, ‘yyyy’), rechts uitvullen met spaties

Patient-s2 DS2N, DS2C

DS2N, DS2C Leeg

DS2B

Leeg

Pagina 28 van 58

8.

Foutcodes

Onderstaande tabel geeft een overzicht van binnen de PVM DIS gehanteerde foutcodes, een beschrijving van de bijbehorende fout, en de gevolgen voor de verwerking. Voor alle foutcodes tussen 1000 en 1999 geldt dat de foutcode en de foutmelding steeds zichtbaar worden in de applicatie zodra de fout optreedt. De verwerking kan slechts worden hervat door een aanpassing te doen. Foutcodes tussen 2000 en 2999, evenals waarschuwingscodes 3000 t/m 3003 kunnen worden ingezien door het na de verwerking aangemaakte verslag in te zien. De applicatie geeft na verwerking aan dat er validatiefouten en/of waarschuwingen zijn opgetreden en dat voor meer informatie het verslag kan worden geopend met de knop ‘Open’. De PVM onderscheid hierin 3 types validaties die bepalend is voor de afhandeling: Type Korte omschrijving T Technische fout

Verwerking Verzending input best. DIS-bestand N N

F

Fatale fout

J

N

W

Waarschuwing

J

J


Omschrijving De PVM zal het aangeboden bestand niet verwerken (geen inhoudelijke controle en geen verzending van het DIS-bestand) De PVM heeft het aangeboden bestand inhoudelijk gecontroleerd en fatale fouten gevonden waardoor er geen output bestand wordt aangemaakt. Er wordt geen DIS-bestand verzonden. De PVM heeft het aangeboden bestand inhoudelijk gecontroleerd, waarschuwingen (niet fatale fouten) gevonden en het output bestand wordt aangemaakt. Er wordt een DIS-bestand verzonden.

Pagina 29 van 58

Overzicht mogelijke fouten bij het verwerken van bestanden Nr 1002

Melding Het programma kan de opgegeven drive:\werkdirectory niet vinden.

Type T

Beschrijving De opgegeven drive:\werkdirectory kan niet gevonden worden.

1007

Het pad bestaat niet. Controleer het pad en probeer het opnieuw. De naam van het aangeboden bestand is verboden. Het aangeboden bestand kan niet uitgepakt worden. De pakbon is leeg. De pakbon bevat meer dan één regel. Het zipbestand bevat niet alle bestanden die door de GA zijn voorgeschreven PATIENT.txt bevat een regel met verkeerde lengte.

T

2001

Naam is niet gevuld

F

Het opgegeven bestand bevindt zich niet in de werkdirectory. De naam van het aangeboden bestand moet legitiem zijn. Het aangeboden bestand moet uitgepakt kunnen worden. (unzippen) Pakbon.txt moet één regel bevatten. Pakbon.txt mag niet meer dan één regel bevatten. De PVM controleert binnen iedere zip of alle voor het type GA verwachte bestanden aanwezig zijn. Er zijn 1 of meerdere regels gevonden waarvan de regellente niet voldoet aan de specificatie (te kort of te lang). Het veld ‘(za )naam_1’ moet gevuld zijn.

2002

Naamcode bevat geen geldige waarde.

F

2003 2004

Naam begint met een spatie. Naam bevat vreemde tekens

F F

2005

Voorletters is niet gevuld.

F

2006

Voorletters begint met een vreemd teken

F

2008

Landcode is niet gevuld

F

1008 1013 1017 1018 1021 1022


T T T T T T

Voor de velden ‘(za )naamcode_1’ en ‘(za )naamcode_2’ zijn alleen de waarden “spatie”, “1” of “2” toegestaan. De naam moet links uitgelijnd zijn. De naam moet gevuld zijn met een legitiem teken. De afhandeling van diakritische tekens wordt beschreven in Appendix ‘A’ De eerste positie van het veld ‘(za )voorletters’ moet gevuld zijn. De eerste positie van het veld ‘(za )voorletters’ moet gevuld zijn met een legitiem teken. De afhandeling van diakritische tekens wordt beschreven in Appendix ‘A’ Het veld ‘(za )landcode’ moet gevuld zijn.

Gevolg De foutcode en foutmelding blijven in beeld totdat een ander, geldig bestand wordt geselecteerd Idem Idem Idem Idem Idem Idem Idem

Resultaatscherm meldt validatiefouten. Detail-informatie kan in het verslag worden bekeken. Idem

Idem Idem

Idem Idem

Idem

Pagina 30 van 58

Nr 2009

Melding Postcode voor landcode 'NL' is niet gevuld

Type F

2010

Postcode bevat geen geldige waarde voor landcode 'NL'

F

2011 2012

Geboortedatum is niet gevuld Geboortedatum bevat geen geldige datum

F F

2013

Geboortedatum ligt in de toekomst

F

2014 2015 2021

F F F

2022 2023

Geslacht is niet gevuld Geslacht bevat een onbekende code Aantal records in PATIENT.txt is ongelijk aan Aantal patiënt volgens de pakbon BSN bevat geen geldige lengte BSN bevat een niet toegestaan teken

2026

BSN voldoet niet aan de 11-proef

F

2028 2029 2030 2031

Declarerende instelling is niet gevuld Instelling volgnr DIS is niet gevuld Koppelnummer is niet gevuld Het bestand bevat geanonimiseerde patiëntnamen

F F F F

2032 2033

Het bestand bevat geanonimiseerde voorletters Het bestand bevat geanonimiseerde BSNwaarden Naamcode_2 is niet gevuld terwijl Naam_2 wel is gevuld SKN bevat geen geldige lengte SKN is niet gevuld

F F

2034 2035 2036


F F

F F F

Beschrijving Indien ‘(za )landcode’ gevuld is met ‘NL’, moet het veld ‘(za )postcode’ gevuld zijn. Indien ‘(za )landcode’ gevuld is met ‘NL’ moet het veld ‘(za )postcode’ gevuld zijn met een postcode die voldoet aan het formaat ‘NNNNAA’. Het veld ‘(za )geboortedatum’ moet gevuld zijn. Het veld ‘(za )geboortedatum’ moet gevuld zijn met een goede datum. Formaat: EEJJMMDD. Het veld ‘(za )geboortedatum’ moet kleiner of gelijk zijn aan de systeemdatum. Het veld ‘(za )geslacht’ moet gevuld zijn. Het veld ‘(za )geslacht’ moet gevuld zijn met 0,1,2 of 9. Het aantal patiënten in pakbon.txt komt niet overeen met het aantal patiënten in patient.txt. Lengte veld is 9 posities Een van de tekens is niet numeriek (0 t/m 9) of bevat minder dan 9 spaties. De aangeleverde cijfer combinatie wordt niet goedgekeurd door de 11-proef. Declarerende instelling is een verplicht veld Instelling volgnr DIS is een verplicht veld Koppelnummer is een verplicht veld Als in het aangeboden bestand een patiënt voorkomt met een naam die louter bestaat uit 1 of meer X-en, dan is sprake van een geanonimiseerd bestand. (N.B de naam XAB of XYZ is daarmee een toegestane naam). Anoniem aanleveren is voor deze GA niet toegestaan. Anoniem aanleveren is voor deze GA niet toegestaan. Anoniem aanleveren is voor deze GA niet toegestaan.

Gevolg Idem

Naamcode_2 moet gevuld zijn indien Naam_2 gevuld is Het veld SK nummer moet 15 posities lang zijn Het veld SK nummer moet gevuld zijn. Leeg 15xspatie is NIET toegestaan.

Idem

Idem

Idem Idem Idem Idem Idem Idem Idem Idem Idem Idem Idem Idem Idem

Idem Idem

Idem Idem

Pagina 31 van 58

Nr 2037

Melding SKN bevat geen numerieke waarde

2038

Het bestand bevat geanonimiseerde SKN waarden BSN is niet gevuld

F

Eerste inschrijving voldoet niet aan patroon YYYYMM of valt buiten bereik 1900 - heden Laatste uitschrijving voldoet niet aan patroon YYYYMM of valt buiten bereik 1900 - heden Opgegeven certificaat '{certificate.input.file.path}' niet gevonden Opgegeven certificaat '{certificate.input.file.path}' kan niet worden gelezen Opgegeven certificaat '{certificate.input.file.path}' kan niet worden gelezen of het opgegeven wachtwoord is niet correct Uw certificaat is verlopen op {certificate.validity.endDate} Uw certificaat is pas geldig vanaf {certificate.validity.startDate} Het bestand bevat geanonimiseerde patiëntnamen.

F

2039 2041 2042 2043 2044 2045

2046 2047 3001

Type F

Gevolg Idem

F

Beschrijving Het veld SK nummer moet gevuld zijn met numerieke waarden Anoniem (15xX of 15x0) of (8x0+7x9) aanleveren is NIET toegestaan. Het veld BSN moet gevuld zijn. Leeg 9xspaties is NIET toegestaan. Eerste inschrijving moet binnen het bereik voor een geldige datum vallen Laatste inschrijving moet binnen het bereik voor een geldige datum vallen Certificaat niet benaderbaar

F

Certificaat niet leesbaar

Idem

F

Certificaat wachtwoord combinatie is niet correct

Idem

F

Certificaat verlopen

Idem

F

Certificaat nog niet geldig

Idem

W

Als in het aangeboden bestand een patiënt voorkomt met een naam die louter bestaat uit 1 of meer X-en, dan is sprake van een geanonimiseerd bestand. (N.B de naam XAB of XYZ is daarmee een toegestane naam) Als in het aangeboden bestand een patiënt voorkomt met een voorletter die louter bestaat uit 4 of meer X-en, dan is sprake van een geanonimiseerd bestand Als in het aangeboden bestand een patiënt voorkomt met een BSN nummer die bestaat uit 9 nullen of 9 spaties, dan is sprake van een geanonimiseerd bestand. Als het certificaat gaat verlopen, dan wordt de gebruiker gewaarschuwd binnen een instelbare termijn in dagen.

Resultaatscherm meldt waarschuwingen. Detailinformatie kan in het verslag worden bekeken. Idem

F

F

3002

Het bestand bevat geanonimiseerde voorletters.

W

3003

Het bestand bevat geanonimiseerde BSN waarden.

W

3004

Uw certificaat is nog {certificate.validity.days.remaining} dagen geldig

W


Idem Idem Idem Idem Idem

Idem

Idem

Pagina 32 van 58

Nr 3102*

Melding Naamcode bevat geen geldige waarde

Type W

3103* 3104*

Naam begint met een spatie Naam bevat vreemde tekens

W W

3106*

Voorletters begint met een vreemd teken

W

3110*

Postcode bevat geen geldige waarde voor landcode 'NL'

W

3112*

Geboortedatum bevat geen geldige datum

W

3113*

Geboortedatum ligt in de toekomst

W

3122* 3123*

BSN bevat geen geldige lengte BSN bevat een niet toegestaan teken

W W

3126*

BSN voldoet niet aan de '11-proef'

W

3131

Het bestand bevat geanonimiseerde patiëntnamen

W

Beschrijving Voor de velden ‘(za )naamcode_1’ en ‘(za )naamcode_2’ zijn alleen de waarden “spatie”, “1” of “2” toegestaan. De naam moet links uitgelijnd zijn. De naam moet gevuld zijn met een legitiem teken. De afhandeling van diakritische tekens wordt beschreven in Appendix ‘A’ De eerste positie van het veld ‘(za )voorletters’ moet gevuld zijn met een legitiem teken. De afhandeling van diakritische tekens wordt beschreven in Appendix ‘A’ Indien ‘(za )landcode’ gevuld is met ‘NL’ moet het veld ‘(za )postcode’ gevuld zijn met een postcode die voldoet aan het formaat ‘NNNNAA’. Het veld ‘(za )geboortedatum’ moet gevuld zijn met een goede datum. Formaat: EEJJMMDD. Het veld ‘(za )geboortedatum’ moet kleiner of gelijk zijn aan de systeemdatum. Lengte veld is 9 posities Een van de tekens is niet numeriek (0 t/m 9) of bevat minder dan 9 spaties. De aangeleverde cijfer combinatie wordt niet goedgekeurd door de 11-proef. Als in het aangeboden bestand een patiënt voorkomt met een naam die louter bestaat uit 1 of meer X-en, dan is sprake van een geanonimiseerd bestand. (N.B de naam XAB of XYZ is daarmee een toegestane naam)

Gevolg Idem

Idem Idem

Idem

Idem

Idem Idem Idem Idem Idem Idem

*Codes uit de range 31xx zijn steeds de tegenhanger van 20xx. De 31xx range wordt alleen gebruikt in de OHW 2.0 afhandeling.


Pagina 33 van 58

8.1

Toelichting op validaties

8.1.1 Validatie 1022 Voor elke GA versie is een vaste regellengte gespecificeerd (zie hoofdstuk 7). Per GA zal tijdens verwerking elke regel gecontroleerd wordt of deze gelijk is aan de lengte volgens de betreffende GA. Indien dit niet het geval is zal deze fout worden gegenereerd.

8.1.2 Validatie 2004 Vanaf PVM DIS versie 5.0 zijn namen die een punt (full stop, ascii teken 046) bevatten toegestaan.

8.1.3 Validatie 2021 Telling pakbon - aantal patiënten Op grond van het veld ‘Aantal Patiënt’ in de pakbon.txt wordt een controle uitgevoerd op het aantal patiënten.

8.1.4 Validatie 2034 Naamcode_2 moet gevuld zijn indien Naam_2 gevuld is. Op dit conditioneel verplichte veld wordt validatie 2034 uitgevoerd.

8.1.5 Validatie 2040 Vanaf PVM DIS 5.0 is deze controle komen te vervallen. Huisnummer is niet langer verplicht. Het veld wordt zoals in voorgaande versies het ook geval was niet doorgegeven.

8.1.6 Validatie 2041 en 2042 Voor GA FZ 2.0 geldt dat de velden eerste en laatste inschrijfdatum gevuld moeten worden met spaties (leeg) of numerieke waarden conform het format YYYYMM. De jaar – maand combinatie mag niet in de toekomst liggen. De validatie wordt als volgt uitgevoerd: 1. Controle format = Leeg (1 of meer spatie(s)), dan doorgeven. Indien niet leeg dan moet het format gelijk zijn aan: ‘YYYYMM’: YYYY numerieke waarden groter dan 1900, MM numeriek 01-12; 2. Controle YYYYMM = kleiner dan of gelijk aan Jaar – Maand van de systeem datum.

8.1.7 Validatie 3001/3002 Vanaf DIS 3.0 De controle op anoniem aanleveren moet voor alle GA versies op het volledige patient.txt bestand worden uitgevoerd en niet alleen op het eerste record. Zodra er een anoniem record wordt gevonden dient de validatie af te gaan. Voor de GA versie [SZ 2.0 OHW] leidt anonieme aanleveringen tot meldingen van het type ‘waarschuwing’ (coderange 3000).

Voor de overige GA versies ([FZ 2.0] en [SZ 7.0]) is anoniem aanleveren niet toegestaan en dient er in deze gevallen de volgende type 2 validatie af te gaan:  2031  2032

8.1.8 Validatie 3003 Afhandeling van het veld Burger Service Nummer (BSN) verschilt per aanleverstroom en GA versie. GA + versie Verplicht Type Lengte Begin End O N 9 129 137 SZG 7.0 V (9xN) AN 9 130 138 Fout - 2022 BSN heeft de verkeerde lengte - 2023 Het BSN bevat een niet toegestaan teken - 2026 Het BSN voldoet niet aan de 11-proef Anoniem (=9x0) aanleveren is NIET toegestaan -2033 BSN anoniem aangeleverd Leeg (=9x[spatie]) aanleveren is NIET toegestaan. PVM versie 2.3.46 trekt leeg 9x[spatie] gelijk aan anoniem9x0 en doorgelaten. Binnen de nieuwe PVM versie mag voor deze nieuwe GA versies 9x[spatie] of 9x0 niet worden geaccepteerd. -2039 BSN moet gevuld zijn PVM versie 2.3.46 maakt binnen de oude GA’s geen onderscheid tussen anonieme en lege BSN. PVM versies 3.0.0 en hoger dienen hier wel onderscheid tussen te maken. -9x9 is de default voor opzettelijk leeg n.a.v. BSN onbekend en moet worden doorgelaten. (hier wordt geen 11-proef validatie op toegepast) -9x[spatie] wordt niet meer ongevormd naar 9x0 maar wordt afgekeurd met melding 2033. SZ 2.0 OHW O (9xN) AN 9 130 138 Uitgangspunten Voor de SZ 2.0 OHW GA is het veld BSN optioneel. Ieder aangeleverd BSN wordt met de default waarde 9x0 gepseudonimiseerd. Er worden wel waarschuwingen in de rapportage opgenomen indien het veld BSN gevuld is, maar niet aan de eisen voldoet: - 3122 BSN heeft de verkeerde lengte - 3123 Het BSN bevat een niet toegestaan teken - 3126 Het BSN voldoet niet aan de 11-proef

8.1.9 Validaties 2035 t/m 2038 Deze validaties hebben betrekking op het Strafrecht Keten nummer en hebben allen betrekking op GA versie [FZ2.0]. GA + versie Verplicht Type Lengte Begin End FZ 2.0 V (15xN) AN 15 139 153 Fout Een SKN bestaat uit 15 posities, eventueel rechts uitgelijnd en uitgevuld met voorloopnullen - 2035 SKN heeft de verkeerde lengte Een SKN bevat alleen cijfers (0-9). Een SKN met ongeldige tekens wordt afgekeurd. - 2037 SKN bevat een niet toegestaan teken Anoniem (=15x0 of 15x9 of 8x0+7x9.) aanleveren is NIET toegestaan -2038 SKN anoniem aangeleverd De volgende codes zullen derhalve worden afgekeurd: 000000000000000


Pagina 35 van 58

999999999999999 000000009999999 Leeg (=15x[spatie]) aanleveren is NIET toegestaan. -2036 SKN moet gevuld zijn

8.1.10 Validaties 2043 t/m 2047 Wanneer de PVM headless wordt gebruikt, is het mogelijk een bestand te verwerken terwijl het certificaat niet bruikbaar is (de GUI voorkomt dit). In deze situatie wordt het bericht niet verstuurd onder vermelding van deze foutcodes.

8.1.11 Validaties 3100 t/m 3199 Deze validaties hebben betrekking op de afhandeling van onderhanden werk zoals beschreven voor de GA [SZ 2.0 OHW]. In de OHW afhandeling zijn een aantal van de te valideren velden optioneel. Dat heeft gevolgen voor het aanmaken van de pseudoniemen. Daarom is er voor gekozen om de validaties voor OHW als volgt af te werken: 1 2

3

Als het een optioneel veld betreft dat leeg (spaties) wordt aangeleverd, dan wordt dit niet gerapporteerd; Als het een optioneel veld betreft dat niet leeg wordt aangeleverd, dan volgt wel een validatie, maar deze wordt als waarschuwing gerapporteerd (31xx melding); Pseudoniemen worden voor OHW met de default waarde 9x0 gegeneerd en leveren dus altijd dezelfde pseudoniemen op.

8.1.12 Validatie 3110 De controle wordt alleen uitgevoerd als er voor zowel postcode als landcode iets is ingevuld, waarbij de landcode ook NL is. ALS landcode = ‘NL’ EN postcode is niet leeg DAN controleren (fouttype waarschuwing) ANDERS niet valideren


Pagina 36 van 58

9.

Meldingen en verslag verwerking PVM-DIS

Voor alle verwerkingen waar sprake is van validatiemeldingen van type ‘2’ en/of ‘3’ geldt dat hiervan melding wordt gemaakt in de werkdirectory of op het scherm (afhankelijk van de wijze waarop de PVM wordt aangestuurd: via de command line of via de grafische user interface). De voortgang van het programma wordt opgeslagen in het verslag met als naam “[aangeboden bestandsnaam]_DIS_PVM.HTML”. 1. Als de Privacy- en Verzend Module niet overgaat tot het verzenden van het resultaatbestand wegens validatiefouten (type 2), dan komen de betreffende fouten in het verslag te staan en wordt gemeld dat het uitvoerbestand niet is aangemaakt. Indien ook type 3 fouten voorkomen worden deze ook in het betreffende verslag gemeld. 2. Als de PVM-DIS door een fout in de omgeving blokkeert, dan wordt de bijbehorende foutcode getoond op het scherm. Er wordt in dat geval geen bestand aangemaakt. 3. Type 1 validaties worden in de GUI en Headless versie in het scherm getoond. 4. Ingeval van alleen type 3 validaties (meldingen) zullen deze in het verslag worden gemeld en zal de Privacy- en Verzend Module het resultaatbestand wel verzenden. Scherm Indien er fouten/waarschuwingen zijn geconstateerd tijdens de verwerking van een bericht zal dit worden getoond op het scherm. Uit de toelichting op het scherm moet duidelijk blijken dat het zowel om zowel fouten als waarschuwingen betreft. Bovendien is het mogelijk voor de gebruiker om via een knop het bijbehorende detail rapport te openen in een browser. Via configuratie is het mogelijk om deze knop zichtbaar te maken. Alleen van de eerste 10 fouten/waarschuwingen per fout-/waarschuwingscode worden de details getoond. Headless Op de command line wordt aan de hand van exit codes melding gemaakt van de voortgang van de verwerking. Daarbij worden de volgende codes gehanteerd: Code 0 1 10 20 30

Melding SUCCESS FILENOTFOUND_ERR VALIDATION_ERR UPLOADING_ERR

40 50

RESTART AANLEVERPLANNING_ERR

100

TECH_ERR


Toelichting De verwerking is succesvol afgerond Bewerking afgebroken door gebruiker Het te verwerken bestand is niet gevonden Er zijn validatiefouten opgetreden Het verwerkte bestand kan niet worden verzonden Het aan te leveren bestand wordt niet verwacht door de aanleverplanning Algemene melding voor technische problemen. Zie het log bestand voor meer informatie

Pagina 37 van 58

XML rapportage Vanaf versie 4.0 kan het verwerkingsverslag ook als XML document worden gegenereerd. In combinatie met de exit codes kan het gedrag van de module automatisch worden geïnterpreteerd vanuit aanleverende informatie systemen. In de map /../ZorgTTP/DIS/pvm/ staat het bestand report-template-zis-DISABLED.xml. Door de bestandsnaam aan te passen naar report-template-zis.xml wordt het aanmaken van de XML rapportage geactiveerd. De rapportage kent de volgende structuur: <Error> <Message> De standaard locatie waar het rapport wordt aangemaakt is gelijk aan de locatie waar de HTML rapportage wordt aangemaakt. De locatie kan worden aangepast door in het bestand /../ZorgTTP/DIS/pvm/translate.properties onderstaand element aan te passen: report.file.path.xml={input.file.path}{input.file.name}_DIS_PVM.XML. Inhoud verslag  Algemeen  Versienummer van de PVM DIS;  Startdatum en tijd van de PVM DIS;  De werkdirectory en de naam van de aangeboden zipfile;  Datum en tijd waarop de verwerking is beëindigd;  Status van de verwerking  Certificaat geldigheidsduur (indien van toepassing) 

Samenvatting    



Detail foutenlijst 

 

Het aantal regels in het bestand; Het aantal regels met fatale fouten (type 2); Het aantal regels met waarschuwingen (type 3); Tabel met alle fouten/waarschuwing codes die in de verwerking zijn opgetreden met code, type (fataal/waarschuwing), omschrijving en het aantal regels waar de fout heeft opgetreden. Van iedere getoonde fout wordt de foutcode, type, het regelnummer, Koppelnummer, de veldnaam, de waarde (inhoud) en een omschrijving van de fout getoond. Van iedere foutcode worden maximaal 10 resultaten in het verslag getoond.

Vragen 

Dit deel bevat de contact gegevens van DBC Onderhoud afdeling DIS


Pagina 38 van 58

Op grond van bovenstaande beschrijving wordt een verwerkingsrapport gegenereerd dat na verwerking beschikbaar komt voor de verzendende partij (de pvm gebruiker). Het rapport kan getoond worden via de knop ‘Toon rapport’ in de GUI. Het rapport wordt opgeslagen in de directory waar het oorspronkelijke bestand zich bevindt. Per berichtafhandeling (GA) kan worden gekozen voor het doorsturen van een samenvatting van het rapport naar DIS waarin de detailfoutenlijst ontbreekt ten opzichte van de volledige rapportage. 1. Type 3 fouten dienen onder de noemer - Waarschuwing - apart geteld te worden. Dit betekent dat het volgende getoond wordt in de samenvatting van het rapport: a. Aantal regels in het bestand b. Aantal regels met fatale fouten c. Aantal regels met waarschuwingen 2. Fouten moeten gesorteerd per categorie worden getoond. 3. Er moet op fouttype worden gesorteerd: a. fouten van type "fatale fout" b. fouten van type "waarschuwing" 4. Bij fouten en waarschuwingen detailinformatie tonen: een te configureren pseudoniem veld uit de betreffende regel. Voor PVM DIS geldt bij punt 4 uit bovenstaande lijst voor het koppelnummer (Koppelnummer) is gekozen. Zie de volgende pagina’s voor voorbeelden van verslagen.


Pagina 39 van 58

Voorbeeld van een verslag dat niet met het bestand wordt meegestuurd naar de ontvangende partij Kwaliteitsrapportage DIS Privacy & Verzend Module

Kenmerken Applicatie

PVM DIS

PVM Versie

5.3.0

Aangeboden bestand

DIS_GGZ_DBC_TEST_070_47471270_00_20150601_01.zip

Werkdirectory aangeboden bestand

D:\zttp\work\route-configurations\DIS\pvm\development\dev-pvm\test

Start verwerking

17-12-2015 / 14:10:06

Einde verwerking

17-12-2015 / 14:10:07

Status verwerking

[Er zijn [fatale fouten en] waarschuwingen opgetreden bij het uitvoeren van de eerste pseudonimisatie][De eerste pseudonimisatie is afgerond]. Het bestand is [niet] naar ZorgTTP verzonden.

Certificaat verloopt

Uw certificaat is nog […] dagen geldig. Voor meer informatie kunt u contact opnemen met Service en Informatiecentrum DIS

Samenvatting Aantal regels in het bestand

100

Aantal regels met fatale fouten (type 2)

100

Aantal regels met waarschuwingen (type 3)

0

Code

Type

Foutomschrijving

Aantal

2010

Fataal

De postcode is verkeerd.

100

2013

Fataal

De geboortedatum van de patient ligt in de toekomst.

100

Detail foutenlijst In onderstaande tabel worden de geconstateerde fouten weergegeven. Van elk soort melding worden de eerste tien gevallen weergegeven. Code Type

Regel KoppelNummer

Veld

Foutomschrijving

Inhoud

2010

Fataal

16

P000004

Postcode


2588

2010

Fataal

23

P000004

Postcode


2588

2010

Fataal

3

P000004

Postcode


2588

2010

Fataal

55

P000004

Postcode


2588

2010

Fataal

57

P000004

Postcode


2588

2010

Fataal

60

P000004

Postcode


2588

2010

Fataal

72

P000004

Postcode


2588

2010

Fataal

81

P000004

Postcode


2588

2010

Fataal

96

P000004

Postcode


2588

2010

Fataal

98

P000004

Postcode


2588

2013

Fataal

16

P000004

Geboortedatum

De geboortedatum van de patient 20700101 ligt in de toekomst.

2013

Fataal

23

P000004

Geboortedatum De geboortedatum van de patient 20700101


Pagina 40 van 58

ligt in de toekomst. 2013

Fataal

3

P000004

Geboortedatum


2013

Fataal

55

P000004

Geboortedatum


2013

Fataal

57

P000004

Geboortedatum


2013

Fataal

60

P000004

Geboortedatum


2013

Fataal

72

P000004

Geboortedatum


2013

Fataal

81

P000004

Geboortedatum


2013

Fataal

96

P000004

Geboortedatum


2013

Fataal

98

P000004

Geboortedatum


Vragen Als u vragen heeft naar aanleiding van deze rapportage, neem contact op met: Nederlandse Zorgautoriteit Postadres: Postbus 3017, 3502 GA Utrecht Website: www.dbcinformatiesysteem.nl E-mail: [email protected] Telefoon: 030-285 08 11


Pagina 41 van 58

Voorbeeld van een verslag dat met het bestand wordt meegestuurd naar de ontvangende partij Kwaliteitsrapportage DIS Privacy & Verzend Module Kenmerken Applicatie

PVM DIS

PVM Versie

5.3.0

Aangeboden bestand

DIS_GGZ_DBC_TEST_070_47471270_00_20150601_01.zip

Werkdirectory aangeboden bestand

D:\zttp\work\route-configurations\DIS\pvm\development\dev-pvm\test

Start verwerking

17-12-2015/ 14:10:06

Einde verwerking

17-12-2015 / 14:10:07

Status verwerking

[Er zijn [fatale fouten en] waarschuwingen opgetreden bij het uitvoeren van de eerste pseudonimisatie][De eerste pseudonimisatie is afgerond]. Het bestand is [niet] naar ZorgTTP verzonden.

Certificaat verloopt

Uw certificaat is nog […] dagen geldig. Voor meer informatie kunt u contact opnemen met Service en Informatiecentrum DIS

Samenvatting Aantal regels in het bestand

100

Aantal regels met fatale fouten (type 2)

100

Aantal regels met waarschuwingen (type 3)

0

Code

Type

Foutomschrijving

Aantal

2010

Fataal


100

2013

Fataal

De geboortedatum van de patient ligt in de toekomst.

100

Vragen Als u vragen heeft naar aanleiding van deze rapportage, neem contact op met: Nederlandse Zorgautoriteit Postadres: Postbus 3017, 3502 GA Utrecht Website: www.dbcinformatiesysteem.nl E-mail: [email protected] Telefoon: 030-285 08 11


Pagina 42 van 58

10. 10.1

Werking DRM-DIS

Algemeen

De DRM-DIS is de module die de gepseudonimiseerde data van het CMT ontvangt. Het is een push DRM wat wil zeggen dat het CMT de berichten naar de DRM pushed. De DRM-DIS is een webapplicatie bedoeld voor de Oracle Application Server: OC4J.

10.2

Outputbestanden DRM-DIS

De DRM-DIS maakt voor iedere berichtverzending een zipfile aan met als naam “ttp_dis_” gevolgd door de door de aanleverende instelling verstuurde bestandsnaam. Bijvoorbeeld: PVM verstuurt: DIS_GGZ_DBC_TEST_070_47471221_0_20150301.zip DRM maakt aan: ttp_dis_DIS_GGZ_DBC_TEST_070_47471221_0_20150301.zip Mocht er al een bestand met deze naam bestaan, dan wordt geen nieuwe file aangemaakt. De ontvangen bestanden worden door de CMT naar de DRM getransporteerd. Als webservice ontvangt de DRM deze bestanden en verwerkt deze. Na verwerking worden de bestanden in een in te stellen folder geplaatst (in te stellen via de eigenschap drm.store.location). De output zipfile bevat ongewijzigd alle outputbestanden van de PVM, met uitzondering van patient_s2.txt. In dat bestand zijn alle 1e orde pseudoniemen vervangen door 2e orde pseudoniemen. De regels van de patient_s2.txt wordt door de DRM voorzien van de regelafsluiting zoals gedefinieerd in de “dis.newline” property file: UNIX: UNIX platform gedefinieerde new line karakter: \n. WINDOWS: Windows gedefinieerde new line karakter: \r\n. MAC: Macintosh gedefinieerde new line karakter: \r.

10.3

ID 1: Afsplitsen verwerkingsrapport bij anonieme aanlevering

Bij anonieme aanlevering zal een verwerkingsrapport meegestuurd worden met de aanlevering. Bij aankomst wordt door de DRM dit verwerkingsrapport afgesplitst van de aanlevering. De aanlevering zal net als voorheen in de configureerbare (drm.store.location setting in dis-drm.properties bestand) folder terecht komen. Het verwerkingsrapport echter, zal als HTML bestand in een ‘REPORT’ folder opgeslagen worden direct onder de folder waarin de aanlevering terecht komt. Hieronder is een voorbeeld van de folderstructuur van hoe dit eruit zou kunnen zien: ${drm.store.location}/ /ttp_dis_DIS_GGZ_DBC_TEST_070_22220041_01_20150623_02.zip /REPORT/ /DIS_GGZ_DBC_TEST_070_22220041_01_20150623_02.html


Pagina 43 van 58

10.4

ID 1: Tweede certificaat ondersteuning

De DRM is in staat berichten van de DIS PVM 2.3.46 te ontvangen en te verwerken als ook berichten van de DIS PVM 3.0.0. De berichten (patient-s0.txt) van de DIS PVM 2.3.46 zijn met een ander certificaat versleuteld dan van de DIS PVM 3.0.0. De DRM is in staat met de sleutels van beide certificaten deze patient-s0.txt bestanden te openen om zodoende het bericht op te leveren conform de specificaties zoals in dit document beschreven. In pseudocode ziet het er als volgt uit: Probeer het patient-so.txt bestand te openen met sleutel1. ALS het niet lukt met sleutel1 DAN probeer dan sleutel2. ALS het niet lukt met sleutel2 DAN Er wordt een foutmelding hiervan gelogd ANDERS Vervolg verwerkingsproces ANDERS Vervolg verwerkingsproces

10.5

Het verwerkingsproces

De DRM is een webapplicatie die als service binnen Oracle application server runt. Een bestand dat via CMT richting de DRM wordt gepushed wordt als volgt verwerkt: 1. CMT stuurt een bericht naar de DRM 2. De DRM ontvangt het request van de CMT en start de verwerking van het binnengekomen bericht 3. De DRM maakt een ttp_dis_.tmp bestand aan in de drm.store.location (dit is een zip bestand). 4. Als het bericht een html bestand bevat is dat een rapport en wordt dit rapport bewaard zoals hiervoor beschreven. 5. Het pseudoniemen bestand hernoemd naar patient_s2.txt en wordt verwerkt: a. De IDZ en regelnummer worden voor elke regel in het pseudoniemen bestand geplaatst 6. Het patient_s2.txt wordt in het tijdelijke zip bestand geplaatst 7. Als het bericht afkomstig van de DIS 3.0 is wordt er een voorverwerking uitgevoerd: a. Indien er een pseudonyms.dat aanwezig is wordt deze uitgepakt als zip en in de drm.store.location gezet. b. Het temp.txt bestand wordt hernoemd tot ‘patient-s0.txt’. c. Het IDZ en regelnummer wordt voor elke regel gezet en het bestand wordt gesloten. d. Alle bestanden worden in het tijdelijke zip bestand geplaatst (stap 3) 8. De DRM verwijderd het oorspronkelijke bericht 9. De DRM geeft antwoord terug aan de cmt dat het bericht is verwerkt.


Pagina 44 van 58

Appendix A

Conversie ascii tekens

Onderstaande tabel geeft aan hoe binnen de PVM wordt omgegaan met aangeboden tekens. De werkwijze voor het normaliseren van deze tekens dient overeen te komen met de werkwijze op dit gebied bij andere ZorgTTP projecten teneinde een zo uniform mogelijke normalisatie van de input te bereiken. N.B ten opzichten van voorgaande versies van dit specificatiedocument dient rekening gehouden te worden met de volgende wijziging: 1. Voorletter/voornaamconversie;y-ij dient niet langer te worden uitgevoerd. Alleen op diakriet normaliseren en niet op y-ij De voorbewerking op voornaam wordt derhalve ljust(upper(translate_unicode(voornaam)),1) De voorbewerking op achternaam blijft ljust(upper(translate_unicode(genormaliseerde(achternaam))),8) Voor de afhandeling van het veld achternaam in de PVM DIS geldt dat er één foutsituatie, Fout 2004, is. Indien deze optreedt zal de aanlevering niet doorgaan. Voor de afhandeling van het veld voornaam in de PVM DIS geldt dat er 2 foutsituaties zijn, te weten : 1. De eerste positie van de voornaam bevat een blanco ( = chr(32) ), dit triggert de fout: Fout 2005 2. De eerste positie van de voornaam bevat een van de tekens in de range van de characterset 0-31, 33-64, 91-96, 123-137, 139, 141, 143-153, 155, 157,160, 163191, dit triggert de fout: Fout 2006 Indien één van deze fouten voorkomt zal de aanlevering niet doorgaan. Voor zowel de voornaam als de achternaam geldt dat, indien het omgezette teken valt in de range “A” t/m “Z” en indien de overige velden voldoen, er een pseudoniem wordt aangemaakt. Conversietabel Ascii Teken Omzetten Teken 8859naar 1 0 NUL 1 SOH 2 STX 3 ETX 4 EOT 5 ENQ 6 ACK 7 BEL 8 BS 9 HT 10 LF 11 VT 12 FF 13 CR 14 SO 15 SI Specificaties DIS 5.3 Versie 1.0 © ZorgTTP

Afhandeling achternaam Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004

Afhandeling voorletter Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Pagina 45 van 58

Ascii Teken Omzetten Teken 8859naar 1 16 DLE 17 DC1 18 DC2 19 DC3 20 DC4 21 NAK 22 SYN 23 ETB 24 CAN 25 EM 26 SUB 27 ESC 28 FS 29 GS 30 RS 31 US 32 32 [blanko] 33 ! 34 " 35 # 36 $ 37 % 38 & 39 ' 32 [blanko] 40 ( 41 ) 42 * 43 + 44 , 45 32 [blanko] 46 . 32 [blanko] 47 / 48 0 49 1 50 2 51 3 52 4 53 5 54 6 55 7 56 8 57 9 58 : 59 ; 60 < 61 = 62 > 63 ? 64 @ Specificaties DIS 5.3 Versie 1.0 © ZorgTTP

Afhandeling achternaam Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004

Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004

Afhandeling voorletter Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2005 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Pagina 46 van 58

Ascii Teken Omzetten Teken 8859naar 1 65 A 65 A 66 B 66 B 67 C 67 C 68 D 68 D 69 E 69 E 70 F 70 F 71 G 71 G 72 H 72 H 73 I 73 I 74 J 74 J 75 K 75 K 76 L 76 L 77 M 77 M 78 N 78 N 79 O 79 O 80 P 80 P 81 Q 81 Q 82 R 82 R 83 S 83 S 84 T 84 T 85 U 85 U 86 V 86 V 87 W 87 W 88 X 88 X 89 Y 89 Y 90 Z 90 Z 91 [ 92 \ 93 ] 94 ^ 95 _ 96 ` 97 a 65 A 98 b 66 B 99 c 67 C 100 d 68 D 101 e 69 E 102 f 70 F 103 g 71 G 104 h 72 H 105 i 73 I 106 j 74 J 107 k 75 K 108 l 76 L 109 m 77 M 110 n 78 N 111 o 79 O 112 p 80 P 113 q 81 Q Specificaties DIS 5.3 Versie 1.0 © ZorgTTP

Afhandeling achternaam

Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004

Afhandeling voorletter

Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006

Pagina 47 van 58

Ascii Teken Omzetten Teken 8859naar 1 114 r 82 R 115 s 83 S 116 t 84 T 117 u 85 U 118 v 86 V 119 w 87 W 120 x 88 X 121 y 89 Y 122 z 90 Z 123 { 124 | 125 } 126 ~ 127 128 € 129 130 ‚ 131 ƒ 132 „ 133 … 134 † 135 ‡ 136 ˆ 137 ‰ 138 Š 83 S 139 ‹ 140 Œ 79 O 141 142 Ž 90 Z 143 144 145 ‘ 146 ’ 147 “ 148 ” 149 • 150 – 151 — 152 ˜ 153 ™ 154 š 83 S 155 › 156 œ 79 O 157 158 ž 90 Z 159 Ÿ 89 Y 160 161 ¡ 73 I 162 ¢ 67 C Specificaties DIS 5.3 Versie 1.0 © ZorgTTP



Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004

Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006

Fout 2004

Fout 2006

Fout 2004

Fout 2006

Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004

Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006

Fout 2004

Fout 2006

Fout 2004

Fout 2006

Fout 2004

Fout 2006

Pagina 48 van 58

Ascii Teken Omzetten Teken 8859naar 1 163 £ 164 ¤ 165 ¥ 166 ¦ 167 § 168 ¨ 169 © 170 ª 171 « 172 ¬ 173 174 ® 175 ¯ 176 ° 177 ± 178 ² 179 ³ 180 ´ 181 µ 182 ¶ 183 · 184 ¸ 185 ¹ 186 º 187 » 188 ¼ 189 ½ 190 ¾ 191 ¿ 192 À 65 A 193 Á 65 A 194 Â 65 A 195 Ã 65 A 196 Ä 65 A 197 Å 65 A 198 Æ 65 A 199 Ç 67 C 200 È 69 E 201 É 69 E 202 Ê 69 E 203 Ë 69 E 204 Ì 73 I 205 Í 73 I 206 Î 73 I 207 Ï 73 I 208 Ð 68 D 209 Ñ 78 N 210 Ò 79 O 211 Ó 79 O Specificaties DIS 5.3 Versie 1.0 © ZorgTTP

Afhandeling achternaam Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004 Fout 2004

Afhandeling voorletter Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006 Fout 2006

Pagina 49 van 58

Ascii Teken Omzetten Teken 8859naar 1 212 Ô 79 O 213 Õ 79 O 214 Ö 79 O 215 × 88 X 216 Ø 79 O 217 Ù 85 U 218 Ú 85 U 219 Û 85 U 220 Ü 85 U 221 Ý 89 Y 222 Þ 66 B 223 ß 66 B 224 à 65 A 225 á 65 A 226 â 65 A 227 ã 65 A 228 ä 65 A 229 å 65 A 230 æ 65 A 231 ç 67 C 232 è 69 E 233 é 69 E 234 ê 69 E 235 ë 69 E 236 ì 73 I 237 í 73 I 238 î 73 I 239 ï 73 I 240 ð 79 O 241 ñ 78 N 242 ò 79 O 243 ó 79 O 244 ô 79 O 245 õ 79 O 246 ö 79 O 247 ÷ 73 I 248 ø 79 O 249 ù 85 U 250 ú 85 U 251 û 85 U 252 ü 85 U 253 ý 89 Y 254 þ 66 B 255 ÿ 89 Y




Pagina 50 van 58

Appendix B

‘11-proef’

In deze bijlage wordt de 11-proef beschreven. De 11-proef wordt uitgevoerd om vast te stellen of een Burger Service Nummer (BSN) valide is. Input: 9-cijferig nummer Bereken de 11-proef als volgt: 1st digit * 9 + 2nd digit * 8 + 3rd digit * 7 + 4th digit * 6 + 5th digit * 5 + 6th digit * 4 + 7th digit * 3 + 8th digit * 2 + 9th digit * -1 Het nummer voldoet aan de 11-proef als de som deelbaar is door elf én dit een geheel getal oplevert. Voorbeeld Input: 070536247 1st digit * 9 = 2nd digit * 8 = 3rd digit * 7 = 4th digit * 6 = 5th digit * 5 = 6th digit * 4 = 7th digit * 3 = 8th digit * 2 = 9th digit * -1 = elf proef som

0 56 0 30 15 24 6 8 -7 ---------- + 132

132 / 11 = 12. Daarom voldoet 070536247 aan de 11-proef.


Pagina 51 van 58

Appendix C

Installatie en Deinstallatie

De PVM installer ondersteunt een zogenaamde update installatie. De update installatie houd rekening met de volgende condities: - De user eigenschappen mogen niet worden ge-update wanneer hier geen wijzigingen zijn t.a.v. functionaliteit - Indien user properties wel gewijzigd moeten worden moet deze worden bewaard door de installer in een UserData folder en gemeld worden naar de gebruiker . De installer zal daarna de betreffende property bestanden overschrijven in de installatie folder. - Als het een update betreft dan moeten alle stappen worden overgeslagen in de install wizard (behalve de installatie stap). De installer bevat alle informatie van de vorige installatie om de installatie zonder interactie van de gebruiker te kunnen uitvoeren d.w.z. de installer weet de folder locatie van de installatie, program Group, de certificaatgegevens zijn ingesteld in de property bestanden en of er een desktop icon is geïnstalleerd. Tijdens de update installatie zullen de property bestanden gpvm, pvg, user en pvm niet worden overschreven. - Deinstallatie is tevens gewijzigd. De property bestanden (indien aanwezig) pvm, gpvm, pvg en user zullen nooit worden verwijderd. Op deze manier zullen deze gegevens ook na deinstallatie niet verloren gaan. Clean installatie Preconditie: er is nog geen installatie voor de pvm uitgevoerd. 1. De gebruiker start de pvm installatie 2. Het Welkom scherm wordt getoond 3. De gebruiker klikt op volgende 4. De installatieFolder scherm wordt getoond 5. De gebruiker vult gegevens in en klikt op volgende 6. Het StartMenuMap scherm wordt getoond 7. De gebruiker vult gegevens in en klikt op volgende 8. Het Snelkoppeling scherm wordt getoond 9. De gebruiker maakt keuze en klikt op volgende 10. Het BezigInstallatieVoortgang scherm wordt getoond a. De installer maakt installatie folder aan en program Group b. De installer installeert de bestanden in de installatie folder (geen overschrijving van de pvg, pvm, user en gpvm.properties) c. De installer bewaart de certificaatgevens in de user.properties. Het certificaat wachtwoord wordt versleuteld opgeslagen. d. De installer maakt evt. snelkoppeling aan 11. Het Eindeinstallatie scherm wordt getoond


Pagina 52 van 58

Update installatie Preconditie: er is reeds een installatie voor de pvm uitgevoerd. 1. De gebruiker start de pvm installatie 2. Het Welkom scherm wordt getoond 3. De gebruiker klikt op volgende 4. Het BezigInstallatieVoortgang scherm wordt getoond a. De installer installeert en overschrijft de bestanden in de installatie folder (geen overschrijving van de pvg, pvm, user en gpvm.properties) 5. Het Eindeinstallatie scherm wordt getoond Er zijn 2 mogelijkheden voor update: met en zonder overschrijving van gebruikers eigenschappen. Deze use case beschrijft zonder overschrijving en is de standaard use case die door de installer wordt uitgevoerd. Update installatie met overschrijving van de property bestanden Preconditie: er is reeds een installatie voor de pvm uitgevoerd. 1. De gebruiker start de pvm installatie 2. Het Welkom scherm wordt getoond 3. De gebruiker klikt op volgende 4. Het BezigInstallatieVoortgang scherm wordt getoond a. De installer kopieert de gpvm, pvm, pvg en user.properties bestanden naar de /UserData b. De installer installeert en overschrijft de bestanden in de installatie folder (geen overschrijving van de pvg, pvm, user en gpvm.properties) c. De installer toont een melding op het scherm dat de property bestanden zijn bewaard in de UserData folder 5. Het Eindeinstallatie scherm wordt getoond

Deinstallatie Preconditie: Er is een installatie gedaan van de pvm 1. De gebruiker start het deinstallatie programma 2. Het Welkom scherm wordt getoond 3. De gebruiker klikt volgende 4. De DeinstallatieVoortgang wordt getoond a. De deinstaller verwijderd alle bestanden en folders behalve pvm, pvg, user en gpvm.properties 5. Het EindeDeinstallatie scherm wordt getoond


Pagina 53 van 58

Appendix D versie 5.3

Additionele

specificaties

gerealiseerd

in

Issues uit offerte PVM DIS 5.3 Issue 64

65

Referentie

Omschrijving issue

Mailwisseling Bert-Jan Bongers Mailwisseling Bert-Jan Bongers

Issue: CZ 5.0 en GGZ 6.0 Gewenste wijziging: uitzetten CZ 5.0 en GGZ 6.0


Issue: vanwege verhuizing kloppen de adresgegevens niet meer Gewenste wijziging: aanpassen adresgegevens SIDIS in verwerkingsrapport en handleidingen

Pagina 54 van 58

Appendix E

Actuele Productieversies PVM DIS

Met de introductie van versie 5.2 is besloten om voor alle oude in gebruik zijnde versies de melding te activeren dat er een nieuwe versie beschikbaar is. Dit in tegenstelling tot eerdere situaties waarbij er voor gekozen is om alleen voor een bepaald deel van de gebruikersgroep deze melding te tonen in verband met het parallel ondersteunen van een oude en een nieuwe versie van de PVM of om te kunnen differentiëren naar type gebruiker (GGZ, SZ, FZ, etc). Daarvoor kan worden gekozen om bijvoorbeeld bepaalde functionele aanpassingen aan de programmatuur eerst in het deel van de DIS gebruikerspopulatie te introduceren waarop de wijziging van toepassing is. Voor de overige gebruikers wordt daarmee voorkomen dat ze direct worden gedwongen een nieuwe versie te installeren zonder dat daartoe een functionele noodzaak bestaat. Bij het opstarten van de PVM wordt voor het uitvoeren van de versiecontrole verbinding gemaakt met ZorgTTP.nl. Indien het versienummer van de PVM afwijkt ten opzichte van het versienummer op de website dan wordt hiervan melding gemaakt aan de gebruiker. Het versienummer staat ingesteld op de volgende historische URL’s: Versie

URL

3.0.1 3.0.2 4.0 5.0 5.1 5.2

https://www.zorgttp.nl/pvm/dis/latestVersion/301/LatestVersion https://www.zorgttp.nl/pvm/dis/latestVersion/302/LatestVersion https://www.zorgttp.nl/pvm/dis/latestVersion/400/LatestVersion https://www.zorgttp.nl/pvm/dis/latestVersion/500/LatestVersion https://www.zorgttp.nl/pvm/dis/latestVersion/510/LatestVersion https://www.zorgttp.nl/pvm/dis/latestVersion/520/LatestVersion


Ingestelde Waarde 4.0.0 4.0.0 4.0.0 5.0.0 5.1.0 5.2.0

Pagina 55 van 58

Appendix F

Ontwerp Webservice Aanleverplanning

Het ontwerp voor de webservice is beschreven in het door DIS opgestelde document: FO versie 1.0 WS Interface, 11 augustus 2010, DISnr: DIS00865 [DIS00865 Functioneel Ontwerp Webservice versie 1.0 definitief.pdf] De uit het ontwerpdocument relevante elementen voor de PVM specificatie zijn de te verzenden en terug te ontvangen parameters. Er is daarbij sprake van een tweetal varianten op de webservice. Een variant voor de oude PVM DIS versies en een variant voor de PVM DIS versies vanaf versie 3.0. Oude webservice De oude webservice kan worden aangeroepen op het adres https://www.disportal.nl/Aanleverplanning/AanleverplanningService en ontvangt conform de beschrijving op https://www.disportal.nl/Aanleverplanning/AanleverplanningService?WSDL vanuit de PVM twee elementen middels een webservice aanroep: Omschrijving

Element

UserName / gebruikersnaam

(P_GEB_NM)

Filename / bestandsnaam

(P_BST_NM)

Als antwoord geeft de oude webservice 2 elementen terug aan de PVM: Omschrijving

Element


(P_BST_NM)

Status

(P_STATUS)

Waarbij de status de waarden ‘VERWACHT’ of ‘NIET VERWACHT’ kan hebben. Alleen als de status ‘VERWACHT’ is wordt de bestandsnaam gevuld en meegegeven anders wordt een leeg element meegeven. Webservice vanaf PVM 3.0 De huidige webservice ontvangt vanuit de PVM vier parameters middels de URL https://www.disportal.nl/Aanleverplanning/AanleverplanningServicePVM conform de beschrijving zoals gegeven op https://www.disportal.nl/Aanleverplanning/AanleverplanningServicePVM?WSDL. In de aanroep worden vier parameters ontvangen. Omschrijving

Element

UserName / gebruikersnaam

(P_GEB_NM)


(P_BST_NM)

PVM versie waaronder het bestand is aangeleverd

(P_PVM_VRS)

Certificaatnummer waaronder is aangeleverd

(P_CRT_NR)


Pagina 56 van 58

Omschrijving

Element

Filename / bestandsnaam Status

(P_BST_NM) (P_STATUS)

In de PVM wordt het element P_GEB_NM ontdaan van eventuele spaties voorafgaand of volgend op het element (trimmen van leading en trailing spaces). Waarbij de status de waarden ‘VERWACHT’ of ‘NIET VERWACHT’ kan hebben. Alleen als de status ‘VERWACHT’ is wordt de bestandsnaam gevuld en meegegeven anders wordt een leeg element meegeven. Alleen als de status ‘NIET VERWACHT’ is wordt de foutomschrijving mee terug gegeven. N.B. Vanaf 1-12-2011 worden ten gevolge van het faillissement van CA Diginotar ceritificaten van meerdere CA’s ondersteund. Het element P_CRT_NR is daarmee niet uniek op een bepaalde CA terug te herleiden. Vooralsnog is er voor gekozen om geen maatregelen te nemen om dit issue op te lossen. Mogelijke oplossingen zijn: 1. Aanvullend zou het veld “Issuer” kunnen worden meegeleverd om het certificaat serienummer opnieuw uniek te maken door de naam van de CA te koppelen aan het serienummer. Let wel dat hierbij het nieuwe element ook aanvullend aan de webservice zal moeten worden toegevoegd. 2. het weglaten van het certificaat serienummer.


Pagina 57 van 58

Appendix G

Voorbeelden afhandeling BSN per GA

Onderstaande tabel bevat voorbeelden van de afhandeling van het veld BSN voor verschillende situaties per GA.

GA versie

BSN input 9x9

SZ 7.0, FZG 2.0, GBG 1.0, GGZ 7.0

OHW 2.0

Geen fatal/warn

Geen fatal/warn

OS1B340acab7b574a7dc5b81a3ea4137 OS1B340acab7b574a7dc5b81a3ea4137 9x0 (nul)

fatal 2033

warn 3003 OS1B

9xspatie

fatal 2039

Geen fatal/warn OS1B

Vreemd teken 1234%6789

fatal 2023, 2026

warn 3123 OS1B

Te kort 9999999

fatal 2022, 2023, 2026

warn 3122 OS1B

Niet 11-proef 123456789

fatal 2026

warn 3126 OS1B


Pagina 58 van 58

SPECIFICATIES Privacy- en Verzendmodule DBC Informatie Systeem (DIS 5.3)

Recommend Documents