De Basisgegevensset Zorg in de praktijk

Transcriptie

1 De Basisgegevensset Zorg in de praktijk Versie april 2018 Architectuurteam Registratie aan de bron

2 Inhoud 1. De BgZ als patient summary De BgZ in de praktijk Het model Vastleggen Genereren Delen Gebruiken Eén definitie, een veelvoud aan instantiaties Wat verder van belang is Wettelijke kaders De behandelend zorgverlener is verantwoordelijk Het gebruik van gegevens voor andere doeleinden zoals registraties Als de BgZ niet genoeg is Context Bijlage Inhoud BgZ gebaseerd op zibs release Versie Datum Omschrijving april 2018 Eerste publicatie april 2018 Van een aantal zibs was in v1.0 in de bijlage de verkeerde versie weergegeven. Dat is in v1.1 aangepast. Verantwoording Een deel van het gedachtengoed zoals dat is uitgewerkt in dit document is geïnspireerd op resultaten van het estandards 1 initiatief: ehealth Standards and Profiles in Action for Europe and Beyond. En daarvan met name de volgende documenten: Patient Summary brochure V9 estandards 2 Final Activity Report relevant to Global Standards and the EU/US MoU (Deliverable 5.3) 3 En daarvan met name paragraaf 6.2 en appendix 2 The Detailed Layer applied to PS of the Lifecycle s_and_eu_us_mou.pdf 1/12

3 1. De BgZ als patient summary Van elke burger worden bij allerlei zorginstellingen gegevens vastgelegd. Medische gegevens, maar bijvoorbeeld ook administratieve en verzekeringsgegevens, wie de huisarts is van de patiënt en hoe diens gezinssituatie eruitziet. De Basisgegevensset Zorg (BgZ) 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 4. De BgZ is een patient summary, een beknopt klinisch document 5 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. Epd en patient summary Van een patiënt worden gedurende het leven, in principe van conceptie tot overlijden, veel gegevens vastgelegd is allerlei dossiers. In de praktijk gaat het om meerdere elektronische patienten dossiers (epd s), bijgehouden door meerdere zorgverleners, in meerdere zorginstellingen en in meerdere systemen. Een epd is een uitgebreide en gedetailleerde vorm van documenteren en het zal verschillen in uitgebreidheid en omvang, afhankelijk van de scope en jurisdictie van de zorg, de aard van de zorg, in welke omstandigheden de zorg wordt geleverd, de periode gedurende welke de zorg wordt geleverd etc. Een patient summary daarentegen biedt een momentopname, met als doel een beknopte weergave (samenvatting) van de toestand van de patiënt te bieden op een bepaald tijdstip, en voldoende context om continuïteit van zorg te ondersteunen. Binnen de zorg bestaan meerdere 6 patient summaries. Zo wordt bijvoorbeeld in Nederland in het kader van huisartswaarneming een samenvatting van het huisartsendossier van een patiënt uitgewisseld via het LSP 7, onder de naam Professionele Samenvatting. Op Europees niveau is er sprake van een International Patient Summary (IPS 8,9 ) voor uitwisseling tussen zorgverleners in verschillende landen, met name in het kader van ongeplande of acute zorg. De BgZ kan de zorgprofessional (of de patiënt) in bepaalde gevallen voorzien van essentiële informatie die van belang is voor continuïteit van zorg. Hoe goed die match is in een bepaald geval, is altijd afhankelijk van de specifieke casus. De inhoud van de BgZ is gedefinieerd met de intentie om de toegevoegde waarde van 4 Continuïteit van zorg is de mate waarin een reeks van afzonderlijke medische handelingen wordt ervaren als onderling verbonden en samenhangend en in overeenstemming met de medische behoeften van de patiënt en zijn persoonlijke context [Afgeleid van Haggerty, J.L. et al., Continuity of care: a multidisciplinary review, British Medical Journal 327 (7425): , november 2003] 5 Met een klinisch document wordt niet perse een fysiek document bedoeld; het kan ook informatie in elektronische vorm zijn of informatie die wordt weergegeven op een beeldscherm. 6 In de zorg is het maken en gebruiken van samenvattingen een zinvolle bezigheid die wordt aangewend om zowel complexiteit en omvang van de informatie te managen, met als doel klinische zorg efficiënter en effectiever te ondersteunen. Daarom komen samenvattingen ook vaker voor. Ze worden op veel verschillende manieren gedefinieerd en gebruikt. Het resultaat is dat er vele soorten 'samenvatting' bestaan, zowel in de vorm van papier als digitaal, verschillend qua scope, inhoud, verfijning en volwassenheid /12

4 de gegevensset in veel uiteenlopende situaties zo groot mogelijk te laten zijn. Ervaringen met het gebruik van de BgZ in de praktijk zullen leiden tot aanpassingen en aanvullingen van de BgZ om die toegevoegde waarde te optimaliseren. Zie figuur 1 voor een model van de levenscyclus van een BgZ. Figuur 1 - Model van de levenscyclus van de BgZ. De specificatie van de BgZ is te vinden in de bijlage van dit document. Daar is te zien dat de BgZ bestaat uit achttien secties, variërend van behandelrestricties tot sociale anamnese, en van klachten en diagnoses tot vitale functies. Elk van de secties bevat één of meer BgZ-onderdelen zoals behandelaanwijzingen, tabakgebruik, problemen, medicatiegebruik, vaccinaties of bloeddruk. Elk van deze, in totaal 28, onderdelen is gedefinieerd op basis van een zorginformatiebouwsteen (zib). De 18 secties zijn bedoeld om structuur aan te brengen in de BgZ, door bepaalde onderdelen te groeperen. De secties komen sterk overeen met de secties van CCR/CCD 10. De BgZ definieert niet alleen de onderdelen (op basis van de zibs), maar ook hoe de onderdelen in het kader van de BgZ moeten worden gevuld. Voor het BgZ-onderdeel Problemen moeten bijvoorbeeld alle bekende problemen van alle probleemtypen (klachten, diagnoses etc.) worden meegenomen. Voor het BgZ-onderdeel Bloeddruk, de laatst bekende bloeddruk. En voor het onderdeel Verrichtingen alle bekende operatieve verrichtingen. De BgZ definieert dus zowel welke patiëntgerelateerde gegevens onderdeel zijn van de BgZ (op basis van zibs) en ook hoe deze onderdelen in het kader van de BgZ moeten worden gevuld. De BgZ creëert focus bij de implementatie van zib-compliant systemen. Op verschillende terreinen is inmiddels afgesproken dat de gestandaardiseerde (zib-compliant) gegevens die onderdeel zijn van de BgZ met prioriteit zullen worden toegepast in zorginformatiesystemen. Voorbeelden daarvan zijn de epd s van de umc s in het kader van het programma Registratie aan de bron 11 en de epd s van de NVZ-ziekenhuizen in het kader van het VIPP 12 -programma. Daarnaast is door het programma MedMij 13 gekozen voor implementatie van zibs en de BgZ. Ook de ggz heeft interesse uitgesproken in de BgZ in het kader van het Het feit dat op al deze terreinen wordt gekozen om de systemen zib-compliant te maken met de gegevens van de BgZ brengt eenduidige vastlegging en meervoudig gebruik van deze patiëntgegevens dichterbij. In het volgende hoofdstuk wordt beschreven op welke manier de BgZ in de praktijk kan worden gebruikt CCR%20CCD%20v1%200.pdf /12

5 2. De BgZ in de praktijk 2.1. Het model Het gebruik van de BgZ in de praktijk wordt beschreven aan de hand van het model in onderstaande figuur. Feitelijk is dat een detaillering van de middelste laag Gebruik BgZ in het model van figuur 1. Figuur 2 - Gebruiksmodel BgZ Het model laat vier stappen of fasen zien die worden onderscheiden bij het gebruik van de BgZ in de praktijk: 1. Vastleggen van de gegevens 2. Genereren van de BgZ 3. Delen van de BgZ 4. Gebruiken van de informatie die de BgZ biedt In het model is ook meegenomen de casus dat de BgZ binnen het eigen systeem wordt gebruikt en niet wordt gedeeld met gebruikers van andere systemen. Dat is vergelijkbaar met de casus van het gebruik van een zogenaamd basisdossier binnen een ziekenhuis. Met delen wordt in het model van figuur 2 dus bedoeld dat de gegevens worden gedeeld met gebruikers van andere systemen in andere organisaties. De vier stappen worden in de paragrafen hierna beschreven. Daarbij wordt met name aandacht besteed aan de functionele toepassing van de BgZ. Uiteraard vormen wettelijke kaders altijd het uitgangspunt. Meer daarover in paragraaf Vastleggen De eerste stap in het praktisch gebruik van de BgZ is dat de gegevens moeten worden vastgelegd. Vastleggen betekent in dit geval dat de gegevens die onderdeel zijn van de BgZ door een zorgverlener tijdens het zorgproces worden geregistreerd in het zorginformatiesysteem waarin hij/zij werkt. Uitgangspunt: een zorgverlener legt alleen gegevens vast die in het kader van het zorgproces voor hem/haar relevant zijn. In de praktijk betekent dit dat een zorgverlener niet bewust de gegevens die onderdeel zijn van de BgZ vastlegt, maar de gegevens die van belang zijn voor het zorgproces waarin hij/zij werkzaam is. Bepaalde gegevens die door hem/haar worden vastgelegd zullen onderdeel zijn van de BgZ, andere gegevens niet. Dat betekent ook dat een zorgverlener vaak maar een deel van de gegevens van de BgZ zal vastleggen. Het is dus absoluut niet de bedoeling dat wordt afgedwongen dat een zorgverlener alle gegevens van de BgZ vastlegt, als dat niet relevant is in het kader van het zorgproces waarin hij of zij werkzaam is. In de praktijk zijn verschillende zorgverleners (artsen, verpleegkundigen, paramedici) betrokken bij de zorg voor de patiënt en zullen ze allemaal gegevens in het dossier vastleggen. Elk van deze zorgverleners kan dus gegevens vastleggen die onderdeel zijn van de BgZ. 4/12

6 Een situatie die in de (ziekenhuis)praktijk ook kan voorkomen is dat gegevens die dezelfde patiënt betreffen, in verschillende systemen wordt vastgelegd. Zo is het mogelijk dat in een ziekenhuisomgeving een groot deel van de voor de BgZ relevante gegevens worden vastgelegd in het centrale epd-systeem, maar dat de IC of de SEH werkt in een eigen IC-, respectievelijk SEH-systeem. Voorbeeld 1: Een zorgverlener legt als enige gegevens betreffende een bepaalde patiënt vast in een zorginformatiesysteem. Als onderdeel van het zorgproces worden door hem/haar niet lichaamsgewicht en lichaamslengte vastgelegd. Dat betekent dat die gegevens niet vastgelegd zullen zijn in het systeem en ook niet beschikbaar zijn als uit dat systeem een BgZ wordt gegenereerd. Voorbeeld 2: In een ziekenhuis worden door de ene zorgverlener als onderdeel van de intake gegevens als sociale anamnese en gebruikte medicatie vastgelegd en door een andere zorgverlener gegevens als allergieën, diagnoses en nieuwe medicatieafspraken. Op het moment dat uit dat systeem een BgZ wordt gegenereerd zullen al die gegevens daarvan onderdeel zijn. Zib-compliance is noodzakelijk Om de gegevens die onderdeel zijn van de BgZ op een goede manier vast te kunnen leggen, moet het systeem waarin de gegevens worden geregistreerd zib-compliant zijn voor de onderdelen van de BgZ. Dat betekent o.a. dat het systeem de gegevens conform het gegevensmodel van de zib moeten kunnen opslaan of moet kunnen mappen. Maar ook dat de manier waarop de gegevens in het scherm worden getoond en vastgelegd, in lijn is met het gegevensmodel van de zib. Meer over zib-compliance is te vinden in het document Zib-compliance. Een raamwerk en aanpak voor toetsing Genereren In de vorige paragraaf is toegelicht op welke manier gegevens worden vastgelegd. De volgende stap is dat er op enig moment een BgZ voor een bepaalde patiënt wordt gegenereerd, op basis van de gegevens die in een systeem, of in meerdere systemen, zijn vastgelegd. Genereren moet in deze context worden gezien als het op applicatieniveau 15 bij elkaar brengen van de gegevens die tot de BgZ behoren, uit één of meer informatiesystemen. Het resultaat van deze stap is: dat een overzicht of een document met de BgZ-gegevens is ontstaan dat voor eigen gebruik kan worden opgeslagen of op het beeldscherm van de gebruiker kan worden getoond; dat een document met de BgZ-gegevens is ontstaan dat met anderen, binnen of buiten de eigen organisatie, kan worden gedeeld. De stap genereren kan in principe een simpele exercitie zijn als het gaat om het bij elkaar brengen van gegevens uit één bron (vergelijkbaar met een SQL-query op een database), maar ook complex als het gaat om gegevens die uit meerdere bronnen bij elkaar gebracht en gecombineerd moeten worden Er is bewust voor gekozen om in deze stap nog even weg te blijven van formats op basis van communicatiestandaarden als HL7 CDA en FHIR omdat die met name gerelateerd zijn aan de manier waarop de gegevens worden gedeeld, hetgeen in de volgende stap aan de orde zal komen. In de praktische uitvoering zullen de stappen genereren en delen sterk aan elkaar gerelateerd zijn en vaak in elkaar overlopen. 5/12

7 Genereren bestaat in principe uit de volgende stappen: Ontsluiten - van het bronsysteem c.q. de bronsystemen waarin de voor de BgZ relevante gegevens vastgelegd zijn Selecteren - van de voor de BgZ relevante gegevens uit de systemen op basis van de regels (business rules) die daar voor gelden (zoals die zijn geformuleerd in de definitie van de BgZ, bijvoorbeeld de laatst bekende bloeddruk) Accorderen - van, instemmen met de inhoud van de BgZ (indien gewenst) Bij deze stappen kunnen er in principe twee mechanismes een rol spelen: Automatisch, geïmplementeerd in de systemen Veel van de acties kunnen automatisch plaatsvinden op basis van duidelijke business rules en worden geprogrammeerd in de systemen. De business rules die ten grondslag liggen aan het samenstellen van een BgZ zijn goed gedefinieerd. De achilleshiel voor een automatische uitvoering is de kwaliteit waarmee de gegevens in het systeem, c.q. de systemen zijn vastgelegd. Handmatig, met betrokkenheid van de zorgverlener Bepaalde selecties of keuzes kunnen mogelijk niet (met voldoende kwaliteit) automatisch worden uitgevoerd; in die gevallen kan betrokkenheid van een zorgverlener van belang zijn. Ook waar het gaat om het accorderen (indien gewenst) kan het een keuze zijn om de verantwoordelijke zorgverlener actief betrokken te laten zijn. Hierbij nog de volgende opmerkingen: In geval de gegevens in een enkel systeem opgeslagen zijn, is ontsluiten relatief simpel, mits het systeem zib-compliant is (zie paragraaf 2.2). Maar in de praktijk kan er ook sprake zijn van een meer complexe situatie waarbij gegevens uit verschillende systemen moeten worden ontsloten. Daarbij kan worden gedacht aan systemen als ziekenhuisinformatiesystemen (ZIS), laboratoriuminformatiesystemen (LIS), aan specifieke systemen zoals een IC-systeem of een SEHsysteem, een cardiologisch epd, maar ook aan andere databasesystemen of data repositories. Het selecteren van gegevens houdt in dat de gegevens die volgens de definitie onderdeel zijn van de BgZ, worden geselecteerd. Dat zijn bijvoorbeeld de gemeten lichaamsgewichten. Als die in hetzelfde bronsysteem staan dan gaat het om het laatst bekende gewicht in dat systeem. Maar als er metingen in verschillende bronsystemen staan moet er worden vastgesteld welk van die metingen de laatst bekende meting is. Belangrijk is in alle gevallen dat de betrokken systemen zib-compliant zijn, zoals ook al aangegeven in paragraaf 2.2. Accorderen houdt in dat een zorgprofessional de gegenereerde gegevensset op volledigheid en eventueel juistheid beoordeeld en accordeerd. Het accorderen van de BgZ kan een stap zijn waarvoor bewust wordt gekozen. Het accorderen van een BgZ zal altijd handmatig plaatsvinden door een zorgverlener die daarvoor verantwoordelijkheid kan nemen. Het resultaat van de stap genereren is dat er een (al of niet geaccordeerde) BgZ beschikbaar is op applicatieniveau. 6/12

8 Voorbeeld 3: Een zorgverlener legt als enige gegevens betreffende een bepaalde patiënt vast in een zorginformatiesysteem. Op het moment dat een BgZ wordt gegenereerd om uit te wisselen met een andere zorgverlener worden de gegevens, die onderdeel zijn van de BgZ, automatisch door het systeem geselecteerd. De zorgverlener kan er voor kiezen om het verzenden ook automatisch te laten plaatsvinden, of het resultaat te controleren voordat het wordt verzonden. Voorbeeld 4: In een ziekenhuisomgeving worden gegevens betreffende een patient door meerdere zorgverleners in meerdere systemen vastgelegd. Ook labresultaten van de patient zijn vastgelegd in meerdere systemen. Op het moment dat een BgZ wordt gegenereerd, worden de gegevens geselecteerd in de verschillende systemen. Om de BgZ samen te stellen worden op basis van de context van de gegevens (zoals datum/tijdstip van vastleggen) bepaalde gegevens (zoals bepaalde labresultaten) wel/niet meegenomen in de BgZ. Omdat de gegevens in het kader van een overdracht worden gedeeld met zorgverleners in een andere organisatie wordt de BgZ handmatig geaccordeerd door de zorgverlener die verantwoordelijk is voor de overdracht. Voorbeeld 5: In een omgeving (zoals een ziekenhuis of kliniek) waarin door meerdere zorgverleners zorg wordt verleend aan een patiënt, wordt besloten om de gegevens van de BgZ onderdeel te laten zijn van het basisdossier. Dat is een verzameling patientgegevens die voor elke betrokken zorgverlener van belang worden geacht. Elke betrokken zorgverlener kan op elk moment als onderdeel van het zorgproces gegevens vastleggen in het systeem die onderdeel zijn van de BgZ. Op het moment dat een betrokken zorgverlener het basisdossier wil inzien worden automatisch alle gegevens geselecteerd en wordt de BgZ samengesteld en is in te zien in de schermen van het systeem Delen De volgende stap is in de meeste gevallen dat de BgZ wordt gedeeld. Hiermee wordt bedoeld dat de gegevens worden gedeeld of uitgewisseld met andere zorgverleners of met de patiënt. Voor het delen of uitwisselen van gegevens in de vorm van een BgZ zijn verschillende praktische oplossingen mogelijk. Daarbij spelen twee aspecten een rol: Er moet worden gekozen voor een format voor de uitwisseling van de gegevens. De twee standaard formats zijn op dit moment op basis van HL7 CDA of HL7 FHIR Er moet worden gekozen voor een infrastructurele oplossing die zal worden gebruikt voor het delen van de gegevens. Daarvoor zijn oplossingen mogelijk als: o Point-to-point push oplossingen gebaseerd op secure of secure FTP o Point-to-point push oplossingen gebaseerd op IHE XDM of IHE XDR o Publish & pull oplossingen gebaseerd op het IHE XDS profiel o Client-server push, pull oplossingen gebaseerd op FHIR RESTful services o AORTA (LSP) Meer details over deze oplossingen zijn te vinden in het document 16 Architectuur volume 2 Technische implementatie van zibs, de hoofdstukken 5 en _Volume_2_v1.0.pdf 7/12

9 Voorbeeld 6: Tussen twee ziekenhuizen zijn afspraken gemaakt dat in het kader van de overdracht van bepaalde patiënten van het ene ziekenhuis naar het andere (o.a.) de BgZ wordt uitgewisseld. Op het moment van overdracht wordt door het ene ziekenhuis de BgZ van de betreffende patient gegenereerd (zoals beschreven in de vorige paragraaf) en wordt er een HL7 CDA document van gemaakt. Dat document wordt gepubliceerd op een regionale IHE-XDS gebaseerde infrastructuur. Het tweede ziekenhuis krijgt een melding van publicatie en haalt het HL7 CDA document op. Voorbeeld 7: Een patiënt maakt gebruik van een PGO (Persoonlijke Gezondheidsomgeving) die compatibel is met de MedMij-afspraken en -standaarden. D.m.v. van een HL7 FHIR koppeling kan de patiënt zijn/haar BgZ downloaden via de website van het ziekenhuis waar hij/zij in behandeling is. Functionele en technische implementatie Ten aanzien van de praktische implementatie speelt er nog een aspect dat te maken heeft met het verschil tussen de functionele implementatie en de technische implementatie van de uitwisseling. De functionele implementatie refereert aan de gegevens die in het kader van de use case daadwerkelijk door de gebruiker (zorgverlener) in het kader van het zorgproces worden vastgelegd en vervolgens uitgewisseld met een andere gebruiker (zorgverlener). Uitgangspunt bij registratie is, zoals genoemd in paragraaf 2.2, dat de zorgverlener alleen die gegevens vastlegt die voor het zorgproces van belang zijn en dus niet per se alle gegevens die onderdeel zijn van de BgZ. In een bepaalde use case kan dat bijvoorbeeld betekenen dat wel diagnoses, medicatiegegevens, vaccinaties en vitale functies vastgelegd en als onderdeel van de BgZ uitgewisseld worden, maar niet bijvoorbeeld geplande zorgactiviteiten. Functioneel wordt er in dat geval feitelijk een subset van de BgZ-gegevens vastgelegd en uitgewisseld. De technische implementatie refereert aan de manier waarop de daadwerkelijke technische uitwisseling plaatsvindt en de implementatie daarvan in de software. Zoals hiervoor beschreven zijn daarbij met name twee standaarden van belang: HL7 CDA en HL7 FHIR. Voor bijvoorbeeld HL7 CDA betekent dit dat er landelijk een standaard HL7 CDA document is gespecifieerd voor de BgZ. Dat document wordt in de software van de systemen geïmplementeerd en in de praktijk uitgewisseld. Ook in geval van een HL7 FHIR implementatie is er een landelijke standaardspecificatie die in de software moet worden geïmplementeerd. Zo n implementatie in software kost de nodige inspanningen, tijd en geld. Als de technische implementatie van bijvoorbeeld een HL7 CDA document gebeurt voor de volledige BgZ, d.w.z. met alle gegevenselementen die onderdeel zijn van de definitie van de BgZ, dan kan er, technisch gezien altijd een volledige BgZ worden uitgewisseld. Maar afhankelijk van de use case (de functionele implementatie), kan er slechts een deel van de gegevens van de BgZ ingevuld kan. Dat betekent dat de technische implementatie van de BgZ in een systeem maar eenmaal plaats hoeft te vinden. Vervolgens is het relatief gemakkelijk om use cases voor uitwisseling te ondersteunen, waarbij het op functioneel niveau voldoende is om de BgZ-gegevens of een subset daarvan uit te wisselen Gebruiken De laatste stap is het gebruiken van de gegevens die gedeeld of overgedragen zijn. Uitgangspunt is dat de gegevens voor de partij waarmee de gegevens worden gedeeld (de ontvanger), bruikbaar zijn. Bijvoorbeeld ter ondersteuning van een klinische taak als onderdeel van een zorgproces (als de ontvanger een zorgverlener is). Of voor de patiënt, als inzage in gegevens die een zorgaanbieder over hem of haar heeft vastgelegd. 8/12

10 In de praktijk zal er door de ontvangende partij een eerste check worden gedaan waarbij wordt gekeken of de gegevens er leesbaar en relevant uitzien, en van belang zijn voor de uit te voeren klinische taak. Een belangrijke rol speelt daarbij helderheid over en vertrouwen in de partij die de gegevens deelt. In de verdere verwerking kunnen de volgende aspecten/overwegingen op enig moment (d.w.z. bij ontvangst van de BgZ, maar ook op later moment ) een rol spelen: Opname, behoud - Wat gebeurt er met het ontvangen document? Wordt het document opgeslagen? Zo ja, op welke manier en waar? Hoe lang wordt het bewaard? Hergebruik - In hoeverre kunnen gegevens worden hergebruikt? NB. Gegevens die vastgelegd zijn voor een bepaald doel zijn niet noodzakelijkerwijs geschikt voor hergebruik voor een ander doel. Reconciliatie, assimilatie - In hoeverre worden de ontvangen gegevens op gestructurerde wijze opgenomen in het eigen dossier van de ontvanger (ander dan alleen opslag als document/brief)? Worden gegevens van de ontvangen BgZ geselecteerd om die vervolgens gestructureerd over te nemen in het eigen dossier? Voorbeeld 8: Een zorgverlener ontvangt in het kader van de overdracht van een patiënt een BgZ betreffende die patiënt van een andere zorginstelling. Als onderdeel van die BgZ worden het actuele medicatiegebruik en de actuele medicatie- en toedieningsafspraken meegestuurd. De zorgverlener bespreekt deze tijdens het consult met de patiënt, stelt vast dat het inderdaad de actuele gegevens zijn en neemt deze gegevens over in het eigen dossier (reconciliatie). Voorbeeld 9: Een patiënt maakt gebruik van een PGO die compatibel is met de MedMij-afspraken en -standaarden en downloadt zijn/haar BgZ via de website van het ziekenhuis waar hij/zij in behandeling is. Als hij/zij de BgZ bekijkt, blijkt dat er in het ziekenhuis blijkbaar geen informatie is over zijn/haar allergieën en intoleranties. Hij/zij neemt vervolgens actie om het ziekenhuis te informeren dat hij/zij in ernstige mate overgevoelig is voor penicilline Eén definitie, een veelvoud aan instantiaties In de voorgaande paragrafen is beschreven dat gegevens door zorgverleners tijdens het zorgproces worden vastgelegd, al of niet in verschillende bronsystemen (par. 2.2). Op een bepaald moment wordt er op basis van de definitie van de BgZ een concrete instantiatie 17 van een BgZ gegenereerd (par. 2.3), gedeeld (par. 2.4) en gebruikt (par. 2.5). Alhoewel er dus één definitie is van de BgZ, is er in principe een veelvoud van instantiaties mogelijk voor een bepaalde patient, afhankelijk van het moment waarop, en uit welk systeem of welke systemen de instantiatie wordt gegenereerd. De BgZ is dus geen persistent document 18 dat in de loop van de tijd aangevuld wordt, maar een samenvatting van de gegevens in een dossier op een bepaald moment in de tijd (een snapshot). Die eigenschap maakt de BgZ niet minder waardevol, maar het is van belang om dit te onderkennen bij het praktisch gebruik. 17 Een instantiatie van een BgZ betekent in dit geval dat er op basis van de definitie van de BgZ een concrete invulling wordt gerealiseerd van de BgZ, op een bepaald moment, voor een bepaalde patient, op basis van gegevens van uit een bepaald bronsysteem of bronsystemen. 18 Een document dat langere tijd van waarde blijft 9/12

11 3. Wat verder van belang is In het voorgaande hoofdstuk zijn de basisprincipes beschreven van de manier waarop de BgZ in de praktijk kan worden gebruikt. Daarnaast zijn er nog andere aspecten/overwegingen die een rol (kunnen) spelen als de BgZ in de praktijk wordt toegepast. In dit hoofdstuk wordt een aantal daarvan aan de orde gesteld Wettelijke kaders Dit document richt zich met name op een toelichting van de functionele toepassing van de BgZ. Overeenkomstig de lagen van interoperabiliteit 19 zijn aanvullende afspraken nodig om in de praktijk te komen tot implementatie van een informatieoverdracht. Daarbij gelden uiteraard altijd de wettelijke kaders als uitgangspunt. Overeenkomstig de eis uit de Algemene Verordening Gegevensbescherming (AVG 20 ) zal een Data Privacy Impact Assessment (DPIA 21 ) voor iedere gegevensverwerking onderdeel moeten zijn van de implementatie. Op basis hiervan moet worden bepaald wat er in een bepaalde use case kan en mag worden uitgewisseld. Ook ontwikkelingen in het kader van de Wet Cliëntenrechten 22 bij elektronische verwerking van gegevens in de zorg zijn van belang. Dat betreft o.a. gespecificeerde patiënttoestemming 23 bij de uitwisseling en verwerking van gegevens De behandelend zorgverlener is verantwoordelijk In het voorgaande hoofdstuk zijn allerlei praktische aspecten beschreven van de manier waarop een BgZ in de praktijk kan worden gebruikt. Daaruit blijkt dat de BgZ als patient summary een belangrijke toegevoegde waarde kan hebben als het gaat om het ondersteunen van continuïteit van zorg. Maar ook dat er allerlei praktische aspecten een rol spelen waar het bijvoorbeeld gaat om volledigheid, actualiteit en doelmatigheid van de gegevens die beschikbaar komen via de BgZ. Het is in dit soort gevallen altijd aan de behandelende zorgverlener, d.w.z. de gebruiker van de BgZ, of en in hoeverre hij/zij gebruik maakt van de gegevens die op die manier ontvangen zijn. Daarbij spelen de overwegingen die genoemd zijn in paragraaf 2.5 o.a. een rol Het gebruik van gegevens voor andere doeleinden zoals registraties In dit document ligt de nadruk op het gebruik van de BgZ door zorgverleners als ondersteuning van continuïteit van zorg, en op de interactie tussen zorgverleners/zorgaanbieders en patiënt. Andere mogelijke toepassingen van de BgZ zijn bijvoorbeeld de aanlevering van gegevens aan (kwaliteitsregistraties) of ten behoeve van onderzoek. De manier waarop dat in de praktijk kan werken en de overwegingen ten aanzien van volledigheid, actualiteit en doelmatigheid zijn vergelijkbaar met hetgeen in dit document beschreven is Als de BgZ niet genoeg is In de voorgaande hoofdstukken was het uitgangspunt, dat de BgZ werd gedeeld of uitgewisseld. In specifieke use cases is het heel goed denkbaar dat er naast de gegevens die onderdeel zijn van de BgZ, andere aanvullende gegevens wenselijk en noodzakelijk zijn. De vraag welke (extra) informatie bij een overdracht nodig is naast de BgZ, is in zijn algemeenheid niet te beantwoorden. Het antwoord is sterk afhankelijk van de situatie. Vaak zal de reden van overdracht (de /12

12 verwijsreden ) al heel veel extra informatie geven. Daarnaast zullen vaak aandoeningspecifieke gegevens nodig zijn die niet in de BgZ zitten. Voor een deel kunnen deze aanvullende gegevens deel uitmaken van een overdrachts- of verwijsbrief, waarin de verwijzer ook meer toelichting kan geven in de vorm van proza. En dan nog zal na overdracht van gegevens, in de praktijk vaak blijken dat er vragen overblijven en er aanvullende informatie nodig is. In de dagelijkse praktijk heeft de ontvangend zorgverlener een aantal opties om aan aanvullende informatie te komen, zoals bellen of mailen met de verwijzer. Gemakkelijker en efficiënter wordt het als de ontvanger in de nabije toekomst, zelf de mogelijkheid krijgt aanvullende gegevens te raadplegen via het LSP, een XDS-netwerk of de Persoonlijke Gezondheidsomgeving van de patiënt Context Context 24 is een belangrijk begrip dat ook in relatie tot de BgZ van belang is. Voor een juiste interpretatie van de gegevens die onderdeel zijn van de BgZ, is de context van die gegevens essentieel. Zo kan het bijvoorbeeld van belang zijn om te weten welke medicatie wordt gebruikt naar aanleiding van welke diagnose. De BgZ biedt echter zelf geen context informatie: het is een verzameling van losse patientgerelateerde gegevens die op een bepaald moment bij elkaar worden gebracht (soms uit verschillende bronsystemen) om op dat moment een patient summary, de BgZ, te vormen. Bepaalde zibs geven echter de mogelijkheid om relaties te leggen en daarmee context aan te brengen. In het genoemde voorbeeld zijn zowel gebruikte medicatie als diagnoses (problemen) elementen van de BgZ. De zib Medicatieafspraak die onderdeel vormt van de medicatiegegevens biedt de mogelijkheid om de relatie naar de reden van voorschrijven (de diagnose) aan te geven, en geeft in dat geval een bepaalde context. In de praktijk zal die informatie vaak niet echter beschikbaar zijn. Er zijn beperkte mogelijkheden om op die manier context mee te geven. Als die context niet op die manier (dat wil zeggen op basis van de mogelijkheden die de zibs daarvoor bieden) is vastgelegd, dan is die context niet aanwezig in de BgZ. Het overdragen van de BgZ, zonder verdere contextinformatie, is vaak niet voldoende voor de continuïteit van zorg. In dat geval zijn samenwerkings- en procesafspraken nodig en/of aanvullende gegevens (bijvoorbeeld in de vorm van een begeleidende brief) om voldoende context te hebben en de behandeling over te kunnen nemen en voort te zetten. 24 Een paar definities voor context: Context is de totale omgeving waarin iets zijn betekenis krijgt Context is het verband waarin iets zich voordoet 11/12

13 Bijlage Inhoud BgZ gebaseerd op zibs release 2017 # 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 v3.1 BurgerlijkeStaat v3.0 Betaler v3.1 3 Behandelrestricties 3.1 Behandelaanwijzingen Bekende behandelaanwijzingen BehandelAanwijzing v Wilsverklaring Bekende wilsverklaring Wilsverklaring v3.1 4 Contactpersonen 4.1 Contactpersoon Eerste relatie/contactpersoon Contactpersoon v3.1 5 Functionele status 5.1 Functionele/mentale status 6 Klachten en diagnoses 6.1 Problemen (incl. diagnoses) Laatst bekende functionele/mentale status Bekende problemen van alle probleemtypen FunctioneleOfMentaleStatus v3.1 Probleem v4.1 7 Sociale anamnese 7.1 Woonsituatie Laatst bekende woonsituatie Woonsituatie v Drugsgebruik Bekend drugsgebruik Drugsgebruik v Alcoholgebruik Bekend alcoholgebruik Alcoholgebruik v Tabakgebruik Bekend tabakgebruik Tabakgebruik v Voedingsadviezen Bekende voedingsadviezen Voedingsadvies v3.1 8 Waarschuwingen 8.1 Alerts Bekende alerts Alert v3.2 9 Allergieën 9.1 Allergie-intoleranties Bekende allergieën AllergieIntolerantie v Medicatie 10.1 Medicatieafspraak Bekende medicatieafspraken Medicatieafspraak v Medische hulpmiddelen 10.2 Toedieningsafspraak Bekende toedieningsafspraken ToedieningsAfspraak v Medicatiegebruik Bekend medicatiegebruik MedicatieGebruik2 v Medische hulpmiddelen Bekende medische hulpmiddelen MedischHulpmiddel v Vaccinaties 12.1 Vaccinaties Bekende vaccinaties Vaccinatie v Vitale functies 13.1 Bloeddruk Laatst bekende bloeddruk Bloeddruk v Lichaamsgewicht Laatst bekende lichaamsgewicht Lichaamsgewicht v Lichaamslengte Laatst bekende lichaamslengte Lichaamslengte v 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) LaboratoriumUitslag v4.1 Verrichting v4.1 Contact v3.1 OverdrachtGeplande- ZorgActiviteit 18 Zorgverleners 18.1 Huisarts De gegevens van de huisarts Zorgverlener v3.2 v3.1 12/12