|
|
| (132 tussenliggende versies door 2 gebruikers niet weergegeven) |
| Regel 1: |
Regel 1: |
| − | {{DISPLAYTITLE:Functioneel Ontwerp BgZ medisch-specialistische zorg|noreplace}}
| + | {{NoteBox|Dit materiaal is vervallen! |
| − | __NUMBEREDHEADINGS__
| |
| − | {{NoteBox|Dit materiaal wordt nog bewerkt en is nog niet definitief!}} | |
| − | =Inleiding=
| |
| − | ==Algemeen==
| |
| − | Deze informatiestandaard beschrijft de uitwisseling van de Basisgegevensset Zorg (BgZ) tussen zorgverleners. De Basisgegevensset Zorg is de minimale verzameling van patiëntgegevens die specialisme-, ziektebeeld- en beroepsgroepoverstijgend relevant is en van belang voor de continuïteit van zorg. Deze gegevensverzameling kan uitgewisseld worden tussen instellingen en patiënten (bijvoorbeeld middels MedMij en PGO's), en tussen instellingen onderling. Deze informatiestandaard richt zich op de uitwisseling tussen zorgaanbieders van medisch-specialistische zorg. Waar de BgZ beschrijft hoe de BgZ eruit ziet, beschrijft deze informatiestandaard hoe de BgZ in de medisch-specialistische zorg toegepast wordt (c.q. kan worden).
| |
| | | | |
| − | Er worden twee use cases uitgewerkt:
| + | Zie: [[Landingspagina_BgZ|Landingspagina BgZ]] voor de meest recente versies. |
| − | # uitwisselen BgZ bij verwijzing;
| |
| − | # opvragen BgZ van een eerdere behandeling elders.
| |
| − | | |
| − | Voor meer over informatiestandaarden, zie: [https://www.nictiz.nl/standaardisatie/informatiestandaarden/wat-is-een-informatiestandaard/ Wat is een informatiestandaard]
| |
| − | | |
| − | Het functioneel ontwerp beschrijft voor alle uitwisselscenario's (in dit document use cases genoemd) uit de informatiestandaard de transacties, transactiegroepen, de systemen, de systeemrollen en de bedrijfsrollen van zorgverleners of patiënten. Daarvoor worden de eisen gegeven voor het sturen of ontvangen van gegevens. In hoofdstuk 2 wordt verder ingegaan op wat een use case inhoudt. Per use case zijn de nadere details beschreven. Voor meer informatie over informatiestandaarden en hoe deze worden ontwikkeld, zie de [https://www.nictiz.nl/standaardisatie/informatiestandaarden/|Nictiz webpagina voor informatiestandaarden].
| |
| − | | |
| − | ==Doelgroep==
| |
| − | * Betrokkenen bij beleid over digitale uitwisseling tussen instellingen.
| |
| − | * Medisch specialisten en daarbij betrokken zorgverleners.
| |
| − | * Zorg-ICT architecten, functionele en applicatiebeheerders.
| |
| − | * Productmanagers, architecten, ontwerpers en testers van XIS-leveranciers, regio-organisaties.
| |
| − | | |
| − | ==Kaders en uitgangspunten==
| |
| − | * De BgZ2017 en BgZ2020 zijn basis voor de informatiestandaard. Dus eventuele overige additionele noodzakelijke informatie (zoals radiologiebeelden, informatie die niet in de BgZ voorkomt) vallen buiten deze informatiestandaard.
| |
| − | * Het betreft de uitwisseling van één BgZ, niet het opvragen en samenvoegen van meerdere BgZ's. Aan de wijze waarop meerdere BgZ's verwerkt worden in het EPD (sequentieel of parallel) stelt de informatiestandaard geen eisen.
| |
| − | ===Richtlijn en proces===
| |
| − | De informatiestandaard betreft de volgende zorgprocessen:
| |
| − | # Vanuit de zorgverlener verzenden van de BgZ bij een verwijzing of overdracht van een patiënt/cliënt naar een andere instelling binnen de medisch-specialistische zorg.
| |
| − | #* Het gaat om een verwijzing of overdracht waarbij de ontvangende zorgverlener een eigen behandelovereenkomst met de patiënt aangaat, niet om collegiaal consult etc.
| |
| − | # Vanuit de zorgverlener opvragen van de BgZ bij een andere instelling voor medisch-specialistische zorg waar de patiënt onder behandeling is of is geweest.
| |
| − | Dat laatste betreft instellingen waarvan bekend is dat de patiënt daar onder behandeling is geweest; "zoeken" naar dergelijke instellingen is geen onderdeel van deze informatiestandaard.
| |
| − | | |
| − | In scope zijn zowel de activiteiten van zorgverleners als administratieve medewerkers ((overnemen van medische informatie, contactpersonen, eigen huisarts en dergelijke).
| |
| − | | |
| − | ===Inzet zibs en doorontwikkeling===
| |
| − | De BgZ is een gegevensverzameling gebaseerd op een aantal zibs. Daarbij is de BgZ als uit te wisselen verzameling soms beperkt, bijvoorbeeld tot de laatste klinische uitslagen. De intentie van zibs is het implementeren van herbruikbare bouwstenen voor eenmalig vastlegging en meervoudig gebruik. Zibs zijn dan ook bouwstenen in veel andere verzamelingen dan de BgZ. Deze andere verzamelingen zijn deels al in ontwikkeling (in de Oncologie, in de Geboortezorg etc.). Daarnaast zullen zibs ook de basis zijn van onderzoek en kwaliteitsverantwoording. De te implementeren zibs zullen dus ook bouwstenen zijn voor deze andere processen.
| |
| − | | |
| − | Daarom dienen de zibs zodanig in de systemen geïmplementeerd te worden, dat hergebruik voor andere doeleinden dan de BgZ gefaciliteerd wordt. Doel is hergebruik op alle gebieden van de zorg, niet alleen implementatie van de BgZ. De informatiestandaard BgZ kan gebruik buiten de BgZ niet specificeren of kwalificeren, maar gebruik buiten de scope van de BgZ is wel het doel.
| |
| − | ===Specifieke zorgprocessen===
| |
| − | Veel zaken kunnen niet in een algemene standaard over de BgZ afgesproken worden, maar alleen binnen een specifiek zorgproces. Zo kunnen aan de BgZ hier weinig eisen gesteld worden over al dan niet verplicht gevulde gegevens, al dan niet overnemen etc. In een concreet zorgproces, bijvoorbeeld het overdragen van een COVID-19 patiënt of een doorverwijzing naar een academisch ziekenhuis bij een complex colorectaal carcinoom met metastasen, kunnen uiteraard veel specifiekere afspraken gemaakt worden.
| |
| − | | |
| − | Veel delen van deze informatiestandaard zijn daarom "informatief". Dat geeft aan dat een instelling hier de vrijheid heeft om dit al dan niet toe te passen. Door het opnemen in deze informatiestandaard wordt wel een context geschetst, waarnaar in dergelijke gedetailleerdere specificaties verwezen kan worden.
| |
| − | | |
| − | ===Reikwijdte Informatiestandaard===
| |
| − | De reikwijdte van de informatiestandaard beslaat de functionele beschrijvingen en de dataset voor alle gegevensuitwisselingen binnen één of meerdere zorgprocessen.
| |
| − | ====Instellingen====
| |
| − | In scope zijn de volgende instellingen:
| |
| − | # universitair medische centra;
| |
| − | # ziekenhuizen;
| |
| − | # klinische revalidatiecentra;
| |
| − | # dialysecentra;
| |
| − | # radiotherapeutische centra;
| |
| − | # epilepsiecentra;
| |
| − | # audiologische centra;
| |
| − | # overige zelfstandige klinieken.
| |
| − | | |
| − | ====Buiten scope====
| |
| − | * Uitwisseling tussen of opvragen van andere zorgverleners dan zorgverleners binnen medisch-specialistische zorg (huisartsen, GGZ-instellingen, verpleeghuizen e.d.).
| |
| − | * BgZ in kader van acute zorg/SEH.
| |
| − | * Verwijzingen van/naar andere sectoren (1e lijn, GGZ, …).
| |
| − | * Multidisciplinair overleg (MDO).
| |
| − | * Ontslagbrief (BgZ-uitwisseling naar 1e lijn).
| |
| − | * Uitwisseling binnen de instelling.
| |
| − | * Documenten anders dan een gestructureerde en machine-leesbare BgZ.
| |
| − | Uiteraard kan voor ieder proces dat buiten scope valt de informatiestandaard gebruikt worden voor zover van toepassing. Er worden echter geen aanpassingen doorgevoerd n.a.v. processen buiten scope.
| |
| − | | |
| − | ===Infrastructuur===
| |
| − | * Infrastructuur voor uitwisseling of opvraging is buiten scope.
| |
| − | * Waar in deze informatiestandaard gesproken wordt over "sturen", "ontvangen" en dergelijke, wordt nadrukkelijk geen uitspraak gedaan over infrastructurele aspecten, maar over de functionaliteit voor de zorgverlener. Dus waar de zorgverlener een handeling verricht waarna een collega elders een dossier in kan zien, is er sprake van "verzenden", ongeacht of er technisch gegevens worden opgehaald of opgestuurd.
| |
| − | | |
| − | ==Kwalificatie==
| |
| − | Op basis van dit FO en de daarbij behorende dataset is een kwalificatiescript opgesteld. Het opstellen van kwalificatiescripts valt buiten de scope van dit FO. Voor meer informatie zie de [[BgZ:V1.0_BgZ_MSZ_Kwalificatie|Kwalificatie BgZ Medisch-specialistische zorg]].
| |
| − | | |
| − | ==Begrippenkader==
| |
| − | {| class="wikitable"
| |
| − | |-
| |
| − | | BgZ || De Basisgegevensset Zorg is de minimale set van patiëntgegevens die specialisme-, ziektebeeld- en beroepsgroepoverstijgend relevant is en van belang voor de continuïteit van zorg. Zie [https://www.nictiz.nl/standaarden/basisgegevensset-zorg/ BgZ]
| |
| − | |-
| |
| − | | Dossier || De schriftelijk of elektronisch vastgelegde gegevens met betrekking tot de verlening van zorg aan een patiёnt.
| |
| − | |-
| |
| − | | Dossierhouder || De zorgverlener of instelling die het dossier beheert.
| |
| − | |-
| |
| − | | Dossierplicht || De verplichting om een dossier te voeren zoals vastgelegd in de WGBO. De WGBO stelt dat een dossier bijgehouden wordt "voor zover dit voor een goede hulpverlening aan de patiënt noodzakelijk is". We gaan er hier van uit dat wanneer een zorgverlener gegevens vastlegt, dit voortvloeit uit deze plicht, en dat gegevens die niet nodig zijn, niet vastgelegd worden.
| |
| − | |-
| |
| − | | Duplicaatdetectie || Vinden van duplicaatgegevens op basis van identificerende informatie. Bij betrekken van gegevens uit andere bronnen kunnen makkelijk dezelfde gegevens meerdere keren verkregen worden.
| |
| − | |-
| |
| − | | Elektronisch patiëntendossier || Verzameling van alle elektronisch vastgelegde persoonlijke gezondheidsinformatie van een cliënt bij een zorginstelling of een andere organisatie die persoonlijke gezondheidsinformatie verwerkt.
| |
| − | |-
| |
| − | | Externe gegevens || Gegevens die een zorgverlener vastlegt in het eigen dossier, maar duidelijk herkenbaar als komende uit een externe bron. Van bijvoorbeeld verrichtingen of metingen uit het verleden kan een zorgverlener wel kennis nemen, maar er nooit de auteur van worden.
| |
| − | |-
| |
| − | | Gegevensontvanger || De zorgverlener of instelling die een BgZ ontvangt van de dossierhouder.
| |
| − | |-
| |
| − | | Gegevensverstrekker || De dossierhouder die een BgZ deelt met een gegevensontvanger.
| |
| − | |-
| |
| − | | Hergebruiken || Het gebruiken van gegevens die oorspronkelijk elders zijn vastgelegd door een zorgverlener in het eigen zorgproces. Inzien en overnemen zijn beide vormen van hergebruik van gegevens.
| |
| − | |-
| |
| − | | Inzien || De zorgverlener neemt kennis van de gegevens die gedeeld zijn.
| |
| − | |-
| |
| − | | Metagegevens || Gegevens over het oorspronkelijke brongegeven, bijvoorbeeld identificatie, verantwoordelijke, auteur, datum vastlegging, instelling van vastlegging. Er kunnen metagegevens zijn per document (BgZ) of per zib.
| |
| − | |-
| |
| − | | Ontdubbelen || Na duplicaatdetectie maar één keer tonen of overnemen van gedupliceerde gegevens.
| |
| − | |-
| |
| − | | Overnemen || De zorgverlener neemt gegevens die oorspronkelijk elders zijn vastgelegd over in het eigen dossier. Na overnemen is de zorgverlener altijd [[#Verantwoordelijkheid|verantwoordelijk]] voor de gegevens.
| |
| − | | |
| − | Overnemen van gestructureerde en gecodeerde gegevens dient te gebeuren met een enkele handeling, zonder de knip- en plakfuncties van tekstverwerking. Waar in deze standaard gesproken wordt van overnemen van gegevens, wordt altijd gestructureerd overnemen bedoeld, en nooit handmatig knippen en plakken van losse velden, of overtypen van gegevens.
| |
| − | |-
| |
| − | | Reconciliëren || Het proces waarmee voorkomen wordt dat conflicterende of gedupliceerde gegevens ontstaan, en waarmee geborgd wordt dat alleen gegevens worden overgenomen die de zorgverlener in het kader van de dossierplicht over wil nemen.
| |
| − | |-
| |
| − | | Uitwisselen || Het delen van gegevens buiten de zorginstelling.
| |
| − | |-
| |
| − | | Zib || Zorginformatiebouwsteen, zie [http://www.zibs.nl zibs.nl]
| |
| − | |-
| |
| − | | Zorgaanbieder || Een instelling dan wel een solistisch werkende zorgverlener.
| |
| − | |-
| |
| − | | Zorginstelling || Een rechtspersoon die zorgaanbieder is.
| |
| − | |-
| |
| − | | Zorgverlener || Individuele beroepsbeoefenaar, zoals geregeld in of op grond van artikel 3 en 34 Wet BIG.
| |
| − | |}
| |
| − | | |
| − | Zie ook: [https://www.nictiz.nl/standaardisatie/overzichten/begrippen/ Nictiz Begrippenlijst] | |
| − | | |
| − | Hieronder is de samenhang van een aantal centrale begrippen weergegeven. Lezend van links naar rechts: Hergebruiken kan zijn: Inzien of Overnemen. Bij Overnemen worden Metagegevens bron en Externe gegevens overgenomen.
| |
| − | [[Bestand:Begrippen.png|omkaderd|links]] | |
| − | <br clear=all>
| |
| − | | |
| − | ==Juridische aspecten==
| |
| − | Zie de [https://www.rijksoverheid.nl/documenten/brochures/2021/03/03/factsheet-toestemmingen-voor-het-uitwisselen-van-medische-gegevens-tussen-zorgverleners Factsheet 'Toestemmingen voor het uitwisselen van medische gegevens tussen zorgverleners'] van VWS voor meer informatie.
| |
| − | | |
| − | {{NoteBox|Deze sectie is informatief. Wetgeving en documentatie van VWS is hier leidend.}}
| |
| − | | |
| − | Het regelen van toestemming is buiten scope van deze informatiestandaard. Toestemming is geregeld in wetgeving, niet in informatiestandaarden. Hier wordt dan ook alleen de context geschetst.
| |
| − | ===Toestemming===
| |
| − | De grondslag voor het delen van de BgZ tussen zorgverleners is altijd toestemming van de patiënt (het delen van de BgZ binnen de instelling en binnen de behandelrelatie laten we buiten scope, het gaat hier altijd om het delen van de BgZ tussen instellingen). Daarbij kan sprake zijn van uitdrukkelijke of veronderstelde toestemming.
| |
| − | Bij het uitwisselen van de BgZ is altijd '''uitdrukkelijke toestemming''' nodig.
| |
| − | ===Relevantie===
| |
| − | Bij delen van medische informatie op basis van veronderstelde toestemming is het alleen toegestaan die informatie te delen die nodig is voor de behandeling. Daarbij treden een aantal complexiteiten op:
| |
| − | * de ontvangende arts is vaak beter in staat te beoordelen welke informatie nodig is voor de behandeling dan de verzendende arts;
| |
| − | * er is weinig informatie waarvan zeker is dat die nooit relevant is - zo kunnen psychische aspecten bij veel behandelingen een rol spelen, zijn contactpersonen en familieleden relevant bij onverwachte calamiteiten etc.;
| |
| − | * de BgZ kan dermate omvangrijk zijn dat het praktisch ondoenlijk is voor de verzendende arts die informatie grondig te filteren;
| |
| − | * niet gedeelde informatie kan veelal afgeleid worden uit wel gedeelde informatie (zo is uit medicatie vaak af te leiden welke aandoeningen spelen).
| |
| − | In de medisch-specialistische zorg is daarom het uitgangspunt dat de hele BgZ relevant kan zijn en gedeeld mag worden. Wel is bij het uitwisselen van de BgZ daarom altijd '''uitdrukkelijke toestemming''' nodig. De reden dat geen veronderstelde toestemming gebruikt kan worden is dat de BgZ een "brede" verzameling gegevens is, die niet alle relevant hoeven te zijn voor het voorhanden probleem.
| |
| − | Mocht in uitzonderlijke gevallen de dossierhoudende zorgverlener niet de hele BgZ, maar enkel een deel daarvan uit willen wisselen met een zorgverlener elders dan dient daarvoor een andere oplossing dan het delen van de BgZ gekozen te worden.
| |
| − | | |
| − | ===Toestemming verlenen===
| |
| − | Bij '''verwijzing''' kan de dossierhouder op moment van verwijzing vragen naar de toestemming. De patiënt verleent die, of niet, en er kan in overeenstemming daarmee gehandeld worden.
| |
| − | | |
| − | Bij '''opvragen''' van gegevens eerdere behandeling zijn er twee mogelijkheden:
| |
| − | # Er is sprake van '''eerder gegeven toestemming''' aan de dossierhouder. Bijvoorbeeld, een patiënt kan bij behandeling in ziekenhuis A toestemming geven om later gegevens omtrent die behandeling te delen met ziekenhuis B in de eigen regio, wanneer daar reden voor is. In dat geval kan de BgZ worden opgevraagd met als grondslag deze eerder gegeven toestemming. Deze eerder gegeven toestemming dient uiteraard te voldoen aan de wet- en regelgeving, dus voldoende specifiek te zijn om deze gegevens te mogen delen met deze instelling. De eerder gegeven toestemming kan uit een toestemmingsregister komen, maar kan ook bij de bevraagde zorginstelling vastgelegd zijn, bijvoorbeeld in een patiëntenportaal. De eerder gegeven toestemming kan ook kort voor het opvragen geregeld worden, bijvoorbeeld als onderdeel van het maken van een afspraak.
| |
| − | # De patiënt verleent '''op dat moment toestemming'''. Deze toestemming moet gedeeld worden met de dossierhouder, die daarna actief het dossier ter beschikking stelt. De toestemming moet gegeven worden aan de dossierhouder, niet aan de opvragende partij, en wordt op een betrouwbare wijze gedeeld. Zie ook bovengenoemde Factsheet, waar deze optie beschreven wordt.
| |
| − | | |
| − | Een eerder gegeven toestemming verdient altijd de voorkeur omdat deze rechtstreeks aan de dossierhouder gegeven wordt en efficiënter is. Er kan echter niet van uitgegaan worden dat dit altijd mogelijk of gedaan is. Optie 2 is dus een alternatief wanneer er geen eerder gegeven toestemming is en er toch inzage gewenst is.
| |
| − | | |
| − | ===Geen toestemming===
| |
| − | Wanneer de patiënt bezwaar maakt tegen digitale uitwisseling wordt de BgZ niet uitgewisseld. (Deze informatiestandaard gaat niet over de vraag of de informatie op andere wijze, zoals papier of een PGO, gedeeld wordt.)
| |
| − | ===Afschermen gegevens===
| |
| − | Afschermen van gegevens die niet gedeeld mogen worden is een functionaliteit van het verzendende systeem en niet van de BgZ-uitwisseling. Wanneer een patiënt bezwaar maakt tegen het delen van bepaalde gegevens met anderen, maar die niet uit het EPD van de eigen instelling verwijderd wil zien, moet het systeem de mogelijkheid bieden per type zib aan te geven dat dit niet gedeeld mag worden. Zo kan een patiënt bijvoorbeeld het delen van Drugsgebruik en Alcoholgebruik af laten schermen voor delen, terwijl de overige gegevens wel gedeeld mogen worden. Bij het genereren van de BgZ moet dan rekening gehouden worden met afgeschermde gegevens. Dit afschermen kan vastgelegd worden op EPD-niveau, bijvoorbeeld via een patiëntportaal.
| |
| − | | |
| − | Enkel de keuze bieden tussen de hele BgZ delen en de BgZ niet delen is niet verenigbaar met het vrijelijk geven van toestemming conform de AVG. Zie ook de Factsheet.
| |
| − | | |
| − | ===Onvolledigheid gegevens===
| |
| − | Uitgangspunt bij het ontvangen van een BgZ is dat er nooit vanuit mag worden gegaan dat gegevens volledig zijn. Een burger heeft het wettelijke recht delen van het dossier te laten verwijderen en/of kan deze af laten schermen tegen delen met derde partijen. Daarnaast kan uiteraard iedere BgZ onvolledig zijn omdat gegevens simpelweg niet bekend zijn in het bronsysteem. Daarom is het ontbreken van een gegeven nooit een aanwijzing dat van een bepaalde conditie, bevinding of verrichting geen sprake is: die conclusie mag alleen getrokken worden wanneer dat expliciet is aangegeven ("patiënt heeft geen ...").
| |
| − | ===Verantwoordelijkheid===
| |
| − | De zorgverlener die gegevens overneemt in het eigen dossier is altijd verantwoordelijk voor het overnemen van die gegevens. Voor veel historische gegevens is verifiëren niet mogelijk: van een bloeddrukmeting van twee maanden terug kan een zorgverlener nooit controleren of die bloeddrukmeting juist was. Ook wanneer verifiëren niet mogelijk is, blijft de zorgverlener verantwoordelijk bij overnemen in het eigen dossier. In zulke gevallen zal die verantwoordelijkheid eruit bestaan dat gegevens uit een vertrouwde bron worden overgenomen en dat bij twijfel aan de juistheid van die gegevens deze ofwel niet overgenomen worden ofwel duidelijk aantekening daarvan gemaakt wordt.
| |
| − | | |
| − | =Use cases=
| |
| − | Een use case is een specifieke beschrijving van een praktijksituatie in de zorg waarbij voor een concrete situatie het uitwisselen van informatie wordt beschreven aan de hand van actoren (mensen, systemen) en transacties (welke informatie wordt wanneer uitgewisseld). Een use case is een verbijzondering van een specifiek onderdeel van het zorgproces. Een informatiestandaard kan bestaan uit één of meerdere use cases. Iedere use case koppelt met een scenario in ART-DECOR. Wanneer verschillende use cases gebruik maken van hetzelfde scenario kan een andere indeling gewenst zijn, bijvoorbeeld op basis van proces. In dit FO wordt elke use case geanalyseerd en uitgewerkt.
| |
| − | ==Algemeen==
| |
| − | De informatiestandaard BgZ voor medisch-specialistische zorg betreft de BgZ2017 en BgZ2020.
| |
| − | ===Hoofdstukken===
| |
| − | De BgZ kent de volgende hoofdstukken:
| |
| − | # Demografie en identificatie
| |
| − | # Financiële informatie
| |
| − | # Behandelrestricties
| |
| − | # Contactpersonen
| |
| − | # Functionele status
| |
| − | # Klachten en diagnoses
| |
| − | # Sociale anamnese
| |
| − | # Waarschuwingen
| |
| − | # Allergieën
| |
| − | # Medicatie
| |
| − | # Medische hulpmiddelen
| |
| − | # Vaccinaties
| |
| − | # Vitale functies
| |
| − | # Uitslagen
| |
| − | # Verrichtingen
| |
| − | # Contacten
| |
| − | # Zorgplan
| |
| − | # Zorgverleners
| |
| − | | |
| − | Deze hoofdstukindeling geldt voor BgZ2017 en voor BgZ2020.
| |
| − | ===BgZ 2017===
| |
| − | Functionele beschrijving: [https://www.registratieaandebron.nl/pdf/BgZ_specificatie_obv_zibs_2017_v1.1.pdf BgZ_specificatie_obv_zibs_2017_v1.1]
| |
| − | | |
| − | De datasets en transacties worden ontwikkeld in de [https://www.nictiz.nl/standaardisatie/art-decor/ ART-DECOR omgeving] van Nictiz.
| |
| − | | |
| − | [https://decor.nictiz.nl/art-decor/decor-datasets--bgz2017- BgZ2017 dataset in ART-DECOR]
| |
| − | | |
| − | ===BgZ 2020===
| |
| − | Functionele beschrijving: [https://www.nictiz.nl/wp-content/uploads/BgZ2020-specificatie-obv-zibs-2020-v1.1.pdf BgZ2020-specificatie-obv-zibs-2020-v1.1]
| |
| − | | |
| − | ART-DECOR specificatie wordt nog opgesteld.
| |
| − | ===Metagegevens===
| |
| − | Metagegevens kunnen op document- en zib-niveau aanwezig zijn. Het eerste is bij uitwisseling BgZ altijd nodig; het tweede is anno 2021 nog niet wijdverbreid, maar wel wenselijk voor de toekomst.
| |
| − | ====Metagegevens op documentniveau====
| |
| − | Ieder document moet metagegevens bevatten. Waar dat gebeurt wordt tenminste vastgelegd:
| |
| − | * een documentidentificatie;
| |
| − | * datum van het document (welke datum wordt gebruikt wordt in de technische uitwerking bepaald - veelal zal dit een datum van aanmaak document zijn);
| |
| − | * de instelling waarvan het document verkregen is.
| |
| − | | |
| − | In de technische uitwerking wordt beschreven hoe deze metagegevens zich verhouden tot standaarden als XDS, CDA en FHIR.
| |
| − | | |
| − | ====Metagegevens op zib-niveau====
| |
| − | =====BgZ en zibs 2017=====
| |
| − | Zibs die uitgewisseld worden kennen een context, waarvan een deel in de BasisElementen zit. Dit zijn de BasisElementen in zibs 2017:
| |
| − | * identificatie van het gegeven / de zib;
| |
| − | * auteur (de vastlegger);
| |
| − | * informatiebron (wie de informatie geleverd heeft);
| |
| − | * onderwerp (meestal: patiënt);
| |
| − | * datumtijd.
| |
| − | Daarnaast is bij uitwisseling met de BgZ van belang:
| |
| − | * (verantwoordelijke) instelling.
| |
| − | | |
| − | =====BgZ en zibs 2020=====
| |
| − | In de zibs 2020 is de groep BasisElementen, die een impliciet onderdeel was van alle zibs, vervallen. In veel gevallen zijn de gegevens daarin (zoals Datum , Auteur etc.) al expliciet onderdeel van de betreffende zib, zoals de Uitvoerder van een Verrichting of MedicatieafspraakDatumTijd. Daarmee zijn metagegevens voor de zibs niet van toepassing: het zijn ofwel expliciete onderdelen van de zib, ofwel functioneel niet relevant. Op technisch niveau kunnen metagegevens wel aanwezig zijn, zie daarvoor de technische uitwerking.
| |
| − | | |
| − | =====Persistente identificaties=====
| |
| − | Bij iedere zib die vastgelegd wordt dient een persistente identificatie vastgelegd te worden. Dat is een:
| |
| − | * wereldwijde unieke identificatie;
| |
| − | * die bij herhaalde bevraging voor dezelfde zib dezelfde waarde heeft.
| |
| − | In de technische documentatie wordt dit uitgewerkt.
| |
| − | | |
| − | ===Bedrijfsrollen===
| |
| − | {| class="wikitable"
| |
| − | |-
| |
| − | ! Rol!! Toelichting
| |
| − | |-
| |
| − | | Verwijzer || De arts die een patiënt verwijst of overdraagt naar een andere arts bij een andere instelling en in het kader daarvan de BgZ deelt.
| |
| − | |-
| |
| − | | Nieuwe behandelaar || De arts van de andere instelling die de BgZ ontvangt en een behandelovereenkomst met de patiënt aangaat (of voortzet).
| |
| − | |-
| |
| − | | Behandelaar || De arts die een patiënt behandelt en gegevens wil opvragen van een eerdere behandeling bij een andere zorginstelling.
| |
| − | |-
| |
| − | | Dossierhouder
| |
| − | || De instelling waar de patiënt eerder behandeld is en die de BgZ deelt met de (huidige) behandelend arts bij een andere instelling.
| |
| − | |-
| |
| − | | Eerdere behandelaar || De arts van de andere instelling waar de patiënt eerder onder behandeling is geweest.
| |
| − | |}
| |
| − | | |
| − | ==Use case 1: Uitwisseling BgZ bij verwijzing of overdracht==
| |
| − | ===Doel en relevantie===
| |
| − | Bij het verzenden van een BgZ naar een andere instelling kan van verschillende varianten sprake zijn.
| |
| − | * Een arts verwijst naar een andere arts, er is een overdracht van een patiënt naar die andere instelling en de eigen behandeling is daarmee afgelopen.
| |
| − | * Een tweede arts doet een deel van de behandeling zonder dat de eerdere arts de (eigen) behandeling beëindigt.
| |
| − | In al deze gevallen spreken we in deze informatiestandaard van verwijzing en/of overdracht. We maken geen strikt onderscheid tussen verwijzen en overdracht, en ook niet op de vraag of de verwijzende arts al dan niet bij de behandeling betrokken blijft. Dat kan per zorgproces nader bepaald worden. De essentie hier is dat de tweede arts een eigen, zelfstandige behandelovereenkomst met de patiënt aangaat.
| |
| − | | |
| − | [[Bestand:Use case 1 overdracht.png]]
| |
| − | | |
| − | {| class="wikitable"
| |
| − | |-
| |
| − | ! Rol!! Toelichting
| |
| − | |-
| |
| − | | Verwijzer || De arts die een patiënt verwijst of overdraagt naar een andere arts bij een andere instelling en in het kader daarvan de BgZ deelt.
| |
| − | |-
| |
| − | | Nieuwe behandelaar || De arts van de andere instelling die de BgZ ontvangt en een behandelovereenkomst met de patiënt aangaat (of voortzet).
| |
| − | |}
| |
| − | | |
| − | ===Proces en context===
| |
| − | ====Patient journey====
| |
| − | Een patiënt is onder behandeling bij een oncoloog in een regionaal ziekenhuis. De patiënt heeft een complexe aandoening, waarvoor de behandeling beter voortgezet kan worden in een nabij academisch ziekenhuis. De behandelend arts verwijst de patiënt door naar het academisch ziekenhuis, en verstrekt daarbij (alle of een deel van) de volgende documenten:
| |
| − | # een verwijsbrief;
| |
| − | # de BgZ van de patiënt;
| |
| − | # eventuele verdere bijlagen of verwijzingen.
| |
| − | De patiënt komt op een consult in het academisch ziekenhuis. De behandelend arts daar opent het eigen EPD en ziet de BgZ en de overige informatie uit het regionale ziekenhuis in. Het academisch ziekenhuis zet de behandeling voort.
| |
| − | | |
| − | ====Precondities====
| |
| − | * De patiënt is onder behandeling in een instelling.
| |
| − | * De behandelend arts besluit tot verwijzing of overdracht.
| |
| − | * De gegevens van de patiënt zijn vastgelegd in het EPD.
| |
| − | * De patiënt maakt geen bezwaar tegen (digitale) uitwisseling van gegevens.
| |
| − | * Behandelend en ontvangend ziekenhuis kunnen digitaal de BgZ uitwisselen.
| |
| − | | |
| − | ====Trigger event====
| |
| − | Het besluit van een arts om een patiënt te verwijzen of over te dragen aan een andere instelling, waar de patiënt onder behandeling zal komen.
| |
| − | | |
| − | ====Proces====
| |
| − | # De behandelend arts kiest een instelling en specialisme (en mogelijk een zorgverlener binnen die instelling) waarnaar verwezen wordt.
| |
| − | # De behandelend arts rondt de verwijzing af.
| |
| − | # De BgZ wordt verzonden.
| |
| − | #* De stap: "verzenden BgZ" kan expliciet zijn, maar kan ook "onder water" geschieden, bijvoorbeeld als deel van het afronden van de verwijzing.
| |
| − | # Een arts in de ontvangende instelling ziet de BgZ in.
| |
| − | | |
| − | {{NoteBox|'''Toestemming - Informatief'''
| |
| − | | |
| − | Er is uitdrukkelijke toestemming nodig voor delen van de BgZ.
| |
| | }} | | }} |
| − |
| |
| − | ==Use case 2: Opvraging BgZ bij eerdere behandelaar==
| |
| − | Bij deze use case is sprake van behandeling waarbij gegevens van een andere instelling, waar een eerdere behandeling heeft plaatsgevonden, worden opgevraagd.
| |
| − |
| |
| − | [[Bestand:Use case 2 opvragen.png]]
| |
| − | ===Bedrijfsrollen===
| |
| − | {| class="wikitable"
| |
| − | |-
| |
| − | ! Rol!! Toelichting
| |
| − | |-
| |
| − | | Behandelaar || De arts die een patiënt behandelt en gegevens wil opvragen van een eerdere behandeling bij een andere zorginstelling.
| |
| − | |-
| |
| − | | Dossierhouder
| |
| − | || De instelling waar de patiënt eerder behandeld is, en die de BgZ deelt met de (huidige) behandelend arts bij een andere instelling.
| |
| − | |-
| |
| − | | Eerdere behandelaar || De arts van de andere instelling waar de patiënt eerder onder behandeling is geweest.
| |
| − | |}
| |
| − |
| |
| − | ===Proces en context===
| |
| − | ====Patient journey====
| |
| − | Een patiënt komt voor behandeling bij een zorgverlener. Uit de anamnese blijkt een eerdere behandeling bij een andere instelling. De zorgverlener vraagt de BgZ op bij de andere instelling.
| |
| − |
| |
| − | We maken een voorlopig onderscheid in twee subcasussen: opvraag met en zonder collegiaal contact.
| |
| − | * Met collegiaal contact volgt de gebruikelijke handelwijze waarbij een arts een eerdere arts belt om nadere informatie over de patiënt en naar eerdere behandelingen/bevindingen te informeren.
| |
| − | * Opvragen zonder collegiaal contact kan wanneer er sprake is van eerder gegeven toestemming.
| |
| − | =====Variant: Opvraging met collegiaal contact=====
| |
| − | De huidige behandelaar neemt contact op met de dossierhoudende instelling en wordt doorverwezen naar de eerdere behandelaar. Beiden spreken de casus collegiaal door. De eerdere behandelaar verstrekt de BgZ aan de huidige behandelaar en heeft daarbij de optie:
| |
| − | * een collegiale brief mee te zenden;
| |
| − | * aanvullende documentatie (brieven, beelden, verslagen etc.) mee te zenden.
| |
| − |
| |
| − | {{NoteBox|'''Toestemming - Informatief'''
| |
| − |
| |
| − | Toestemming kan bij opvragen BgZ met collegiaal contact van tevoren geregeld zijn, door opnemen van de relevante toestemmingen in een toestemmingsregister. Is dat niet het geval, dan kan tijdens de opvraging de toestemming geregeld worden:
| |
| − | * de huidige behandelaar vraagt de (aanwezige) patiënt een brief met toestemming voor opvragen van informatie bij de dossierhoudende instelling, eventueel met nadere omschreven doelstelling of reikwijdte, te ondertekenen;
| |
| − | * de huidige behandelaar stuurt de toestemming aan de eerdere behandelaar (de wijze waarop is buiten scope, dat kan met bestaande kanalen voor veilige ad hoc communicatie tussen zorgverleners);
| |
| − | * de eerdere behandelaar ziet de toestemming in en slaat deze op.
| |
| − |
| |
| − | Verder wijkt opvragen met collegiaal contact niet af van [[#Use_case_1:_Uitwisseling_BgZ_bij_verwijzing_of_overdracht|use case 1]], zie verder aldaar.
| |
| − | }}
| |
| − |
| |
| − | =====Variant: Opvraging zonder collegiaal contact=====
| |
| − | Wanneer de eerdere behandelaar niet meer werkzaam is bij de dossierhoudende instelling, of wanneer collegiaal contact niet nodig of wenselijk is, vraagt de huidige zorgverlener de BgZ op bij de dossierhoudende instelling. De zorgverleners bij die instelling hoeven daarbij geen rol te spelen op dat moment. De dossierhoudende instelling levert de BgZ (zoals die op dat moment uit het EPD gegenereerd kan worden) op aan de huidige behandelaar.
| |
| − |
| |
| − | {{NoteBox|'''Toestemming - Informatief'''
| |
| − |
| |
| − | Toestemming dient bij opvragen BgZ zonder collegiaal contact anders geregeld te zijn. Dat kan bijvoorbeeld:
| |
| − | # door vooraf opnemen van de relevante toestemmingen in een toestemmingsregister;
| |
| − | # door de patiënt toestemming te laten geven middels een app;
| |
| − | # via het patiëntenportaal van de dossierhoudende instelling.
| |
| − |
| |
| − | Omdat de werkwijze met collegiaal contact omslachtig is (in ieder geval wanneer dit contact alleen nodig is voor de toestemming) is het zeer wenselijk een van de drie bovenstaande opties te gebruiken. De derde is veelal nu al beschikbaar.}}
| |
| − |
| |
| − | ====Pre-condities====
| |
| − | * Er is sprake van een eerdere behandeling.
| |
| − | * De gegevens van de patiënt zijn daar vastgelegd in het EPD.
| |
| − | * Er is een volgende behandeling in een andere instelling voor medisch-specialistische zorg.
| |
| − | * De (huidig) behandelend arts wil de gegevens van de eerdere behandeling inzien.
| |
| − | * Er is uitdrukkelijke toestemming, ofwel:
| |
| − | ** De patiënt geeft toestemming en deze toestemming wordt gedeeld met de dossierhoudende instelling.
| |
| − | ** Er is een eerder gegeven toestemming die toegankelijk is voor de dossierhoudende instelling.
| |
| − |
| |
| − | ====Trigger event====
| |
| − | Het verzoek van een behandelend arts om eerder vastgelegde gegevens van een andere instelling in te zien.
| |
| − |
| |
| − | ====Proces====
| |
| − | # De behandelend arts vraagt een BgZ op.
| |
| − | #* Hoe de BgZ wordt opgevraagd is buiten scope. Verondersteld wordt dat er een infrastructuur is waarmee de BgZ wordt opgevraagd.
| |
| − | # De eerdere instelling stelt de BgZ beschikbaar aan de opvragende instelling.
| |
| − | #* Niet alle instellingen hebben de mogelijkheid een BgZ direct aan te maken. Soms is deze pas na enige tijd beschikbaar. Het heeft uiteraard de voorkeur wanneer een opvragende arts de gegevens direct ook in kan zien. Dat is echter geen verplichting: ook een proces met opvragen van de BgZ op het moment dat een consult gepland wordt om tijdens of voor het consult in te zien heeft meerwaarde.
| |
| − | #* De BgZ mag ook de laatste BgZ zijn wanneer een instelling deze na iedere wijziging opslaat: opnieuw genereren hoeft niet als geborgd is dat het de laatste stand van zaken is.
| |
| − | # De BgZ wordt ter beschikking gesteld aan de huidige behandelend arts.
| |
| − | # De behandelend arts raadpleegt de BgZ.
| |
| − |
| |
| − | =Informatieoverdracht=
| |
| − | Bij de informatieoverdracht wordt beschreven hoe de use cases - uitwisselingen tussen personen en instellingen - corresponderen met transacties tussen de informatiesystemen.
| |
| − |
| |
| − | De transacties zijn beschreven in ART-DECOR. De "systeemrol" beschrijft de rol van een informatiesysteem in het delen van informatie. Omdat veel van de systeemaspecten betrekking hebben op het verwerken dan wel verstrekken van de informatie is ook een kolom "verwerkersrol" toegevoegd, waaraan in de systeemeisen gerefereerd wordt.
| |
| − | {| class="wikitable" "cellpadding="10"
| |
| − | ! | '''Transactiegroep'''
| |
| − | ! | '''Transactie'''
| |
| − | ! | '''Systeemrol'''
| |
| − | ! | '''Verwerkersrol'''
| |
| − | |-
| |
| − | | rowspan="2"| BgZ bij verwijzing
| |
| − | ||Sturen BgZ
| |
| − | ||Sturend Systeem
| |
| − | ||Gegevensverstrekkend Systeem
| |
| − | |-
| |
| − | ||Ontvangen BgZ
| |
| − | ||Ontvangend Systeem
| |
| − | ||Gegevensontvangend Systeem
| |
| − | |-
| |
| − | | rowspan="2"|[https://decor.nictiz.nl/art-decor/decor-scenarios--bgz2017-?id=2.16.840.1.113883.2.4.3.11.60.42.4.35&effectiveDate=2018-08-30T09%3A30%3A49&datasetId=&datasetEffectiveDate=&language=nl-NL&scenariotree=true Opvragen BgZ]
| |
| − | ||[https://decor.nictiz.nl/art-decor/decor-scenarios--bgz2017-?id=2.16.840.1.113883.2.4.3.11.60.42.4.36&effectiveDate=2018-08-30T09%3A30%3A49&datasetId=&datasetEffectiveDate=&language=nl-NL&scenariotree=true Opvragen BgZ]
| |
| − | ||Raadplegend Systeem
| |
| − | ||Gegevensontvangend Systeem
| |
| − | |-
| |
| − | ||[https://decor.nictiz.nl/art-decor/decor-scenarios--bgz2017-?id=2.16.840.1.113883.2.4.3.11.60.42.4.37&effectiveDate=2018-08-30T09%3A30%3A49&datasetId=2.16.840.1.113883.2.4.3.11.60.42.1.1&datasetEffectiveDate=2018-01-01T00%3A00%3A00&conceptId=2.16.840.1.113883.2.4.3.11.60.42.2.1&conceptEffectiveDate=2018-01-01T00%3A00%3A00&language=nl-NL&scenariotree=true Beschikbaar stellen BgZ]
| |
| − | ||Beschikbaarstellend Systeem
| |
| − | ||Gegevensverstrekkend Systeem
| |
| − | |}<small>Tabel Overzicht transactiegroepen</small>
| |
| − |
| |
| − | De implementatiescenario's zeggen niets over de technische uitwerking, maar alleen over de trigger en de daaruit voortvloeiende transactie.
| |
| − |
| |
| − | Van de beide transactiegroepen worden twee varianten uitgewerkt:
| |
| − | * een variant waarbij het dossierhoudend EPD de BgZ beschikbaar stelt als een geheel document;
| |
| − | * een variant waarbij het dossierhoudend EPD de BgZ per onderdeel beschikbaar kan stellen, en waarbij het andere EPD bepaalt welke delen opgehaald worden: dat kan dus tezamen de hele BgZ of een deelverzameling daarvan zijn.
| |
| − |
| |
| − | Zie verder de technische uitwerking.
| |
| − |
| |
| − | =Systeemaspecten=
| |
| − | {{IssueBox|Soorten gegevens en metadata
| |
| − |
| |
| − | # historische gegevens: in 1998 is voor patiënt X opgeslagen dat deze in 1992 appendicitis heeft ondergaan, maar er zijn geen nadere gegevens vastgelegd
| |
| − | # gegevens uit anamnese: een arts voert bij de anamnese n.a.v. informatie patiënt in dat deze in 2012 elders een appendicitis heeft ondergaan, maar heeft geen nadere gegevens nodig
| |
| − | #* bij metagegevens informatiebron vastleggen: patiënt
| |
| − | #* in zib Verrichting alleen VerrichtingType 'appendicitis' en VerrichtingStartDatum '2012' vastleggen
| |
| − | # gegevens van elders: een BgZ die binnengekomen en verwerkt is, bevat gegeven dat patiënt in 2012 een appendicitis heeft ondergaan, maar geen nadere gegevens (mogelijk vanwege een van bovenstaande gevallen)
| |
| − | #* bij metagegevens informatiebron (de andere instelling) vastleggen - dit kan niet met zibs 2017(!)
| |
| − | # nieuw ingevoerde gegevens: de patiënt ondergaat een appendicitis in de instelling
| |
| − | #* metagegevens en de relevante gegevens van Verrichting (Uitvoerder, Datum etc.) vastleggen
| |
| − |
| |
| − | Verwerkersrol: Vastlegggend Systeem toevoegen, en eisen dat dit alles vastgelegd wordt.
| |
| − | }}
| |
| − | Deze informatiestandaard beschrijft de mogelijkheden tot verwerking in de aangesloten systemen. Deze sectie is deels niet voorschrijvend: instellingen hebben voor de eigen systemen hebben de vrijheid zelf keuzes te maken welke variant gekozen wordt. Wel beoogt deze sectie helder te maken wat de varianten inhouden, zodat eenduidige afspraken rond verwerking in systemen gemaakt kunnen worden. De sectie "Eisen" is wel voorschrijvend.
| |
| − | ==Eisen per systeemrol==
| |
| − | {| class="wikitable"
| |
| − | |-
| |
| − | ! Systeemrol !! Eis
| |
| − | |-
| |
| − | | Sturend Systeem|| Het EPD moet een BgZ kunnen '''sturen bij verwijzing''' naar een andere zorginstelling of zorgverlener.
| |
| − | |-
| |
| − | | Sturend Systeem|| Een zorgverlener moet een '''andere zorginstelling kunnen kiezen''' om een BgZ mee te delen, met eventueel specialisme.
| |
| − | |-
| |
| − | | Beschikbaarstellend Systeem|| Het EPD moet de mogelijkheid bieden om op een opvraging een '''BgZ beschikbaar te stellen'''.
| |
| − | |-
| |
| − | | Beschikbaarstellend Systeem|| Het EPD moet kunnen vaststellen dat sprake is van een '''eerder gegeven toestemming''' die delen van het BgZ toestaat.
| |
| − | |-
| |
| − | | Raadplegend Systeem|| Het EPD moet de mogelijkheid bieden om een '''BgZ op te vragen''' bij een beschikbaarstellend EPD.
| |
| − | |-
| |
| − | | Raadplegend Systeem|| Een zorgverlener moet '''een te bevragen zorginstelling kunnen kiezen'''.
| |
| − | |-
| |
| − | | Ontvangend Systeem|| Het EPD moet de mogelijkheid bieden om '''een BgZ te ontvangen'''.
| |
| − | |-
| |
| − | | Ontvangend Systeem|| Het EPD moet de betrokken afdelingen (administratief en/of specialisme) '''kunnen verwittigen van een ontvangen BgZ''', waarna die BgZ ingezien kan worden.
| |
| − | |}
| |
| − |
| |
| − | ==Verwerkersrol: Gegevensverstrekkend EPD==
| |
| − | ===Eisen aan de verwerking===
| |
| − | {| class="wikitable"
| |
| − | |-
| |
| − | ! Eis!! Toelichting
| |
| − | |-
| |
| − | | Toevoegen metagegevens || Een EPD moet metagegevens toevoegen aan een BgZ.
| |
| − | |-
| |
| − | | Volledigheid definiëren || Een EPD moet beschrijven welke secties en welke zibs van de BgZ wel en niet ondersteund worden. Deze documentatie moet beschikbaar zijn bij kwalificatie en voor ketenpartners.
| |
| − | |}
| |
| − |
| |
| − | ===Eisen aan de metagegevens===
| |
| − | Een verstrekkend EPD moet [[#Metagegevens|metagegevens]] toe kunnen voegen.
| |
| − |
| |
| − | {| class="wikitable"
| |
| − | |-
| |
| − | ! Eis!! Toelichting
| |
| − | |-
| |
| − | | Document-metagegevens meesturen || Er moeten document-metagegevens toegevoegd worden aan een verstuurde BgZ.
| |
| − | |-
| |
| − | | Aanwezige externe metagegevens meesturen || Wanneer gegevenselement van elders betrokken is, en er zijn [[#Metagegevens op zib-niveau|metagegevens op zib-niveau]] opgeslagen, dan dienen die meegezonden te worden.
| |
| − | * Bijvoorbeeld: medicatie is opgehaald van het LSP en de identificaties van de LSP-bevraging zitten in het EPD, dan dienen deze meegezonden te worden.
| |
| − | |-
| |
| − | | Geen externe metagegevens aanmaken || Wanneer gegevenselement van elders betrokken is, en er zijn geen metagegevens opgeslagen, dan worden deze niet meegezonden.
| |
| − | * Bijvoorbeeld: medicatie is overgenomen van een papieren AMO (Actueel Medicatie Overzicht). Op een AMO staan geen metagegevens op rij-niveau. Deze kunnen dus niet opgeslagen en meegestuurd worden.
| |
| − | |-
| |
| − | | Eigen persistente metagegevens meesturen || Wanneer het gegevenselement niet van elders betrokken is, en het systeem kan persistente identificaties (die bij een volgende bevraging hetzelfde zijn) aanmaken, dan dienen deze meegezonden te worden.
| |
| − | |-
| |
| − | | Geen niet-persistente eigen identificaties meesturen || Wanneer het gegevenselement niet van elders betrokken is, en het systeem kan geen persistente identificaties aanmaken, dan worden geen identificaties meegezonden. Andere metagegevens mogen wel meegestuurd worden.
| |
| − | * Deze situatie is niet wenselijk en dient uitgefaseerd te worden.
| |
| − | |-
| |
| − | | Geen metagegevens bij onduidelijke bron || Wanneer het systeem geen onderscheid kan maken tussen eigen en van elders betrokken informatie, worden geen identificaties meegezonden.
| |
| − | * Deze situatie is niet wenselijk en dient uitgefaseerd te worden.
| |
| − | * (Eigen persistente identificaties aanmaken leidt in deze situatie tot feitelijke duplicaten die schijnbaar uniek zijn, dat kan niet.)
| |
| − | |}
| |
| − |
| |
| − | ==Verwerkersrol: Gegevensontvangend EPD==
| |
| − | ===Eisen aan de verwerking===
| |
| − | {| class="wikitable"
| |
| − | |-
| |
| − | ! Eis!! Toelichting
| |
| − | |-
| |
| − | | Tonen BgZ || Een EPD moet alle informatie die via een BgZ ontvangen wordt, tekstueel kunnen tonen aan de zorgverlener.
| |
| − | |-
| |
| − | | Hergebruik definiëren || Een EPD moet beschrijven welke mogelijkheden het wel en niet biedt betreffende hergebruik. Deze documentatie moet beschikbaar zijn bij kwalificatie en voor ketenpartners.
| |
| − |
| |
| − | |}
| |
| − |
| |
| − | ===Eisen aan de metagegevens===
| |
| − | {| class="wikitable"
| |
| − | |-
| |
| − | ! Eis!! Toelichting
| |
| − | |-
| |
| − | | Document-metagegevens opslaan || Een EPD moet metagegevens op document-niveau op kunnen slaan.
| |
| − | |-
| |
| − | | Zib-metagegevens opslaan || Een EPD moet metagegevens op zib-niveau op kunnen slaan. Wanneer deze aanwezig zijn, is opslaan van document-metagegevens optioneel.
| |
| − | |}
| |
| − |
| |
| − | ===Verwerking van de informatie===
| |
| − | Bij de verwerking van de informatie bestaan de volgende secties beschreven mogelijkheden.
| |
| − |
| |
| − | Welke van deze mogelijkheden optimaal is, is afhankelijk van het concrete zorgproces. Ook zal de situatie voor een algemeen ziekenhuis anders zijn dan in een zelfstandige kliniek die slechts een beperkt aantal behandelingen uitvoert. De informatiestandaard stelt dan ook geen eisen aan wanneer (voor welke informatiesoort) welke optie gekozen moet worden. Wel is een (minimale) eis dat alle informatie uit een BgZ getoond moet kunnen worden.
| |
| − |
| |
| − | ===Tonen===
| |
| − | De BgZ wordt als geheel getoond in het ontvangende EPD. Dit is een minimale optie die in ieder geval ondersteund moet worden. (Dit wil niet zeggen dat het als document in technische zin ontvangen moet zijn, alleen dat het als een geheel gepresenteerd wordt. Dat kan ook wanneer de BgZ als losse zibs is opgehaald.)
| |
| − |
| |
| − | [[Bestand:Alleen-tonen.png|geen|omkaderd]]
| |
| − |
| |
| − | {{ReminderBox|Voorbeeld: patiënt wordt van ziekenhuis A verwezen naar ziekenhuis B. De behandelend arts in ziekenhuis B wil de overdracht inzien en kan daarbij de volgende documenten kiezen en als geheel inzien.
| |
| − | * Verwijsbrief
| |
| − | * BgZ
| |
| − | * Aanvullende documenten en/of beelden}}
| |
| − |
| |
| − | ===Ontdubbelen===
| |
| − | Bij sommige informatietypen (denk bijvoorbeeld aan medicatieverstrekkingen die via het LSP zijn opgehaald) die zowel in de BgZ als het eigen EPD al beschikbaar zijn, is het mogelijk aan uniek identificerende gegevens te zien dat dit "hetzelfde" gegeven betreft. Deze kunnen ontdubbeld worden, waarbij duplicaatinformatie niet getoond wordt. Dit kan zowel gebeuren bij "tonen in context" als reconciliatie.
| |
| − | {{ReminderBox|Voorbeeld: een patiënt met een pacemaker wordt van ziekenhuis A verwezen naar ziekenhuis B. Patiënt is reeds bekend in ziekenhuis B, en de pacemaker is geregistreerd in het eigen EPD. Bij ontvangst van de BgZ ziet EPD B dat het serienummer van de pacemaker in de BgZ hetzelfde is als de pacemaker in EPD B. Er wordt maar één pacemaker getoond bij de medische hulpmiddelen.}}
| |
| − |
| |
| − | Dat ontdubbelen kan, betekent niet automatisch dat het wenselijk is. Dat is een keuze die de zorgverleners van een instelling in samenspraak met de leverancier van het systeem maken. Omdat dit ook per zorgproces kan verschillen, doet deze informatiestandaard geen uitspraak over wanneer wel en niet ontdubbeld dient te worden.
| |
| − |
| |
| − | Ontdubbelen kan een rol spelen bij [[#Tonen in context|Tonen in context]], [[#Handmatig overnemen|Handmatig overnemen]] en [[#Automatisch overnemen|Automatisch overnemen]].
| |
| − |
| |
| − | ===Duplicaatdetectie===
| |
| − | {{NoteBox|Informatief}}
| |
| − | Ontdubbelen is afhankelijk van de mogelijkheid tot automatische duplicaatdetectie. Hier worden de mogelijkheden aangegeven. Of een EPD deze mogelijkheden biedt is aan het EPD. We gaan ervan uit dat duplicaatdetectie door een zorgverlener altijd mogelijk is: handmatige duplicaatdetectie wordt dan ook niet beschreven.
| |
| − |
| |
| − | Duplicaatdetectie is belangrijk bij het uitwisselen van de BgZ. Wanneer in de BgZ aangegeven is dat een patiënt een pacemaker heeft, en in het eigen EPD is ook een pacemaker geregistreerd, wil dat uiteraard niet zeggen dat de patiënt twee pacemakers heeft. Het is ook geen gegeven dat het een en dezelfde pacemaker is: mogelijk is de ene een oudere en de andere een vervangende. Duplicaatdetectie maakt het mogelijk te zien wanneer iets "hetzelfde" is en dus maar een keer getoond of opgenomen hoeft te worden.
| |
| − |
| |
| − | Duplicaatdetectie kan altijd met persistente identificaties: kunstmatige identificaties per zib, die wereldwijd uniek zijn en opgeslagen worden. (Dergelijke identificaties zijn meestal een combinatie van een lokale identificatie met een OID of URI, waarbij de combinatie uniek is. Zie verder de technische uitwerking.) Die identificaties zijn er echter niet altijd, en worden niet altijd opgeslagen. De volgende tabel geeft de mogelijkheden wanneer er geen persistente identificaties op zib-niveau zijn. Systemen mogen intelligente oplossingen voor duplicaatdetectie en -signalering in te bouwen.
| |
| − |
| |
| − | {| class="wikitable"
| |
| − | !Hoofdstuk
| |
| − | !Duplicaatdetectie
| |
| − | |-
| |
| − | | | Demografie en identificatie
| |
| − | | | N.v.t., deze gegevens worden niet uit de BgZ overgenomen.
| |
| − | |-
| |
| − | | | Financiële informatie
| |
| − | | |
| |
| − | |-
| |
| − | | | Behandelrestricties
| |
| − | | | Duplicaatdetectie zal niet mogelijk zijn.
| |
| − | |-
| |
| − | | | Contactpersonen
| |
| − | | | Geen BSN. Duplicaatdetectie lastig, wellicht op rol. Overnemen na beoordelen moet wel haalbaar zijn.
| |
| − | |-
| |
| − | | | Functionele status
| |
| − | | | Duplicaatdetectie zal niet mogelijk zijn.
| |
| − | |-
| |
| − | | | Klachten en diagnoses
| |
| − | | | Duplicaatdetectie is moeilijk. Er is in ieder geval geen identificatie die over systemen heen gebruikt kan worden. Diagnoses kunnen uiteraard gegroepeerd worden rond de ProbleemNaam. Daarin zitten echter Snomed codes (subset zoals gedefinieerd in de Diagnosethesaurus). Van ontvangende systemen te verwachten dat ze deze codes kunnen mappen op elkaar lijkt te veel gevraagd. In klinische setting zou geëist kunnen worden DHD DT codes te gebruiken. Duplicaatdetectie wordt bemoeilijkt doordat ProbleemDatum ook een "vage" datum (bijvoorbeeld alleen een jaar) mag zijn.
| |
| − | |-
| |
| − | | | Sociale anamnese
| |
| − | | | Duplicaatdetectie op delen van de sociale anamnese door software lijkt niet haalbaar.
| |
| − | |-
| |
| − | | | Waarschuwingen
| |
| − | | | Duplicaatdetectie lijkt lastig bij gebrek aan duidelijke identificatie, temeer daar het een Probleem of AlertNaam kan zijn.
| |
| − | |-
| |
| − | | | Allergieën
| |
| − | | | In theorie zou (gedeeltelijke) duplicaatdetectie op basis van VeroorzakendeStof mogelijk moeten zijn. Praktisch gezien lijkt dat wat hoog gegrepen.
| |
| − | |-
| |
| − | | | Medicatie
| |
| − | | | Ook hier lijkt duplicaatdetectie hoog gegrepen: er is wel detectie mogelijk op farmaceutisch product, maar de combinatie met dosering, datum, voorschrijver etc. maakt het onwaarschijnlijk dat vastgesteld kan worden of iets "hetzelfde" is. Duplicaatvermoeden kan op basis van product wellicht wel aangegeven worden.
| |
| − | |-
| |
| − | | | Medische hulpmiddelen
| |
| − | | | Duplicaatdetectie zou deels mogelijk moeten zijn op serienummer – geen zekerheid dat dezelfde nummering in zendend en ontvangend systeem zit, maar behoorlijke afdekking via GTIN en HIBC.
| |
| − | |-
| |
| − | | | Vaccinaties
| |
| − | | | Voor vaccinaties i.h.k.v. Rijksvaccinatieprogramma zou redelijke duplicaatdetectie mogelijk moeten zijn, het gaat dan om een beperkt en bekend lijstje, alhoewel hier ook vage datums kunnen spelen. Voor latere vaccinaties is dat minder zeker, vooral gegeven datums etc.: hoe wat je met “vage” datums dat het “dezelfde” vaccinatie is?
| |
| − | |-
| |
| − | | | Vitale functies
| |
| − | | | Zijn er maar 3, laatste bloeddruk, lengte, gewicht, met datums. Duplicaten zullen niet altijd een rol spelen: bij volwassenen is lengte vrij constant, de anderen (en lengte bij kinderen) zijn datumgebonden en zullen dus geen duplicaat zijn. Desalniettemin kunnen gegevens ook dubbel binnenkomen via 2 ontvangen BgZ's.
| |
| − | |-
| |
| − | | | Uitslagen
| |
| − | | | Betreft de laatste klinische bepalingen. Duplicaatdetectie kan wellicht op basis van datumtijd en testcode bij uitslagen die uit dezelfde bron komen.
| |
| − | |-
| |
| − | | | Verrichtingen
| |
| − | | | De Snomed-codes (subset zoals gedefinieerd in de Verrichtingenthesaurus) bieden redelijke basis voor duplicaatdetectie. Mogelijk maken datums het lastiger 100% zeker duplicaten te ontdekken.
| |
| − | |-
| |
| − | | | Contacten
| |
| − | | | Betreft eerdere opnames.
| |
| − | |-
| |
| − | | | Zorgplan
| |
| − | | | Dit betreft het zorgplan in de BgZ van verzendende instelling A. Duplicaten zijn niet te verwachten.
| |
| − | |-
| |
| − | | | Zorgverleners
| |
| − | | | Huisarts: overnemen indien niet bekend lijkt mogelijk en wenselijk, al is de meerwaarde beperkt.
| |
| − | |}
| |
| − |
| |
| − | ===Tonen in context===
| |
| − | De informatie wordt getoond in de context in het ontvangende EPD waar ook de "eigen" informatie getoond wordt, maar als herkenbaar blokje met externe informatie.
| |
| − |
| |
| − | Eventueel wordt [[#Ontdubbelen |Ontdubbelen]] toegepast.
| |
| − | [[Bestand:Tonen-in-context.png|geen|omkaderd]]
| |
| − |
| |
| − | {{ReminderBox|Voorbeeld: patiënt wordt van ziekenhuis A verwezen naar ziekenhuis B. De arts in ziekenhuis B ziet de diagnoses die in ziekenhuis A gedaan zijn, als duidelijk herkenbare externe diagnoses in de probleemlijst in het eigen EPD. De externe diagnoses zijn “alleen lezen”.}}
| |
| − |
| |
| − | ===Handmatig overnemen===
| |
| − | De ontvangende zorgverlener ziet de met de BgZ aangeleverde informatie naast relevante bestaande informatie uit het eigen EPD, en kan besluiten items van de aangeleverde BgZ over te nemen in het eigen EPD. (Het gaat er hierbij om dat het voor de zorgverlener overkomt als een deel van het eigen dossier. Of dit in de database van het eigen EPD is, of technisch anders is vormgegeven, doet niet ter zake.)
| |
| − |
| |
| − | Bij het overnemen is reconciliatie van belang: overgenomen gegevens dienen niet duplicaten van of strijdig met bestaande informatie te zijn. Reconciliatie kan hier deels automatisch en deels handmatig zijn. Eventueel wordt [[#Ontdubbelen |Ontdubbelen]] toegepast. Bij het overnemen wordt de informatie gekopieerd met behoud van structuur en coderingen.
| |
| − | [[Bestand:Reconciliatie-handmatig.png|geen|omkaderd]]
| |
| − |
| |
| − | Daarbij zijn twee varianten te onderscheiden:
| |
| − | # De oorspronkelijke bron moet als "auteur" van het gegeven bewaard blijven. Te denken valt aan diagnose, waarbij de oorspronkelijke arts die de diagnose gesteld heeft, vastgelegd wordt.
| |
| − | # De bron hoeft niet bewaard te blijven. Te denken valt aan een nieuw woonadres: relevant is dat dit het huidige adres is, niet wie dat als eerste ergens heeft vastgelegd. Ook kan de informatie geverifieerd worden en als eigen informatie vastgelegd. Wanneer bijvoorbeeld in een sociale anamnese staat dat een patiënt 10 sigaretten per dag rookt, en de de patiënt bevestigt aan de arts dat dit nog steeds klopt, kan dit overgenomen worden. Het hoeft dat niet relevant te zijn wie oorspronkelijk dat aantal heeft vastgelegd.
| |
| − | {{ReminderBox|Voorbeeld met bron: patiënt wordt van ziekenhuis A verwezen naar ziekenhuis B. De arts in ziekenhuis B ziet de diagnoses die in ziekenhuis A gedaan zijn, als duidelijk herkenbare externe diagnoses in de probleemlijst in het eigen EPD. De mogelijkheid bestaat externe diagnoses aan te vinken voor “overnemen in eigen EPD”. Daarbij wordt de arts die de diagnose gesteld heeft als auteur bewaard.}}
| |
| − |
| |
| − | {{ReminderBox|Voorbeeld met bron: in de BgZ staan de medicatieafspraken van de patiënt. De arts neemt deze medicatieafspraken over. Daarbij worden metagegevens (bijvoorbeeld het document en de instelling waaruit de informatie betrokken is) vastgelegd.}}
| |
| − |
| |
| − | {{ReminderBox|Voorbeeld zonder bron: patiënt wordt van ziekenhuis A verwezen naar ziekenhuis B. EPD B ziet dat de BgZ een andere huisarts bevat dan het eigen EPD. De administratie heeft de mogelijkheid het nieuwe adres over te nemen in het eigen EPD. Na navraag bij de patiënt besluit men dat te doen. De BgZ waar de gegevens uit komen is niet relevant en wordt niet opgeslagen.}}
| |
| − |
| |
| − | {{ReminderBox|Voorbeeld zonder bron: in de BgZ staat het medicatiegebruik van de patiënt. De arts doet medicatieverificatie met de patiënt samen en verifieert deze. De juiste medicatieregels worden overgenomen. De bron is niet relevant: de arts neemt de medicatieregels over onder eigen verantwoordelijkheid, alsof ze zelf ingevoerd waren. Het overnemen is alleen een stap om typewerk en invoerfouten te voorkomen.}}
| |
| − |
| |
| − | Het is ook mogelijk dat de informatie in het EPD en de BgZ conflicteert. Bijvoorbeeld: de patiënt rookt wel volgens het EPD en niet volgens de BgZ. De arts kan met de patiënt nagaan wat juist is en indien nodig het EPD bijwerken.
| |
| − |
| |
| − | ===Automatisch overnemen===
| |
| − | De informatie uit de BgZ wordt automatisch opgenomen in het eigen EPD. Dit kan wellicht gebeuren met niet-medische informatie (adressen, contactpersonen, financiering anders dan zorgverzekeraar etc.), maar mogelijk ook met goed identificeerbare informatie samen met automatische ontdubbeling. Ook voor toegevoegde brieven e.d. is het een optie. Zonder identificeerbare informatie geen voor de hand liggende optie omdat het tot verdubbeling van informatie kan leiden. Daarnaast zal in de meeste gevallen een arts alleen relevante informatie op willen nemen.
| |
| − |
| |
| − | Automatisch overnemen kent geen handmatige stap. Reconciliatie kan in dit geval dus alleen automatisch. Eventueel wordt daarvoor [[#Ontdubbelen |Ontdubbelen]] toegepast. Reconciliatie is niet van belang wanneer het informatie betreft die in het eigen dossier nog niet aanwezig is. Bij het overnemen wordt de informatie gekopieerd met behoud van structuur en coderingen.
| |
| − |
| |
| − | {{ReminderBox|Voorbeeld: patiënt wordt van ziekenhuis A verwezen naar ziekenhuis B. De patiënt is in het EPD nog niet bekend. Demografische gegevens, contactpersonen en de huisarts worden overgenomen uit de BgZ in het eigen EPD.}}
| |
| − |
| |
| − | ==Context van de externe informatie==
| |
| − | Gegevens kunnen na reconciliatie overgenomen worden als "eigen" en "externe" informatie. Wanneer informatie opgenomen wordt als "eigen" informatie worden geen gegevens over de externe context opgeslagen.
| |
| − |
| |
| − | {{ReminderBox|Voorbeeld: De administratie van een ziekenhuis ontvangt een BgZ met gegevens over de contactpersonen van de patiënt. Aan de balie wordt geverifieerd met de patiënt dat deze gegevens nog actueel zijn. Daarna worden de gegevens overgenomen in het EPD. Er wordt niet vastgelegd dat deze uit een BgZ zijn overgenomen.}}
| |
| − |
| |
| − | Meestal is het wel van belang uit welke externe bron gegevens overgenomen zijn. Dan kunnen metagegevens vastgelegd worden op document-niveau en op zib-niveau. Bij vastleggen als "externe informatie" moet tenminste een van beide opties gekozen worden.
| |
| − |
| |
| − | Zie verder onder [[#Metagegevens|Metagegevens]].
| |
| − |
| |
| − | ==Vasthouden externe context==
| |
| − | {{NoteBox|Informatief}}
| |
| − | De externe context moet altijd ingezien kunnen worden waar deze medisch relevant is. Het is afhankelijk van het zorgproces wanneer dit wel en niet van toepassing is. De informatiestandaard stelt dan ook geen eisen. Als handreiking: de context is veelal van belang bij de volgende BgZ secties:
| |
| − | * Diagnoses
| |
| − | * Verrichtingen
| |
| − | * Medicatievoorschriften
| |
| − | * Labuitslagen
| |
| − | * Behandelrestricties
| |
| − | * Alerts
| |
| − | * Allergieën
| |
| − | * Medische hulpmiddelen
| |
| − | * Zorgplan
| |
| − | en normaliter minder van belang bij:
| |
| − | * Demografie
| |
| − | * Financieel
| |
| − | * Contactpersonen
| |
| − | * Zorgverleners (huisarts)
| |
| − |
| |
| − | Altijd geldt dat een arts informatie op kan nemen als eigen gegevens wanneer deze opnieuw vastgesteld kunnen worden. Wanneer in de BgZ een allergie staat, en de arts verifieert dat met de patiënt, kan dat een eigen gegeven worden zonder externe context. Het overnemen wordt dan niet meer dan slim kopiëren.
| |
| − |
| |
| − | Historische informatie kan nooit een eigen gegeven worden: een labonderzoek of klinische meting van een half jaar geleden kan niet opnieuw gedaan worden.
| |
