Advies TBC-Automatisering. Standaardisatie en uitwisseling van gegevensbestanden

Advies TBC-Automatisering

Standaardisatie en uitwisseling van gegevensbestanden

Landelijke Werkgroep Automatisering TBC Utrecht, april 2004




ADVIES TBC-AUTOMATISERING

Voorlegger ten behoeve van de bestuursvergadering van GGD Nederland d.d. 2 juni 2004

Toelichting: Volledige titel: TBC automatisering “Standaardisatie en uitwisseling van gegevensbestanden”. Dit advies is opgesteld door de Landelijke werkgroep automatisering TBC (LWA tbc). Voor administratie en registratie van gegevens in de tuberculosebestrijding zijn in Nederland veel verschillende softwaresystemen in gebruik. Naast de Cliënt Informatie Systemen (CIS) heeft de digitalisering van de röntgenbeelden de afgelopen jaren een enorme vlucht genomen. Ook hiervoor zijn verschillende softwaresystemen in gebruik. Het uitwisselen van gegevens tussen deze systemen is niet optimaal tot zeer gebrekkig. De werkgroep doet verslag van een onderzoek naar nut, noodzaak en uitvoerbaarheid van landsbrede gegevensuitwisseling. De inhoudelijke standaardisatie is uitgewerkt (door de CPT/KNCV) en de werkgroep heeft i.s.m. vier grote softwareleveranciers een technische standaard voorbereid. Er is een datamatch-experiment uitgevoerd. TNO heeft in opdracht van de werkgroep architecturen uitgewerkt voor landsbrede uitwisseling van gegevens. Met NICTIZ zijn oriënterende besprekingen gevoerd. In het rapport worden de uitkomsten van bovenstaande activiteiten samengevat en worden aanbevelingen gedaan voor een implementatietraject. De stuurgroep VISI constateert dat het voorliggende opschalingstraject TBC-bestrijding (ROI Limburg) bij uitstek kansen biedt om de knelpunten in de automatisering nu aan te pakken; dit automatiseringstraject is een belangrijke ondersteuning aan de functionele regionale opschaling van de TBC. Er zijn hoge kosten mee gemoeid. Een implementatietraject zal landelijk gefaciliteerd moeten worden om aanbestedings- en schaalvoordelen optimaal te benutten.

Financiële en personele consequenties: Goede afstemming met AII en het “Realisatietraject versterking Infectieziektebestrijding” (waarvoor naar alle waarschijnlijkheid VWS financiële middelen ter beschikking stelt) is nodig.

Eerder genomen besluiten: Bestuurs-/ALV besluiten over screening asielzoekers

Advies; adviescie/bestuurscie: De projectgroep infectieziekten ondersteunt het voorgestelde besluit en ziet grote voordelen in standaardisatie van de automatisering tbc.

3


Voorgesteld besluit: • Met instemming kennis te nemen van het verslag en de aanbevelingen. • Te besluiten een landelijke werkgroep in te richten van regionaal betrokken/deskundige medewerkers aan wie verzocht wordt: 1. na overleg met TNO en NICTIZ een implementatietraject uit te werken op grond van de aanbevelingen van de LWAtbc; 2. een begroting op te stellen van de implementatie en frictiekosten; 3. na overleg met potentiële financiers een plan voor financiële dekking voor te stellen.




Vervolgprocedure:

Bijlagen: TBC automatisering “Standaardisatie en uitwisseling van gegevensbestanden”


4

5



Inhoudsopgave

6

Samenvatting

9

1. Achtergrond

11

2. Probleem en opdrachtformulering

12

3. Werkwijze

13

4. Resultaten 4.1.1 Voordelen van gegevensuitwisseling door standaardisatie 4.1.2 Mogelijkheden en beperkingen voor de uitwisseling van gegevens 4.1.3 rendement van een landelijke database 4.2 Automatisering en regionalisering 4.3 Invoeren van een standaard 4.3.1 Standaardisatie in de zorg 4.3.2 Organisatorische infrastructuur 4.3.3 Vervolgtraject

14 14 14 15 15 16 16 17 17

5. Conclusies en aanbevelingen

19

Geraadpleegde bronnen Samenstelling werkgroepen

21 22

7



Samenvatting Voor administratie en registratie van gegevens in de tuberculosebestrijding zijn in Nederland veel verschillende softwaresystemen in gebruik. Naast de Cliënt Informatie Systemen (CIS) heeft de digitalisering van de röntgenbeelden de afgelopen jaren een enorme vlucht genomen. Ook hiervoor zijn verschillende softwaresystemen in gebruik. Om het standaardisatieproces op gang te brengen heeft een werkgroep van de Commissie voor de Praktische Tuberculosebestrijding (CPT) een inhoudelijke standaard vastgesteld, waardoor een breed draagvlak is bij de professionals in de tuberculosebestrijding. De door de gezondheidsraad voorgestelde opschaling zal de vraag naar uniformiteit en standaardisatie in automatiseringssystemen doen toenemen. De regionalisering biedt daarom een unieke gelegenheid om het automatiseringsvraagstuk aan te pakken De grote diversiteit aan softwaresystemen bemoeilijkt de onderlinge uitwisseling van geautomatiseerde gegevens. De inhoudelijk vastgestelde standaard is niet vertaald in een technische standaard, dit is nodig alvorens het kan worden geïmplementeerd in de verschillende systemen. Ook is het niet mogelijk om informatie en digitale röntgenfoto’s via een beveiligd netwerk uit te wisselen. Er is geen organisatorische infrastructuur voor de GGD’en voor de invoering van een vastgestelde professionele standaard. Er zijn geen afspraken over beheer en onderhoud van de standaard. Nadat er een landelijke werkgroep is samengesteld is de opdracht uitgewerkt waarin de werkgroep heeft onderzocht wat de belangrijkste voordelen van gegevensuitwisseling zijn, welke mogelijkheden en beperkingen er zijn en wat het mogelijke rendement van een centrale database zou kunnen zijn. De werkgroep heeft zich gebogen over de vraag wat de TBC regionalisering betekent voor de automatisering. Daarnaast is een voorstel uitgewerkt over de wijze waarop de standaard kan worden ingevoerd. Om deze opdracht uit te werken zijn twee werkconferenties georganiseerd, is een datamatch uitgevoerd, een werkdocument inhoudelijke en technische standaard ontwikkeld in samenwerking met de softwareleveranciers, door TNO een advies uitgebracht en zijn er oriënterende besprekingen gehouden met NICTIZ. In de afgelopen anderhalf jaar heeft de landelijke werkgroep automatisering tuberculosebestrijding zich gebogen over een aantal belangrijke knelpunten in het veld. De uitvoerders en softwaresysteembouwers zijn hierbij nauw betrokken. De belangrijkste voordelen van standaardisatie en gegevensuitwisseling via een landelijke database zijn de mogelijkheid om via een systeem digitale foto’s op te vragen bij een andere GGD. Tevens kan worden voorkomen dat mensen te frequent worden gescreend op tuberculose. Met behulp van gegevens uit de DICOM header zijn er beperkte mogelijkheden voor het inrichten van een landelijke database. De minimale set gegevens, nodig voor een landelijke database, is vastgesteld en is door de meeste GGD’en ook aan te leveren, met uitzondering van het toekennen van een uniek nummer. De afwezigheid van een systeem voor het toekennen van unieke nummers voor identificatie van gegevens is een van de belangrijkste knelpunten die moet worden opgelost. Op basis van een data-match is het rendement van gegevensuitwisseling gekwantificeerd. Er kan voorzichtig worden uitgegaan van een rendement van 5-6% voor de screeningen van gedetineerden in PI’s als er een landelijke database wordt ingericht. In het kader van de regionalisering wordt geadviseerd slechts een softwaresysteem per regio te gaan gebruiken, dit maakt de uitwisselbaarheid van gegevens het meest eenvoudig. Bovendien bevordert het de standaardisatie van werkwijzen op de tbc-afdelingen. De landelijke werkgroep heeft uitspraken en aanbevelingen gedaan over het gebruik van (inter)nationale standaarden in de medische sector. GGD Nederland is aangesloten bij de stichting HL7 en beschikt zodoende over de meest recente standaarden. De werkgroep heeft een schets gegeven van de organisa-

8

9


torische infrastructuur die nodig is voor het beheer en onderhoud van een landelijk systeem. Tevens doet zij een voorstel voor een vervolgtraject voor de implementatie van de standaard in samenwerking met NICTIZ en TNO.


1. Achtergrond Een van de subdoelstellingen in het projectvoorstel van VISI beschrijft de noodzaak van een goed doordachte en solide informatie-uitwisseling op het terrein van infectieziektebestrijding en hygiënezorg in verband met de snelle nationale en internationale ontwikkelingen op deze werkgebieden.1) Dit geldt zeker voor de Nederlandse tuberculosebestrijding waar een grote diversiteit van software systemen in gebruik is voor de registratie en administratie van cliëntgegevens, daarnaast wordt de afgelopen jaren door de GGD’en in toenemende mate gebruik gemaakt van digitale röntgenapparatuur. Dit brengt nieuwe vragen, problemen en uitdagingen met zich mee. In 1999 adviseerde de commissie WBO van de gezondheidsraad2) om de uitvoeringsoperatie van de tuberculosebestrijding terug te brengen tot ongeveer acht of tien regionale verbanden. Vanuit het ROI Limburg is in het kader van het project VISI hierover een advies uitgebracht. De voorgestelde opschaling zal de vraag naar uniformiteit en standaardisatie in automatiseringssystemen doen toenemen. De regionalisering biedt daarom een unieke gelegenheid om het automatiseringsvraagstuk aan te pakken. Vanuit de Commissie voor de Praktische Tuberculosebestrijding (CPT) hebben rondom dit onderwerp twee werkgroepen een advies uitgebracht. De werkgroep digitalisering heeft de CPT geadviseerd een werkgroep standaardisering in te stellen met de opdracht de inhoudelijke standaard voor de TBC vast te stellen. Het Eindrapport Commissie Standaardisatie is in november 2002 vastgesteld op de vergadering van de Commissie Praktische Tuberculosebestrijding (CPT) en in januari 2003 verzonden naar alle deelnemers van de werkconferentie, GGD directeuren en alle hoofden afdeling AGZ/TBC. Deze inhoudelijke standaard is vastgesteld door professionals uit de TBC bestrijding. De complexiteit van het standaardisatietraject wordt mede bepaald door het feit dat er 40 GGD’en zijn, 3 softwareleveranciers voor cliënt informatie (Tubisgroep, Ensemble/Mars en Prevalent) die samen 75% van de GD’en bedienen, daarnaast is er een 10 tal verschillende geautomatiseerde administratiesystemen in gebruik (zie bijlage 1). Er zijn twee leveranciers voor digitale röntgen apparatuur; Oldelft en GE Medical systems. Standaardisatie in de automatisering is een dynamisch proces. Dat er geen sprake is van standaardisatie is onder andere sterk tot uiting gekomen bij het onderzoek van ZonMw en de KNCV naar de screeningsresultaten van asielzoekers.3) Huidige ontwikkelingen zoals de digitalisering van de MRU en de realisatie van de integratie met bestaande softwaresystemen verhogen de kwaliteit en efficiency van de tuberculosebestrijding. Dit roept nieuwe vragen op rondom de gegevensuitwisseling van de GGD’en die een functie vervullen bij de screening van gevangenen en asielzoekers . Naast juridische en organisatorische randvoorwaarden spelen diverse andere factoren een rol bij de invoering van een landelijk automatiseringstraject.4) Het gaat daarbij om goede afspraken over privacy, gegevenbeheer en -bewerking, netwerkonderhoud, gebruikersvriendelijkheid enzovoort.

10

11


2. Probleem en opdrachtformulering


3. Werkwijze

Binnen de automatisering van de tuberculosebestrijding zijn de volgende problemen gedefinieerd: • Er is een grote diversiteit van softwaresystemen op de GGD’en met een TBC afdeling, hierdoor is het niet eenvoudig om geautomatiseerde gegevens van de tbc afdelingen tussen GGD’en onderling uit te wisselen. • Er is een landelijke inhoudelijke standaard vastgesteld, maar deze is nog niet vertaald in een technische standaard. • Het is niet mogelijk om informatie en digitale röntgenfoto’s digitaal via een netwerk uit te wisselen. • Er is geen bestaande organisatorische infrastructuur voor de GGD’en voor de invoering van een vastgestelde professionele standaard in de gebruikte softwarepakketten. Er zijn geen afspraken over het beheer en onderhoud van de standaard.

Er is een landelijke werkgroep automatisering TBC (LAW-tbc) geïnstalleerd, deze is samengesteld uit GGD medewerkers van TBC afdelingen (voortgekomen uit deelnemers werkgroep standaardisatie), GGD Nederland, KNCV en medewerkers van het VISI project. De werkgroep is acht keer in vergadering bijeen geweest. Voor de uitwerking van deelvraagstukken zijn de volgende activiteiten georganiseerd • de werkgroep heeft twee werkconferenties georganiseerd, • er is een datamatch uitgevoerd, • samen met softwareleveranciers is een werkdocument inhoudelijke en technische standaard ontwikkeld, • TNO, afdeling medische informatica heeft een advies uitgebracht en • er werd een oriënterend gesprek gevoerd met NICTIZ.

Opdracht aan de landelijke werkgroep Op basis van de bovenstaande problematiek heeft de werkgroep de volgende opdrachten uitgewerkt: • De werkgroep onderzoekt • wat de belangrijkste voordelen zijn van gegevensuitwisseling • welke mogelijkheden en beperkingen er zijn voor uitwisseling gegevens, waaronder digitale röntgenfoto’s • wat het (mogelijke) rendement is van een landelijke database voor de tuberculosebestrijding. • De werkgroep brengt een advies uit aan ROI Limburg over de automatisering in relatie met de regionalisering. • De werkgroep doet een voorstel voor de wijze waarop de vastgestelde standaard kan worden ingevoerd en adviseert over een mogelijk vervolgtraject. De werkgroep doet een voorstel met betrekking tot de organisatorische infrastructuur voor beheer en onderhoud van standaarden.

Voor de werkconferenties zijn alle GGD’en, met vertegenwoordigers uit de verschillende gebruikersgroepen, software leveranciers en koepelorganisaties uitgenodigd. Deelnemers zijn zo veel mogelijk persoonlijk benaderd, tevens zijn de hoofden afdeling AGZ/TBC uitgenodigd. Verslagen van deze conferenties zijn in bijlagen aan dit document toegevoegd5) 6) (bijlage 3 en 4). In juli 2003 is in samenwerking met GGD Nederland een datamatch uitgevoerd door de vier GGD’en die MRU’s gebruiken voor de screening van gevangenen (bijlage 5). Het doel van de match is om een inschatting te kunnen maken wat het rendement is van efficiëntere gegevensuitwisseling via een landelijke database. Om dit juridisch verantwoord eenmalig te kunnen uitvoeren is een juridisch protocol geschreven. Op 7 mei en 11 december 2003 is een bespreking geweest met de vijf softwareleveranciers om te komen tot de formulering van een technische standaard. TNO, afdeling medische informatica, werd de opdracht gegeven het beschreven werkdocument te toetsen en gevraagd een aantal scenario’s voor te leggen voor een mogelijk vervolgtraject voor de invoering van de standaard. Op 4 februari is een eerste oriënterende bespreking geweest met NICTIZ over een mogelijk vervolgtraject.

12

13


4. Resultaten In dit hoofdstuk worden achtereenvolgens de drie deelvraagstukken uitgewerkt, gebaseerd op de geformuleerde opdracht van de werkgroep.

4.1.1 Voordelen van gegevensuitwisseling door standaardisatie Standaardisatie levert een kwaliteitsverbetering op, vergelijkbaarheid van gegevens wordt verbeterd, de transparantie en uitwisselbaarheid van gegevens worden bevorderd. De belangrijkste voordelen van geautomatiseerde gegevensuitwisseling tussen GGD’en zijn door de werkgroep als volgt geformuleerd: 1. Digitale foto’s kunnen via een netwerk worden verzonden waardoor ze op een andere locatie door een tuberculosearts kunnen worden beoordeeld en 2. Er kan worden voorkomen dat iemand te frequent wordt gescreend op tuberculose 3. Snellere beschikbaarheid van foto’s en medische informatie verhoogt de efficiency van werken Uiteraard zijn er op detailniveau meer voordelen te benoemen, zoals efficiëntere gegevensuitwisseling bij bron- en contactopsporing en deelname aan landelijke onderzoeken naar effectiviteit van screening.

4.1.2 Mogelijkheden en beperkingen voor uitwisseling van gegevens In de huidige situatie is het door de grote diversiteit aan softwaresystemen niet mogelijk om vanuit de cliënt informatiesystemen gegevens aan te leveren voor een landelijke database. Hiervoor zal eerst standaardisatie moeten worden doorgevoerd (zie hoofdstuk 4.3.1). De gegevens uit de DICOM-header (vanuit de digitale fotobestanden) bieden beperkte mogelijkheden voor het inrichten van een centrale database. Het is echter wel lastig om alle bestanden effectief te raadplegen voor een 100 % match. Bij bijvoorbeeld de Vries uit 1-9-1970 verschijnen dezelfde achternamen voor verschillende personen. Er is dus een behoorlijke zoektijd en het zoekresultaat is niet 100% efficiënt. Gebruik van unieke nummers is hiervoor de oplossing, maar dit is niet eenvoudig te realiseren. Er zijn minimaal 7 items nodig om na te gaan of iemand bekend is bij de GGD. Dit zijn: voornaam, achternaam, voorletter(s), geboortedatum, geslacht, nummer en naam van de GGD waar de verrichting is gedaan. Om allerlei redenen zou het handig zijn om de onderzoeksdatum te weten, maar dit is niet noodzakelijk voor het vinden van een foto. Een van de belangrijkste knelpunten van dit moment is de afwezigheid van een systeem voor unieke nummering voor identificatie van gegevens. Het doel van unieke nummering is 4-ledig; • dubbelingen worden voorkomen • het geeft informatie over de TBC voorgeschiedenis, • snelle en betrouwbare check van eerder gemaakte foto’s en • vanuit statistische oogpunt is de betrouwbaarheid van de gegevens in de database groter De belangrijkste voorwaarden waaronder unieke nummering kan plaatsvinden is als er toestemming is van betrokkene en informatie verstrekt wordt over de Database. Tevens moet in een protocol zijn vastgelegd wie wanneer toegang heeft tot de database waarbij de cliënt de vrijheid heeft om te weigeren. De knelpunten die kunnen optreden bij het toekennen van unieke nummers: iemand heeft de vrijheid om te weigeren of is niet in staat om toestemming te geven door bijvoorbeeld taalproblemen. Ook kan het

14


voorkomen dat iemand geen identifiers (bij zich) heeft. Een registratiesysteem met unieke nummering (b.v. sofi-nummer of GBA nummer) moet gemeld worden bij het College Bescherming Persoonsgegevens (CBP). Ieder aangemeld systeem wordt door het CBP getoetst op koppelingsmogelijkheden met bestanden die voor andere doeleinden worden gebruikt. Wanneer die koppeling mogelijk is geeft het college geen toestemming. Dit maakt het vrijwel onmogelijk om het sofi-nummer of GBA nummer te gebruiken als identifier in een tbc-registratie systeem. Op de ministeries van BZK en SZW wordt op dit moment nagedacht en gewerkt aan de ontwikkeling van de eNIK (elektronische Nederlandse IdentiteitsKaart) in combinatie met biomarkers. Tevens wordt vanuit die ministeries aansluiting gezocht bij VWS die zich in het verleden heeft bezig gehouden met het ontwikkelen van een zorgpas. Het is van belang deze ontwikkelingen nauwlettend te blijven volgen. Naar verwachting zal dit echter niet op korte termijn zijn gerealiseerd.

4.1.3 Rendement van een landelijke database Om een indicatie te krijgen van het mogelijke rendement van een landelijk systeem voor gegevensuitwisseling is een datamatch uitgevoerd. De gegevenbestanden, afkomstig uit de DICOM header, zijn samengevoegd. Het betreft data van 4 GGD’en die de verplichte gedetineerden screeningen uitvoeren in de Penitentiaire Inrichtingen (PI’s). Het doel van de match was om te onderzoeken hoeveel dubbele, mogelijk niet noodzakelijke screeningen worden gedaan7) (bijlage 5), dit in verband met het grote aantal recidivisten in PI’s. Alvorens deze data-match werd uitgevoerd werd een juridisch protocol opgesteld.8) Hoewel hieruit geen harde conclusies kunnen worden getrokken kan met enige terughoudendheid worden geconstateerd dat 5-6 % van de records in dit onderzoek werden gekwalificeerd als vermoedelijk onterecht gescreend op TBC.

4.2 Automatisering en regionalisering Aan de hand van de ervaringen uit Limburg is tijdens een van de werkconferenties besproken aan welke eisen software moet voldoen in het kader van regionalisering van de tuberculose bestrijding. In Limburg wordt op dit moment nog gewerkt met drie verschillende systemen van dataopslag, er wordt nog niet gewerkt met gedigitaliseerde röntgenapparaten. Vanuit de werkgroep wordt geadviseerd: • Kies in het kader van regionalisering voor 1 systeem in 1 regio, dit maakt uitwisselbaarheid van gegevens het meest eenvoudig • Bij het gebruik van mobiele röntgenunits moet speciale aandacht zijn voor het synchronisatie proces • het systeem moet de mogelijkheid bieden om vanuit 1 werklocatie cliëntgegevens en foto’s van het hele werkgebied uit te wisselen • het systeem moet de inhoudelijke standaard bevatten die door de CPT is vastgesteld. • het softwarepakket moet de gegevens, nodig voor de regionale surveillance, kunnen aggregeren Voor een optimale toegankelijkheid van de TBC zorg zal de bestrijding op locaties blijven bestaan. Dit vraagt om goede uitwisselingsmogelijkheden van gegevens tussen front office en back office. Automatisering kan hierin een ondersteunende functie vervullen.

15


4.3 Invoeren van een standaard In dit hoofdstuk worden achtereenvolgens aanbevelingen gedaan met betrekking tot standaardisatie, de organisatorische infrastructuur en een vervolgtraject dat nodig is voor de invoering van de standaard. Het opstellen en invoeren van standaarden in de automatisering is een complexe aangelegenheid. Bij het beschrijven van een technische standaard kon de werkgroep regelmatig constateren dat automatiseerders en mensen uit de praktijk elkaar niet altijd verstaan. Ook moet geconstateerd worden dat de kennis over dit specialistische onderwerp niet altijd in huis was. Dat is dan ook de reden waarom TNO en NICTIZ werden benaderd voor advies.

4.3.1 Standaardisatie in de zorg Voor de vertaling van de inhoudelijk vastgestelde standaard in een technische standaard heeft de werkgroep twee maal een bijeenkomst georganiseerd met softwareleveranciers. Hiervoor werden de vijf softwarebedrijven uitgenodigd met de grootste tbc-gebruikersgroepen, het betreft drie leveranciers van Client Informatie Systemen (Tubis, Ensemble en Prevalent) en twee leveranciers van digitale röntgenapparatuur (Oldelft en GE Medical). Uit het overleg is een werkdocument tot stand gekomen waarin een aanzet is gegeven voor de vertaling van de inhoudelijk vastgestelde standaard in een beschrijving van een technische standaard9) (bijlage 2). Dit beschrijvingsproces is vanwege zijn complexiteit niet afgerond. Op detailniveau zijn er nog de nodige knelpunten geconstateerd met betrekking tot nomenclatuur en gebruikte coderingen in de verschillende systemen. Om die reden adviseert de werkgroep dit werkdocument verder uit te werken in samenwerking met een professionele onafhankelijke organisatie zoals het Nederlands ICT Instituut in de Zorg (NICTIZ). Voorts is in het overleg met de softwareleveranciers de afspraak gemaakt om de bestaande nationale en internationale automatiseringsstandaarden te gaan volgen. In de medische informatica zijn diverse standaarden vastgesteld waaraan systemen moeten voldoen. In het kader van dit TBC automatiseringstraject acht de LWA-tbc de volgende standaarden van belang: HL7 (XML versie 3.0), DICOM 3 inclusief part 10, NEN 7510.


4.3.2 Organisatorische infrastructuur Er is voor de GGD’en nog geen landelijke infrastructuur voor de invoering van een landelijke vastgestelde standaard in de verschillende softwaresystemen. De organisatie van de werkconferenties en de activiteiten van de landelijke werkgroep hebben hiertoe een eerste aanzet gegeven. Er is zodoende een netwerk van softwareleveranciers en gebruikersgroepen, die gezamenlijke thema’s bespreken. Er is echter geen procedure voor wijziging of invoering van standaarden. Voor wijziging en vaststellen van inhoudelijke TBC-standaard is de CPT het aangewezen overlegorgaan. De invoering van de voorliggende inhoudelijke standaard heeft de nodige financiële en organisatorische consequenties. De werkgroep stelt voor om hiervoor de bestaande de beleids- en overlegstructuur van GGD Nederland te gebruiken (via projectgroep infectieziekten, OVC en/of AII). De werkgroep adviseert om voor het beheer en onderhoud van de standaard een onafhankelijke organisatie zoals het NICTIZ in te schakelen. Gedurende het project is GGD Nederland, op verzoek van de LWA-tbc, aangesloten bij de Stichting HL7 Nederland, hierdoor is de HL7 standaard op CD-rom beschikbaar voor alle GGD’en. Softwareleveranciers is geadviseerd zelf aan te sluiten bij de stichting HL7, zodat zij zelf kunnen beschikken over de standaard en rechtstreeks worden geïnformeerd over wijzigingen en vernieuwingen. Er is nog geen goede structuur die het mogelijk maakt een landelijke database voor gegevensuitwisseling te beginnen. Hiervoor moet eerst overeenstemming zijn over houderschap, beheer en onderhoud van de gegevens. De landelijke werkgroep heeft zich in de activiteiten beperkt tot de invoering van een inhoudelijke standaard en onderzoek naar de mogelijkheden van gegevensuitwisseling tussen GGD’en. Het landelijk recent geïmplementeerde meldingsysteem voor infectieziekten (Osiris)13) kan als voorbeeld dienen hoe houderschap, beheer en onderhoud van landelijke bestanden zowel inhoudelijk als bestuurlijk geregeld kan worden. Gezien de omvangrijke financiële investeringen voor de aanschaf en onderhoud van alle software en röntgenapparatuur zou onderzocht kunnen worden in hoeverre efficiënte inzet van middelen kan worden vergroot vanuit een landelijke structuur.

4.3.3 Vervolgtraject Stichting HL7 (Health Level 7) is de organisatie die standaarden ontwikkelt voor uitwisseling, beheer en integratie van gegevens ten behoeve van medische zorg en de uitvoering, besturing en evaluatie van dienstverlening in de gezondheidszorg.10) GGD Nederland heeft zich inmiddels aangesloten bij de stichting HL7, zodat zij kan beschikken over de reeds ontwikkelde standaarden. DICOM staat voor Digital Imaging and Communications in Medicin. Part 10 beschrijft de standaarden voor archivering en het format voor gegevensuitwisseling van digitaal beeldmateriaal.11) NEN 7510 is een (ontwerp) norm voor de beveiliging van patiënten gegevens in automatiseringssystemen.12) Verder zijn uit dit overleg de volgende constateringen en opmerkingen gedaan: • De in het eindrapport van de CPT werkgroep voorgestelde fasering wordt door de softwareleveranciers bij voorkeur losgelaten, in principe wil men alles in een keer standaardiseren • Opgemerkt is dat voor een aantal leveranciers het gaat om een forse investering om te kunnen voldoen aan de vastgestelde standaard • Softwareleveranciers stellen het zeer op prijs centraal overleg te hebben over standaardisatie en zien hierin een faciliterende rol voor GGD Nederland. De CPT is het orgaan dat de inhoudelijke standaard vaststelt en voorstellen doet voor inhoudelijke wijzigingen.

Aan TNO, afdeling medische informatica is gevraagd een advies uit te brengen over een vervolgtraject met betrekking tot de invoering van de standaard.14) In het advies zijn drie verschillende architecturen beschreven, daarmee is een eerste aanzet gegeven voor een mogelijk vervolgtraject. Tijdens een van de werkconferenties is gesproken over de mogelijkheden voor een proeftuin in een van de regio’s. Wanneer de inhoudelijk vastgestelde standaard vertaald is in een technische standaard en geïmplementeerd is in de softwaresystemen, moet worden uitgetest of uitwisseling tussen verschillende pakketten mogelijk is. De werkgroep adviseert in overweging te nemen om voor het uittesten van de geïmplementeerde standaard een proeftuin te starten in een regio waar met veel verschillende softwaresystemen wordt gewerkt. Een geschikte regio daarvoor is Zuid-Holland in combinatie met Zeeland (in verband met de mobiele röntgenunit). Alvorens de standaard in de systemen kan worden ingevoerd zal aan NICTIZ het door de werkgroep opgestelde werkdocument worden voorgelegd om de beschrijving van de technische standaard af te ronden. Pas daarna kan tot implementatie worden overgegaan. Implementatie van automatiseringsstandaarden is een technische exercitie die moet worden uitgevoerd door automatiseerders met hoogwaardige kennis over de HL7 en DICOM, in samenwerking met de softwareleveranciers. De inschatting is dat een implementatietraject ruim een jaar tijd in beslag zal nemen. Voor deze kostbare investering zijn eventueel subsidiemogelijkheden beschikbaar bij Senter.15) Senter is

16

17


een agentschap van het ministerie van economische zaken en verantwoordelijk is voor het uitvoeren van subsidie-, krediet- en fiscale regelingen en programma's op het gebied van technologie, energie, milieu, export en internationale samenwerking. Doelstelling hierbij is het duurzaam versterken van de positie van het bedrijfsleven en kennisinstellingen in Nederland. Schematisch ziet een volgtraject er als volgt uit:

Mei 2004 Projectvoorstel schrijven en indienen bij NICTIZ met doel: uitschrijven technische implementeerbare standaard Juli – September 2004 Indien acceptatie projectvoorstel door NICTIZ is de tijdsduur voor uitschrijven standaard 3 – 6 maanden.


5. Conclusies en aanbevelingen In de afgelopen anderhalf jaar heeft de landelijke werkgroep automatisering tuberculosebestrijding zich gebogen over een aantal belangrijke knelpunten in het veld. De uitvoerders en softwaresysteembouwers zijn hierbij nauw betrokken. De belangrijkste voordelen van standaardisatie en gegevensuitwisseling via een landelijke database zijn de mogelijkheid om via een systeem digitale foto’s en medische informatie op te vragen bij een andere GGD. Tevens kan worden voorkomen dat mensen ten onrechte worden gescreend op tuberculose. Met behulp van gegevens uit de DICOM header van de digitale fotobestanden zijn er beperkte mogelijkheden voor het inrichten van een landelijke database. De minimale set gegevens die nodig voor een landelijke database is vastgesteld en zijn door de meeste GGD’en aan te leveren (bijvoorbeeld in Excell), met uitzondering van het toekennen van een uniek nummer. De afwezigheid van een systeem voor het toekennen van unieke nummers voor identificatie van gegevens is een van de belangrijkste knelpunten dat moet worden opgelost.

Mei – september 2004 Schrijven aanvraag subsidie t.b.v. implementatie traject bij Senter

Op basis van een data-match is het rendement van gegevensuitwisseling gekwantificeerd. Er kan voorzichtig worden uitgegaan van een rendement van 5-6% voor de screeningen van gedetineerden in PI’s als er een landelijke database wordt ingericht.

Mei – december 2004 Inrichten vervolgproject, in samenwerking met TNO. Indien subsidie wordt verkregen is de duur van implementatietraject 12 – 18 maanden

In het kader van de regionalisering wordt geadviseerd slechts een softwaresysteem per regio te gaan gebruiken, dit maakt de uitwisselbaarheid van gegevens het meest eenvoudig. Bovendien bevordert het de standaardisatie van werkwijzen op de tbc-afdelingen.

Afronding standaardisatietraject bij een zeer voorspoedig verloop van alle fasen: eind 2005

De landelijke werkgroep heeft uitspraken en aanbevelingen gedaan over het gebruik van (inter)nationale standaarden in de medische sector, een heeft schets gegeven van de organisatorische infrastructuur die nodig is voor het beheer en onderhoud van een landelijk systeem. Overwegende dat, GGD Nederland is aangesloten bij de stichting HL7 en een project in voorbereiding heeft met het NICTIZ en TNO, doet de werkgroep de volgende aanbevelingen: • GGD’en en GGD Nederland onderschrijven dat opgestelde inhoudelijke standaard gebaseerd moet zijn op de (inter)nationale richtlijnen en standaarden zoals NEN, HL7 XML versie 3 en DICOM 3 inclusief part 10. • GGD’en in Nederland streven ernaar om voor de TBC maximaal 3 verschillende softwaresystemen voor de cliënt informatie systemen te gebruiken. • Per regio wordt slechts een softwaresysteem voor cliënt informatie gebruikt. • Door op grotere schaal te gaan werken is het noodzakelijk dat er efficiënte uitwisseling van gegevens en informatie plaatsvindt tussen frontoffice en backoffice in de regio. De werkgroep adviseert dan ook om het vervolgtraject voor automatisering te koppelen aan het traject van opschaling van de TBC regio’s. Voor optimale betrokkenheid vanuit de regio’s zou per regio een afgevaardigde in de landelijke werkgroep kunnen participeren. • Geadviseerd wordt om de standaard uit het werkdocument versie 2.0 in samenwerking met NICTIZ verder uit te schrijven alvorens het wordt ingevoerd • NICTIZ wordt gevraagd deze standaard te gaan beheren, het NICTIZ beheert ook de standaarden van overige instellingen in de zorg • Geadviseerd wordt deze standaard aan te bieden aan en integreren met het lopende automatiseringstraject voor de asielzoekers • Er wordt een implementatietraject opgesteld, gebaseerd op de aanbevelingen van TNO, waardoor de standaard kan worden ingevoerd in de systemen. Tevens wordt onderzocht of er voldoende draagvlak is voor een (pilot) traject in een van de regio’s met een landelijke database waardoor het opvragen, zoe-

18

19


ken, archiveren en verzenden van foto’s en andere gegevens tussen GGD’en wordt vereenvoudigd. Het verdient aanbeveling hiervoor externe deskundigheid in te huren en externe financiële middelen te zoeken voor financiering van de implementatie (bijvoorbeeld bij Senter). • Absolute voorwaarde voor efficiënte uitwisseling van gegevens is het toekennen van unieke cliënten_id. De landelijke ontwikkelingen op dit terrein worden nauwlettend gevolgd en mogelijkheden voor oplossen van dit probleem worden verder onderzocht. • De werkgroep stelt voor om een formele structuur op te zetten waarlangs wijzigingen en nieuwe standaarden in de softwaresystemen kunnen worden geïntroduceerd. • De werkgroep verzoekt de stuurgroep om naast GGD Nederland, de KNCV en de CPT te informeren over de uitkomsten en aanbevelingen In haar laatste bespreking hebben de werkgroepleden zich bereid verklaard om zorg te dragen voor een goede overdracht. Totdat er meer zicht is op een concrete voortzetting van dit automatiseringstraject blijft de werkgroep voortbestaan. Een deel van de werkgroepleden is, indien wenselijk, bereid in een vervolgtraject een bijdrage te blijven leveren aan de kwaliteitsverbetering van de TBC automatisering.


Verwijzingen en geraadpleegde bronnen 1. Projectvoorstel Versterking infrastructuur infectieziektebestrijding en technische hygiënezorg, GGD Nederland, september 2000 2. Gezondheidsraad “Wet bevolkingsonderzoek: tuberculose” 1999/01, 22 april 1999 VWS nummer 325267 3. Verslag van de 260ste vergadering van de CPT, gehouden 17 maart 2000 in de jaarbeurs te Utrecht 4. Doosje J., Kritische succesfactoren bij de invoering van een geautomatiseerd surveillancesysteem voor infectieziekten juni 2002, afstudeerpaper MPH opleiding Netherlands School of Public Health 5. verslag VISI werkconferentie TBC automatisering 3 oktober 2002 6. verslag werkconferentie 13 maart 2003 “Automatisering in de tuberculosebestrijding (2)”, naar een efficientere gegevensuitwisseling 7. LWA TBC – Onderzoeksrapportage matching databases, onderzoek naar dubbele screening in de PI, Utrecht, 24 juli 2003 8.

Haringhuizen G., Protocol “Onderzoek naar onnodige stralingsbelasting bij verplichte screening op tuberculose-infectie”, GGD Nederland Utrecht, 28 februari 2003

9. Werkdocument: Inhoudelijke en technische standard TBC automatisering, januari 2003, versie 2.0 10. http://www.hl7.nl 11. http://medical.nema.org 12. http://www.nen.nl/nl/act/spec/ibiz/content.html 13. Doosje J., Bosman A. Van Straaten E, GGD’en gaan infectieziekten elektronisch melden via Internet, infectieziektebulletin; 13.1:59-62, februari 2002 14. TNO-rapport PG/TG 2003.329 Stand van zaken TBC standaard, 16 december 2003 15. www.senter.nl

20

21


Deelnemers Landelijke werkgroep TBC-automatisering Max Antheunisse Miranda Brouwer Jelle Doosje Marc van de Geer George Haringhuizen Nico Kalisvaart Sytze Keizer Hans van Keulen Vincent Kuyvenhoven Aart Lodder Ans Lohuis Carolien Moree Maurits Verhagen


Bijlage 1. Overzicht TBC Software bij GGD’en

GGD Zeeland GGD Hart voor Brabant (tot 1 april 2004) GGD Nederland Hulpverleningsdienst Flevoland GGD Nederland KNCV GG&GD Amsterdam (tot juni 2003) GGD Nederland KNCV GGD Nederland (agendalid) GGD Nijmegen GG&GD Amsterdam GGD Noord en Midden Limburg

Deelnemers overleggen TBC- softwareleveranciers Henk Jan Boom Atte Bootsma H. Bredewoud Balt Delhaas Jelle Doosje Bianca van Emmerik George Haringhuizen J. van Lieshout Hans van Keulen Nick de Ruyter Richard Sommer Mark Verkooijen

22

Ensemble (Mars) Alca Systems (Tubis) Prevalent Ensemble (Mars) GGD Nederland Prevalent GGD Nederland Prevalent GGD Nederland Acha (Tubis) Medical GE Oldelft

23



Bijlage 2

GGD - GIS

Gemeente Den Haag, Dienst OCW,GGD GG&GD Amsterdam GG&GD Utrecht GGD Amstelland - De Meerlanden GGD Drenthe GGD Eemland GGD Eindhoven GGD Fryslân GGD Gooi & Vechtstreek GGD Hart voor Brabant GGD Kennemerland GGD Kop Van Noord-Holland GGD Midden-Holland GGD Midden-Nederland GGD Nieuwe Waterweg Noord GGD Noord- en Midden Limburg GGD Noord-Kennemerland GGD Noordwest-Veluwe GGD Oostelijk Zuid-Limburg GGD Regio Achterhoek GGD Regio IJssel-Vecht GGD Regio Nijmegen GGD Regio Stedendriehoek GGD Regio Twente GGD Rivierenland GGD Rotterdam e.o. GGD West-Brabant GGD Westelijke Mijnstreek GGD Westfriesland GGD Zaanstreek/Waterland GGD Zeeland GGD Zuidelijk Zuid-Limburg GGD Zuid-Holland Noord GGD Zuid-Holland West GGD Zuid-Holland Zuid GGD Zuidhollandse Eilanden GGD Zuidoost-Brabant Hulpverlening Gelderland Midden Hulpverleningsdienst Flevoland HVD Groningen

GGD Plaats

TBC Software

Den Haag Amsterdam Utrecht Amstelveen Assen Amersfoort Eindhoven Leeuwarden Bussum Den Bosch Haarlem Den Helder Gouda Zeist Vlaardingen Venlo Alkmaar Harderwijk Heerlen Doetinchem Zwolle Nijmegen Deventer Enschede Tiel Rotterdam Breda Geleen Hoorn Zaandam Goes Maastricht Leiden Zoetermeer Dordrecht Spijkenisse Helmond Arnhem Lelystad Groningen

Prevalent Tubis Prevalent Tubis Tubis Prevalent Anders Tubis Anders Tubis Tubis Anders Anders Prevalent Ensemble Anders Prevalent Prevalent Anders Anders Tubis Prevalent Prevalent Tubis Anders Ensemble Prevalent Anders Prevalent Tubis Tubis Prevalent Tubis Anders Prevalent Ensemble Tubis Anders Tubis Tubis

Werkdocument: Inhoudelijke en technische standaard TBC automatisering

Landelijke Werkgroep Automatisering TBC GGD Nederland, januari 2004

24

25



Inhoudsopgave

Gebruikte afkortingen

28

1. Inleiding

29

2. Uitwisselstandaarden

30

3. Invoervelden en antwoordcategorieën uit de inhoudelijke standaard

32

4. Aanmaken van een HL7 (XML) uitwisselingsbestand

47

5. Patiënten dossier

48

Bijlagen

26

27


Gebruikte afkortingen

CIS CPT HL7 DICOM MED MTM NEN NTR RIM ZIN

Cliënt Informatie Systeem Commissie voor de Praktische Tuberculosebestrijding Health Level 7 Digital Imaging and Communication in Medicin Medisch Elektronisch Dossier Medisch Technisch Mederwerker Nederlandse Norm voor Informatiebeveiliging in de Zorg Nederlandse Tuberculose registratie Referentie Informatie Model Zorg Identificatie Nummer


1. Inleiding Dit document geeft een beschrijving van de vertaling van een inhoudelijk vastgestelde standaard in een technische standaard. De Landelijke Werkgroep Automatisering TBC(LWA-tbc) is er bij de taakstelling van uitgegaan dat standaardisering en automatisering dynamische processen zijn en dat er later –bij gebleken consensus- altijd andere elementen aan de standaard moeten kunnen worden toegevoegd. Te denken valt hierbij aan het ontwikkelen van een Medisch Elektronisch Dossier (MED), automatisering van de Nederlandse Tuberculose Registratie (NTR) of nieuwe laboratorium gegevens bij screeningen. Deze aanvullingen moeten inpasbaar zijn zonder dat gemaakte codes en afspraken worden geschonden. In dit kader heeft de commissie besloten volledig aan te sluiten bij de bestaande internationale standaarden zoals deze ook in ziekenhuizen worden gebruikt. Dit heeft als voordeel dat de blauwdruk voor eventuele toekomstige uitbreidingen al aanwezig is en men bij het implementatietraject gebruik kan maken van de in deze omgeving beproefde uitwisselingsprotocollen (DICOM 3.3. HL7 3.0 –XML, NEN 7510). Bij het opstellen van dit document is het rapport van de commissie standaardisatie (d.d. 12 november 2002) gebruikt als uitgangspunt. De onderwerpen van bijlage 3 uit dit rapport zijn opgenomen in de uitwerking van dit verslag in hoofdstuk 3. Het verdient aanbeveling het eindrapport van de commissie standaardisatie te gebruiken als naslagdocument. Dit document is tot stand gekomen in samenwerking met de softwareleveranciers die het grootste deel van de TBC afdelingen bedienen, het betreft Tubis, Prevalent, Ensemble, Oldelft en Medical GE (zie bijlage deelnemerslijst). Daarnaast in TNO afdeling Medisch Informatica gevraagd de beschreven standaard te toetsen op bestaande nationale en internationale standaarden. Om de complexiteit van het voorliggende standaardisatietraject aan te geven is een deel van de opmerkingen en discussies uit het overleg met softwareleveranciers, de werkgroep en TNO in de voetnoten weergeven. De werkgroep realiseert zich dat het aansluiten bij internationale standaarden niet eenvoudig is en de nodige investeringen met zich meebrengt, maar hoopt met dit document een positieve bijdrage te leveren in het proces van standaardisatie.

28

29


2. Uitwisselstandaarden Uitwisseling van foto bestanden met DICOM 3.3. Wat de foto’s betreft concludeert de werkgroep dat men zich in het verleden bij de ontwikkeling van software en interfaces niet strikt aan de DICOM standaard heeft gehouden. DICOM velden mogen alleen gevuld worden met informatie die voor deze velden is bedoeld conform de DICOM standaard. Ze mogen niet gevuld worden met informatie die andere doeleinden dient. Mocht er behoefte zijn andere informatie (b.v. vermelding van de risicogroep) in de DICOM header op te nemen, zodat deze op de foto (in de overlay) kan worden geprojecteerd, dan dienen hiertoe –conform de DICOM standaard- speciale velden te worden aangemaakt (z.g. private fields met oneven nummers). Dit heeft als secundair voordeel dat deze informatie voor andere instanties dan GGD’en niet zichtbaar is. Daarnaast zal gevoelige informatie die zich in de DICOM header bevindt - conform het rapport van de commissie standaardisatie - gecodeerd moeten worden. 1) 2) De werkgroep stelt verder vast dat de aan de GGD’en geleverde viewing stations van de firma Oldelft geen DICOM files kunnen lezen wanneer deze niet op hun eigen systemen zijn aangemaakt. Deze stations kunnen alleen DICOM files lezen wanneer deze worden aangeboden in een door Oldelft ontwikkelde HyperArchief structuur. De werkgroep ziet deze situatie als onwenselijk en stelt dat alle bij de GGD gebruikte leesstations in staat moeten zijn elke DICOM file te kunnen lezen conform de DICOM compabiliteit. 3) Ook voor het lezen van loss-less gecomprimeerde files zal een voorziening moeten worden gemaakt. Alleen op deze wijze kan een universele DICOM uitwisselbaarheid -ook met ziekenhuizen - worden gegarandeerd. Alle foto’s worden in de Hyperview Archief als loss-less file opgeslagen op CD of DVD. Bij het lezen worden ze gedecomprimeerd en aan het viewing station aangeboden. De viewingstations kunnen alleen gedecomprimeerde files lezen. Export van Dicom beelden is altijd uncompressed om compatibiliteit tussen verschillende systemen te waarborgen. Hyperview kan lossless compressed images uitpakken en viewen. 4) Om de digitale opslag van foto’s universeel en onafhankelijk van de modaliteit te maken zou het handig zijn om het gebruik van header completion te gebruiken. Dit betekent dat iedere foto die door het beeldarchief ontvangen wordt, gechecked wordt ten opzichte van de werklijst server waarbij onjuiste velden gecorrigeerd worden en missende informatie wordt toegevoegd.


Uitwisseling van data bestanden met HL7 De HL7 standaard is een berichtenstandaard: HL7 omvat de specificatie van de functionele inhoud van berichten (conform OSI laag 7). Daarnaast is HL7 een communicatie standaard: HL7 omvat de specificatie van de functionele en deels de technische wijze van berichtenuitwisseling, alsmede de controle daarop conform OSI (Open Systems Interconnection) laag 6 en lager, lower level protocollen. De standaardisatie binnen HL7 is gericht op samenwerking en integratie met zoveel mogelijk andere standaarden voor deelgebieden waarvoor reeds specifieke standaarden bestaan. Meer informatie over HL7 is te vinden op Internetpagina www.HL7.nl. CEN/TC251 is de Europese standaardisatie organisatie, die verantwoordelijk is voor het maken van standaarden in de zorg, heeft besloten zich te baseren op HL7 versie 3. Binnen de Europese (en daarmede tevens nationale) systematiek worden met van het RIM afgeleide General Purpose Information Components zaken gemaakt die Archetypes genoemd worden. Elk archetype beschrijft een concept zoals dat gebruikt wordt in een zorgdomein. Alle concepten (archetypes) bij elkaar wordt een domeinmodel genoemd. Alle begrippen die uitgewisseld worden zijn in zo’n model terug te vinden.Het vervaardigen van berichten of uit te wisselen documenten die voldoen aan kwaliteitseisen en algemeen geaccepteerde normen maakt het noodzakelijk om op basis van het HL7 versie 3 RIM een domeinmodel te maken. Dit domeinmodel wordt vervolgens gebruikt bij het definiëren van berichten of documenten. Naast het domeinmodel zal ook een genormeerde set met referentie data types toegepast moeten worden. Het toepassen van genormaliseerde methoden om domeinmodellen te maken of berichten/documenten te maken, is specialistisch werk. Deze kennis is niet altijd aanwezig bij alle leveranciers. Leveranciers zijn vaak wel goed in staat op een proprietary oplossing ad-hoc te maken.

Uitwisseling van medische gegevens Communiceren van medische gegevens van patiënten zal aandacht moeten besteden aan de beveiliging ervan. Een technische uitwisselingstandaard zal daar expliciet aandacht aan moeten schenken. Tot de uitwisselingsstandaard kan behoren een universeel afgesproken stelsel van regels (policy). Daarnaast zullen de regels aanleiding geven tot technische voorzieningen. Deze technische voorzieningen behoren ook tot de toe te passen uitwisselingsstandaard. Met name zal op basis van de komende NEN EN7510 (Medische Informatica- Informatiebeveiliging in de zorg-Algemeen) er een reeks andere normen, Technische specificaties en implementatie richtlijnen uitgebracht gaan worden,die van belang zullen zijn.

1) De werkgroep adviseert hierin alle verplichte categorieën op te nemen. Dit impliceert dat ook de zeevaartkeuringen als aparte categorie zal moeten worden toegevoegd 2) Tubis: Hier zijn inderdaad behoorlijke aanpassingen voor nodig, zowel aan de kant van Tubis als aan de OWS kant, private fields zijn op dit moment niet beschikbaar. 3) Oldelft: Ons systeem voldoet voor 100% aan de Dicom standaard, Hyperview kan gebruikt worden om beelden te viewen vanuit ieder Dicom archief, niet alleen uit het rogan archief. Wil men gewoon een extern beeld kunnen viewen dan is daar tegenwoordig de Dicom Dir standaard voor (DICOM part 10), op het CD’tje staat dan vaak ook de viewer. De werkgroep heeft gelijk als men stelt dat onze HyperVIEW geen Dicomdir viewer is, dat klopt en is als zodanig ook nooit zo verkocht 4) Om het geheel landelijk goed te kunnen regelen, moet er eenduidigheid zijn in de patiënt id (landelijk uniek nummer en 1 centrale database), de naam en allerlei andere velden. Uit privacy overweging zouden dan vele velden alleen in de centrale database kunnen staan, en niet bij de foto (zoals bv instelling, adres, etc). Bij de foto staan dan alleen (eenduidig) de relevante gegevens als ID, onderzoeksdatum en opname/image gegevens.

30

31


3. Invoervelden en antwoordcategorieën uit de inhoudelijke standaard Het rapport van de commissie standaardisatie beschrijft 35 invoervelden met de bijbehorende antwoordcategorieën. Deze kunnen worden onderverdeeld in 3 hoofdgroepen: 3.1. Patiënt gegevens 1+2 (1 t/m 13) 3.2. Categorie bezoeker en reden bezoek (14,15) 3.3. Verrichtingen en resultaten (16 t/m 35) - BCG - Foto - Mantoux Zes van de 35 beschreven invoervelden behoeven nog een nadere uitwerking en discussie. Dit zijn de velden: naam en voornaam (veld 1 en 2), categorie bezoekers (14b en 14e), reden komst (veld 15), resultaat BCG (veld 17) en uitslag eerste lezing röntgenfoto (veld 26).

3.1 Patiëntgegevens De patiëntgegevens zijn om logische en praktische redenen gegroepeerd in 3 categorieën. De eerste categorie patiëntgegevens 1 met de personalia die voor onderzoeksdoeleinden verwijderd of geanonimiseerd kunnen worden en bevat patiëntgegevens 2 waarbij dit niet kan. Hierin wordt van de personalia alleen het geboorte jaar en geslacht weergegeven. Via het gebruikte GGD specifieke ID nummer kan men eventueel –met toestemming van de betreffende GGD- de volledige personalia achterhalen. Tevens bevinden zich hier de door HL7 aangedragen mogelijkheden om ID nummers van verschillende GGD’en te koppelen, wanneer het bij nader onderzoeken om dezelfde patiënten blijkt te gaan. Op deze wijze worden automatische alle onder deze ID nummers vallende foto en mantoux uitslagen en BCG gegevens gebundeld. Ook het CRV nummer wordt in deze koppeling opgenomen. Ditzelfde zou men ook kunnen doen voor het NTR registratienummer(s) 5) wanneer hier binnen het CPT overeenstemming over bestaat. 6)

Patiënt gegevens 1 Veld 1. Naam (verplicht veld) [DICOM (0010, 0010)] 7) Het betreft hier een gestandaardiseerd DICOM text veld (0010, 0010) dat op de overlay van de foto verschijnt. DICOM onderscheid in dit veld geen voor- of achternamen, voorvoegels of tussenvoegsels. Het

5) Dit betreft patiënten, profylaxe patiënten of patiënten die alternatief voor een profylaxe behandeling 2 jaar onder röntgencontrole worden gehouden. 6) Tubis: COA/IND levert CRV-gegevens incompleet aan blijkt in de praktijk. Bovendien blijken er dubbele CRV-nummers te bestaan, dit is onwenselijk, omdat er bij de bouw van de Tubis-functionaliteit van uit is gegaan dat CRVnummers uniek zijn. Reactie werkgroep: dit onderstreept eens te meer dat we zo snel mogelijk moeten gaan voor een uniek zorgnummer op biometrische gronden. Ik heb begrepen dat dit in de toekomst ook verplicht wordt als ik alle epistels goed gelezen heb en dat dit nummer in de diverse kwaliteits systemen zal worden opgenomen. Tot die tijd is het nog roeien met de beperkte riemen die we hebben. Op de correcte invoer van namen zal dus extra zorg moeten worden besteed.

32


enige onderscheid dat DICOM maakt is die tussen hoofden kleine letters. Standaard wordt nu in dit veld de achternaam ingevuld in hoofdletters. Daarna volgen 2 dakjes en vervolgens de voorletters. Deze worden weergegeven als hoofdletters met daartussen puntjes. Later is men om verwarring bij m.n. asielzoeker te voorkomen, i.p.v. voorletters de volledige voornaam cq voornamen gaan toevoegen achter de dakjes. Dit laatste met het risico dat de voor dit veld beschikbare aantal karakters (64) wordt overschreden en de boel wordt afgekapt. ACHTERNAAM^^voor- en tussenvoegsels^Voorna(a)m(en)

7) TNO: De uitwerking in de diverse velden geschiedt op basis van de HL7 versie 2 methodiek. HL7 versie 3.0 gebruikt XML als uitwisselingsstandaard en niet de ‘dakjes’ van HL7 versie 2. HL7 versie 3 maakt gebruik van een Referentie Informatie Model (RIM). HL7 versie 2.x berichtenstandaarden worden ‘gegoten’ en geïmplementeerd in een op Edifact lijkend formaat. HL7 versie 3 berichten worden ‘gegoten’ en geïmplementeerd in een XML formaat. Ook worden HL7 versie 3 berichten afgeleid van een RIM door gebruik te maken van speciale gereedschappen (Rose-Tools en Visio). 8) Oldelft; De DICOM standaard voorziet al in een definitie van dit veld en het heeft dus de voorkeur om hieraan te conformeren, men gaat hier uit van 5 velden, gescheiden door een ^ : family name complex^given name complex^middle name^name prefix^name suffixZie ook de bijlage uit de dicom standaard (part 5, bijlage). Ons systeem kan HL7 berichten ontvangen en converteren naar een dicom modality worklist bericht. Maar dan zouden de informatiesystemen deze HL7-berichten moeten uitsturen. De werklijst naar de verschillende modaliteiten worden door elke modaliteit, fosfor, digidelca-M “anders” gebruikt. Alvorens te archiver zou een dicom header completion kunnen plaats vinden vanuit het volledige HL7-bericht van het desbetreffende informatiesysteem. Het gebruik van dicom header completion maakt het systeem onafhankelijk van de gebruikte modaliteit. Het idee hier is dat het archief de ontvangen plaatjes controleert met behulp van de worklist server. Als een modaliteit dus bepaalde velden niet of verkeerd invult, zal de dicom header veranderd/aangevuld worden met de juiste gegevens alvorens de foto op te slaan. Alles valt of staat met de juistheid van de informatie die aangeleverd wordt door het informatie systeem richting de werklijst server (HL7 broker). Tubis: De voornaam is juist ook ingevoerd om het MTM-ers mogelijk te maken, de goede client aan de goede foto te koppelen. Het komt, m.n. bij buitenlandse tweelingen, zeer regelmatig voor dat achternaam, geboortedatum en voorletters identiek zijn. Zonder voornaam valt er dus geen goed onderscheid te maken. (Dat is ook de reden dat hij wordt opgenomen). Met het toevoegen van een extra voornaam-veld zijn we er ook nog niet, omdat dan de Oldeft-software zodanig moet worden aangepast. dat dit veld ook zichtbaar wordt voor degene die het rontgenapparaat bedient. Een veld opnemen en een veld overal zichtbaar maken zijn twee verschillende zaken: het veld zou in dit geval niet alleen in de overlay op het viewing station moeten worden getoond (=vrij eenvoudig), maar ook in de OWS-software (= volgens mij meer werk). Al met al lijkt dit dus een simpele aanpassing maar heeft hij flinke (financiële) gevolgen, waarover ook overleg met de GGD’s plaats zal moeten vinden. Werkgroep: Het is bekend dat hiervoor Oldelft programmatuur moet worden aangepast. Dit geldt voor alle nieuw te creëren velden. Het percentage 2-lingen is overigens gering. Bovendien hebben de meeste 2-lingen al een CRV nummer, en het moet wel erg gek lopen als ook deze hetzelfde zijn. De regel luidt: let bij 2=lingen altijd extra goed op. Het veld voornaam is overigens een bekende dimensie van een HL7 veld naam (wat in totaal 256 karakters bevat). Als programmatuur wil samenwerken met HL7 versie 3, via een soort plug en play koppeling dan zal men er niet onderuitkomen om dit soort velden in de software op te nemen, wil men deze (aan de exportkant) als HL7 compatible aanbieden.

33


Een ander nadeel is dat de voornaam meestal alleen bij bijv. Somaliers en niet bij Nederlanders wordt ingevuld. Het veld voornaam blijft dan leeg met als gevolg dat er niets meer achter de dakjes verschijnt. De hele familie heeft dan JANSSEN zonder verdere toevoegingen. ACHTERNAAM^^voor- en tussenvoegsels^…………………….. Het voorstel is om dit veld specifiek te reserveren voor uitsluitend de achternaam (in hoofdletters), voorvoegsels (kleine letters) en voorletters (hoofdletters gescheiden door puntjes). Mocht het nodig of wenselijk zijn voornamen op te nemen ter identificatie van een patient (of als aanvulling bij jeugdige patienten) dan zal hiervoor in DICOM een apart private veld moeten worden gecreeerd. Dit zal dan tevens op de overlay van de foto verschijnen. Wat er in het veld naam verschijnt beperkt zich dus tot de achternaam in hoofdletters gevolgd door 2 dakjes, vervolgens de voor en tussenvoegsels (gescheiden door 1 dakje), en dan de voorletters (gescheiden door puntjes). De voor- en tussenvoegsels en de voorletters komen uit separate velden [HL7, Mars, Tubis, Prevalent] . Het DICOM veld naam (0010, 0010) is dus samengesteld uit in totaal 3 afzonderlijke velden. ACHTERNAAM^^voor- en tussenvoegsels^V.O.O.R.L.E.T.T.E.R.S. Hoe men met meisjesnamen en dubbele namen omgaat is per GGD en gebruiker verschillend. Ook hierin zal naar uniformiteit gestreefd moeten worden. Voorstel is ook wat dit betreft de HL7 standaard te volgen. 8)

Veld 2. Voorna(a)am(en) (facultatief veld) De voornaam is geen standaard DICOM veld, maar wordt wel in TUBIS, MARS of Prevalent gebruikt en aangemaakt. Hij zal dus alleen op de overlay van de foto verschijnen als men hem achter het DICOM veld achternaam plakt (DICOM 0010,0010). Uiteraard kan men de voorletters dan daar niet meer kwijt. HAVERKAMP^^Peter Jan danwel HAVERKAMP^^P.J. Het voorstel is de voorletters –wanneer ingevuld- standaard achter de achternaam te plakken en een apart veld te creëren (of te reserveren) binnen de DICOM header voor voornamen. Bij Somaliërs en andere asielzoekers verschuiven namen vaak per generatie en heeft men vaak geen duidelijk voor- en achter namen.


Zijn zoon heet Hamid Amed Abdullahi De voornaam is Hamid De achter naam is AHMED ABDULLAHI Of als variatie De voornaam is Hamid Amed De achternaam is ABDULLAHI Bij veel buitenlanders wordt 1-1 of 1-7 als geboorte dag en maand genoteerd. Zodat het toch handig is de namen volledig over te nemen en geen afkortingen te gebruiken. Wanneer er onduidelijkheid blijft bestaan over waar precies de voornaam ophoudt en de achternaam begint wordt voorgesteld alles in hoofdletters te noteren. ABDULLAHI YOUSEF^^A. Het voorstel is de roepnaam als voornaam te hanteren en de “rest’ als achternaam. Ook kan men voorstellen wanneer er onduidelijkheid bestaat over voor- en achternaam alle namen met hoofdletters in te voeren ingevoerd. In de DICOM header module patient bestaan nog een aantal niet verplichte velden die wellicht kunnen worden gebruikt: 0010, 1001: Other Patient names en 0010, 4000: Patient comments 9)

Veld 3. Voorletters (facultatief veld) Dit is geen DICOM veld, maar wordt wel als afzonderlijk veld door MARS, TUBIS en Prevalent onderscheiden. In de huidige situatie wordt dit veld meestal na 2 dakjes toegevoegd aan het DICOM veld (0010,0010). Voorstel is dit zo te laten. WETERING^^J.P.R.

Veld 4. Voorvoegsels (facultatief veld) Voorvoegsels worden na de achternaam in het DICOM veld naam (0010, 0010) toegevoegd. Ze worden conform de HL 7 standaard genoteerd. WETERING^^J.P.R^^van^der

Voorbeeld: Amed Abdullahi Yousef De voornaam is Ahmed De achternaam is ABDULLAHI YOUSEF Of De voornaam is Ahmed Abdullahi De achternaam is YOUSEF

34

9) Opmerking: veel gegevens, met name van asielzoekers, worden automatisch overgenomen uit bestanden die door de COA worden aangeleverd. Gebruiken het COA dezelfde standaard? Zo nee: wordt dan voorgesteld, aangeleverde gegevens handmatig te gaan nabewerken? Is hierover overleg geweest met de GGD’s (want dat nabewerken kost nogal wat tijd…)? 35


Patiëntgegevens 2 10)


worden opgeslagen 0010, 1000: Other Patient ID

Veld 5. Geboortedatum (verplicht veld) [DICOM (0010, 0030)] Dit is een verplicht DICOM veld. Dd-mm-yyyy 11)

Veld 6. Geslacht (verplicht veld) [DICOM (0010, 0040)] Dit is een verplicht DICOM veld. Wanneer het geslacht (bijv bij bron- en contactonderzoeken) niet bekend is kan een 0 worden ingevuld. Wijzigingen hierin moeten later kunnen worden aangebracht. De Nederlandse antwoordcategorien (zie voor toelichting o.a. Bijlage 3 van het eind rapport commissie standaardisatie) kunnen in het invoerscherm van het CIS eventueel worden gehandhaafd, maar voor de uitwisselstandaard worden M (male), F (female) en O (other) gebruikt, zoals ook in de Dicomstandaard: Patient's Sex (0010,0040) Sex of the named Patient. Enumerated Values: M = male F = female O = other

Veld 8. Landelijk uniek(e) registratie nummer(s) (facultatief veld) 12) DICOM biedt standaard maar 2 velden om ID nummers in op te slaan. Patient ID (verplicht veld) en other patient ID (facultatief veld). Dit is wat weinig voor de verschillende ID nummer die bij de diverse GGDen voor 1 patiënt in omloop zijn of kunnen zijn. Wel biedt HL7 de mogelijkheid om ID nummers te koppelen. Momenteel is als landelijke nummers alleen de CRV nummers beschikbaar. Dit nummer geldt alleen voor vervalt wanneer iemand een verblijfsvergunning krijgt. Het nummer geldt dan ook alleen voor asielzoekers en BWers (buitenlandse werkers). Andere landelijke nummers lijken momenteel nog toekomst muziek. Voorgesteld wordt om wanneer nader onderzoeken worden verricht en records tussen diverse GGDen worden uitgewisseld deze bestanden aan elkaar te koppelen via de mogelijkheden die HL7 hiertoe biedt. Aldus ontstaat een logisch ID nummer dat uit verscheidene ID nummer is opgebouwd. Zoekopdrachten naar een bepaalde client geven dan automatisch een overzicht van alle records die onder beide ID nummers zijn opgeslagen. HL/7 is een set afspraken om informatie uit te wisselen, verder doet het niets, het bijhouden van verschillende nummers, het uitgeven van nummers, het later koppelen van verschillende nummers tot 1 preferred number, zal door een systeem gedaan moeten worden. In de ziekenhuizen wordt dit gedaan binnen het ZIS, bij de GGD zou hiervoor ook een landelijk systeem opgezet kunnen. 13)

Veld 7. Cliëntnummer (verplicht veld) [DICOM (0010, 1120)] Dit is een verplicht DICOM veld wat op de overlay van de foto verschijnt. Het bevat een specifiek ID nummer, bepaald door het automatiseringsprogramma van de GGD waar het record wordt gemaakt. Tevens beschikt de DICOM header over nog een ander veld waar facultatief een 2de ID nummer kan

10) Aandachtspunt: anonimiteit is onvoldoende gewaarborgd als de gehele geboortedatum toegevoegd wordt aan gegevenset voor onderzoeks- en surveillancedoeleinden. 11) Discussie Het voorstel van de commissie was om 00-00-yyyy ite gebruiken als bezoekers van het TBC bureau alleen een geboortejaar hebben. Dit betekent wel dat men dan extra nauwkeurig moet zijn met het invullen van voor- en achternamen. 00-00-yyyy is geen bruikbare notatie, in ieder geval niet binnen Tubis, omdat dit door het systeem (d.i. door Progress) als een ongeldige datum wordt herkend. We kunnen Tubis hier wel op aanpassen, als de eigenaren dat willen, maar daarmee zijn we nog niet van die geboortedata af. De 01-01 /01-07 systematiek is voor zover bekend niet door de GGD’s zelf uitgevonden maar door de IND/COA: die levert dergelijke geboortedata aan (ze staan ook op officiële identiteitspapieren die mensen hebben) bij gegevens die nu automatisch geïmporteerd worden. Werkrgoep: Het lijkt wel handig om aan te geven wanneer het gaat om een gefingeerde geboortedatum, aangezien deze gebruikt wordt om ID nummers te creëren. Data als 1-1 en 1-7 zijn hier niet geschikt voor. Daarnaast is 0,5 % van de mensen echt op deze data geboren. Die zijn dan moeilijk te matchen en verdwjinen in de groep die niet op die datum maar in wezen op een gefingeerde datum zijn geboren. De vraag is hoe HL7 versie 3 met deze problematiek omspringt. Bij HL7 kan men bijvoorbeeld ook aangeven wanneer een naam fictief is (omdat iemand anoniem wil blijven bijv.). Maar dan is dat wel meteen duidelijk. 12) Een wet is in voorbereiding om het unieke patiëntnummer (ZIN) mogelijk te maken. Het gebruik zal verplicht worden gesteld. Daaraan gekoppeld zal een ‘passende beveiliging’ vereist gaan worden. De wet zal wellicht gaan verwijzen naar de NEN 7510-Norm Informatiebeveiliging in de zorg. De NEN 7510 norm zal eisen gaan stellen aan de communicerende partijen. GGD Nederland zal bij het maken van een technische invulling hier rekening mee moeten houden.

36

13) Discussie Hoe gaan gegevens beheerd worden? (m.a.w.: wie houdt de tabel met overlappende nummers bij?) Waar kunnen die zoekopdrachten gegeven worden? Reactie Wanneer er gegevens uitgewisseld gaan worden zoals beoogd in het rapport van de commissie Standaardisatie zal een centrale databank gemaakt moeten worden die aangeeft bij welke bron welke gegevens beschikbaar zijn. De gegevens blijven daarbij onder verantwoordelijkheid van de bron, de database maakt ze alleen –door middel van zoekopdrachten- toegankelijk. Het beheer hiervan en de bewaking van de standaard zal bij de GGD Nederland worden gelegd. Hierbij zal gebruik gemaakt gaan worden van HL7 versie 3 en de daarin vastgelegde protocollen (XML). 14) Opmerking Het vastleggen van een instelling heeft privacy-consequenties, denk aan de PI’s. Met name daarom zal bij Tubis op korte termijn zelfs de code uit de dicom-header verdwijnen. Hoe zit het hier met privacy van de cliënt? Reactie Er is een verschil tussen de uitwisseling van foto’s (dus ook digitale foto’s) en de uitwisseling van zorggegevens. Voor beiden gelden m.i. andere juridische protocollen. Ik denk dat we dit nog eens moeten natrekken en hier duidelijk over moeten zijn in het eindverslag. Foto’s kunnen altijd, door iedereen, (ook vele jaren later worden opgevraagd) om ze met nieuwe foto’s te vergelijken. De toestemming van de patient is hier meestal niet voor nodig. De DICOM header maakt onderdeel van de foto en moet daarom zonder gevoelige gegevens worden aangeboden. Feitelijk had deze informatie hier ook niet in mogen staan. Wat de continuiteit van zorg betreft is het wel belangrijk te weten waar en waarom een bepaalde foto is gemaakt. Deze gegevens worden ook separaat bij de foto aangeleverd. Men kan er over twisten of het bij PI ‘s noodzakelijk is het volledige adres hiervan aan te leveren. Wel is het voor de follow up belangrijk te weten of een foto bij de PI of een andere instelling is gemaakt. Overigens is het veld ook facultatief.

37


Veld 9. Adres [HL7] (facultatief veld) In te vullen volgens de HL7 protocollen vanuit MARS, TUBIS of Prevalent. Het gaat bij dit veld altijd om een moment opname. Als de persoon in kwestie later verhuist, wordt het record niet gewijzigd. Dit gebeurt pas in een volgend record. Hier geldt dus het adres op de datum dat de foto werd gemaakt, de mantoux of de BCG werd gezet.

Veld 10. Instelling waar bezoeker verblijft [HL 7] (facultatief ) Bijvoorbeeld een pension voor dak- en thuislozen, een asielzoekerscentrum etc. Ook dit is een momentopname en hier geldt dus de naam van de instelling waar de persoon verbleef op het moment dat de persoon werd gefotografeerd, de mantoux of BCG vaccinatie werd gezet.14)

Veld 11. Nationaliteit [HL7] (facultatief ) Van belang bij o.a. asielzoekers en BW keuringen. Hoewel de DICOM header een veld biedt voor etniciteit (Ethnic Group: 0010, 2160), (etniciteit = niet hetzelfde als nationaliteit), doet de werkgroep het voorstel deze informatie niet in de DICOM header te plaatsen. Dit is ook conform het advies van de commissie standaardisatie. Voor Nationaliteit wordt de cijfercode (4 karakters) gebruikt die ook bij de Gemeentelijke Basis Administratie (GBA) wordt gehanteerd. Veld 11a Te overwegen is om het veld geboorteland en geboorteland moeder toe te voegen

aan de standaard. 15) 16)

Veld 12. In Nederland sinds (facultatief ) Veld van belang voor het screenen van risicogroepen.

Veld 13. Waar binnenkomst screening (facultatief ) Veld van belang voor het screenen van risicogroepen. 17)


3.2 Categorie bezoeker en reden komst Veld 14. Categorie bezoeker [immigrant/asielzoeker/contact 18)/overige] [DICOM private field] Antwoordcategorien (zie voor toelichting o.a. Bijlage 3 van het eindrapport commissie standaardisatie): IM = Immigrant voor screening AZ = Asielzoeker voor screening CON = Contact bij bron- en contactopsporing PI = screening gedetineerden OVE = overig [conditioneel verplichte velden wanneer contactonderzoek wordt ingevoerd] 14a Ring Antwoordcategorien (zie voor toelichting o.a. Bijlage 3 van het Eindrapport commissie standaardisatie): 1,2 of 3; door GGD te bepalen 19) 14b Relatie 20) Antwoordcategorien (zie voor toelichting o.a. Bijlage 3 van het Eindrapport commissie standaardisatie): F = Familie VK = Vrienden/kennissen W = Werk SO = School/ opleiding C/V = Club/vereniging/kerk U = Uitgaansleven I = Institutioneel (bv bejaardenhuis) H = Hulpverleners O = Overig 14c Patiënt nummer waar het contact bij behoort Nummer van patiënt-contactonderzoek door GGD te bepalen

15) De CPT werpgroep verbetering NTR (Nederlandse Tuberculose Registratie) zal zeer waarschijnlijk op korte termijn adviseren over te gaan van nationaliteit op geboorteland. 16) Discussie: geboorteland moeder graag vervangen door ‘risicoland’. In de praktijk zijn veel moeders en vaders ondertussen in Nederland geboren, maar krijgen kinderen toch een BCG-vaccinatie omdat ouders regelmatig familie in risicolanden bezoeken. 17) Opmerking: dit veld bestaat binnen Tubis nog niet. Met name bij asielzoekers is deze informatie ook niet altijd bekend: de COA/IND levert alleen actuele en geen historische informatie mee bij herhalingsscreeningen. Zo is zelfs niet altijd bekend of een herhalingsscreening betrekking heeft op een tweede, derde, vierde of vijfde ronde, zeker niet als asielzoekers van centrum naar centrum verplaatst worden.

38

18) Bij contactonderzoek velden 25 t/m 30 verplicht invullen 19) Discussie:Tubis kent 5 ringen. Is dit van belang? 20) Opmerking: Tubis kent naast c.q. in plaats (HV) van deze codes ook de volgende: B = Bezoekers H = Huisgenoten K = Kennissen M = Medepatienten HV = Hulpverleners Wat hiermee te doen? Vertalen? Reactie: Aan de uitvoerkant richting interface moeten alle software leveranciers dezelfde codes aanleveren. Dit zal dus een vertaalslag inhouden.

39


14d GGD die het contactonderzoek uitvoert [DICOM Institution name (0008,0080)] Eerste 2 cijfers postcode GGD-locatie


Veld 15. Reden komst [verplicht veld bij overigen; HL7] 22) Antwoordcategorien (zie voor toelichting o.a. Bijlage 3 van het eind rapport commissie standaardisatie):

14e omschrijving relatie/commentaar [vrij memoveld] Catagorie bezoeker overige: 21) ALC = Alcoholverslaafde BAI = beroepsrisico asielzoekers/immigranten BG = beroepsgroep gezondheidszorg BO = beroepsrisico overig BDD = beroepsrisico drugsverslaafden/ dak- en thuislozen BPI = beroepsrisico PI BS = beroepsrisico stage CAG = contacten andere GGD COO = contacten onbekend eigen/andere GGD DAK = dak of thuisloze DET = Gedetineerde DRUG = drugsverslaafde EMI = emigratie ILL = Illegale KIN = kind allochtoon incl pasgeboren OUDT = oud-TBC-patient TINF = TBC-geinfecteerde TPAT = TBC patient REI = reiziger tropen/risicolanden RIS = risicogroep niet nader gespecificeerd. SPB = sociaal pensionbewoner VER = persoon met verwijzing VSL = verslaafden overig ZEE = Zeevarende ZEL = eigen beweging, zelfverwijzing

21) Tubis kent hierop de volgende afwijkingen en aanvullingen (afwijkingen kunnen bij export overigens eenvoudig worden geconverteerd). Afwijkingen zijn ontstaan ofwel omdat gebruikers gewend waren aan bepaalde codes, ofwel omdat in deze velden codes maximaal 3 karakters mogen hebben. Het werd niet opportuun gevonden pakket en schermen aan te passen voor 4 karakter-codes. BGZ = Beroepsrisico Gezondheidszorg EB = Eigen Beweging (=zelfverwijzing) OUT = Oud-TBC-Patienten PG = Pasgeborenen (=kind) PM = PM-afspraak REN = Reizigers na reis TPA = TBC patiënten (actief ) TIN = TBC geinfecteerden VAA = Verslaafden - alcohol VDA = Verslaafden - harddrugs VS = Verslaafden

40

22) Tubis kent deels een afwijkende lijst. Dat wordt met name veroorzaakt door het feit, dat een deel van de informatie (beroep en reiziger bijvoorbeeld) al bepaald wordt door de categorie en niet nogmaals als reden hoeft te worden vermeld. Hieronder de Tubis-codes: BCC = BCG vaccinatie - nacontrole BCG = BCG vaccinatie BOS = Bronopsporing C2J = Controle - 2 jaar COP = Nacontrole oud patiënt CC = Controle client CPP = Controle - Primaire profylaxe CPR = Controle - profylaxe CTB = Controle - TB Patient DOT = DOT-Supervisie therapie KEA = Keuring - aanstelling KEB = Keuring - betaald KEU = Keuring KL = Klachten MEL = Melding nieuwe patiënt (NTR) NO = Nader Onderzoek O = Overig O1 = Onderzoek 1e ronde (o.a. contactonderzoek, blijkt uit categorie) O2 = Onderzoek 2e ronde O3 = Onderzoek 3e ronde O4 = Onderzoek 4e ronde O5 = Onderzoek 5e ronde PM = PM - afspraak PO = Periodiek onderzoek POS = Positieve Mantoux R = Rontgenfoto - eenmalig R1 = Rontgenfoto - eerste screening RV = Rontgenfoto - vervolgonderzoek SC0 = Screening <12 SC1 = screening 1e ronde IM/AZ SC2 = screening 2e ronde IM/AZ SC3 = screening 3e ronde IM/AZ SC4 = screening 4e ronde IM/AZ SC5 = screening 5e ronde IM/AZ SCH = screeningsonderzoek (herhaling) (o.a. wanneer ronde niet bekend is) Reactie werkgroep: In principe is de tubissituatie meegenomen in het rapport van de commissie standaardisatie, waarin ook een Tubisafvaardiging aanwezig was. De werkgroep stelt het rapport niet ter discussie. Er zullen dus diverse vertaalslagen moeten worden gemaakt.

41


SC1-5 = screening 1- 5 keer tot 2 jaar na binnenkomst SOR = screening overige risicogroepen BOSP = Bronopsporing C1-3 = Contactonderzoek r 1-3 OVE = Overig Overigen: BAS = Beroep: aanstellingsscreening BPS = beroep: periodieke screening BUS = Beroep: uitdienstscreening BTP = Behandeling TBC-patient BCG = BCG vaccinatie BCC = Controle na BCG vaccinatie ES = Screening voor emigratie NLT = Nacontrole gedurende 2 jr bij latente TBC NLOT = Nacontrole oud TBCpatient NO = Nader onderzoek PBLT = Profylactische behandeling latente TBC PP = Primaire profylactische behandeling RSV = Reizigersscreening vóór reis RSN = Reizigersscreening na reis RSO = reizigersscreening onbekend voor of na reis SK = screening na klachten

3.3 Verrichtingen en resultaten


Dit veld is al vergeven aan de GGD waarvan de desbetreffende modaliteit is Verderop wordt ook over mantoux gesproken en geldt bovenstaande.

Veld 19. Datum waarop de BCG is gezet [HL7] dd-mm-yyyy

Foto gegevens Veld 20. Naam GGD waar de foto is gemaakt [DICOM: Institution name (0008,0080)] Dit veld wordt gebruikt voor invoer van de instelling waar de foto wordt gemaakt. Wanneer foto’s met MRU-BUS zijn gemaakt, wordt de instantienaam op het OWS ingesteld.

Veld 21. Datum foto [DICOM Image date] Hier moet de datum van de foto komen zoals die door de operator workstation is gegenereerd op het moment dat de digitale foto werd genomen. Andere data zijn vanuit een diagnostisch oogpunt niet interessant.

Veld 22. Foto ID (UID) nummer [DICOM: Image Number (0020,0013)] De foto beoordeling is gekoppeld aan het foto ID nummer. Dit is een UID een z.g. Unique Identifier. De beoordeling is niet te koppelen aan bijv. het ID nummer van de client en de datum waarop de foto is gemaakt. Dit eerste kan wijzigen. Veel makkelijker is de koppeling rechtstreeks via het foto ID nummer te laten verlopen. 24)

BCG gegevens Veld 16. BCG vaccinatie in anamnese [ ja/nee/onbekend] [HL7]

Veld 17. Resultaat BCG controle [vrij memoveld] [HL7] Bijv. dubieus BCG vaccinatie litteken op de linker schouder. 23)

Veld 18. Naam GGD waar de BCG is gezet [DICOM: Institution name (0008,0080)] Commentaar:

23) Opmerking: Ook hier graag standaard-coderingen. Tubis kent de volgende statussen: GL = Geen litteken aanwezig LA = BCG litteken aanwezig ON = Onbekend PM = Positieve Mantoux VC = Vaccinatie VL = Vaccinatie en bcg-litteken Reactie Lijkt me goed om hier in de werkgroep nog nader naar te kijken.

42

Veld 23. Röntgenapparaat waar de foto mee is gemaakt [DICOM: Station Name (0008, 00xx)] Opmerking:

24) Tubis: Zou moeten worden opgenomen in Tubis. Hiertegen is geen bezwaar, behalve het financiële aspect. Vraag aan Oldelft: is de UID inderdaad uniek, ook als foto’s van de ene naar de andere Archiver worden gekopieerd? Zo ja, dan stel ik voor om aan de GGD’s voor te stellen, deze gegevens voortaan met elkaar te gaan delen. Zoals gezegd: dat vraagt aan beide kanten (Tubis en Oldelft) aanpassingen. Reactie werkgroep: Deze vraag aan een DICOM engeneer van Oldelft voorleggen, het is de vraag hoe Siemens het doet. Oldelft: Het UID wordt gemaakt op het moment dat de foto genomen wordt, dit UID is niet uniek, het is alleen maar een foto nummer, beter is het denk ik om veld 0008,0018 te gebruiken, dit veld is opgebouwd uit : RootUID.190.1.SN.SeriesNO.ImageNO RootUID is een uniek nummer uitgegeven aan Rogan Delft BV 190 Is het Digidelca Product nummer 1 is het applicatie nummer SN is het serienummer van de digidelca SeriesNO is het nummer van de beeldserie ImageNO is het nummer van het beeldje (0020,0013) Met bovenstaand nummer garandeer je een wereldwijd uniek nummer per beeld

43


Is al opgenomen in de DICOM-header. De bussen geven hier een MRU-nummer door. Zie eerdere opmerkingen punt 18 en 20.

Veld 24. View position [DICOM: Patient Orientation (0020,0020)] Antwoordcatagorien (zie voor toelichting o.a. Bijlage 3 van het eind rapport commissie standaardisatie): PA=Postero-anterieur AP=antero posterieur LL=links-lateraal RL=rechts lateraal RLD=rechts lateraal dors. LLD=links lateraal dorsaal RLO=rechts lateraal oblique LLO=Links lateraal oblique

Veld 25. Dosis gegevens [DICOM: Exposure Time + DICOM: Exposure time in mAs] Dit veld is opgenomen omdat het binnenkort wettelijk verpliht wordt dit op te nemen in de systemen. Tubis: Er zijn nog maar weinig apparaten in gebruik, die deze gegevens registreren. Voor zover bekend in Tubis-land op dit moment maar twee. Ook dit veld zou in Tubis moeten worden opgenomen. In het algemeen geldt dat er bij uitwisseling voor moet worden gezorgd dat gegevens steeds uit één bron afkomstig zijn: ofwel Mars/Prevalent/Tubis, ofwel het foto-archief. Gezien het feit dat niet iedereen digitaal werkt en dat de client-registratiesystemen leidend zouden moeten zijn, heeft het de voorkeur de communicatie met de foto-archieven uit te breiden zodat Mars/Prevalent/Tubis alle benodigde gegevens kunnen aanleveren. Oldelft: Deze gegevens, afkomstig van de modaliteit, kunnen door de modaliteit in de header worden gezet, waarna deze gegevens in het foto archief zitten, bij het tonen van de foto zijn deze gegevens vervolgens weer zichtbaar, echter de Digidelca en fosforsystmen (en vele anderen) beschikken nog niet over deze functionaliteit. Indien dit wel werkzaam is wordt het uiteraard opgenomen in het archief.

Veld 26. Uitslag eerste lezing [HL7] 25) Veld gekoppeld aan het foto ID nummer. Aangezien aan digitale foto’s nadat ze zijn vervaardigd niets meer kan worden veranderd, is het onmogelijk hier achteraf leesresultaten aan toe te voegen. Dit zal altijd met een of ander gekoppeld bestand moeten gebeuren. Vaak is het bij een eerste beoordeling niet mogelijk volledige conclusies te trekken. Een uitslag sqa kan men uitaard alleen maar geven wanneer er oude foto’s gearriveerd zijn. Men zal dus in eerste instantie gewoon de afwijking kunnen beschrijven en er later –wanneer de oude foto’s bekend zijn- sqa aan toevoegen. Antwoordcatagorien, (zie voor toelichting o.a. Bijlage 3 van het eind rapport commissie standaardisatie) 0N = geen afwijkingen, normaal 0A = artefact, foto niet over

44


1A = artefact, foto over (alleen voor intern gebruik; wordt niet uitgewisseld) 0B = overige bevindingen (GAVB) 1P = afwijking, niet verdacht voor TBC 0T = afwijking, passend bij oude TB 1T = afwijking verdacht voor TBC Bij alle uitslagen (behalve 0N) kunnen details aangegeven worden in het memoveld (automatisch doorkoppelen), zo ook verandering tov vorige foto, en eventueel of actie nodig is. Dus: eigen systematiek handhaven. Diagnose: TBCA = Actieve TBC TBCO = Oude TBC LTR = latente recente TBCinfectie (mantouxomslag) LTWR = latente TBCinfectie: waarschijnlijk recent (positieve mantoux) LTO = latente TBCinfectie: waarschijnlijk oud (positieve mantoux) PATH = Pathologische afwijkingen anders dan TBC ESO= Einde screening/onderzoek of screening voltooid (bv, terug naar land van herkomst, screening afgerond, of onderzoek voortgezet andere GGD, door b.v. verhuizing)

25) Tubis Hier zal (opnieuw) een vertaalslag moeten worden gemaakt. Tubis kent de volgende codes: BP = (Broncho) pneumonie BWT = Bijwerkingen tuberculostatica GD = Geen Diagnose LI = Luchtweginfectie LTC = LTBI, Controle LTG = LTBI, geen actie LTP = LTBI, Profylaxe M = Maligniteit (verdenking op) O = Overig OTB = Status na TB - medicamen. beh. OTO = Status na TB - niet med. Beh. PP = Primaire Profylaxe RAI = Rest-Afw. (post)inf. niet TB RAT = Rest-Afwijking (post-) Traumatisch S = Sarcoidose (verdenking) TBC = Tuberculose (actief ) VC = BCG Complicatie GA = Geen Afwijking Overigens: worden hier niet drie gegevens in één veld opgenomen? - De uitslagcode; - Eventuele memo-velden; - Diagnose-code? En zo ja: waarom dan in één veld? Dat maakt ze moeilijk scheidbaar. Reactie werkgroep: Het lijkt inderdaad beter om hier verschillende velden (of subvelden) voor te maken. Tubis is op dit punt veel ruimer dan de standaard, hier zal naar gekeken moeten worden. Een vertaalslag maken of de landelijke standaard aanpassen?

45


ASO = Afgebroken screening/onderzoek (bv met onbekende bestemming vertrokken; 2x opgeroepen niet verschenen, mantoux niet afgelezen)

Veld 27. Uitslag tweede lezing : memoveld Hier moet het mogelijk zijn een uitslag met eigen getypt commentaar weer te geven

Veld 28. Vrij memoveld [voor röntgen verslag] [HL7] Veld is gekoppeld aan het foto ID nummer.

Veld 29. Naam arts die lezing heeft verricht [HL 7] Veld is gekoppeld aan het foto ID nummer.


4. Aanmaken van een HL7 (XML) uitwisselingsbestand HL7 werkt met gebeurtenissen (events). Men moet vooraf definieren welke gebeurtenissen tot een uitwisselingsbestand leiden (message). Dit message wordt dan –ongewild- aangemaakt en naar een bepaalde directory (map) verzonden. In de nieuwste versie van HL7 (beta versie 3.0) wordt voor deze uitwisseling een .xml file aangemaakt. Dit is een universeel leesbaar bestand dat in elke willekeurige database als record kan worden opgenomen. Wanneer er zowel een foto als een mantoux wordt aangevraagd lijkt het om logische redenen verstandig om hiervoor 2 verschillende gebeurtenissen te creëren en dus 2 verschillende records aan te maken. In totaal zijn er 3 gebeurtenissen waarbij een .xml record dient te worden aangemaakt. 1. wanneer een foto is gemaakt 2. wanneer een Mantoux is gezet 3. wanneer een BCG is gezet

Veld 30. Naam arts die de 2e lezing heeft verricht Bij gebeurtenis 3 (wanneer een BCG is gezet) kan het record meteen worden afgesloten. Bij gebeurtenissen 1 en 2 kan dit pas gebeuren nadat de uitslag aan het record is toegevoegd. Mantoux gegevens Veld 31. Naam GGD waar de mantoux is gezet [DICOM: Institution name (0008,0080)] Zie eerdere opmerking bij punt 18.

Wijzigingen in de reeds bestaande records zullen alleen optreden wanneer ook voor deze gebeurtenissen events worden gedefineerd. De uitslagen zullen dan automatisch in de nog niet afgesloten records worden opgenomen. Events 4 en 5 zijn dus:

Veld 32. Datum mantoux zetten [HL7]

4. wanneer een foto is gelezen 5. wanneer een mantoux is afgelezen

Veld 33. Datum mantoux aflezen [HL7]

Veld 34. Uitslagwaarde mantoux [HL7] Uitslag waarde met een getal van 2 karakters, dus een maximum van 99 mm

Veld 35. Resultaat mantoux onderzoek [vrij memoveld] Hier moet een getypt (niet gecodeerd) commentaar ingevoerd kunnen worden. Sommige mantoux reacties hebben een zeer harde induratie, bij andere voelt het aan als een waterbed, soms is er sprake van blaarvorming. Deze verschillende consistenties hebben diagnostische betekenis.

Normaal gesproken zal MARS, tubis of prevalent het uitwisselingsbestanden bijwerken wanneer een foto is gelezen vanuit zijn eigen database. Wanneer foto’s op afstand worden gelezen (bijv. op CD rom) zal en omgekeerd proces moeten plaatsvinden. Hierbij moet worden opgemerkt dat een CD rom ongeschikt is om uitwisselingsbestanden (zou men deze er al opkrijgen) bij te werken. Hiervoor is hooguit een CD-RW geschikt. Deze worden echter door de Oldelft software als CD-ROM gebrand en zijn dus eveneens ongeschikt om achteraf wijzigingen in aan te brengen. Wil men foto’s op CD op afstand lezen, en de uitslagen hiervan in een later stadium in de eigen database terug invoeren, dan zal dit door middel van een separaat uitwisselingsbestand moeten gebeuren. De te lezen records moet men dan in een database opnemen en separaat met de CD versturen. Een floppy zou zich hier in principe wel voor lenen maar lijkt thans min of meer out of date. Een bijkomend nadeel is de privacy gevoeligheid van dergelijke uitwisselingsbestanden wanneer ze op een floppy in combinatie met de CD worden aangeboden. Daarnaast bestaat de mogelijk deze uitwisselingsbestanden op te slaan in een soortement van centrale database. Voor HL7 ver 2.2. zijn hier bij de HL7 organisatie kant en klare database voor verkrijgbaar draaiend onder Access. Voor HL 7 versie 3.0 zijn deze op korte termijn (?) te verwachten. Deze optie verdient de voorkeur aangezien hij de mogelijkheid bied ID nummers van verschillende GGD te koppelen, wanneer het om dezelfde clienten blijkt te gaan. 26)

26) De ervaring is dat het uitwisselen van HL7 berichten is een complex geheel is, er bestaan veel meer soorten berichten dan welke hierboven worden beschreven. Het wordt aanbevolen een bedrijf in de arm te nemen die ervaring heeft met dit soort berichten verkeer.

46

47



5. Patiënten dossier

Bijlage 3. VISI Werkconferentie TBC-automatisering 3 oktober 2002. Naar een efficiëntere gegevensuitwisseling

De commissie standaardisatie doet geen uitspraken om tot de invoering van een MED [Medissch Elektronisch Dossier] te komen. Wel wordt automatisch een soort van MED dossier “gevormd” door de chronologisch gerangschikte records. Dit bestaat uit de afzonderlijke mantoux uitslagen en de afzonderlijke foto uitslagen alsmede het toegevoegde commentaar [ de vrije memovelden]. Als enige overige informatie is hierin tevens informatie over de BCG vaccinatie en een evt. BCG vaccinatie litteken opgenomen. Wanneer ID nummers aan elkaar gekoppeld worden zullen alle onder deze ID nummers vallende foto, mantoux en BCG gegevens worden gebundeld. Tevens zullen in deze “bundel” alle -digitale- foto’s zich moeten “bevinden”. Het “patienten dossier”wordt dus gevormd door de gebundelde data gegevens en de gebundelde thorax-foto’s. 27)

1.

Opening door George Haringhuizen De lopende initiatieven op dit moment zijn: • Het ROI Limburg werkt aan de VISI opdracht schaalvergroting TBC bestrijding. geautomatiseerd / gedigitaliseerd worden. • KNCV en RIVM zijn gestart met het ontwikkelen van een elektronische meldingsapplicatie van de NTR-delen 2 en 3. Dit automatisering project valt buiten de discussie van de geautomatiseerde gegevensuitwisseling waarover vandaag gesproken wordt. • De juridische omgeving van de tbc-registratie en uitwisselen van gegevens tussen GGD’en en landelijke organisaties. Deze opdracht is door de KNCV uitbesteed aan Holvast en partners. • Het samenvoegen van de MSI en DJI-bestanden. Belangrijk is of het technisch en juridische mogelijk is om de bestanden toegankelijk te maken voor anderen dan de beheerders van de bestanden. • De CPT commissie Standaardisering van de KNCV. • Deze bijeenkomst van de landelijke VISI werkgroep TBC automatisering.

Tevens moet het mogelijk zijn digitale foto’s van derden (ziekenhuizen) aan de records toe te voegen voor de volledigheid van het dossier. Deze kunnen namelijk zonder problemen naar het archief worden gekopieerd [althans dit zou moeten kunnen]. In dit geval wordt de foto onder het ziekhuis ID nummer in het fotoarchief opgenomen. Tevens moet er bij dit soort gebeurtenissen een HL7 record worden aangemaakt. Door koppeling van ID nummers zal de ziekenhuisfoto dan eveneens in het patiëntendossier worden opgenomen. 28)

Onderliggende doelen voor de verbeteringen in de TBC automatisering zijn: • De mogelijkheid op grotere schaal te werken • Het lezen van foto’s op afstand • Het voorkomen van dubbele en onnodige screening Bijkomende voordelen zijn: elektronische overdracht, het faciliteren van verpleegkundigen die bron- en contact onderzoek doen en het leveren van een bijdrage aan de landelijke surveillance en wetenschappelijk onderzoek. De intentie is om op korte termijn 1 systeem te ontwikkelen waarmee via een minimaal pakket aan gegevens duidelijk kan worden wie wanneer gescreend is.

27) Tubis: Het produceren en inlezen van CD’s (RW of niet) is een tijdrovende aangelegenheid. Als sprake is van uitwisseling van gegevens met een centrale database lijkt het zinniger, dit proces te automatiseren en te laten lopen met versleutelde informatie via beveiligde (internet-) verbindingen. Dat vraagt weliswaar een grotere initiële investering, maar die wordt ruimschoots terugverdiend door besparing op personeelskosten. Reactie: Klopt, bij gebruikmaking van HL7v3 kan men niet zonder een centrale database, die versleutelde informatie bevat. Dit kan eventueel via het internet. 28) Dit het beste en eenvoudigste gerealiseerd worden als er voor een cliënt één uniek nummer bekend is. Het tonen van verschillende ID nummers vanuit de viewingssoftware is niet toegestaan. Handmatige toevoeging is uiteraard wel mogelijk via een add to multi functionaliteit binnen HyperVIEW. Vanuit een informatiesysteem kunnen wel koppelingen of omnummeringsmodules worden gemaakt, echter blijft het de vraag wanneer en hoe dit te implementeren bij alle verschillende GGD’s. Intern bij 1 GGD kan een omnummering van een client soelaas bieden. Dit gebeurt in de praktijk al bij de tijdelijke cliëntnummers van MRU-BUS cliënten e.d. Een mogelijkheid bij 1 landelijk nummer is dat op het moment dat van 1 patiënt twee id’s bekend zijn aan alle deelsysteem kenbaar te maken dat er 2 nummers zijn maar dat in de toekomst alleen nog nummer 1 toegepast moet worden. Zo gebeurt het ook binnen de ziekenhuis wereld, men gebruik daar ADT-koppelberichten voor. Dit is echt een hele complexe materie waar professionele ondersteuning bij nodig is.

48

Voor wat betreft de juridische aspecten maken de KNCV en Holvast goede vorderingen op het terrein van de verschillende registratiemogelijkheden. Om screeningsgegevens landelijk bij elkaar te brengen is toestemming nodig van het College Bescherming Persoonsgegevens, maar i.v.m. de wettelijke opdrachten van de GGD’en is dit niet per patiënt nodig. Dus zonder het werkproces enorm te verzwaren is het toch mogelijk een bestand te creëren.

2.

Stand van zaken project ‘koppeling van computersystemen voor de tbc-bestrijding’ in opdracht van de GGD Hart voor Brabant en GGD Flevoland door Frans van Muilwijk Aanleiding was: Het landelijk project asielzoekers en gedetineerden, twee gescheiden databases van dezelfde doelgroep, zoekproblemen bij verzoeken om oude foto’s en databasevervuiling. De (telefoon)verbindingen zijn de beperkende factor, het duurt bv. al 4 minuten om een foto te versturen. De dagopbrengst van een bus zou 17 uren duren om over te brengen. De RX moet eerst volledig verzonden worden, pas daarna is op het leesstation diagnostiek mogelijk. Enkele ontwikkelingen: ISDN, ADSL, Glasvezelverbinding, Glasvezelnet van KPN, Gemnet enz, VPN via internet en Straalverbindingen (tot 32 mb). De oplossing voor GGD Hart voor Brabant en GGD Flevoland is: • 1 database van Tubis voor beide GGD’s

49


3.


• 1 centraal RX-bestand (alle foto’s) • 1 decentraal RX bestand (gedeeltelijk fotobestand)

• Door uitwisseling van digitale foto beelden kunnen foto’s “op afstand” worden beoordeeld door de TBC arts

Voordelen zijn: • Sneller afhandelen verzoeken oude foto’s • Voorkomen dubbele foto’s asielzoekers • Opmaat voor elektronisch versturen van de foto’s • Opmaat koppelingen met andere GGD’s • Toename flexibiliteit (Foto lezen, consultatie) • Toename snelheid (AC, TNV)

Deze werkconferentie richt zich hoofdzakelijk op het eerste vraagstuk, dat in 3 werkgroepen verder wordt uitgewerkt.

Presentatie van de resultaten CPT werkgroep standaardisatie door Ans Lohuis Voorgeschiedenis Standaardisatie TBC-bestrijding: Vanaf 1996 start automatisering in de tbc-bestrijding. Het lukt niet om eenzelfde registratiesysteem voor alle GGD’en te introduceren. Daardoor zijn er verschillende software pakketten ontwikkeld met eigen coderingen van gegevens. In 1997 is een poging gedaan tot standaardisatie vanuit de KNCV middels MIS (Management Informatie Systeem), dit is echter nooit als referentiemodel gebruikt en uitgewerkt. Vanaf 2000 wordt de ontwikkeling van digitalisering van rontgenfoto’s op GGD’en geïntroduceerd. Hierdoor ontstaat de behoefte van het digitaal uitwisselen van foto’s en wordt standaardisatie dringender vereist Dit is nodig voor: 1. uitwisseling van cliënten- en patiëntengegevens tussen GGD’en onderling en 2. landelijke gegevensverzameling (WBO/MSI) In februari 2001 werd de “Commissie Standaardisatie Registratie Tuberculosebestrijding” geïnstalleerd. De taakopdracht van de commissie bestaat uit het vergelijken van bestaande coderingen en terminologie in geautomatiseerde systemen. Het doel is om te komen tot formulering van een uniforme minimale set van gegevens en coderingen, nodig voor uitwisselen van cliënten en patiëntgegevens tussen GGD’ en. De werkgroep heeft de volgende werkwijze gevolgd: • Er is overzicht gemaakt Inzicht krijgen in werkwijze van 3 meest toegepaste registratie systemen (Tubis, Mars, Prevalent). Overeenkomsten, verschillen en problemen worden door de werkgroep in kaart gebracht • Uitwerking van taakopdrachten in tabellen met coderingen • Discussie over doel en haalbaarheid van taakopdracht: inhoudelijk en technisch • Terugrapportage in CPT (Commissie Praktische Tuberculosebestrijding) met als doel besluitvorming • Eindrapportage met aanbevelingen, discussiepunten en conclusies naar verwachting januari 2003 gerealiseerd

4. en 5. Uitwerking drie deelopdrachten en terugkoppeling van de uitkosten, voorstellen en adviezen De landelijke werkgroep TBC automatisering heeft de twee belangrijkste voordelen van gegevensuitwisseling in de TBC als volgt geformuleerd: • Door uitwisseling van een set cliëntgegevens kan worden nagegaan of iemand op een andere locatie al onder controle is geweest, zodat niet opnieuw gescreend hoeft te worden. Dit bespaart kosten voor de GGD en onnodig onderzoek voor de cliënt

50

Werkgroep 1: Uitwisseling dicom-index gegevens via centrale database De presentatie van Max Antheunisse over de Dicomheader is zeer verhelderend. In deze werkgroep worden de volgende deelvraagstukken beantwoord: 1. Klopt het dat de dicomheader informatie via Hyperarchief op eenvoudige wijze geschikt te maken is voor een centrale database? 2. In welk format moet de informatie omgezet werden (excell?) 3. Hoe moet een centrale database er uit zien? Vindt uitwisseling plaats via - CD Rom - Internet peer-to-peer - Internet centrale database Ad 1. Het klopt dat de dicomheader is te gebruiken voor een centrale database. Het is echter wel lastig om alle bestanden effectief te raadplegen, je wilt namelijk een 100 % match. Bij bijvoorbeeld de Vries uit 1-9-1970 verschijnen dezelfde achternamen voor verschillende personen. Er is dus een behoorlijke zoektijd en niet 100% efficiënt. Voorgesteld wordt om i.s.m. de leverancier een proeftuin te creëren om dit uit te testen, te evalueren en te analyseren waar problemen zitten. Hiervoor is een partij nodig die bereid is te investeren om dubbelen te voorkomen. Aan de hand van de resultaten kunnen conclusies worden getrokken en belanghebbende partijen worden ingeschakeld. Ad 2. Hierover is geen uitspraak gedaan Ad 3. Geen voorkeur uitgesproken, maakt niet uit. Werkgroep 2: Gestandaardiseerde gegevensuitwisseling In deze werkgroep worden de volgende deelvraagstukken beantwoord: 1. Welke kerngegevens zijn minimaal nodig om na te gaan of iemand eerder voor Tuberculosescreening is geweest? 2. Zijn deze kerngegevens door iedereen digitaal aan te leveren? Ad. 1 De volgende gegevens zijn minimaal nodig: Voor- en achternaam, voorletters, geboortedatum, geslacht, nummer, GGD-naam waar de foto is gemaakt Om allerlei redenen zou het handig zijn om de onderzoeksdatum datum te weten, maar het is niet noodzakelijk. Nationaliteit en soort röntgenonderzoek is niet noodzakelijk om te weten. Ad 2. Voor wat betreft de aanwezigen hier zijn de kerngegevens voor iedereen aan te leveren, maar niet alle GGD’en zijn hier aanwezig, dus het is wel een aandachtspunt. Er wordt opgemerkt dat het goed is dat de softwarebouwers hier samen rond de tafel zitten. Het kan veel voordelen opleveren als deze bijeenkomsten wordt voortgezet. Werkgroep 3: Randvoorwaarden In deze werkgroep worden de volgende deelvraagstukken beantwoord:

51


1. Welke infrastructuur maakt het mogelijk om landelijke afspraken te maken over gegevensuitwisseling? 2. Wie coördineert en wie verzamelt de gegevens? 3. Wat wordt er van elke GGD verwacht? 4. Welke juridische knelpunten zijn er en wie gaat dat oplossen? De werkgroep kwam al heel snel in de nut-noodzaakdiscussie terecht. Dit systeem levert op dat je weet wie/wat/waar geweest is. Het is maar de vraag of de wie/wat/waar database zoveel oplost. Er zijn op dit moment geen percentages te noemen van dubbele foto’s en wanneer er geen match is etc. De mogelijkheid van een centraal bestand is dat je iedereen door het systeem kan halen. Dit hangt samen met het werkproces en doel. Gegevens worden centraal aangeleverd, maar niet teruggekoppeld. Dit is makkelijker en juridisch eenvoudiger. Als je voor het systeem een goede identifier kan realiseren zou dat de grootste winstfactor zijn. Dit kan alleen als er politieke bereidheid is om te mogen werken met de bestaande codes en de unieke nummering. GGD’en verzamelen gegevens, daarbij moet rekening gehouden worden met kosten en baten. De suggestie wordt gedaan dat het beheer het beste kan worden neergelegd bij een grote GGD met veel automatiseringskennis en vaardigheden, bv. Lelystad of Tilburg.


6.

Afspraken over vervolgtraject Samenvattend de belangrijkste conclusies vanuit de werkgroepen: • Voordat geïnvesteerd wordt op een nieuw systeem moet er het perspectief zijn dat in de toekomst uitgebreidere uitwisseling van gegevens mogelijk wordt • Om te onderzoeken of het nut zal opleveren zijn de volgende stappen mogelijk 1. Match van de 4 grootste databases van asielzoekers en mogelijk gedetineerden Dit zal door het VISI team worden besproken in de landelijke werkgroep 2. Een proeftuin, technisch bij een klein aantal GGD’en en/of inhoudelijk bij een groter aantal GGD’ en. Dit gebeurt door de landelijke werkgroep. De aanwezige GGD’en worden uitgenodigd hierover mee te denken. Het investeringselement is belangrijk. 3. Een gesprek met Justitie inzake de indentificeerbaarheid en gebruik van de nummers is noodzakelijk. GGD Nederland en de KNCV moeten hierin leidend zijn en het gesprek voorbereiden. 4. Er moet een gesprek komen tussen de programmaleveranciers om tot een wijze van codering en unieke nummering te komen. De vergadering stemt er in toe dat het VISI team hierin het initiatief neemt.

Een andere optie is de mogelijkheid van een pilot/proeftuin met een minimum aantal deelnemende GGD’en voor een nuttig gebruik van het bestand om het inhoudelijk rendement te bepalen. Vanuit de zaal wordt opgemerkt dat er grote vraagtekens zijn bij het op te zetten systeem. Nog een aanvulling: dubbele foto’s/zoeken in het systeem. Is het de investering waard om daar antwoord op te geven, zeker als er geen vervolgtraject is? Om tot een gecentraliseerde oplossing te komen moet er wel perspectief zijn. Uit de praktijk blijkt nl. dat het eigenlijk maar kleine problemen zijn. Een tussenoplossing is kijken wat er in de bestanden staat van de GGD’en Lelystad, Tilburg, Groningen e.a. Daaruit kan (bij benadering) worden vastgesteld hoeveel dubbelen er zijn om een idee te krijgen. Rondom dit traject moet nadrukkelijk een gesprek met Justitie en COA plaatsvinden om het probleem op te laten pakken, bv. n.a.v. het onderzoek waaruit blijkt dat sommige gedetineerden 4 à 5 keer per jaar op de foto gaan. Hoe kan het strategisch het beste worden aangepakt? GGD’en Justitie hebben een contract waarin staat dat de Staat uitwijst wie er op de foto moet. Het advies van een van de aanwezige leveranciers is te kijken naar een methode van standaardisering voor 3 informatiesystemen waarbij de leveranciers een uniforme code gebruiken voordat de foto gemaakt wordt. Dit geeft later grote voordelen. Voorgesteld wordt om tijdig een gesprek tussen de leveranciers te organiseren. NB. Men moet niet de illusie hebben dat heel Nederland dekkend kan worden gemaakt. N.a.v. de uitwisselbaarheid van foto’s zegt Max Antheunisse dat gevoelige gegevens, bv. de risicogroep waartoe iemand behoort (b.v. gedetineerde of dak- en thuisloze) eruit gehaald moeten worden zodat het niet in de header komt. Hans van Keulen merkt op dat het mogelijk/wenselijk is om tussentijds een manier te verzinnen om foto’s efficiënt uit te wisselen, ook al is het maar een preview, bv. in jpeg. Hier kan je doublures niet mee voorkomen, maar het kan wel handig zijn. Er is gesproken over een situatie waar we graag naartoe willen. Het heeft geen zin om oude bestanden te gebruiken, maar je kunt ze wel als controle/referentiebestanden gebruiken voor analyses en vergelijkingen. Ook is het een indicatie aan potentieel op dubbels.

52

53


Bijlage 4. Verslag werkconferentie 13 maart 2003 (vastgesteld 23-04-03) “Automatisering in de tuberculosebestrijding (2)”Naar een efficiëntere gegevensuitwisseling Aanwezig zijn GGD medewerkers/automatiseerders (13 verschillende GGD-en), Oldelft, Prevalent, ALCA, Acha, Ensemble (zie bijlage), Holvast en Partners, KNCV, RIVM en GGD Nederland George Haringhuizen, projectleider VISI opent de vergadering en heet iedereen van harte welkom. Tbc-automatiserings infrastructuur; Technisch en Organisatorisch (presentatie door Jelle Doosje, GGD Nederland projectmedewerker VISI). Er wordt een toelichting gegeven op het Eindrapport Commissie Standaardisatie dat in januari 2003 is vastgesteld op de vergadering van de Commissie Praktische Tuberculosebestrijding (CPT). Het rapport is verzonden naar alle deelnemers van de werkconferentie, GGD directeuren en alle hoofden afdeling AGZ/TBC. Er is een inhoudelijke standaard vastgesteld door professionals, gebaseerd op zowel landelijke als internationale afspraken en standaarden. In het rapport wordt voorgesteld om de standaard gefaseerd te implementeren in samenspraak met automatiseerders van GGD’en en softwareleveranciers. De complexiteit van dit standaardisatietraject wordt bepaald door het feit dat er 40 GGD’en zijn, 4 grote softwareleveranciers (Oldelft, Tubisgroep, Ensemble/Mars en Prevalent) en een 10-15 tal verschillende geautomatiseerde administratiesystemen. Toekomstige ontwikkelingen en wensen van gebruikers, zoals bijvoorbeeld de ontwikkeling van elektronisch patiënten dossier (EPD), zorgen er voor dat standaardisatie een dynamisch proces is. Voordelen van standaardisatie zijn: kwaliteitsverbetering, verbeteren van vergelijkbaarheid, transparantie en uitwisselbaarheid van gegevens. Gestandaardiseerde gegevensets maken het mogelijk gegevens te poolen zodat de noemer vergroot wordt, waardoor de betrouwbaarheid van analyses toeneemt. De uitkomsten van de eerste werkconferentie worden in het kort weergegeven (zie verslag 3 oktober werkconferentie). De 1-malige match van de PI databases van de 4 Mobiele Röntgen Units (MRU) is nog niet uitgevoerd. Hiervoor is een juridisch protocol opgesteld die kon worden onderschreven door de 4 deelnemende GGD’en (Flevoland, Groningen, Tilburg en Zeeland). Er wordt naar gestreefd de match op korte termijn uit te voeren. Het ROI Limburg werkt in het kader van VISI een opdracht uit over TBC regionalisering. Het ROI ontwikkelt een plan met criteria en randvoorwaarden in relatie met werken op grotere schaal en een plan voor het regionaal verzamelen van gestandaardiseerde gegevens. De landelijke werkgroep tuberculosebestrijding adviseert het ROI Limburg over de eisen waaraan software moet voldoen. De juridische randvoorwaarden met betrekking tot beheer, houderschap en bewerking van geautomatiseerde gegevens worden uitgewerkt door de KNCV en bureau Holvast & Partners in samenwerking met GGD Nederland. Tussen analoog en digitaal. Gegevensuitwisseling anno nu (door Max Antheunisse, tuberculose arts GGD Zeeland). In een powerpoint presentatie wordt geschetst hoe in het verleden en tegenwoordig tuberculoseartsen röntgenfoto’s beoordelen, gegevens vastleggen en uitwisselen. De populatie in penitentiaire inrichtingen bestaat voor een aanzienlijk deel uit gevangenen die regelmatig terugkeren voor een verblijf in de inrichting. Zij worden daarom regelmatig op de foto gezet. Als er afwijkingen gevonden worden zal er altijd een poging worden gedaan foto’s op te vragen bij een van de GGD-en. Ondanks alle moderne hulpmiddelen worden ook tegenwoordig digitale gegevens op CD-rom via post verzonden, nadat telefonisch is nagegaan of betrokkene bekend is bij de andere GGD. Op een zeer illustratieve wijze wordt duidelijk dat het opvragen van 1 digitale foto veel handelingen met zich meebrengt. CD-rom moet in diskettestation geplaatst en ingebrand worden. Vervolgens via de post verzenden, na lezen worden di-

54


gitale gegevens naar de eigenaar van de gegevens teruggestuurd. Vanwege privacywetgeving moet de CD-rom met gevoelige informatie daarna vernietigd worden. Slotconclusie is dat met een centrale database met een zoekmogelijkheid en uitwisselingsmogelijkheid veel efficiencywinst kan worden bereikt. De privacybescherming kan hierdoor beter geregeld worden doordat er niet overal kopieën van digitale foto’s hoeven worden opgeslagen en vernietigd in de afzonderlijke databases. Identificatie en (on)mogelijkheden voor unieke nummering (door Vincent Kuyvenhoven, artsconsulent KNCV). Het doel van unieke nummering is 4-ledig; dubbelingen worden voorkomen, het geeft informatie over de TBC voorgeschiedenis, snelle en betrouwbare check van eerder gemaakte foto’s en de noemerproblematiek wordt vermeden. De belangrijkste voorwaarden waaronder unieke nummering kan plaatsvinden is als er toestemming is van betrokkene en informatie verstrekt wordt over de Database. Tevens moet in een protocol zijn vastgelegd wie wanneer toegang heeft tot de database waarbij de cliënt de vrijheid heeft om te weigeren. De knelpunten die kunnen optreden bij het toekennen van unieke nummers: iemand heeft de vrijheid om te weigeren of is niet in staat om toestemming te geven door bijvoorbeeld taalproblemen. Ook kan het voorkomen dat iemand geen identifiers (bij zich) heeft. Een registratiesysteem met unieke nummering (b.v. sofinummer of GBA nummer) moet gemeld worden bij het College Bescherming Persoonsgegevens. Ieder systeem wordt getoetst op koppelingsmogelijkheden met bestanden die voor andere doeleinden worden gebruikt. Wanneer die koppeling mogelijk is geeft het college geen toestemming. Dit maakt het vrijwel onmogelijk om het sofinummer of GBA nummer te gebruiken als identifier in een tbc-registratie systeem. Op de ministeries van BZK en SZW wordt op dit moment nagedacht en gewerkt aan de ontwikkeling van de eNIK (elektronische Nederlandse IdentiteitsKaart) in combinatie met biomarkers. Tevens wordt vanuit die ministeries aansluiting gezocht bij VWS die zich in het verleden heeft bezig gehouden met het ontwikkelen van een zorgpas. Het is van belang deze ontwikkelingen nauwlettend te blijven volgen. Naar verwachting zal dit echter niet op korte termijn zijn gerealiseerd. Een mogelijke oplossing voor de tussenliggende periode is het verstrekken van een TBC-pas, voorzien van een uniek landelijk nummer. Standaardisatie en Gegevensuitwisseling Inleiding door Hans van Keulen, informatie manager GGD Nederland. In deze sessie hebben automatiseerders en GGD medewerkers met elkaar verkend hoe de standaard uit het eindrapport kan worden ingevoerd. De volgende deelvragen zijn besproken: • op welke wijze moet zowel inhoudelijke als technische standaardisatie worden ingevoerd • wat is een realistische termijn waarop dit kan worden ingevoerd door de aanwezige automatiseerders en GGD’en • welke keuzes zijn er voor de ontwikkeling van een landelijke database of module voor de uitwisseling van gegevens (inclusief foto’s) • Welke regio (een van de zeven GGD afdelingen) zou geschikt en bereid zijn mee te doen in proeftuin of pilot? Automatisering en Regionalisering Tuberculosebestrijding Inleiding door Hanneke Wessels, beleidssecretaris VISI (GGD ZZL) en Maurits Verhagen, tuberculose arts (GGD N&M Limburg) Aan de hand van de ervaringen uit Limburg is onderzocht aan welke eisen software moet voldoen in het kader van regionalisering van de tuberculosebestrijding. De volgende vragen zijn aan de orde geweest: • Aan welke eisen moet de software voldoen in relatie met de verschillende scenario’s die op dit moment in Limburg worden uitgewerkt • Wat betekent schaalvergroting naar 8 tot 10 TBC centra in Nederland, voor de bestaande automatise-

55


ringssystemen. Hoe kijkt men hier in de overige regio’s tegenaan? • Welke regio (een van de zeven GGD afdelingen) zou geschikt en bereid zijn mee te doen in proeftuin of pilot? Terugkoppeling van de uitkomsten uit de workshops: Workshop 1: Standaardisatie en gegevensuitwisseling • GGD’en moeten in het kader van gegevensuitwisseling prioriteit geven aan de invoering van een landelijke standaard. Dit is niet vanzelfsprekend omdat elke GGD z’n eigen regie voert op het terrein van automatisering. • Als alle partijen zich hiervoor optimaal inzetten moet het mogelijk zijn de invoering van de inhoudelijke standaard eind van dit jaar te hebben vertaald naar een technische standaard in de systemen • Een mogelijk knelpunt is dat eigen coderingen niet te vertalen zijn en niet kunnen worden gestandaardiseerd. • De pilotregio moet een regio zijn met verschillende automatiseringssystemen, Zuid-Holland is genoemd als geschikte regio. De vier software leveranciers zijn bereid de technische standaard verder uit te werken, bij voorkeur onder aansturing van GGD Nederland/KNCV. Er wordt daarbij aangesloten bij de internationale HL7 standaard. Het eindpunt is een landelijke centrale vorm van database. Dit is niet op korte tijd te realiseren. De eerste stap is het realiseren van uitwisseling, dus de inhoudelijke standaard technisch vertalen in verschillende pakketten, zodat onderlinge communicatie mogelijk is. Workshop 2: Automatisering en regionalisering van de tuberculosebestrijding In Limburg wordt gewerkt met drie verschillende systemen van dataopslag, er wordt nog niet gewerkt met gedigitaliseerde röntgenapparaten. Vanuit de werkgroep wordt geadviseerd: • in het kader van regionalisering kiezen voor 1 systeem in 1 regio, dit maakt uitwisselbaarheid het meest eenvoudig. • het maakt niet uit of er met of zonder mobiele röntgenunit wordt gewerkt, • het systeem moet de mogelijkheid bieden om vanuit 1 werklocatie cliëntgegevens en foto’s van het hele werkgebied uit te wisselen. • het systeem moet de inhoudelijke standaard bevatten die door de CPT is vastgesteld. • het softwarepakket moet de gegevens, nodig voor de regionale surveillance, kunnen aggregeren Tijdens het overleg is globaal gekeken naar de verschillende regio’s (7 GGD afdelingen) en het gebruik van softwarepakketten. Grootste deel van Noord Holland Flevoland, Noord Nederland, Brabant/Zeeland (m.u.v. een aantal GGD’en) maken gebruik van hetzelfde softwarepakket (tubis). Provincie Utrecht heeft voor de hele provincie hetzelfde systeem (prevalent). Overijssel/Gelderland, Zuid Holland en Limburg gebruiken diverse verschillende softwarepakketten. Zuid-Holland of Gelderland/Overijssel worden genoemd als meest geschikte regio voor een proeftuin. Financiering In de discussie komt naar voren dat de financiering van dit standaardisatie-proces een belangrijk knelpunt is. GGD’en zijn afhankelijk van de besturen om hierop te investeren. GGD Nederland zou hierin eventueel een rol kunnen vervullen. De bereidheid om te investeren op TBC-automatisering is mede afhankelijk van het feit in hoeverre bestaande systemen zijn afgeschreven. De landelijke standaard moet bekend gemaakt worden bij de directies en besturen, onder het motto: ‘’een slag slaan in de automatisering van de tbc’’. De directie moet er op worden gewezen dat er de komende jaren ruimte gecreëerd moet worden voor budget. De vereniging, dus de directeuren, zouden een beleidsafspraak moeten ma-

56


ken met een tijdsplanning. Dit kan eventueel in een ALV in het najaar gebeuren. De eerste stap kan door de leveranciers gezet worden, nl. de vertaalslag tussen de inhoudelijke standaard en de technische wijziging van het programma. Hieruit zullen ongetwijfeld bepaalde vragen naar boven komen. De leveranciers moeten dan ook in gesprek raken met een aantal deskundigen bij GGD’en. In de proefregio kan gekeken worden hoe het ingevoerd/doorgevoerd kan worden. Afspraken • Op uitnodiging van GGD Nederland (VISI) gaan de softwareleveranciers met elkaar in gesprek om afspraken te maken over de vertaling van de inhoudelijke standaard in de systemen. Uitwisselbaarheid van gegevens is het uitgangspunt. • Deze standaardisatie zal met gesloten beurzen worden doorgevoerd • GGD Nederland (VISI) organiseert een bijeenkomst met de GGD’en in Zuid-Holland en toetsen of men in regionaal verband wil mee te werken in een proeftuin/pilot. • Vanuit VISI zal in samenspraak met de KNCV een rapport worden opgesteld over de voorgestelde aanpak van standaardisatie en automatisering, dit zal worden voorgelegd aan de ALV van GGD Nederland. In het kader van het project VISI wordt afgesproken om de eerste twee activiteiten voor 1 juni uit te voeren zodat er een goed advies kan worden geformuleerd aan stuurgroep VISI. Het advies kan zodoende worden meegenomen in de planvorming voor de versterking van de infrastructuur van de infectieziektebestrijding. Dit plan zal op 3 juni tijdens de landelijke congresdag infectieziekten worden opgesteld. Daarna zullen er afspraken gemaakt worden over implementatie, de programmatuur en het testen in een van de zeven regio’s. Tevens zal er een gesprek met bestuurders worden voorbereid en georganiseerd.

JD 250403

Aanwezig 13 maart 2003 Acha Automation B.V. ALCA Systems B.V. ALCA Systems B.V. ALCA Systems B.V. Ensemble Gemeente Den Haag, Dienst OCW, GGD GG&GD Amsterdam GG&GD Amsterdam GGD Flevoland GGD Flevoland GGD Hart voor Brabant

de heer N. de Ruyter mevrouw H. Smits de heer A. Bootsma de heer A. Vleugel mevrouw J. Smith de heer E.M. Huisman de heer R. Woudstra mevrouw C. Moree de heer D. Fleury de heer M. van de Geer mevrouw M.A. Brouwer

GGD Nederland GGD Nederland GGD Nederland GGD Nederland GGD Noord- en Midden Limburg GGD Rivierenland GGD Rivierenland GGD Rotterdam e.o. GGD Rotterdam e.o.

de heer M.J. van Keulen de heer G.B. Haringhuizen de heer J. Doosje mevrouw Jambroes de heer M. Verhagen de heer E. van Verseveld mevrouw A.J. Tjaden mevrouw M. Straal de heer M. Dral

57



GGD Twente GGD Twente GGD Zaanstreek-Waterland GGD Zeeland GGD ZO Brababnt GGD Zuidelijk Zuid-Limburg

de heer H.G. Robers mevrouw C. Molenveld de heer J.J. Sierhuis de heer M. Antheunisse mevrouw W. Meijer mevrouw H. Wessels

Bijlage 5. LWA tbc - Onderzoeksrapportage matching dicom

GGD Zuid-Holland Noord Holvast & Partners KNCV Tuberculosefonds KNCV Tuberculosefonds Oldelft Benelux B.V. Oldelft Benelux B.V. PreValent Informatiesystemen B.V.

mevrouw M. van de Zwan de heer J. Holvast de heer J.V. Kuyvenhoven mevrouw C. Erkens de heer F. Lenten de heer M. Verkooijen mevrouw J. van Lieshout

Onderzoek, uitgevoerd door Miranda Brouwer, GGD Hart voor Brabant, Max Anteunissen, GGD Zeeland en Hans van Keulen, GGD Nederland, mede in opdracht van Jan van der Have, HVD Groningen en Marc van de, Geer GGD Flevoland.

RIVM- Rijksinstituut Volksgezondheid en Milieu de heer E. van Straten Van Muilwijk projectmanager de heer F. van Muilwijk

databases, onderzoek naar dubbele screening in de PI. Utrecht, 24 juli 2003

Voor het onderzoek zijn databases met de DICOM headers ontvangen van de volgende GGD’en: HVD Groningen GGD Flevoland GGD Zeeland GGD Hart voor Brabant Er is een beveiligde database samengesteld, deze wordt behouden tot het moment van vaststelling van de onderzoeksresultaten in vergadering LWA tbc.

Samenstelling landelijke VISI werkgroep automatisering (maart 2003) Miranda Brouwer Sytze Keizer Carolien Moree Ans Lohuis Max Anteunissen Maurits Verhagen Marc van de Geer Vincent Kuyvenhoven Nico Kalisvaart George Haringhuizen Hans van Keulen Aart Lodder Jelle Doosje

GGD Hart voor Brabant GG&GD Amsterdam GG&GD Amsterdam GGD Nijmegen GGD Zeeland GGD Noord en Midden Limburg GGD Flevoland KNCV KNCV GGD Nederland GGD Nederland GGD Nederland GGD Nederland

De aangeleverde CD’s zijn vernietigd onder toezicht van Miranda Brouwer, GGD Hart voor Brabant en Max Anteunissen, GGD Zeeland De database is beperkt tot records: • uit de periode van 01-07-2002 t/m 31-3-2003 (9 maanden) • acc-num = ‘gedetineerden’ Database controle: • Ter test is buiten het veld ‘acc-num’ naar term ‘gedetineerden’ gezocht, deze was niet gevonden • groepeer op serie_date AND patient_id met meer dan 1 voorkomen 70 voorkomens gevonden, allen hebben twee records op zelfde serie_date en patient_id • Aantal items geboren op 1-1 (ongeacht geboorte jaar): 686 Representatief aantal met zelfde geboortedag is 57 Items met geboortedag 1-1 of 1-7 eruit gefilterd; van de 20785 records blijven 18920 records over voor het onderzoek Het totaal aantal records waarover in de database is 20785, het aantal records waarover het onderzoek is gedaan is 18920, waarvan 2063x F (11%) en 16857x M (89%) Groepeer op gender=F AND patient_achternaam AND birthdate • 48 combinaties komen tweemaal voor met een record binnen 31 dagen • 110 combinaties komen tweemaal voor met een record voor een periode groter dan 30 dagen en kleiner dan 180 dagen • 3 combinaties komen driemaal voor met een record binnen 31 dagen • 6 combinaties komen driemaal voor met een record voor een periode groter dan 30 dagen en kleiner dan 210 dagen; • 2 combinaties komen viermaal voor met een record voor een periode groter dan 30 dagen en kleiner dan 210 dagen; Samenvattend VROUWEN: 118 records vermoedelijk onterecht (uit de 2063 records van vrouwen maakt 6%)

58

59



Groepeer op gender=M AND patient_achternaam AND birthdate • 1486 combinaties komen tenminste tweemaal voor met een record op het totaal • 568 combinaties komen tweemaal voor met een record binnen 31 dagen (418x) of langer dan 179 dagen (150x) • 713 combinaties komen tweemaal voor met een record voor een periode groter dan 30 dagen en kleiner dan 180 dagen • 32 combinaties komen driemaal voor met een record binnen 31 dagen (8x) of langer dan 210 dagen (24x) • 136 combinaties komen driemaal voor met een record voor een periode groter dan 30 dagen en kleiner dan 210 dagen; • 26 combinaties komen viermaal voor met een record binnen 31 dagen (2x) of langer dan 210 dagen (24x) • 159 combinaties komen meer dan driemaal voor met een record in het bestand (9 maanden), van deze 159 combinaties zijn 70 records vermoedelijk onterecht Samenvattend MANNEN: 919 records vermoedelijk onterecht (uit 16857 records van mannen maakt 5%) Totaal: 18920 records waarvan 1037 records vermoedelijk onterecht maakt 5 %.

Criteria voor kwalificatie ‘onterecht’ Een foto is vermoedelijk onterecht indien: • bij zelfde (patient_achternaam AND birthdate AND gender) • interval tussen voorkomens tussen groter dan 30 en kleiner dan 180 dagen; voor voorkomens die driemaal een fotorecord hebben is er een onzekerheid van naar schatting 16% bij mannen (de drie records verschillen maximaal 210 dagen, voor deze records is niet bekeken hoe groot de onderlinge intervallen zijn). Er is gekozen voor een interval van tenminste 30 dagen, met de volgende redenen: • medisch • client opnieuw aangeboden door medische dienst (onterecht) • overplaatsingen • dubbele archivering Er is gekozen voor een interval van kleiner dan 180 dagen, met de volgende redenen: • beleid op risicogroep

60

61

Advies TBC-Automatisering. Standaardisatie en uitwisseling van gegevensbestanden

Recommend Documents