Versie Doeboek Van zorgproces naar kwaliteitsregistraties met zorginformatiebouwstenen

Transcriptie

1 Versie 0.99 Doeboek Van zorgproces naar kwaliteitsregistraties met zorginformatiebouwstenen

2 Dit Doeboek is geschreven met medewerking van: Organisatie Amsterdam UMC DHD DICA Erasmus MC FMS GGZ Nederland IKNL LUMC MUMC NFU Nictiz NOG NOV NVOG NVPC NVZ Perined Radboudumc Registratie aan de bron UMCG UMCU V&VN ZN 2/84

3 Inhoudsopgave Inleiding Doeboek... 6 Aanleiding... 7 Doel van het Doeboek... 8 Opbouw Doeboek... 9 Vijflagen-interoperabiliteitsmodel... 9 Leeswijzer Doeboek Doorontwikkeling Doeboek Wet- en regelgeving; Kaders & richtlijnen Inleiding Wet- en regelgeving Overzicht Enkele aandachtspunten voortkomend uit Wet- en regelgeving Richtlijnen & zorgproces Overzicht Enkele aandachtspunten voortkomend uit Richtlijnen & zorgproces Standaarden Overzicht Enkele aandachtspunten voortkomend uit Standaarden Gebruik van zorginformatiebouwstenen en de Basisgegevensset Zorg Inleiding Zorginformatiebouwstenen Instantiatie van een zib Basisgegevensset Zorg Wat te doen als kwaliteitsregistratie? Analyse datadictionary kwaliteitsregistratie Inleiding Doel van het analysebestand Uitleg analysebestand Globale indeling Uitleg per kolom Werkwijze voor analyse Algemeen /84

4 3.4.2 Stappenplan analyse Data niet geheel conform zibs, maar wel hiervan afleidbaar Inleiding Gegevens "niet conform zib" Bewerking: extractie en afleiding Extractieregels: om de juiste zib uit een informatiesysteem te selecteren Afleidingsregels: om de variabele af te leiden uit (een combinatie van) dataelementen Voorbeelden van afwijkingen van zib-dataelementen Variabele geheel conform zib-dataelement Datatype niet conform zib-dataelement Code-/waardelijsten niet conform zib-dataelement Definitie niet conform zib Meerdere dataelementen uit één zib nodig om variabele te kunnen afleiden Dataelementen uit meer dan één zib nodig om variabele te kunnen afleiden Overige situaties Data niet conform zorginformatiebouwstenen Inleiding Check op aansluiting op zorgproces Klinische relevantie Belang voor meten van kwaliteit Afleidbaarheid van andere gegevens Uitvraag elders De uitvraag van gegevens vormgeven Stap Stap Stap Stap Kandidaat-zibs Mogelijke situaties met betrekking tot een gegeven Uitleg beslispunten Uitkomsten Het realiseren van een technisch format en een technische implementatie Inleiding /84

5 6.2 Mapping op communicatiestandaarden HL7 CDA en FHIR HL7 CDA (Clinical Document Architecture) HL7 FHIR (Fast Healthcare Interoperability Resources) Uitwisseling op basis van HL7 CDA of FHIR Uitwisselingsmechanismen Samenstellen van een specificatie Bewerken van de data vanuit de communicatiestandaard Beheerafspraken kwaliteitsregistraties Inleiding Wijzigingen in het zorgproces Aanbevelingen ten aanzien van beheerafspraken Wijzigingen in gebruike standaarden (zibs) Aanbevelingen ten aanzien van beheerafspraken Wijzigingen in aanleverende systemen van zorginstellingen Aanbevelingen ten aanzien van beheerafspraken Wijzigingen in gebruikte HL7 CDA-templates of FHIR-profielen Aanbevelingen ten aanzien van beheerafspraken Wijzigingen in wet- en regelgeving Aanbevelingen ten aanzien van beheerafspraken Bijlage 1 Overzicht betrokken partijen Bijlage 2 Afbeelding analysebestand Bijlage 3 Uitleg per kolom Grijs: Eigen toevoeging Blauw: Datadictionary kwaliteitsregistratie Groen: Zibs en BgZ Oranje: Van zibs naar KR Geel: Vragen en actiepunten Paars: Zorgproces Roze: Epd /84

6 Inleiding Doeboek Inhoudsopgave Inleiding Doeboek Inleiding Doeboek... 6 Aanleiding... 7 Doel van het Doeboek... 8 Opbouw Doeboek... 9 Vijflagen-interoperabiliteitsmodel... 9 Leeswijzer Doeboek Doorontwikkeling Doeboek /84

7 Aanleiding De curatieve zorg in Nederland kent anno 2018 ruim 100 landelijke zorginhoudelijke registraties 1, waarvan circa de helft (landelijke) kwaliteitsregistraties zijn. Deze kwaliteitsregistraties zijn een belangrijke factor in de door de ziekenhuizen ervaren grote administratieve lastendruk. Het is geen geheim dat de ziekenhuizen de administratieve lastendruk waar mogelijk willen te reduceren. Een van de oplossingen in dit kader is de kwaliteitsregistraties goed te laten aansluiten op het zorgproces en op de landelijke standaarden in de zorg (zoals de zibs en BgZ) volgens de principes van Registratie aan de bron (i.c. eenduidige vastlegging voor meervoudig gebruik). Daarmee worden de registratielasten structureel beperkt. In 2017 zijn vijf versnellingstrajecten vanuit het programma Registratie aan de bron gerealiseerd op basis van de zibs. Hierbij is aangetoond 2 dat zorginformatie die binnen het zorgproces eenduidig is vastgelegd in het epd, goed hergebruikt kan worden voor aanleveringen aan de diverse kwaliteitsregistraties. Deze positieve uitkomsten hebben de weg geëffend om deze wijze van aanleveren van data aan kwaliteitsregistraties verder vorm en inhoud te geven. In 2017 heeft de NFU een visiedocument rond kwaliteit uitgebracht 3. Vanuit deze visie dient de administratiedruk geminimaliseerd te worden en de gegevenskwaliteit optimaal te zijn, uitgaande van de principes van Registratie aan de bron. Deze visie wordt ook onderschreven door de NVZ en FMS. Het Doeboek draagt hieraan bij door een praktische vertaalslag van de gestelde doelen van dit visiedocument te bieden. 1 Overzicht landelijke zorginhoudelijke registraties NVZ november 2017; 2 Eindrapportage projecten Registraties aan de bron in het jaar van de Transparantie; 3 NFU Visiedocument Meer waarde voor de patiënt ; 7/84

8 Doel van het Doeboek In toenemende mate benaderen organisaties verantwoordelijk voor de kwaliteitsregistraties en de wetenschappelijke verenigingen het programma Registratie aan de bron met de vraag op welke wijze zij het beste invulling kunnen geven aan de principes ervan. De centrale vraag is hoe zij hun dataset zo kunnen vormgeven, dat deze voldoet aan de landelijke standaarden (zibs/bgz)? Het doel van dit Doeboek is om een handleiding te bieden aan de kwaliteitsregistraties om te komen tot een optimale dataset op basis van de principes van eenmalig, eenduidig vastleggen voor meervoudig gebruik. Uit de versnellingsprojecten is naar voren gekomen 4 dat het nodig is om een gezamenlijke aanpak voor opschaling te ontwikkelen. In samenwerking met alle betrokken partijen is daarom dit Doeboek ontwikkeld. Het ondersteunt kwaliteitsregistraties bij het zetten van stappen op weg naar een gegevensuitvraag die in lijn is met de landelijke standaarden en uitgangspunten. Deze aanpak sluit aan bij de beweging in de (curatieve) zorg om te komen tot gestructureerd en gestandaardiseerd (eenheid van taal) vastleggen van zorginformatie. Er zijn in dit kader diverse VIPP-programma's (Versnellingsprogramma Informatie-uitwisseling Patiënt en Professional) 5 gestart. Een belangrijke doelstelling van VIPP is het implementeren van standaarden als SNOMED CT en zorginformatiebouwstenen, met als eerste de zibs van de BgZ. In het Doeboek wordt de werkwijze beschreven hoe te komen tot een registratie die aansluit bij de principes van Registratie aan de bron, te weten: Het zorgproces staat centraal; Gegevens worden tijdens het zorgproces eenduidig vastgelegd; Het verzamelen van gegevens voor andere doeleinden dan het zorgproces brengt geen extra registratielast met zich mee; Gegevens kunnen worden aangeleverd/uitgewisseld conform zibs; De eenduidig vastgelegde gegevens kunnen worden gebruikt voor zorgverlening, kwaliteitsregistraties en wetenschappelijk onderzoek (meervoudig gebruik). Het Doeboek richt zich op zowel nieuwe als bestaande registraties. Daarnaast creëert het Doeboek helderheid over het moment van gebruik van de bestaande (en nog te ontwikkelen) kaders en/of richtlijnen. In het volgende hoofdstuk volgt een leeswijzer met uitleg over lezen en gebruiken van dit Doeboek VIPP ziekenhuizen; VIPP ZKN; VIPP ggz; 8/84

9 Opbouw Doeboek De hoofdstukken van dit Doeboek zijn geschreven in overeenstemming met de volgorde van de lagen van het interoperabiliteitsmodel 6. Hieronder wordt dit model kort toegelicht. Daarna volgt een visuele weergave van de opbouw van het Doeboek in relatie tot de lagen uit dit model. Vijflagen-interoperabiliteitsmodel Voor de architectuur van vastleggen en uitwisselen van zorginformatie wordt algemeen uitgegaan van het vijflagen-interoperabiliteitsmodel (of -architectuurmodel), zoals beschreven door Nictiz. Een goed ingerichte architectuur ontstaat door afspraken te maken op alle niveaus in de organisatie met alle betrokkenen, dus van de infrastructuur tot aan het beleid. Figuur 1 Vijflagen-interoperabiliteitsmodel 6 Interoperabiliteitsmodel; 9/84

10 Figuur 2 Indeling Doeboek in relatie tot het vijflagen-interoperabiliteitsmodel 10/84

11 Leeswijzer Doeboek Of het nu gaat om een bestaande of een nieuwe registratie, het is aan te raden om de hoofdstukken opeenvolgend te lezen en te gebruiken, omdat in de diverse hoofdstukken wordt terugverwezen naar eerder beschreven informatie. Hoofdstuk 1 geeft in het kort informatie over relevante wet- en regelgeving, kaders en richtlijnen. Ook wordt de relatie met het zorgproces benoemd. Hoofdstuk 2 behandelt de beschikbare documentatie over het gebruik van zorginformatiebouwstenen en de Basisgegevensset Zorg. Hoofdstukken 3 t/m 5 behandelen de eigenlijke uitvoering van een analyse van een datadictionary. In het Doeboek ligt de focus op datadictionaries van kwaliteitsregistraties maar de analyse zou ook op andere gegevensverzamelingen uitgevoerd kunnen worden. Hoofdstuk 3 geeft uitleg over het uitvoeren van een analyse van de datadictionary van een kwaliteitsregistratie ten opzichte van de zibs en de BgZ. Dit gebeurt aan de hand van een analysesjabloon in Excel 7. Dit sjabloon is een onderdeel van dit Doeboek. In Hoofdstuk 4 wordt nadere uitleg gegeven hoe gevraagde gegevens van zibs kunnen worden afgeleid als ze niet 1 op 1 overeenkomen met een dataelement van een zib. Dit kan om verdere bewerkingen vragen. Hoofdstuk 5 beschrijft de situatie dat voor een gevraagd gegeven geen zib-dataelement gevonden kan worden. Er worden verschillende manieren benoemd hoe hiermee om te gaan. Hoofdstuk 6 geeft uitleg over hoe de dataset technisch uitgevraagd en aangeleverd kan worden, nadat de dataset is geharmoniseerd met de standaarden, uitgaande van het zorgproces. Hierin komt ook de rol van een eventuele verwerker aan de orde. Hoofdstuk 7 bevat adviezen voor beheerafspraken van een registratie van de betreffende datadictionary en sluit deze eerste versie van het Doeboek af. Doel is om aangesloten te blijven op nieuwe ontwikkelingen in het zorgproces, de (zib)standaarden of de eigen datadictionary. Bijlage 1 geeft een overzicht van de relevante partijen/actoren bij de in dit Doeboek beschreven activiteiten. Bijlage 2 bevat een afbeelding van het analysesjabloon. Bijlage 3 geeft gedetailleerde uitleg over de kolommen uit het analysesjabloon. 7 Sjabloon analyse kwaliteitsregistratie v1.0 11/84

12 Doorontwikkeling Doeboek Dit is versie 0.99 van het Doeboek. Deze versie gaat de komende maanden in de praktijk gebruikt en getest worden. Daaruit zullen diverse bevindingen volgen, die moeten leiden tot aanpassing en verbetering van dit document. Op basis daarvan zal een nieuwe versie geschreven worden waarin alle feedback en verbeterpunten zullen worden opgenomen. 12/84

13 1 Wet- en regelgeving; Kaders & richtlijnen Inhoudsopgave hoofdstuk 1 1 Wet- en regelgeving; Kaders & richtlijnen Inleiding Wet- en regelgeving Overzicht Enkele aandachtspunten voortkomend uit Wet- en regelgeving Richtlijnen & zorgproces Overzicht Enkele aandachtspunten voortkomend uit Richtlijnen & zorgproces Standaarden Overzicht Enkele aandachtspunten voortkomend uit Standaarden... 20

14 14/84

15 1.1 Inleiding Zorginhoudelijke kwaliteitsregistraties hebben als doel de kwaliteit van zorg te monitoren en te verbeteren. In dit Doeboek geven we richtlijnen voor het doorontwikkelen of opzetten van een registratie op basis van standaarden. Behalve met deze standaarden moet een registratie ook rekening houden met kaders in de vorm van richtlijnen, wet- en regelgeving. In dit hoofdstuk noemen wij enkele aspecten uit de betreffende kaders die voor het Doeboek van belang zijn. Hierbij wordt voor specifieke uitleg en invulling verwezen naar de brondocumentatie. 1.2 Wet- en regelgeving Overzicht Dossierplicht Zorgverleners zijn vanuit de Wet op de geneeskundige behandelingsovereenkomst (WGBO) 8 verplicht om een medisch dossier van een patiënt bij te houden. Een groot aantal zorginhoudelijke gegevens wordt dus al in dit kader vastgelegd. Om extra registratielast te minimaliseren wordt aan kwaliteitsregistraties gevraagd de uitvraag zoveel mogelijk te baseren op data die al binnen het zorgproces worden vastgelegd. De wettekst van de WGBO is hier te vinden. Op bijvoorbeeld de site van de KNMG staat nog nadere informatie over (implementatie van) de WGBO. Privacy Met ingang van 25 mei 2018 is de Algemene verordening gegevensbescherming (AVG) 9 van kracht. Aangezien kwaliteitsregistraties veelal bijzondere persoonsgegevens verzamelen moeten zij rekening houden met deze wet. Voor alle betrokkenen in de zorg en het sociale domein is de AVG- Helpdesk voor Zorg en Welzijn 10 opgericht. Hier is gevalideerde informatie over de vraagstukken rond en gevolgen van deze wet te vinden, ook specifiek voor kwaliteitsregistraties. Er is ook een Handleiding Algemene verordening gegevensbescherming 11, waarin uitgelegd wordt wat de AVG betekent voor partijen die persoonsgegevens verwerken. Informatiebeveiliging Zorginstellingen die gebruikmaken van het BSN moeten voldoen aan de NEN7510:2017 Informatiebeveiliging in de zorg 12. Voor veilige uitwisseling van gegevens betreffende de gezondheid van personen wordt in de in paragraaf 3.1 beschreven Leidraad Kwaliteitsregistraties gebruikt gemaakt van een beslisboom, opgesteld door de Regionale Privacy Commissie Gezondheidszorg. Deze beslisboom beschrijft de juiste maatregelen om te komen tot een veilige uitwisseling van medische gegevens /84

16 1.2.2 Enkele aandachtspunten voortkomend uit Wet- en regelgeving Wettelijke grondslag Vooralsnog is en komt er geen generieke, wettelijke grondslag voor kwaliteitsregistraties 13. Reden daarvoor is dat grote verschillen bestaan in type gegevens, processen en de organisatie van kwaliteitsregistraties, waardoor niet eenduidig kan worden aangegeven of aanlevering van (persoons)gegevens aan kwaliteitsregistraties rechtmatig is of niet. Voor elke kwaliteitsregistratie moet deze analyse worden uitgevoerd. Zie hiervoor de hierboven genoemde Handleiding AVG, waarmee aan de hand van stroomschema s kan worden bepaald of de verwerking rechtmatig is. Inzet van een derde partij (verwerker) Als een verantwoordelijke (deelnemer) persoonsgegevens laat verwerken door een derde partij moet de verantwoordelijke partij ervoor zorgen dat de verwerker voldoende waarborgen biedt omtrent technische en organisatorische beveiligingsmaatregelen. E.e.a. dient vervolgens in een verwerkersovereenkomst te worden afgesloten. TIP! Laat de opzet en datadictionary van de registratie beoordelen door een jurist, om te bepalen welke wet- en regelgeving van toepassing is. In het kader van de AVG kan het nodig zijn een Data Protection Impact Assessment (DPIA) uit te voeren /84

17 1.3 Richtlijnen & zorgproces Op dit moment lopen de verschillende zorginhoudelijke kwaliteitsregistraties nog erg uiteen qua omvang en vraagstelling. Dit is mede oorzaak van de grote registratielast. Een instelling (veelal de zorgverlener) moet voor elke registratie apart informatie invoeren, en vergelijkbare variabelen worden vaak op een verschillende manier of met verschillende antwoordopties uitgevraagd. Er zijn diverse richtlijnen met betrekking tot het opzetten (of aanpassen) van kwaliteitsregistraties. Doelen zijn o.a. een betere kwaliteit van de inrichting en uitvoering van kwaliteitsregistraties, meer harmonisatie en meer standaardisatie. Hieronder worden enkele van deze richtlijnen beschreven Overzicht Landelijke voorwaardenkader kwaliteitsregistraties MSZ 14 Dit voorwaardenkader is ontwikkeld door een samenwerkingsverband bestaand uit NVZ, NFU, ZKN, de Federatie Medisch Specialisten, ZN en Patiëntenfederatie Nederland. Het wordt ondersteund door Nictiz en het Zorginstituut Nederland. Dit voorwaardenkader bevat criteria over onder meer relevantie, kwaliteit en bedrijfsvoering van kwaliteitsregistraties. Het voorwaardenkader is te vinden op TIP! Het Zorginstituut stimuleert dat (onderdelen van) informatiestandaarden (her)gebruikt worden. Informatiestandaarden worden in het openbare Register van het Zorginstituut opgenomen als deze voldoen aan de criteria uit het Toetsingskader. Leidraad Kwaliteitsregistraties van het Zorginstituut Nederland en Nictiz 15 Doel van deze leidraad is "het verbeteren van afzonderlijke kwaliteitsregistraties én aan harmonisatie van het registratielandschap". De doelgroep wordt gevormd door alle partijen die betrokken zijn bij het opstellen en doorontwikkelen van kwaliteitsregistraties. Het geeft aanbevelingen voor de belangrijkste organisatorische en inhoudelijke aspecten. Ook het gebruik van standaarden zoals zorginformatiebouwstenen komt hierin aan de orde. Registratie aan de bron 16 Het programma Registratie aan de bron heeft als doel te komen tot eenmalige, eenduidige vastlegging van zorginformatie voor meervoudig gebruik. De binnen het programma ontwikkelde zorginformatiebouwstenen zijn daarbij een middel om eenduidige zorginformatie tot stand te brengen. In Hoofdstuk 2 wordt nadere toelichting gegeven over de zorginformatiebouwstenen. In dit Doeboek is het de bedoeling aan te sluiten bij de principes van het programma, zoals verwoord op de site /84

18 1.3.2 Enkele aandachtspunten voortkomend uit Richtlijnen & zorgproces Zoals hierna in paragraaf 4.1 van dit hoofdstuk wordt vermeld bestaat een informatiestandaard uit een functionele beschrijving van tenminste één concreet zorgproces. In de praktijk kan zo'n beschrijving op verschillende manieren worden gemaakt; van een visuele weergave in een stroomdiagram tot het beschrijven van een zorgpad. Deze documentatie dient te worden gebruikt in het analyseren van het zorgproces voorafgaand aan de analyse van de datadictionary. In deze analyse wordt gekeken naar de elementen die worden vastgelegd in het zorgproces. Zo kan op basis van de uitkomsten van de functionele beschrijving van het zorgproces worden bepaald welke elementen er gebruikt kunnen worden voor een gegevensset/datadictionary voor een kwaliteitsregistratie. In de volgende hoofdstukken wordt deze gegevensset als uitgangspunt genomen voor verdere analyse. Soms kan het zijn dat de gegevensset elementen bevat die (uit historisch oogpunt) niet direct met het daadwerkelijke zorgproces te maken hebben en alleen bedoeld zijn voor registratiedoeleinden. De vraag die dan gesteld dient te worden is of het betreffende element klinisch relevant is in dit zorgproces. Mocht dit niet het geval zijn, dan is de aanbeveling om te bepalen of dit element onderdeel zou moeten uitmaken van het zorgproces. De vragen die bij dit element gesteld kunnen worden komen overeen met de vragen die staan vermeld in Hoofdstuk 5. 18/84

19 1.4 Standaarden Kwaliteitsregistraties kunnen, door gebruik te maken van gegevens die in het primaire proces conform standaarden zijn vastgelegd, de administratieve lasten voor zorgaanbieders beperken. Uitgangspunt is dan ook dat er zoveel mogelijk gebruik wordt gemaakt van beschikbare (inter)nationale standaarden. Hieronder wordt een overzicht gegeven van de belangrijkste standaarden in het kader van het Doeboek Overzicht Zorginformatiebouwstenen 17 en Basisgegevensset Zorg 18 In dit Doeboek gaat het met name om het gebruik van zorginformatiebouwstenen (zibs). Deze worden in Hoofdstuk 2 behandeld. De Basisgegevensset Zorg (BgZ) is een set van 28 zibs. Hoe zibs zich verder verhouden tot de BgZ wordt in Hoofdstuk 2 verder uitgelegd. Informatiestandaarden 19 Een informatiestandaard is een verzameling afspraken die ertoe bijdraagt dat informatie met de juiste kwaliteit kan worden vastgelegd, opgevraagd, gedeeld, uitgewisseld en overgedragen. Informatiestandaarden bestaan uit: 1. een functionele beschrijving van tenminste één concreet zorgproces, of een onderdeel daarvan; 2. een gegevensset voor eenduidige afspraken over de context en semantiek van de uit te wisselen gegevens; 3. terminologie- of codestelsels en classificaties, voor het eenduidig vastleggen en coderen van gegevens; 4. technische specificaties om gegevens uit te wisselen. Op de site van Nictiz is nadere toelichting te vinden over wat informatiestandaarden zijn en hoe ze ontwikkeld worden. Codestelsels In de informatiemodellen van de zibs wordt veelvuldig gebruik gemaakt van (inter)nationale codestelsels, terminologieën, classificaties, coderingsstelsels en standaard gegevenssets, zoals SNOMED CT, de Basisregistratie Personen (BRP) en de DHD Diagnosethesaurus. Door aan te sluiten op deze bestaande standaarden, wordt eenheid van taal gecreëerd waardoor eenduidig vastleggen en meervoudig gebruik mogelijk wordt. Op de site van Nictiz is een uitgebreid overzicht van standaarden in de zorg te vinden. Enkele van de belangrijkste standaarden worden hieronder genoemd. Deze standaarden worden vaak gebruikt of kunnen gebruikt worden door kwaliteitsregistraties. Hieronder worden enkele codestelsels genoemd die veel in de zibs gebruikt worden /84

20 SNOMED CT 20 Internationaal, medisch terminologiestelsel. SNOMED CT bevat een grote verzameling standaardtermen met hun synoniemen en de relaties tussen de termen. SNOMED is met een browser te doorzoeken. LOINC 21 Dit codestelsel heeft als doel om concepten te standaardiseren van laboratoriumaanvragen, laboratoriumuitslagen en klinische begrippen. LOINC is met een browser te doorzoeken. DHD Diagnosethesaurus 22 De diagnosethesaurus is een lijst met klinisch relevante diagnosetermen, gebaseerd op de internationale medische terminologiestandaard SNOMED CT. De DHD ontwikkelt ook een Verrichtingenthesaurus. Deze is echter op dit moment (medio 2018) nog niet in gebruik. Het BIG-Register 23 Het BIG-register (Beroepen in de Individuele Gezondheidszorg) is een Nederlands register waarin het basisberoep is opgenomen van individuen werkzaam in aantal beroepsgroepen in de gezondheidszorg. Het BIG-register geeft duidelijkheid over de bevoegdheid van een zorgverlener. Iedereen kan het BIG-register raadplegen Enkele aandachtspunten voortkomend uit Standaarden Voor de (door)ontwikkeling van een kwaliteitsregister zoals in het Doeboek beschreven is expertise nodig van terminologie- en codestelsels, communicatiestandaarden en datamodellering. Bij Nictiz en Registratie aan de bron kan hierover advies gevraagd worden /84

21 2 Gebruik van zorginformatiebouwstenen en de Basisgegevensset Zorg Inhoudsopgave Hoofdstuk 2 2 Gebruik van zorginformatiebouwstenen en de Basisgegevensset Zorg Inleiding Zorginformatiebouwstenen Instantiatie van een zib Basisgegevensset Zorg Wat te doen als kwaliteitsregistratie?... 27

22 22/84

23 2.1 Inleiding De zorginformatiebouwstenen (zibs) 24 zijn ontwikkeld binnen het programma Registratie aan de bron. Het programma is een initiatief van de universitair medisch centra (umc s) en Nictiz. Aanleiding was enerzijds de wens van de umc's om hun epd's gestructureerd en gestandaardiseerd in te richten anderzijds de visie 25 van het NFU-consortium Kwaliteit van zorg op documentatie en gebruik van zorggegevens. Doel van het programma is om zorginformatie eenduidig, eenmalig vast te leggen aan de bron, voor meervoudig gebruik. Zibs zijn een hulpmiddel om dit mogelijk te maken. Een zorginformatiebouwsteen beschrijft nauwkeurig op welke manier een bepaald zorginhoudelijk concept binnen het zorgproces kan worden vastgelegd. Het is een informatiemodel, waarin zo'n concept wordt beschreven in termen van bijbehorende gegevenselementen, de datatypes en codelijsten van die gegevenselementen etc. In 2013 is de eerste verzameling landelijke zibs vastgesteld. Sindsdien zijn er diverse andere koepels (FMS, V&VN, NVZ) bij het programma gekomen en zijn de zibs doorontwikkeld, ook zijn er nieuwe sets bijgekomen, bv. de verpleegkundige zibs. Op dit moment zijn er ca. 100 landelijke zibs. In de afgelopen jaren is de Basisgegevensset Zorg (BgZ) 26 gedefinieerd. Er is brede interesse in de zorg voor de toepassing van zibs en de Basisgegevensset Zorg (BgZ). Inmiddels zijn diverse partijen er mee aan de slag, zoals de umc s, de algemene ziekenhuizen, organisaties op het gebied van de care en de ggz, de eerste lijn en ook op het gebied van persoonlijke gezondheidsomgevingen (pgo s) is aandacht voor zibs. In dit hoofdstuk wordt een korte toelichting gegeven op nut en noodzaak van de zibs. Ook wordt kort belicht wat het belang van de BgZ in deze context is /84

24 2.2 Zorginformatiebouwstenen De zorgbrede toepassing van het model van de zibs is de basis voor eenheid van taal. Er is sprake van eenheid van taal als gezondheidsinformatie voor de ene zorgverlener dezelfde betekenis of bedoeling heeft als voor de andere wanneer deze informatie (elektronisch) uitgewisseld wordt. Eenheid van taal is geen doel op zich, maar is een hulpmiddel om de zorg voor de (individuele) patiënt te verbeteren en veiliger te maken. Cruciaal daarin is dat informatie gedeeld en hergebruikt kan worden zonder dat het aan betekenis verliest en biedt kansen voor efficiëntie door hergebruik van informatie. Het wordt mogelijk om informatie zorgbreed te delen en uit te wisselen, als de klinische concepten die door zorgverleners gebruikt worden, zorgbreed op dezelfde manier, volgens het model van de zibs, gedefinieerd en vastgelegd worden in de systemen. Zibs vormen daarmee de basis voor semantische interoperabiliteit: de mogelijkheid om op een betekenisvolle manier, d.w.z. zoals nodig voor goede zorg, informatie te delen en uit te wisselen. Inhoudelijke informatie over de zibs is terug te vinden op de wiki van zibs 27. Informatie over de laatste release (2017) is te vinden op Binnen het programma zijn rond de zibs ook architectuurdocumenten geschreven. Deze behandelen in detail de zibs en hun gebruik, de technische implementatie ervan en de toepassing van zibs voor kwaliteitsregistraties: Architectuurdocument Volume 1 De grondbeginselen van zorginformatiebouwstenen en hoe ze gebruikt kunnen worden 28 Architectuurdocument Volume 2 "Technische implementatie van zibs 29 Architectuurdocument Volume 4 De manier waarop zibs gebruikt kunnen worden voor de aanlevering aan registraties Instantiatie van een zib In dit Doeboek wordt meerdere malen gesproken over instantiaties, zodoende hieronder de definitie van een instantiatie. Een zib is een informatiemodel. We spreken van een instantiatie van de zib als er daadwerkelijk gegevens opgeslagen zijn van een bepaalde patiënt conform de specificatie van een zib. Een instantiatie wil dus zeggen dat een bepaald gegeven volgens het zibmodel in een zorginformatiesysteem (zoals een epd) is vastgelegd. Voorwaarde daarvoor is uiteraard dat een informatiesysteem zo ingericht is dat de gegevens ook daadwerkelijk vastgelegd kunnen worden /84

25 2.3 Basisgegevensset Zorg De BgZ is een specifieke toepassing van de zibs, welke bestaat uit een aantal zibs met een gedefinieerde vulling. Het is een gegevensset van patiëntgerelateerde (medische) gegevens waarvan door zorgverleners is bepaald dat die specialisme-, ziektebeeld- en beroepsgroepoverstijgend relevant is, en van belang voor de continuïteit van zorg. De BgZ is te zien als een patient summary, een beknopt klinisch document dat in voorkomende gevallen, gepland en ongepland, door patiënt en zorgverleners, kan worden gebruikt om de continuïteit van zorg te ondersteunen. De BgZ kan dan worden gedeeld of uitgewisseld. Uitwisseling van gegevens is altijd gekoppeld aan een specifieke situatie, de use case, die onderdeel vormt van een bepaald zorgproces. De use case voor de BgZ is dus een andere dan die van kwaliteitsregistraties. De reden om toch de BgZ in dit Doeboek te noemen is dat de zibs die onderdeel zijn van de BgZ als eerste geïmplementeerd worden in de informatiesystemen, voortvloeiend uit de diverse programma's die hier ondersteuning aan geven (o.a. VIPP 31, MedMij 32 ). Als een variabele uitgedrukt kan worden in een (dataelement van) een BgZ-zib, is deze geschikt voor geautomatiseerde uitwisseling tussen informatiesystemen, nadat deze informatiesystemen daarvoor zijn toegerust. Om een duidelijk beeld te geven van de BgZ en dus van de zibs die met voorrang worden geïmplementeerd, staat hieronder een overzicht van de BgZ. Links staan de BgZ-onderdelen per sectie, de kolom Inhoud specificeert de vulling van het BgZ-onderdeel, rechts staan de zibs die bij een onderdeel horen met hun versienummer. Tabel 1 Overzicht BgZ # Sectie # BgZ onderdeel Inhoud Zib Versie 1 Demografie en identificatie 2 Financiële informatie 1.1 Patiëntgegevens NAW-gegevens, BSN, geboortedatum, geslacht, overlijdensinformatie, contactgegevens van de patiënt 1.2 Burgerlijke staat Laatst bekende burgerlijke staat 2.1 Verzekeringsgegevens De verzekeringsgegevens van de patiënt Patient 3.1 BurgerlijkeStaat v3.0 Betaler Behandelrestricties 3.1 Behandelaanwijzingen Bekende BehandelAanwijzing 3.1 behandelaanwijzingen 3.2 Wilsverklaring Bekende wilsverklaring Wilsverklaring Contactpersonen 4.1 Contactpersoon Eerste relatie/contactpersoon 5 Functionele status 5.1 Functionele/mentale Laatst bekende status functionele/mentale status 6 Klachten en diagnoses 6.1 Problemen (incl. diagnoses) Bekende problemen van alle probleemtypen Contactpersoon 3.1 FunctioneleOfMentaleStatus 3.1 Probleem /84

26 # Sectie # BgZ onderdeel Inhoud Zib Versie 7 Sociale anamnese 7.1 Woonsituatie Laatst bekende woonsituatie Woonsituatie Drugsgebruik Bekend drugsgebruik Drugsgebruik Alcoholgebruik Bekend alcoholgebruik Alcoholgebruik Tabakgebruik Bekend tabakgebruik Tabakgebruik Voedingsadviezen Bekende voedingsadviezen Voedingsadvies Waarschuwingen 8.1 Alerts Bekende alerts Alert Allergieën 9.1 Allergie-intoleranties Bekende allergieën AllergieIntolerantie Medicatie 10.1 Medicatieafspraak Bekende medicatieafspraken Medicatieafspraak Medische hulpmiddelen 10.2 Toedieningsafspraak Bekende ToedieningsAfspraak toedieningsafspraken 10.3 Medicatiegebruik Bekend medicatiegebruik MedicatieGebruik Medische hulpmiddelen Bekende medische hulpmiddelen MedischHulpmiddel Vaccinaties 12.1 Vaccinaties Bekende vaccinaties Vaccinatie Vitale functies 13.1 Bloeddruk Laatst bekende bloeddruk Bloeddruk Lichaamsgewicht Laatst bekende lichaamsgew icht 13.3 Lichaamslengte Laatst bekende lichaamslengte 14 Uitslagen 14.1 Laboratoriumuitslagen Bekende klinische chemie bepalingen, laatste uitslag 15 Verrichtingen 15.1 Verrichtingen Bekende operatieve verrichtingen 16 Contacten 16.1 Contacten Bekende ziekenhuisopnames (niet poliklinische contacten) 17 Zorgplan 17.1 Geplande zorgactiviteiten Bekende geplande zorgactiviteiten (medicatietoediening, voorgenomen verrichtingen, voorgenomen verpleegkundige acties, voorgenomen vaccinaties, afspraken, gewenste medische hulpmiddelen, overige) Lichaamsgewicht 3.1 Lichaamslengte 3.1 LaboratoriumUitslag 4.1 Verrichting 4.1 Contact 3.1 OverdrachtGeplande ZorgActiviteit 18 Zorgverleners 18.1 Huisarts De gegevens van de huisarts Zorgverlener /84

27 2.4 Wat te doen als kwaliteitsregistratie? Kennis van de zorginformatiebouwstenen en de BgZ is benodigd om de volgende stap van het Doeboek te kunnen uitvoeren. Om te begrijpen wat zibs en de BgZ inhouden wordt aangeraden om de in dit hoofdstuk vermelde documentatie te bestuderen. Desondanks is het mogelijk dat er nog vragen zijn over de zibs en BgZ. Neem dan contact op met het programma Registratie aan de bron of het zib-centrum van Nictiz 27/84

28 3 Analyse datadictionary kwaliteitsregistratie Inhoudsopgave Hoofdstuk 3 1 Inleiding Doel van het analysebestand Uitleg analysebestand Globale indeling Uitleg per kolom Werkwijze voor analyse Algemeen Stappenplan analyse... 33

29 29/84

30 3.1 Inleiding In dit hoofdstuk leggen we uit hoe een kwaliteitsregistratie een analyse kan uitvoeren ten behoeve van een harmonisatieslag tussen de eigen datadictionary en de zorginformatiebouwstenen (zibs). Voor deze analyse is een sjabloon gemaakt, "Sjabloon analyse kwaliteitsregistratie v1.0". Dit analysebestand wordt in dit hoofdstuk toegelicht. Hoewel het Doeboek zich specifiek richt op analyse van kwaliteitsregistraties, kan dit analysebestand en bijbehorende uitleg ook voor andere datasets gebruikt worden, dit is niet beperkt tot registraties. Uiteindelijk doel is dat kwaliteitsregistraties ingericht worden uitgaande van data die in het zorgproces vastgelegd worden. Door dit zoveel mogelijk op basis van zorginformatiebouwstenen vorm te geven wordt een optimaal efficiënte gegevensuitwisseling gerealiseerd. Zie ook Hoofdstuk 1. Op dit moment zal dit nog niet altijd volledig mogelijk zijn. Deze analyse helpt registraties op weg naar het behalen van dit doel, door de uitvraag zoveel mogelijk te harmoniseren met de zibs. Verdere uitgangspunten bij de analyse zijn: Bekijk bij elke variabele of het aansluit bij het zorgproces, of deze vastgelegd wordt in een van de gebruikte informatiesystemen. Als dat niet het geval is, beoordeel dan of deze variabele echt noodzakelijk is (zie ook Hoofdstuk 5 voor een stappenplan hiervoor). Waar mogelijk is de zib leidend (bv. voor datatype, kardinaliteit). Als mapping bij een variabele mogelijk is, houd dan een mappingtabel bij. Maak waar mogelijk gebruik van codestelsels als SNOMED CT, LOINC en andere (inter)nationale standaarden. Maak zoveel mogelijk gebruik van de waardelijsten, dit bevordert het uniform invullen van het sjabloon voor verschillende use cases. Lees nauwkeurig de toelichting van de verschillende kolommen. 30/84

31 3.2 Doel van het analysebestand In het analysebestand wordt eerst de datadictionary van een kwaliteitsregistratie overgenomen. Vervolgens wordt voor elke variabele 33 gezocht naar een overeenkomstig dataelement van een zib. Dit wordt tot in detail uitgeschreven. Dit leidt voor elke variabele tot uitkomsten met betrekking tot de mate van overeenkomst van de variabele met een zib-dataelement. Dit kan variëren van "helemaal conform zib" tot "geheel niet conform zib", met allerlei tussenvormen. Overigens kan een variabele geheel conform zib zijn, maar kan de context nog tot verschillende interpretaties leiden. Gaat het bijvoorbeeld om een preoperatieve of postoperatieve bloeddrukmeting? Hiermee moet bij de analyse rekening worden gehouden, door zorgverleners en het zorgproces uitdrukkelijk in de analyse te betrekken 34. In Hoofdstuk 4 worden daarnaast voorbeelden gegeven hoe context in sommige gevallen in de analyse uitgedrukt kan worden. Het is verder belangrijk dat een analyse door meerdere mensen, zoals een commissie van inhoudsdeskundigen, methodologen en statistici beoordeeld wordt. Hiervoor kan een redactieraad ingesteld worden. Dit om interpretatieverschillen zichtbaar en bespreekbaar te maken, en eventueel feedback hierop te vragen bij bv. Registratie aan de bron of Nictiz. De analyse resulteert in een overzicht in hoeverre de gegevens die de kwaliteitsregistratie uitvraagt voldoen aan de zibstandaarden, en hoe deze zo ver als mogelijk zibconform gemaakt kunnen worden. Op grond hiervan kunnen dan besluiten over aanpassing van de variabelen genomen worden, bijvoorbeeld: Moet de variabele gehandhaafd blijven? Zeker bij niet-zibconforme variabelen moet deze vraag als eerste beantwoord worden. Ga hierbij primair uit van het zorgproces. En is de variabele een gegeven, dat geregistreerd wordt in het epd/ander informatiesysteem? Kan de variabele ongewijzigd (in vraagstelling en antwoordopties) gehandhaafd blijven? Kan de vraagstelling gewijzigd worden zodat uitvraag wel conform zib gedaan kan worden? Is de variabele zodanig specifiek/uniek dat omzetting naar een zibconforme vraagstelling niet mogelijk is, of te weinig toegevoegde waarde heeft? Bij de besluitvorming moeten de verschillende belanghebbenden betrokken worden, zie hiervoor Hoofdstuk Hier wordt de term "variabele" gebruikt om een gegeven uit de datadictionary van de kwaliteitsregistratie aan te duiden, om dit duidelijk te onderscheiden van de term dataelement, die gebruikt wordt voor dataelementen van zibs. 34 Uiteraard kan een zorgproces variaties vertonen tussen verschillende instellingen. Er zullen dan meerdere zorginstellingen bij een analyse betrokken moeten worden. Zie ook suggesties in Hoofdstuk 5. 31/84

32 3.3 Uitleg analysebestand Globale indeling De verschillende onderdelen zijn in de bovenste rijen met kleur onderscheiden: grijs Zelf toe te voegen informatie over de variabele, bijvoorbeeld een volgnummer of andere informatie om de analyse te vergemakkelijken. blauw De variabelen in de datadictionary met bijbehorende relevante informatie. groen Uitwerking van een variabele in zib. oranje Informatie over de benodigde bewerking tussen zib en variabele, bijvoorbeeld om de juiste instantiatie van de zib in de gevraagde context te selecteren. geel paars roze Vragen, toelichting, actiepunten voortkomend uit de analyse. Informatie over het proces waarbinnen een variabele wordt vastgelegd; dit kan het primaire proces zijn, maar ook financiële of administratieve processen kunnen hier relevant zijn. Informatie over hoe een variabele in een bepaald informatiesysteem vastgelegd wordt. De laatste twee onderdelen hoeven geen onderdeel van de analyse te zijn. Ze kunnen echter wel behulpzaam zijn bij het beoordelen van de relevantie en gewenste wijze van uitvragen van een variabele. Het groene deel voorziet in een mogelijkheid om aan te geven of een variabele/zib onderdeel is van de BgZ. Dit is in zichzelf niet nodig voor de analyse, aangezien de BgZ een specifieke gegevensset van zibs vormt met een ander doel dan kwaliteitsregistraties. De enige reden om aan te geven of een zib binnen de BgZ valt, is het feit dat de zorg bezig is deze zibs met voorrang in de informatiesystemen te implementeren 35. Zibs die onderdeel zijn van de BgZ zullen dus sneller beschikbaar zijn in de systemen dan de andere zibs. Het kan nuttig zijn om hier zicht op te hebben. In het bestand zelf is alvast een voorbeeldindeling in hoofdstukken en secties gegeven, op basis van een bestaande registratie. U kunt dit aanpassen aan de daadwerkelijke indeling van de datadictionary Uitleg per kolom Het analysebestand bevat een tabblad Toelichting. Daarin staat een korte samenvatting van wat elke kolom inhoudt. In Bijlage 3 staat een uitgebreidere toelichting. 35 In het kader van diverse VIPP-regelingen, voor o.a. ziekenhuizen, zelfstandige behandelcentra en de ggz. 32/84

33 3.4 Werkwijze voor analyse Algemeen Kennis van de zibs, en van de principes van Registratie aan de bron (eenduidig, eenmalig vastleggen voor meervoudig gebruik) is nodig om een analyse uit te kunnen voeren. Op is een overzicht te vinden van de beschikbare zibs en hun dataelementen. Hier staan ook links naar de Architectuurdocumenten en de beheerafspraken. Elke zib kan vanaf deze website ook in de vorm van een excelbestand, of als pdf gedownload worden. Verder is er een overzicht van de BgZ beschikbaar. Tip! Neem contact op met het programma Registratie aan de bron of met het Zib-centrum van Nictiz voor experts met kennis over zorginformatiebouwstenen Stappenplan analyse Stap 1 Voeg de datadictionary en het analysebestand samen. De lijst met variabelen van de registratie wordt ingevoegd in het blauwe deel van het tabblad "Sjabloon analyse dataset KR" in het analysebestand. Pas de blauwe kolommen aan naar de feitelijke kolommen van de eigen datadictionary. Een datadictionary kan naast de lijst met variabelen uit meerdere tabbladen bestaan, bv. tabbladen met waardelijsten. Het is aan te bevelen om alle tabbladen met voor de analyse relevante informatie (of de volledige datadictionary) op te nemen in het analysebestand. Soms bestaat een kwaliteitsregistratie uit vergelijkbare onderdelen voor verschillende aandoeningen. Voor elk (sub)onderdeel kan een apart analyse-tabblad aangemaakt worden. Dit komt de overzichtelijkheid ten goede. Alternatief is om voor de verschillende onderdelen een apart bestand aan te maken. Stap 2 Voor elke variabele wordt gezocht naar het zib-dataelement waar het mee overeenkomt. Uit de naam en definitie van een variabele, en vaak ook uit de positie ervan in een bepaalde sectie, kan vaak al afgeleid worden binnen welke zib(s) gezocht moet worden voor overeenkomstige dataelementen. Voorbeeld Als het gaat over administratieve eigenschappen van een patiënt, is de zib Patiënt het logische bijbehorende concept, waarbinnen gezocht kan worden naar het juiste dataelement. En als het over eigenschappen van een aandoening gaat, is de zib Probleem het aangewezen concept. 33/84

34 Stap 3 Schrijf de bijbehorende kolommen t/m Q uit, zodat helder is welk dataelement bij een variabele hoort, inclusief datatypes, codelijsten en kardinaliteit. TIP! Het kan handig zijn om de codelijst van een variabele uit te schrijven, als deze niet te lang is. Dan hoeft er minder geschakeld te worden tussen tabbladen. Voor de zib-dataelementen kan het nuttig zijn om hyperlinks naar de betreffende codelijst op zibs.nl te maken. Voorbeeld: Stap 4 Beoordeel de mate van overeenkomst tussen de variabele en het zib-dataelement. Dit kan in kolom R vastgelegd worden. Globaal kunnen de volgende situaties aan de orde zijn: 1 variabele geheel conform zib-dataelement 2 datatype niet conform zib-dataelement 3 codelijst/waardelijst niet conform codelijst zib-dataelement, of codelijst zib kent (nog) niet de benodigde codes 4 definitie niet conform zib 5 meerdere dataelementen uit één zib nodig om variabele te kunnen afleiden 6 dataelementen uit meer dan één zib nodig om variabele te kunnen afleiden 7 eenvoudige combinatie van voorgaande factoren 8 complexe combinatie van voorgaande factoren 99 variabele kan niet in zib-dataelement uitgedrukt worden 34/84

35 TIP! Het is mogelijk (maar niet noodzakelijk) om deze situaties een "waardering" te geven, om een snel overzicht mogelijk te maken. Bijvoorbeeld: Dit is altijd een globale indruk, soms kan een situatie complex zijn terwijl er toch maar sprake is van één afwijking. Als bijvoorbeeld een registratie een meer gedetailleerde codelijst hanteert dan de zib, is afleiding niet eenvoudig of zelfs niet mogelijk. Stap 5 Vul in kolom S het versienummer van de zib uit waarop de analyse van deze variabele gebaseerd is. Zo kan ook bij toekomstige wijzigingen achterhaald worden wat het uitgangspunt was tijdens de analysefase. Stap 6 Vul in kolom T, indien gewenst, in of de zib onderdeel is van de BgZ. Houd hierbij rekening met het feit dat voor sommige zibs de omschrijving van de BgZ een beperking inhoudt. Bv. de zib Zorgverlener is alleen onderdeel van de BgZ als het om een huisarts gaat. Zie hiervoor het overzicht van de BgZ. Stap 7 Geef in kolom U een inschatting van de mate van complexiteit van de bewerking, bv. als in een eerste stadium nog alleen een algemene indruk gewenst is van de stand van zaken. Dan kan de exacte bewerking in een later stadium in kolom V ingevuld worden. Stap 8 Schrijf in kolom V globaal uit wat voor bewerking nodig is om van de gegevens in een zib te komen tot het uiteindelijke antwoord op de gevraagde variabele. In Hoofdstuk 4 wordt verdere uitleg gegeven over de stappen die daarvoor genomen moeten worden. Het is mogelijk dat er meerdere regels in de spreadsheet nodig zijn voor het afleiden van een variabele (zie bv. situatie 5 en 6 in Stap 4). Benoem dan in de eerste regel (op gelijke hoogte met de variabele) het dataelement dat uiteindelijk (het meest) overeenkomt met het gewenste gegeven. Zie voor verdere uitleg Hoofdstuk 4. Als een bewerking zeer complex zou worden, moet bekeken worden of de variabele wel op deze wijze uitgevraagd moet blijven worden, of dat er alternatieve vraagstellingen mogelijk zijn. 35/84

36 Stap 9 Uit het totale bestand kunnen nu diverse conclusies getrokken worden: Welk deel van de variabelen is in zibs uit te drukken? Welk deel van de variabelen is in dataelementen van de zibs uit de BgZ uit te drukken? Welke zibs/bgz-onderdelen worden in deze registratie gebruikt? Voor welk deel van de variabelen is geen zib beschikbaar? Hoe complex is afleiding van de variabelen van zib-dataelementen? Zijn er variabelen die onvoldoende eenduidig gedefinieerd zijn? Zijn er variabelen die beter geformuleerd kunnen worden, op basis van de zibmodellen? Deze conclusies kunnen nu verwerkt worden in een rapport met aanbevelingen voor aanpassing van de registratie zodat deze beter aansluit op standaarden zoals de zibs. Niet voor alles zal een zib of zib-dataelement bestaan, en ook zal dit niet in alle gevallen nodig of nuttig zijn. Overleg hierover met Nictiz of Registratie aan de bron is dan wel wenselijk, zodat hierover eenduidige besluiten kunnen worden genomen 36/84

37 4 Data niet geheel conform zibs, maar wel hiervan afleidbaar Inhoudsopgave Hoofdstuk 4 4 Data niet geheel conform zibs, maar wel hiervan afleidbaar Inleiding Gegevens "niet conform zib" Bewerking: extractie en afleiding Extractieregels: om de juiste zib uit een informatiesysteem te selecteren Afleidingsregels: om de variabele af te leiden uit (een combinatie van) dataelementen Voorbeelden van afwijkingen van zib-dataelementen Variabele geheel conform zib-dataelement Datatype niet conform zib-dataelement Code-/waardelijsten niet conform zib-dataelement Definitie niet conform zib Meerdere dataelementen uit één zib nodig om variabele te kunnen afleiden Dataelementen uit meer dan één zib nodig om variabele te kunnen afleiden Overige situaties... 51

38 38/84

39 4.1 Inleiding Hoofdstuk 4 volgt op de uitkomsten van Hoofdstuk 3, Analyse datadictionaries. Uit deze analyse zijn diverse gegevens naar voren gekomen die wel van zorginformatiebouwstenen af te leiden zijn, maar niet 1 op 1. In kolom U van het analysebestand is gebleken dat voor deze gegevens afleiding of bewerking nodig is. Zoals in Hoofdstuk 1, Kaders en Richtlijnen al is benoemd moeten vragen in een kwaliteitsregistratie in principe aansluiten op gegevens die al in het zorgproces worden vastgelegd. Zeker bij gegevens die niet volledig conform bouwstenen zijn af te leiden verdient het aanbeveling om nut en noodzaak van deze gegevens opnieuw te beoordelen, voordat overgegaan wordt op het schrijven van regels om e.e.a. af te leiden. Zie hiervoor Hoofdstuk 1. Dit hoofdstuk beschrijft mogelijkheden voor het afleiden van gegevens die niet geheel conform zibs zijn. 39/84

40 4.2 Gegevens "niet conform zib" Zoals in het Stappenplan Analyse in Hoofdstuk 3 is benoemd kan in kolom R een eerste beoordeling gegeven worden van de mate van overeenkomst van een variabele met de zibs. De volgende situaties werden daarin onderscheiden: 1 variabele geheel conform zib-dataelement 2 datatype niet conform zib-dataelement 3 codelijst/waardelijst niet conform codelijst zib-dataelement, of codelijst zib kent (nog) niet de benodigde codes 4 definitie niet conform zib 5 meerdere dataelementen uit één zib nodig om variabele te kunnen afleiden 6 dataelementen uit meer dan één zib nodig om variabele te kunnen afleiden 7 eenvoudige combinatie van voorgaande factoren 8 complexe combinatie van voorgaande factoren 99 variabele kan niet in zib-dataelement uitgedrukt worden In paragraaf 4.4 worden de verschillende situaties besproken, en waar mogelijk van voorbeelden voorzien. De laatste situatie (99) zal verder besproken worden in Hoofdstuk 5. 40/84

41 4.3 Bewerking: extractie en afleiding Bij de verschillende besproken situaties is enige vorm van bewerking nodig om te komen tot de gevraagde variabele. De in de voorbeelden gegeven bewerkingsregels zijn een manier om zo'n regel te beschrijven. Het is in gewoon Nederlands geschreven, dus geen formele methode. Ieder is vrij om dit naar eigen inzicht vorm te geven al is het wenselijk om het zodanig op te schrijven dat voor iedereen inzichtelijk is wat er bedoeld wordt. De bedoelde regels dienen uiteindelijk herschreven te worden in code die geschikt is voor het betreffende informatiesysteem. Er kunnen twee soorten bewerkingen nodig zijn: extractie en afleiding. Deze worden hieronder toegelicht. In de voorbeelden wordt met E of A aangegeven of een bewerking een extractie- of een afleidingsregel betreft Extractieregels: om de juiste zib uit een informatiesysteem te selecteren Extractieregels zijn vaak van toepassing in gevallen waarin enige context nodig is. Dus niet eenvoudig "wat is het gewicht van de patiënt", maar "wat is het gewicht van de patiënt gemeten maximaal 3 maanden voor de operatie". Uit de verschillende instantiaties van de zib Lichaamsgewicht moet dan de juiste geselecteerd worden. Het is niet altijd mogelijk om op basis van dergelijke beslisregels een selectie te maken. Bijvoorbeeld omdat de set aan regels te complex zou worden, of omdat de juiste selectie de klinische blik van een zorgverlener vergt. In zo'n geval zal een variabele niet automatisch aangeleverd kunnen worden, maar is een handmatige invulling nodig. Wel kan het soms mogelijk zijn om vanuit het systeem de beschikbare opties aan te bieden waar de zorgverlener dan een selectie uit maakt. Extractieregels worden in principe toegepast bij de extractie van gegevens uit het bronsysteem binnen de aanleverende zorginstelling Afleidingsregels: om de variabele af te leiden uit (een combinatie van) dataelementen Soms is afleiding nodig, bijvoorbeeld als datatype of codelijsten verschillen, of als er meerdere dataelementen nodig zijn om één variabele af te leiden. Afleidingsregels worden in principe bij de kwaliteitsregistratie zelf toegepast, mits de registratie een grondslag heeft om de benodigde variabelen uit te vragen. Ook moeten de beschikbare gegevens voldoende context bieden om de juiste afleiding te kunnen doen, tenzij er geen nadere context nodig is. Bij het formuleren van bewerkingsregels tijdens de analyse moet hier rekening mee gehouden worden. Het kan voorkomen dat de afleiding toch binnen de aanleverende instelling gedaan moet worden. 41/84

42 4.4 Voorbeelden van afwijkingen van zib-dataelementen Variabele geheel conform zib-dataelement De eerste situatie spreekt voor zich, het gegeven kan gewoon gehandhaafd blijven. Voorbeeld Variabele geheel conform zib-dataelement geboortedatum: Registratie: format gespecificeerd als DD-MM-YYYY. Zib Patient dataelement Geboortedatum, datatype TS = timestamp. Ø Actie: geen, datatype TS kan naar wens gespecificeerd worden. Voorbeeld Variabele geheel conform zib-dataelement geopereerde zijde: Registratie: antwoordopties right; left. Zib Verrichting dataelement VerrichtingLateraliteit, codelijst Links; Rechts; Rechts en links. Ø Actie: geen, alle gewenste antwoordopties in de registratie worden gedekt door de opties in de zib. Hieronder gaan we nader in op situaties 2 t/m 8. 42/84

43 4.4.2 Datatype niet conform zib-dataelement Vaak zijn dergelijke gegevens makkelijk af te leiden, maar dit is o.a. afhankelijk van zaken als context. Voorbeeld Datatype niet conform zib-dataelement rookgedrag Registratie vraagt of patiënt rookt, antwoordopties zijn ja/nee; datatype is BL, Boolean. Zib TabakGebruik, dataelement TabakGebruikStatus met TabakGebruikStatusCodelijst; datatype is CD, Coded Descriptor. Ø Actie: Afleiding van de in de zib vastgelegde code naar het juiste antwoord. Ø Bewerking (Afleiding): Rookt dagelijks ja Rookt soms ja Rookt passief nee Ex-roker nee Niet-roker, rookgedrag verleden onbekend nee Nooit gerookt nee Anders nee Merk op dat in dit geval door de mapping informatie verloren gaat: de door de registratie gevraagde informatie is minder gedetailleerd dan de opties in de zib. Ook kan verschillend gedacht worden over de wijze van mapping: moet passief roken wel of niet als roken beschouwd worden? Hetzelfde geldt voor de antwoordoptie "Anders". Voorbeeld Datatype niet conform zib-dataelement gewicht Registratie vraagt "gewicht in kg"; Datatype is INT, Integer. Zib Lichaamsgewicht dataelement GewichtWaarde verwacht een antwoord als "76 kg", dus waarde + eenheid; Datatype is PQ, Physical Quantity. Ø Actie: Afleiding van het getalelement in de zib naar het gevraagde gegeven. Ø Bewerking (Afleiding). NB: Hier wordt alleen de afleiding van de gewichtwaarde sec gegeven. Vaak zal contextinformatie van belang zijn, bijvoorbeeld wanneer het gewicht is gemeten. Dan zal een extra dataelement nodig zijn voor een correcte afleiding. Zie hiervoor ook situatie 5. 43/84

44 4.4.3 Code-/waardelijsten niet conform zib-dataelement Hierbij kunnen gegevens vaak makkelijk afgeleid worden, behalve als de codelijst van de registratie gedetailleerder is dan die van de zib, of als de codelijst van de zib de gevraagde waarden niet kent. In het laatste geval kan gekeken worden of de benodigde waarden opgenomen kunnen worden in de zib-codelijst, bijvoorbeeld in SNOMED CT. Voorbeeld Codelijst/waardelijst niet conform zib-dataelement diagnose Registratie heeft eigen codelijst met 5 gespecificeerde diagnoses en een optie "anders" Zib Probleem dataelement ProbleemNaam, codelijst is SNOMED CT. Ø Actie: Mapping van codelijst zib naar door registratie gehanteerde codelijst. Voorbeeld Codelijst/waardelijst niet conform zib-dataelement specialisme Registratie onderscheidt twee uitgeschreven specialismen, orthopaedics en trauma surgery Zib Verrichting dataelement Uitvoerder heeft als codelijst Vektis AGB-medische specialismen of UZI RoleCodeNL. Ø Actie: Mapping van codelijst zib naar door registratie gehanteerde codelijst. Ø Bewerking (Afleiding). Ø Actie: Alter Alternatief is dat de registratie de AGB- of UZI-codes voor deze twee specialismen overneemt als antwoordoptie. Voorbeeld Codelijst/waardelijst niet conform zib-dataelement Charnley score Registratie vraagt naar de "Charnley score". Dit zou vast te leggen zijn met de zib AlgemeneMeting en de dataelementen MetingNaam (Charnley score) en UitslagWaarde (A, B1, B2, C, n.v.t.). SNOMED CT kent echter niet het concept Charnley score, en ook niet de bijbehorende uitslagwaarden. Ø Actie: Bij Nictiz (nationaal release center voor SNOMED CT) betreffende concepten/codes aanvragen. 44/84

45 4.4.4 Definitie niet conform zib Hierbij kan het nodig zijn om meer dataelementen (mogelijk van meerdere zibs) te betrekken in de afleiding. Voorbeeld Definitie niet conform zib-dataelement samenlevingsverband Registratie vraagt naar samenlevingsverband van patiënt, en onderscheidt daarin opties als getrouwd, gescheiden, geregistreerd partnerschap maar ook samenwonend en latrelatie. Zib BurgerlijkeStaat heeft als definitie " Burgerlijke staat is de formele positie van een mens in de zin en betekenis van het burgerlijk wetboek. Te onderscheiden vallen huwelijkse staat en partnerregistratie (geregistreerd partnerschap). Zib Gezinssituatie, dataelement Gezinssamenstelling beschrijft "de thuissituatie van de patiënt en de samenlevingsvorm. De bijbehorende codelijst kent ook "samenwonend" en "Alleenwonend". Ø Actie: De gevraagde antwoorden zouden uit meerdere zib-dataelementen afgeleid moeten worden. Voor latrelatie moet dan besloten worden of de optie "Alleenwonend" hier voldoende aan voldoet (eventueel in combinatie met zib Contactpersoon, dataelement Relatie = Partner). Ø Bewerking (Afleiding). Ø Actie: De registratie kan ook overwegen de vraagstelling aan te passen. Voorbeeld Definitie niet conform zib-dataelement zorgomgeving Registratie vraagt naar alle relevante zorgverleners rond een patiënt en benoemt hierbij ook geestelijk verzorger en maatschappelijk werker. Zib Zorgverlener, codelijst van dataelement Specialisme kent deze rollen niet; deze rollen lijken dus niet onder de definitie van Zorgverlener te vallen. Ook zib Contactpersoon, dataelement Rol kent deze typen zorgverlener niet. Ø Actie: Onderzoeken of deze rollen nodig zijn. Zo nodig voorstel indienen om deze rollen in de codelijsten op te laten nemen. De codelijst van zib Zorgverlener is overigens een nationale lijst, daarbij zou gekeken moeten worden of wijziging überhaupt mogelijk is. 45/84

46 Voorbeeld Definitie niet conform zib-dataelement comorbiditeit Registratie vraagt naar comorbiditeiten, bv. cardiologische comorbiditeit. Zib Probleem, ProbleemNaam geeft wel naam aandoening, maar definieert niet of dit (vanuit een bepaald kader bezien) de hoofdaandoening is of een comorbiditeit. Verschillende keuzes mogelijk: alle Problemen met ProbeemType diagnose uitvragen, en aan de verwerkerskant de logica te leggen dat het om bv. cardiale comorbiditeit gaat. Of de logica kan aan de kant van de aanleverende partij liggen om diagnoses aan te leveren die van de gevraagde categorie aan te leveren. Ø Actie: Onderzoeken wat de gewenste/best bruikbare oplossing is Meerdere dataelementen uit één zib nodig om variabele te kunnen afleiden In deze gevallen is soms eenvoudige mapping afdoende, soms zijn ook complexere bewerkingsregels nodig. In veel gevallen zijn meerdere dataelementen nodig voor de selectie van de gewenste zib. TIP Als er meerdere regels nodig zijn om een bewerking uit te schrijven, schrijf dan als eerste (op dezelfde regel als de gevraagde variabele) het dataelement dat uiteindelijk (het meest) overeenkomt met het gewenste gegeven. Bij het voorbeeld van de ASA-score dus eerst UitslagWaarde en dan MetingNaam. Dat bevordert de consistentie van het invullen van een analysebestand. 46/84

47 Voorbeeld Meerdere dataelementen uit één zib nodig om variabele te kunnen afleiden behandeld lichaamsdeel Registratie vraagt welk oog geopereerd is, en heeft als codelijst rechteroog en linkeroog. Hiervoor zijn dataelementen VerrichtingAnatomischeLocatie en VerrichtingLateraliteit uit zib Verrichting nodig. Ø Actie: Combineren van beide dataelementen tot de gevraagde enkelvoudige variabele. Ø Bewerking (Afleiding): ALS VerrichtingAnatomischeLocatie = SNOMED-code structuur van oculus EN VerrichtingLateraliteit = Rechts DAN Gevraagde variabele = rechteroog Voorbeeld Meerdere dataelementen uit één zib nodig om variabele te kunnen afleiden ASA-score Registratie vraagt naar de ASA-score. Hiervoor zijn dataelementen UitslagWaarde en MetingNaam uit zib AlgemeneMeting nodig. Ø Actie: Combineren van beide dataelementen tot de gevraagde enkelvoudige variabele. Ø Bewerking (Extractie en Afleiding): ALS MetingNaam = SNOMED-code American Society of Anesthesiologist physical status classification (assessment scale) DAN UitslagWaarde = gevraagde variabele Ø Toelichting: Met de MetingNaam wordt de juiste zib-instantiatie uit het informatiesysteem geëxtraheerd. Aan de kant van de kwaliteitsregistratie wordt uit de combinatie MetingNaam en UitslagWaarde de variabele afgeleid. Ook daar is de MetingNaam nodig, omdat er meerdere zib-instantiaties van AlgemeneMeting kunnen zijn doorgestuurd. 47/84

48 Voorbeeld Meerdere dataelementen uit één zib nodig om variabele te kunnen afleiden datum laatste polibezoek Registratie vraagt naar datum eerste bezoek aan poli heelkunde. Hiervoor zijn vier dataelementen uit zib Contact nodig. ü Actie: Combineren van alle dataelementen tot de gevraagde enkelvoudige variabele. Ø Bewerking (Extractie en Afleiding): ALS ContactMet Zorgverlener, Specialisme = 0303, Medisch specialisten, chirurgie EN ContactType = Poliklinisch EN RedenContact Probleem, ProbleemNaam = code voor betreffende aandoening EN BeginDatumTijd = meest recente van alle zib-instantiaties van dit type DAN BeginDatumTijd = gevraagde variabele Ø Toelichting: Met de verschillende dataelementen wordt de juiste zib-instantiatie uit het informatiesysteem geëxtraheerd. Aan de kant van de kwaliteitsregistratie wordt uit de combinatie van de verschillende elementen de variabele afgeleid. De vraag is wel of het bepalen van de "meest recente" instantiatie bij de extractie, of aan de kant van de registratie moet plaatsvinden. 48/84

49 4.4.6 Dataelementen uit meer dan één zib nodig om variabele te kunnen afleiden. Ook hierbij gaat het vaak om extra informatie die nodig is om de juiste zib te kunnen selecteren. Voorbeeld Dataelementen uit meer dan één zib nodig om variabele te kunnen afleiden lichaamsgewicht Registratie vraagt het lichaamsgewicht, gemeten maximaal 3 maanden vóór de huidige verrichting. Van zib Lichaamsgewicht zijn de dataelementen GewichtWaarde en GewichtDatumTijd nodig. Van zib Verrichting zijn de dataelementen VerrichtingStartDatum en VerrichtingType nodig. Ø Actie: Combineren van de drie dataelementen tot de gevraagde enkelvoudige variabele. Ø Bewerking (Extractie): ALS ((VerrichtingStartDatum 3 mnd) GewichtDatumTijd VerrichtingStartDatum) EN VerrichtingType = code voor huidige verrichting DAN GewichtWaarde = gevraagde variabele Voorbeeld Dataelementen uit meer dan één zib nodig om variabele te kunnen afleiden radiotherapie tijdens OK Registratie vraagt naar wel/geen aanvullende radiotherapie tijdens de OK. Hiervoor zijn twee zib-instantiaties Verrichting nodig, voor de OK en de radiotherapie. Ø Actie: Combineren van vier dataelementen tot de gevraagde enkelvoudige variabele. Ø Bewerking (Extractie en Afleiding): ALS VerrichtingStartDatum (VerrichtingType = code voor OK) = VerrichtingStartDatum (VerrichtingType = code voor radiotherapie) DAN Antwoord gevraagde variabele = Ja Ø Toelichting: Als er inderdaad radiotherapie is gegeven, dan is er dus sprake van een zib Verrichting met VerrichtingType = code voor radiotherapie, en omdat de startdatum daarin dezelfde is als die voor de OK wordt deze zib doorgestuurd. Hieruit kan aan de kant van de registratie het antwoord Ja afgeleid worden. 49/84

50 Voorbeeld Dataelementen uit meer dan één zib nodig om variabele te kunnen afleiden bonegraft tijdens implantatie prothese Registratie vraagt of tijdens implantatie van een gewrichtsprothese wel/niet gebruik is gemaakt van een bonegraft. Zib Verrichting dataelement VerrichtingType kan ingevuld worden met codes voor bonegraft, maar deze zib-instantiatie moet wel horen bij de hoofdverrichting, de implantatie van de prothese. Ø Actie: Analoog aan voorgaand voorbeeld. Voorbeeld Dataelementen uit meer dan één zib nodig om variabele te kunnen afleiden chronische nierinsufficiëntie Registratie vraagt of een patiënt chronische nierinsufficiëntie heeft (Ja/Nee), en noemt als extra voorwaarde een verhoogde creatininewaarde > 177 mmol/l om antwoord Ja in te vullen. Naast zib Probleem met ProbleemNaam = code voor chronische nierinsufficiëntie is nu ook zib LaboratoriumUitslag nodig. Ø Actie: Variabele afleiden uit combinatie van de verschillende dataelementen. Ø Bewerking (Extractie): ALS ProbleemNaam = code voor chronische nierinsufficiëntie EN TestNaam = code voor betreffende meting EN Uitslag > 177 mmol/l DAN Antwoord gevraagde variabele = ja Ø Toelichting: Alleen als de Uitslag van de relevante meting de vereiste waarde heeft, wordt de zib Probleem met ProbleemNaam chronische nierinsufficiëntie doorgestuurd. Hieruit kan aan de kant van de registratie het antwoord Ja afgeleid worden. 50/84

51 Voorbeeld Dataelementen uit meer dan één zib nodig om variabele te kunnen afleiden leeftijd bij stellen diagnose Registratie vraagt de leeftijd van de patiënt op het moment van diagnosestelling. Naast zib Patient dataelement geboortedatum zijn ook elementen van zib Probleem nodig. Ø Actie: Variabele afleiden uit combinatie van de verschillende dataelementen. Ø Bewerking (Extractie en Afleiding): ALS ProbleemNaam = code voor betreffende diagnose EN ProbleemType = diagnose (om evt. te kunnen onderscheiden van begindatum van een klacht, nog voordat er daadwerkelijk de diagnose is gesteld) DAN Leeftijd = BeginDatum (Probleem) Geboortedatum (Patient) Voorbeeld Dataelementen uit meer dan één zib nodig om variabele te kunnen afleiden hoogst gemeten bloeddruk tijdens opname Registratie vraagt alleen de hoogst gemeten bloeddruk in een reeks bloeddrukken die tijdens een opname zijn gemeten. Naast zib Bloeddruk zijn ook elementen van zib Contact nodig. Ø Actie: Variabele afleiden uit combinatie van de verschillende dataelementen. Ø Bewerking (Extractie en Afleiding): ALS BeginDatumTijd (Contact) BloeddrukDatumTijd EindDatumTijd (Contact) EN meerdere instantiaties aanwezig die hieraan voldoen DAN Selecteer instantiatie met hoogste waarde van gewenste dataelement Overige situaties Alle voorgaande situaties kunnen ook in combinatie met elkaar voorkomen. In kolom R kan dan code 7 (eenvoudige combinatie van voorgaande factoren) of 8 (complexe combinatie van voorgaande factoren) worden ingevuld. NB: Het invullen van de codes is niet noodzakelijk. Het is bedoeld om te helpen om overzicht te krijgen over het geheel van de analyse. Onderscheid naar 7 en 8 is dus ook niet per se nodig. 51/84

52 5 Data niet conform zorginformatiebouwstenen Inhoudsopgave Hoofdstuk 5 5 Data niet conform zorginformatiebouwstenen Inleiding Check op aansluiting op zorgproces Klinische relevantie Belang voor meten van kwaliteit Afleidbaarheid van andere gegevens Uitvraag elders De uitvraag van gegevens vormgeven Stap Stap Stap Stap Kandidaat-zibs Mogelijke situaties met betrekking tot een gegeven Uitleg beslispunten Uitkomsten /84

53 53/84

54 5.1 Inleiding Hoofdstuk 5 volgt op de uitkomsten van Hoofdstuk 3, Analyse datadictionaries. Uit deze analyse zijn mogelijk elementen naar voren gekomen die niet aansluiten op de zorginformatiebouwstenen. Dit kan spelen bij zowel een nieuwe registratie als een bestaande registratie, al zal bij het opzetten van een nieuwe registratie al meer rekening zijn gehouden met standaarden 36. In beide gevallen (bestaande en nieuwe registraties) kunnen dus nog enkele variabelen overblijven die niet op basis van zibs kunnen worden uitgevraagd. In dit hoofdstuk gaan we verder met deze uitkomsten. De adviezen in de volgende paragrafen gelden dus voor beide situaties. 36 Zie ook Hoofdstuk 1. Hierin wordt informatie gegeven over zowel het opzetten van een nieuwe registratie als het optimaliseren/harmoniseren van bestaande kwaliteitsregistraties, uitgaande van de Leidraad Kwaliteitsregistraties van het Zorginstituut Nederland en Nictiz. 54/84

55 5.2 Check op aansluiting op zorgproces Voor de variabelen die niet aansluiten op de zibs kan het zinnig zijn om opnieuw te bezien in hoeverre ze aansluiten op het zorgproces. Aan de hand daarvan kan bekeken worden of, en hoe deze variabelen verder uitgevraagd zullen worden. Hieronder worden enkele aspecten benoemd die mee kunnen spelen in deze beoordeling Klinische relevantie Is de variabele klinisch relevant? Betreft het een gegeven dat binnen het zorgproces bruikbaar en zinnig is? Dit kan getoetst worden door bij een representatief aantal ziekenhuizen (bv. 5, waaronder in ieder geval één umc en één algemeen ziekenhuis) na te gaan of/hoe het gegeven door zorgverleners wordt vastgelegd in het primaire zorgproces. Is het van belang voor de klinische besluitvorming? Een dergelijke toetsing geeft tevens een indruk in hoeverre de variabele de registratielast verhoogt. Als dit niet het geval is, (hoe) kan deze variabele dan toch bijdragen aan verbetering van de kwaliteit van zorg? Belang voor meten van kwaliteit Is deze variabele noodzakelijk is voor het meten van kwaliteit: wat levert het op? Kan de variabele gebruikt worden voor het verbeteren van de kwaliteit van zorg en wordt dit ook daadwerkelijk daarvoor gebruikt? Hierbij komen vragen aan de orde als: Draagt informatie afkomstig van deze variabele bij aan verbetering van (de kwaliteit van) de zorg? Wordt de variabele daadwerkelijk hiervoor gebruikt? Is de variabele nog actueel? Als het veld algemeen al optimaal scoort op een variabele is deze mogelijk niet meer actueel. Zijn de uitkomsten objectief vergelijkbaar tussen instellingen, artsen of door de tijd heen? Win hiervoor ook advies van ter zake kundige methodologen en statistici in, en neem het gegeven advies op in de documentatie over de registratie Afleidbaarheid van andere gegevens Bepaal of de variabele op een andere manier, bv. van reeds andere vastgelegde gegevens afgeleid kan worden. Hoe bepaal je of de variabele op een andere wijze afleidbaar is? Onderzoek bij een representatief aantal ziekenhuizen (zie boven) of de variabele afgeleid kan worden op basis van een of meerdere andere gegevens die al in het zorgproces moeten worden vastgelegd. Als dat zo is, vraag het dan niet apart uit maar leid het af uit de reeds beschikbare gegevens. 55/84

56 5.2.4 Uitvraag elders Onderzoek of de variabele al door andere kwaliteitsregistraties wordt uitgevraagd. Als elders al de benodigde informatie opgevraagd wordt beschikbaar is, is het mogelijk niet nodig om dit in de eigen registratie op te nemen. Hoe achterhaal je of een variabele al door een andere registratie wordt opgevraagd? Bekijk hiervoor het overzicht van zorginhoudelijke registraties 37. Bestudeer de datadictionary van registraties die op enig vlak verwantschap vertonen en beoordeel of elders deze variabele ook opgevraagd wordt. Bepaal of het nu nog nodig is om de variabele ook zelf uit te vragen /84

57 5.3 De uitvraag van gegevens vormgeven Er is nu een lijst met variabelen die niet op basis van zibs af te leiden zijn, maar die wel klinisch relevant en/of voor de kwaliteit van zorg noodzakelijk zijn. Deze items zullen dus uitgevraagd blijven worden. Er zijn verschillende mogelijkheden om de vraagstelling voor deze gegevens optimaal vorm te geven: Stap 1 Overleg met Nictiz of ontwikkeling van een eigen zorginformatiebouwsteen voor dit gegeven zinnig en haalbaar is. Als dat het geval is, dan wordt in de paragraaf "Kandidaat-zibs" verdere uitleg gegeven over hoe dit aangepakt kan worden Stap 2 Als dat niet het geval is, beoordeel of de uitvraag aansluit bij (inter)nationale standaarden als SNOMED CT en de wijze van vastleggen zoals in de zibs gehanteerd wordt. Zie hiervoor ook het document Richtlijnen bij afwezigheid zibs van Nictiz, punt 4 op pagina 7. Pas de variabele zoveel mogelijk hieraan aan Stap 3 Als er geen algemene standaarden voor bestaan, maar de variabele komt ook in andere kwaliteitsregistraties voor, sluit dan aan op de bestaande wijze van uitvragen Stap 4 Laat de uiteindelijke wijze van uitvragen controleren door deskundigen op methodologisch gebied. Daarbij gaat het bijvoorbeeld om begrijpelijkheid en eenduidigheid (van zowel de vraag als de antwoordopties), en de mate waarin de vraag bij kan dragen aan kwaliteit. 57/84

58 5.4 Kandidaat-zibs Als er voldoende reden is om voor een bepaalde variabele (of set van variabelen) een eigen bouwsteen te ontwikkelen, dan is ook hier een stappenplan voor beschikbaar. Nictiz heeft hier twee documenten voor uitgegeven, namelijk 'Richtlijnen bij afwezigheid zibs' 38 en 'Toetsingsproces voor nieuwe zibs' 39. De tekst hieronder is een samenvatting van de belangrijkste stappen in het eerste document. Gebruikte terminologie in deze paragraaf: DCM (Detailed Clinical Model): elk concept dat conform de DCM-standaard (zie de 'Richtlijn Detailed Clinical Model' 40 ) is opgesteld en (nog) niet de status 'kandidaat-zib' of 'zib' heeft. Zib (Zorginformatiebouwsteen): deze term wordt gebruikt voor bouwstenen, die onder de landelijke afspraken voor beheer en afhandeling van wijzigingsverzoeken vallen. Zibs worden altijd opgesteld in het format van een DCM, ze zijn dus een subtype van DCM s. Kandidaat-zib: deze term wordt gebruikt voor een concept (meestal een groep gegevenselementen), waarvan is vastgesteld: o dat er nog geen zib van is; o o dat er geen bestaande zib geschikt is om deze gegevenselementen aan toe te voegen via een wijzigingsvoorstel; dat er sprake is van (potentieel) hergebruik Dit document is op dit moment (juli 2018) nog niet op de Nictiz-site beschikbaar /84

59 5.4.1 Mogelijke situaties met betrekking tot een gegeven In figuur X zijn de verschillende situaties en uitkomsten rondom de aan-/afwezigheid van zibs weergegeven. Deze worden hierna verder toegelicht. NB: De figuur laat eigenlijk een verkorte vorm van analyse van een gegeven zien. Figuur 3 Mogelijke situaties en uitkomsten bij aan-/afwezigheid van een geschikte zib Uitleg beslispunten A. Bestaat er een zib, waar dit element bij hoort? De actuele release van (landelijke) zibs is te vinden op de zib-wikipagina zibs.nl. In veel gevallen is het redelijk snel duidelijk of er reeds een zib bestaat, waar dit element onderdeel van is, of zou moeten zijn omdat er sprake is van (potentieel) meervoudig gebruik. Eventueel kan ondersteuning worden gevraagd bij de beheerder van de zibs (Nictiz Zib-centrum 41 ) /84

60 B. Voldoet de zib? Nadat geconstateerd is dat er een zib bestaat, waarbij dit element onderdeel van het informatiemodel van de zib is of zou moeten zijn, kunnen er meerdere redenen zijn, waarom de zib toch niet voldoet. Een aantal voorkomende gevallen (zonder uitputtend te zijn) zijn: Het element is nu geen onderdeel van het informatiemodel van de zib; Het element is wel onderdeel van het informatiemodel van de zib, maar de definitie van het element voldoet niet; Bij het betreffende element in het informatiemodel van de zib is sprake van een waardelijst, maar de waardelijst voldoet niet; Tekstuele toelichtingen in de zib (bijvoorbeeld concept of example instances ) voldoen niet. C. Is er sprake van (potentieel)hergebruik? Indien er nog geen passende zib bestaat, is de belangrijkste overweging of er redelijkerwijs sprake is van potentieel meervoudig gebruik van dit element, anders dan in een specifieke usecase. Is er sprake van (potentieel) hergebruik van het gegevenselement in het zorgproces en/of voor kwaliteitsregistraties? Zo ja, dan is de richtlijn om voor dit element of deze groep van elementen een kandidaat-zib op te stellen. Het hergebruik kan ook het gebruik betreffen van het gegevenselement voor meer dan één zorgdomein (1 e lijn, ggz, 2 e /3 e lijn etc.) Uitkomsten 1. Gebruik de bestaande zib Zie de Architectuurdocumenten volume 1 t/m 4 42 voor de verdere invulling rondom gebruik zib. 2. Dien wijzigingsvoorstel in op deze zib en voeg element los toe aan de gegevensset Bij dit eindpunt is sprake van 2 acties: het indienen van een wijzigingsvoorstel en daarnaast een tijdelijke oplossing voor het feit dat de betreffende zib niet voldoet. Voor de eerste actie (indienen wijzigingsvoorstel): zie Beheerafspraken Zorginformatiebouwstenen V voor een omschrijving hoe en waar een wijzigingsvoorstel moet worden ingediend, en hoe het proces van besluitvorming over een wijzigingsvoorstel verloopt. Voor de tweede actie is het lastig om een altijd geldende richtlijn op te stellen. Omdat bij dit eindpunt in de beslisboom er sprake is van het bestaan van een zib, waar dit element toe zou moeten behoren, is de richtlijn om het element eerst tijdelijk los toe te voegen aan de gegevensset, maar wel de relatie met de betreffende zib zichtbaar te maken. In bijvoorbeeld een nieuwe versie van de gegevensset kan dan de nieuwe zib worden opgenomen. Eventueel kan ondersteuning worden gevraagd bij de beheerder van de zibs (Nictiz) /84

61 3. Beschrijf het gegevenselement (evt. meer elementen in samenhang) in de vorm van een zib, en maak dit bekend bij Nictiz als kandidaat-zib. Het opstellen van een kandidaat-zib is vrij: in principe kan iedereen dat doen. In het document "Toetsingsproces voor nieuwe zibs" wordt het proces rondom het voorstellen en opstellen van een kandidaat-zib tot en met opname in de categorie zibs beschreven. Nadere informatie over het daadwerkelijk opstellen van een zib is te vinden in het Nictiz-document 'Richtlijnen bij afwezigheid zibs'. Paragraaf 4 beschrijft de richtlijnen, die gelden bij het opstellen van een kandidaat-zib. Deze richtlijnen vallen uiteen in: 1. Richtlijnen opstellen zib m.b.t. (inhoudelijk) formaat (vulling paragrafen van DCM-formaat, richtlijnen voor informatiemodel e.d.); 2. Richtlijnen opstellen zib m.b.t. opnemen in het landelijk register kandidaat-zibs. 4. Gebruik geen zib, maar beschrijf het element (evt. meer elementen in samenhang) volgens de hierna genoemde richtlijn In dit eindpunt geen sprake van potentieel hergebruik. Zie hiervoor de toelichting bij beslispunt C. De richtlijn is: gebruik geen zib maar beschrijf het element op basis van bilaterale afspraken, afspraken binnen de beroepsvereniging e.d. Gebruik hiervoor zoveel mogelijk (aanwezige) standaarden, waardelijsten en formele modelleringsmethoden, zoals: de manier waarop gegevenselementen en groepen gegevenselementen in een zib beschreven worden, zie verder paragraaf 4 van het Nictiz-document Richtlijnen bij afwezigheid zibs en de wiki ( reeds in zibs gebruikte waardelijsten zoals voor lateraliteit, geslacht en mate van ernst, inclusief de daar gebruikte codering; eventueel relevante termen uit (inter)nationale standaarden als SNOMED CT, LOINC, etc. Indien een term nog niet vertaald is, ontvangt Nictiz graag een suggestie voor vertaling zodat deze opgenomen kan worden. 61/84

62 6 Het realiseren van een technisch format en een technische implementatie Inhoudsopgave Hoofdstuk 6 6 Het realiseren van een technisch format en een technische implementatie Inleiding Mapping op communicatiestandaarden HL7 CDA en FHIR HL7 CDA (Clinical Document Architecture) HL7 FHIR (Fast Healthcare Interoperability Resources) Uitwisseling op basis van HL7 CDA of FHIR Uitwisselingsmechanismen Samenstellen van een specificatie Bewerken van de data vanuit de communicatiestandaard /84

63 63/84

64 6.1 Inleiding Nu de hoofdstukken C, D & E zijn gevolgd is er een gegevensset ontstaan t.b.v. kwaliteitsregistraties met: instantiaties van (dataelementen van) zibs gegevens die te mappen zijn op basis van een of meerdere zib-instantiaties gegevens die (nog) niet conform zibs te ontsluiten zijn vanuit het zorgproces Deze gegevensset moet nu vanuit de zorginstellingen aangeleverd worden aan de kwaliteitsregistratie. Dit kan in de praktijk op verschillende manieren gebeuren, mede afhankelijk van de systemen die bij een zorginstelling worden gebruikt. Dit kan bijvoorbeeld een geïntegreerd elektronisch patiëntendossier (epd) zijn, of een datawarehouse. De principestappen waarin een gegevensset aangeleverd wordt blijven desondanks gelijk. Om gegevens op basis van zibs naar een registratie te kunnen versturen, moet een zorginstelling deze gegevens ook in de vorm van zibs kunnen opleveren. In dit hoofdstuk wordt ervan uitgegaan dat de betrokken informatiesystemen in een ziekenhuis inderdaad zibs kunnen genereren. Dit uitgangspunt sluit aan bij de ontwikkelingen op verschillende terreinen. Zo is inmiddels afgesproken dat de gestandaardiseerde (zib-compliant) gegevens die onderdeel zijn van de BgZ, met prioriteit toegepast gaan worden in zorginformatiesystemen. Voorbeelden daarvan zijn de epd s van de umc s in het kader van het programma Registratie aan de bron en de epd s van de algemene ziekenhuizen in het kader van het programma VIPP. Daarnaast is ook door het programma MedMij gekozen voor implementatie van de zibs en de BgZ. Zo ook door de ggz in het kader van het programma VIPPGGZ. Architectuurdocument vol.4 44 geeft een uitgebreide beschrijving van hoe zibs gebruikt kunnen worden voor de aanlevering van gegevens aan registraties. Dit hoofdstuk gaat nader in op het onderdeel berichtenverkeer. In het architectuurdocument komt dit kort aan de orde in par. 6.3 en Architectuurdocument vo.4 'Hergebruik van gegevens voor registraties' 64/84

65 6.2 Mapping op communicatiestandaarden HL7 CDA en FHIR 45 Op het moment dat patiëntgerelateerde gegevens moeten worden uitgewisseld tussen twee informatiesystemen, moeten de gegevens in een bericht worden verpakt met behulp van een communicatiestandaard. In een op te stellen specificatie wordt beschreven hoe de afzonderlijke gegevens eruit moeten zien als ze met behulp van zo n standaard worden uitgewisseld. Op dit moment worden daarvoor met name de internationale standaarden HL7 v3 (Health Level 7) 46 - waaronder HL7 CDA en HL7 FHIR - gebruikt. De manier waarop functionele specificaties vertaald moeten worden in technische specificaties, is uitgebreid beschreven in het architectuurdocument vol.2, hoofdstuk Het merendeel van de in Nederland gebruikte epd-systemen heeft inmiddels de mogelijkheid om data te versturen conform deze internationale standaarden van HL7. Hoewel de wens is om één standaard te gebruiken in de toekomst, is dat op dit moment nog niet realiseerbaar en worden zodoende beide standaarden in dit hoofdstuk toegelicht HL7 CDA (Clinical Document Architecture) HL7 CDA is een onderdeel van de HL7v3-standaard. De laatste versie (release 2.0) stamt uit HL7 CDA-documenten zijn op XML (Extensible Markup Language) gebaseerd en specificeren de codering, structuur en semantiek van klinische documenten die bedoeld zijn voor het opslaan en uitwisselen van medische gegevens. Een belangrijk kenmerk van een CDA-document is dat het niet alleen door computers begrepen wordt, maar ook voor mensen leesbaar is. Het document bevat alle informatie die nodig is om de inhoud te kunnen interpreteren. Zowel gestructureerde als ongestructureerde tekst kan hierin worden opgenomen HL7 FHIR (Fast Healthcare Interoperability Resources) De FHIR-standaard is een latere ontwikkeling van HL7 waarin de ervaring van eerdere standaarden is meegenomen. FHIR is volledig op basis van internetstandaarden ontwikkeld, waaronder XML, JSON (JavaScript Object Notation) en HTTP (Hypertext Transfer Protocol). Een belangrijke toepassing is bijvoorbeeld het ontsluiten van epd-systemen voor mobiele toepassingen. De kern van FHIR wordt gevormd door herbruikbare bouwstenen, de zogenaamde resources, waarmee oplossingen voor uitwisseling van zowel administratieve als zorginhoudelijke gegevens kunnen worden gebouwd. Een lijst van beschikbare resources is te vinden op Door middel van profiling (het maken van specificaties in de vorm van structure definitions en extensions) en onderlinge verwijzingen is het mogelijk een specifieke set van resources voor een bepaalde use case te definiëren. Door de gegevenselementen van de zibmodellen te mappen op FHIR resource-elementen is het mogelijk om op een eenduidige en interoperabele manier gegevens die gebaseerd zijn op de bouwstenen onder te brengen in FHIR-resources HL7 Nationaal: HL7 Internationaal: 47 Architectuurdocument vol.2 Technische implementatie van zibs; De praktische aspecten van de implementatie van zibs op het niveau van de applicaties en de gegevensuitwisseling 65/84

66 6.2.3 Uitwisseling op basis van HL7 CDA of FHIR In de afgelopen twee jaar zijn meerdere templates ontwikkeld voor het uitwisselen van gegevenssets gebaseerd op een selectie van zib-instantiaties, in zowel HL7 CDA- als in FHIRformat. Daarnaast is ten behoeve van de uitwisseling van de BgZ een HL7 CDA-template ontwikkeld 48 en wordt deze momenteel (2018) geïmplementeerd bij twee grote epd-leveranciers in Nederland. Binnen het eerdergenoemde programma MedMij zijn FHIR-profielen ontwikkeld om eveneens de BgZ te kunnen uitwisselen. TIP! Neem contact op met Nictiz om te informeren naar beschikbare templates voor zibs op basis van HL7 CDA- of FHIR-standaarden /84

67 6.3 Uitwisselingsmechanismen Voor de daadwerkelijke uitwisseling van gegevens is een uitwisselingsmechanisme nodig als onderdeel van de IT-infrastructuur. In hoofdstuk 6 van architectuurdocument vol.2 wordt een aantal infrastructurele uitwisselingsmechanismen beschreven voor de uitwisselingsstandaarden HL7 CDA en HL7 FHIR. Details per mechanisme zijn terug te vinden in H6 van dit architectuurdocument. Een overzicht is hieronder weergegeven in Tabel 2. # Praktijkoplossingen NB. Dit overzicht is niet compleet maar geeft een aantal oplossingen weer die in de praktijk het meest voor de hand liggen. Type Wat kan het formaat van de content zijn? HL7 CDA Documents HL7 FHIR Documents HL7 FHIR Resources 1 Point-to-point oplossingen gebaseerd op Secure met attachment Secure FTP IHE XDM en IHE XDR profielen Push V V - 2 Oplossingen gebaseerd op het IHE XDS profiel (zoals o.a. geïmplementeerd in regionale samenwerkingsverbanden) Publish & pull V V - 3 Client-server oplossingen gebaseerd op FHIR RESTful services Push, pull - V V 4 AORTA (LSP) Pull, push V V V Tabel 2 Praktijkoplossingen voor de IT Infrastructuur TIP! Betrek in een vroeg stadium verschillende zorginstellingen bij het uitvoeren van de technische implementatie. Zo kunnen vroegtijdig fouten worden ontdekt en worden opgelost in de specificatie en eventuele bewerking op de communicatiestandaard. 67/84

68 6.4 Samenstellen van een specificatie Nadat de keuze is gemaakt voor het toepassen van een standaard (HL7 CDA of FHIR), kan worden gestart met het samenstellen van een HL7 CDA-specificatie of een FHIR-specificatie. Deze technische specificatie zal in overleg met Nictiz opgesteld moeten worden. Hierbij zal dan gebruik gemaakt worden van het platform ART-DECOR van Nictiz. Dit platform geeft inzicht aan zorgverleners en ICT-leveranciers en faciliteert het maken en vastleggen van afspraken in zogenaamde informatiestandaarden. In ART-DECOR is expliciet en eenduidig opgeschreven waaruit de informatiestandaard bestaat. Hierdoor verloopt het proces van ontwikkelen en implementeren van de informatiestandaard efficiënt. 68/84

69 6.5 Bewerken van de data vanuit de communicatiestandaard Het kan zijn dat de technische specificatie toelaat dat er meer gegevens worden verstuurd dan noodzakelijk is, of wettelijk is toegestaan. Een zib kan immers meerdere dataelementen bevatten die niet altijd allemaal nodig zijn voor de kwaliteitsregistratie. Hierdoor kan het zijn dat er nog een bewerking uitgevoerd moet worden op de data die met de communicatiestandaard worden meegestuurd. Het doel hiervan is dat alleen de voor de registratie benodigde gegevens daadwerkelijk aangeleverd worden. Die bewerking kan verschillende vormen aannemen. Voorbeelden van mogelijke bewerkingen zijn: Bepaal de hoogste en de laagste hartfrequentie gemeten tijdens een verrichting en stuur alleen de gewenste door. Verwijder bepaalde gegevenselementen die in het kader van de privacy (AVG) niet aangeleverd mogen worden. Uitgangspunt bij de systeemopzet is dat de gegevens die het epd verlaten zib-compliant zijn. De extractie die nodig is voor de aanlevering van zib-instantiaties is een functionaliteit die in het aanleverende zorginformatiesysteem geïmplementeerd moet zijn. De functionaliteit bewerking kan een systeem zijn dat buiten het zorginformatiesysteem staat en een bewerking op de geëxtraheerde zib-instantiaties uitvoert. De gegevens die het resultaat zijn van de selectie en bewerking worden aangeleverd aan de kwaliteitsregistratie waar de gegevens ontvangen worden. Daar worden ze opgeslagen in het eigen informatiesysteem, voor verdere verwerking. In Architectuurdocument vol.4 par.3.2 en 3.3 worden hiervoor mogelijke systeemoplossingen voorgesteld, waarin de stappen extraheren, bewerken en uploaden nader worden uitgewerkt. Onderstaande afbeelding is uit par 3.2 afkomstig, en geeft een overzicht van hoe deze stappen eruit kunnen zien. Nadere uitleg is te vinden in het architectuurdocument. Figuur 4 Voorbeeld generieke systeemoplossing 69/84

70 7 Beheerafspraken kwaliteitsregistraties Inhoudsopgave Hoofdstuk 7 7 Beheerafspraken kwaliteitsregistraties Inleiding Wijzigingen in het zorgproces Aanbevelingen ten aanzien van beheerafspraken Wijzigingen in gebruike standaarden (zibs) Aanbevelingen ten aanzien van beheerafspraken Wijzigingen in aanleverende systemen van zorginstellingen Aanbevelingen ten aanzien van beheerafspraken Wijzigingen in gebruikte HL7 CDA-templates of FHIR-profielen Aanbevelingen ten aanzien van beheerafspraken Wijzigingen in wet- en regelgeving Aanbevelingen ten aanzien van beheerafspraken /84

71 71/84

72 7.1 Inleiding Nadat harmonisatie heeft plaatsgevonden en alle stappen zijn doorlopen die beschreven zijn in de vorige hoofdstukken, zijn er meerdere factoren die continue monitoring vragen en daarmee van invloed zijn op het beheerproces van de datadictionary van de kwaliteitsregistratie. Naast wijzigingen vanuit de kwaliteitsregistraties zelf zijn er externe factoren die van invloed kunnen zijn op het beheerproces, zoals wijzigingen in: het zorgproces de standaarden (zibs en BgZ) de aanleverende systemen van zorginstellingen HL7 CDA-templates of FHIR-profielen wet- en regelgeving, bv. wijzigingen in landelijke tripartite afspraken over verplichte of vrijwillige indicatorensets, inclusief de sets voor de Transparantiekalender In de volgende hoofdstukken worden aanbevelingen bij elk van deze factoren benoemd om tot duidelijke beheerafspraken te kunnen komen. 72/84

73 7.2 Wijzigingen in het zorgproces Nieuwe inzichten in het ziektebeeld, maar ook organisatorische veranderingen kunnen leiden tot landelijke wijzigingen in het zorgproces. Hierdoor kan het zijn dat bepaalde variabelen uit een kwaliteitsregistratie die voorheen aansloten op het zorgproces, door deze wijziging niet meer aansluiten. Daarmee zouden ze een (mogelijk onnodig) hogere registratielast veroorzaken. Dit kan geminimaliseerd worden door in de beheerafspraken monitoring van dit zorgproces op te nemen Aanbevelingen ten aanzien van beheerafspraken In een eerder stadium is het zorgproces beschreven. Toets eenmaal per jaar, of bij wijzigingen zoals hierboven beschreven, bij een aantal zorginstellingen of het beschreven zorgproces nog actueel is of aanpassingen behoeft. Mochten er wijzigingen optreden in het zorgproces, dan heeft dat mogelijk ook consequenties voor bijvoorbeeld het gebruik van standaarden en de opgestelde specificatie t.b.v. een technische aanlevering. Volg daarom bij wijziging opnieuw de verschillende stappen die benoemd zijn in de hoofdstukken van het Doeboek. 73/84

74 7.3 Wijzigingen in gebruikte standaarden (zibs) Nieuwe inzichten in het gebruik van standaarden kunnen leiden tot wijzigingen van deze standaarden. In dit hoofdstuk beperken we ons tot wijzigingen van de zibs. Dat neemt niet weg dat onderstaande stappen ook voor andere standaarden gebruikt kunnen worden. Het zijn immers niet alleen de zibs die aan verandering onderhevig kunnen zijn. Publicaties van zibs verschijnen gemiddeld een keer per jaar en bevatten telkens een set bouwsteenversies die in samenhang consistent zijn. Om zibs conform een publicatie te implementeren dienen alle relevante zibs in de versie gebruikt te worden. Om tegemoet te komen aan de vraag om flexibiliteit ten behoeve van early adopters, zonder de gewenste en noodzakelijke stabiliteit te ondermijnen, worden de lopende ontwikkelingen uitgebracht in maximaal 4 prepublicaties per jaar. Dit zijn op zich consistente sets zibs. Er is echter geen garantie dat deze bouwstenen in de tijd tot de volgende definitieve publicatie niet worden gewijzigd. Gebruikers van prepublicaties dienen zich dit risico te realiseren. In de beheercyclus van de zibs kunnen overigens alle belanghebbenden participeren. Onder andere leveranciers kunnen zo op de hoogte blijven van de ontwikkelingen. Alle details over dit proces, inclusief de manier waarop wijzigingsvoorstellen kunnen worden ingediend, staan beschreven in het document 'Beheerafspraken Zorginformatiebouwstenen' 49. Voorbeeld Er vindt een wijziging plaats op de zib medicatie. Het resultaat is een uitsplitsing naar meerdere zibs, zodat er meer inzicht ontstaat in het gebruik en toediening van medicatie. Dit betekent dat de oude zib op termijn niet meer gebruikt zal gaan worden. Hierdoor zal de huidige specificatie van de aanlevering met betrekking tot deze zib herzien moeten worden Aanbevelingen ten aanzien van beheerafspraken In de analyse is duidelijk geworden welke zibs van toepassing zijn voor de betreffende dataset van de kwaliteitsregistratie. Via Nictiz kan worden aangegeven voor welke zibs u op de hoogte gewenst te worden gebracht als er wijzigingen op plaatsvinden. Op die manier heeft de registratie altijd actueel inzicht in mogelijke wijzigingen van de gebruikte zibs, zodat daar ook naar gehandeld kan worden. Alternatief is om eenmaal per jaar de nieuwe release van zibs te bekijken en dan te beoordelen of wijzigingen mogelijk effect (gaan) hebben op de bestaande aanleveringen. Zorg voor duidelijke afspraken met de aanleverende organisaties dat het doorvoeren van nieuwe zibs altijd in afstemming gebeurt met de kwaliteitsregistratie en/of dataverwerker van de kwaliteitsregistratie. Mochten er wijzigingen optreden in zibs, dan heeft dat mogelijk ook consequenties voor bijvoorbeeld het zorgproces en de opgestelde specificatie t.b.v. een technische aanlevering. Volg daarom bij wijziging opnieuw de verschillende stappen die benoemd zijn in de hoofdstukken van het Doeboek /84

75 7.4 Wijzigingen in aanleverende systemen van zorginstellingen Door harmonisatie en aansluiting op de aanleverende systemen van een zorginstelling dient ook rekening gehouden te worden met wijzigingen (zoals updates en optimalisaties) van die systemen. Ondanks dat een zorginstelling hier zelf voor verantwoordelijk is, kan het proactief monitoren van ontwikkelingen aan de kant van gebruikte softwaresystemen van een zorginstelling, problemen voorkomen in de aanlevering van informatie. Daarnaast kan door deze monitoring ook vroegtijdig aangesloten worden op verbeteringen en ontwikkelingen. Voorbeeld Een ziekenhuis krijgt een softwareupdate van het elektronisch patiëntendossier (epd). Hierdoor ontstaat nieuwe functionaliteit waardoor er op een andere wijze gegevens worden vastgelegd in het OK-verslag. De oude velden die voorheen gebruikt werden in het OK-verslag worden niet meer gebruikt. Hierdoor is de informatie die t.b.v. de kwaliteitsregistratie vanuit de oude velden werd ontsloten, niet meer op dezelfde manier beschikbaar. Bij de afleidingsregels van historische informatie zal hiermee rekening gehouden moeten worden Aanbevelingen ten aanzien van beheerafspraken Blijf in nauw contact met zorginstellingen om op de hoogte te blijven van nieuwe ontwikkelingen op het gebied van aanleverende systemen. Spreek met zorginstellingen af om veranderingen in systemen vroegtijdig te melden als deze mogelijk invloed hebben op de betreffende aanlevering. 75/84

76 7.5 Wijzigingen in gebruikte HL7 CDA-templates of FHIR-profielen HL7 CDA-templates en FHIR-profielen zijn over het algemeen nauwelijks aan verandering onderhevig. Toch kan het gebeuren dat er wijzigingen optreden in de recent ontwikkelde templates en profielen. Een wijziging in een template of profiel heeft ook gevolgen voor de opgestelde specificatie t.b.v. een technische aanlevering Aanbevelingen ten aanzien van beheerafspraken In de specificatie zijn de benodigde HL7 CDA-templates of FHIR-profielen opgenomen. Via de zib-wiki 50 kan via de pagina van een specifieke zib doorgelinkt worden naar de betreffende pagina s voor HL7 CDA- dan wel FHIR-specificaties. Om op de hoogte te blijven van nieuwe ontwikkelingen moet in de beheerafspraken vastgelegd worden dat deze pagina's voor alle door een registratie gebruikte zibs regelmatig gecontroleerd worden. Via het platform Nictiz ART-DECOR 51 kan meer informatie worden gevonden over de beschikbare HL7 CDA-templates. Voor FHIR-profielen is het platform Simplifier FHIR Registry 52 beschikbaar. Voorbeeld Voor de zib Probleem wordt de beschikbare informatie aangeboden via de specifieke zib-pagina op Op deze pagina vindt men onderaan de betreffende links naar de HL7 CDA- of FHIR-specificaties /84

77 7.6 Wijzigingen in wet- en regelgeving Wijzigingen in wet- en regelgeving kunnen gevolgen hebben voor de datadictionary of technische aanlevering van kwaliteitsregistraties. De mogelijke gevolgen zijn echter te divers om op vooruit te kunnen lopen Aanbevelingen ten aanzien van beheerafspraken Een kwaliteitsregistratie moet in de beheerafspraken een procedure opnemen om op de hoogte te blijven van toepasselijke wet- en regelgeving. In ieder geval is regelgeving rond privacy en toestemming van de patiënt rond gegevensdeling van belang om op te volgen. 77/84

78 Bijlage 1 Overzicht betrokken partijen In het Doeboek worden diverse partijen genoemd die een rol spelen bij het vormgeven/aanpassen van een kwaliteitsregistraties op basis van de principes van Registratie aan de bron. Hieronder worden deze partijen benoemd en toegelicht. Patiënt Terugkoppeling van zelf ingevoerde data en benchmark t.o.v. een vergelijkbare groep patiënten verbetert inzicht over te verwachten uitkomsten na interventies. Transparantie van zorgdata leidt tot overwogen keuzen in het kader van SDM (shared decision making) bij keuzen voor interventies, medicatie etc. Medisch specialist/ Zorgverlener Presentatie van (zelf) ingevoerde data en vergelijking met overeenkomstige patiëntengroepen en interventies leidt tot zorgverbetering. Kwaliteitsregistratie Dit kan elke kwaliteitsregistratie betreffen die met het Doeboek gaat werken. Zorgverleners/wetenschappelijke verenigingen Bij elke ontwikkeling of aanpassing van een kwaliteitsregistratie zijn zorgverleners betrokken. Hun inbreng moet gewaarborgd zijn, bijvoorbeeld door participatie van een koepel of wetenschappelijke vereniging. Programma Registratie aan de bron Registratie aan de bron is een landelijk programma waarin - met zorgprofessionals principes en producten worden ontwikkeld om zorginformatie eenmalig en op een eenduidige manier vast te leggen. Het ontwikkelen van zorginformatiebouwstenen is hiervan een concrete invulling. Op basis van deze zibs is de Basisgegevensset Zorg vormgegeven. Architectuurteam Registratie aan de bron Het architectuurteam staat aan de basis van de ontwikkeling van zorginformatiebouwstenen en de architectuurdocumenten. Nictiz Nictiz (Nederlands Instituut voor ICT in de zorg) draagt bij aan betere gezondheid door betere informatie. Het is expertisecentrum e-health, en partner in landelijke programma s zoals MedMij, VIPP en Registratie aan de bron. Nictiz is ook de functioneel beheerder van de zorginformatiebouwstenen. Bij het zib-centrum van Nictiz kan iedereen terecht met vragen rond de zibs. Ook kan Nictiz ondersteuning bieden en bij het ontwikkelen van informatiestandaarden. VIPP ziekenhuizen VIPP is een implementatieprogramma waarmee ziekenhuizen, revalidatiecentra en categorale instellingen stappen kunnen zetten om de patiënt toegang te geven tot de eigen medische gegevens. Het gebruik van zibs en de BgZ is een van de pijlers onder het programma. MedMij MedMij stelt zich tot doel om iedereen die dat wil te laten beschikken over zijn eigen gezondheidsgegevens in één persoonlijke gezondheidsomgeving. Zo n omgeving een app of website moet op een beveiligde en vertrouwde manier met de zorginformatiesystemen van 78/84

79 zorgaanbieders kunnen communiceren. MedMij stelt hiervoor de spelregels op. Een van die spelregels betreft het gebruik van zibs en de BgZ. Verwerker (databewerker) Soms leveren zorginstellingen gegevens direct aan een kwaliteitsregistratie aan. Vaak zal dit echter via een verwerker gedaan worden. De instelling levert de gegevens aan bij een verwerker, een organisatie die de data landelijk verzamelt en geschikt maakt voor aanlevering aan de registratie. Databewerkers hebben een belang om aan te sluiten op de principes van Registratie aan de bron om gemakkelijker aansluiting te kunnen vinden op hetgeen in het zorgproces wordt vastgelegd. Zorginstituut Nederland Een van de taken van het Zorginstituut Nederland is het bevorderen van de kwaliteit van de gezondheidszorg. Samen met Nictiz heeft het de Leidraad Kwaliteitsregistraties uitgegeven waar in dit Doeboek aan gerefereerd wordt. 79/84

80 Bijlage 2 Afbeelding analysebestand 80/84