Functioneel Ontwerp BgZ medisch-specialistische zorg

1 Inleiding

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:

1. uitwisselen BgZ bij verwijzing of overdracht;
2. opvragen BgZ van een eerdere behandeling.

In beide gevallen is er sprake van een voorgaande behandeling van een patiënt door een zorgverlener (links in het plaatje) en een latere behandeling bij een andere zorgverlener bij een andere zorgaanbieder (rechts in het plaatje). Het verschil zit in de partij die het initiatief neemt.

1. Bij verwijzing of overdracht neemt de huidige zorgverlener (links in het plaatje) het initiatief tot een verwijzing of overdracht. Daarbij wordt informatie gedeeld, waaronder de BgZ (en verder bijvoorbeeld een verwijsbrief, aanvullende beelden of verslagen etc.). De patiënt komt vervolgens als gevolg van de verwijzing of overdracht bij de volgende zorgverlener. Deze kan de informatie uit de BgZ (her)gebruiken.
2. Bij opvragen ligt het initiatief rechts in het plaatje. De huidige zorgverlener merkt dat er een voorgaande behandeling is geweest (bijvoorbeeld door informatie van de patiënt zelf) en wil graag informatie over deze eerdere behandeling. De BgZ wordt dan opgevraagd bij de eerdere zorginstelling, links in het plaatje, die deze verstrekt.

Wanneer de BgZ ontvangen wordt, kan een zorgverlener deze uiteraard inzien, maar de zorgverlener kan de informatie uit de BgZ deels of helemaal overnemen in het eigen dossier. Daarbij is sprake van reconciliëren: de "eigen" en "externe" informatie moet met elkaar kloppen: dubbele en/of conflicterende informatie moet voorkomen worden. Daarnaast is het van belang "meta-informatie" (informatie over de informatie) op te nemen. Duidelijk herkenbaar in het "eigen" dossier moet zijn welke informatie zelf is vastgelegd (of tenminste binnen de eigen zorginstelling) en welke informatie van elders afkomstig is, met daarbij broninformatie zoals welke zorginstelling deze informatie heeft aangeleverd.

Al deze aspecten worden in deze informatiestandaard uitgewerkt.

1.1 Algemeen

Voor meer over informatiestandaarden, zie: 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 webpagina voor informatiestandaarden.

1.2 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.

1.3 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.

1.3.1 Richtlijn en proces

De informatiestandaard betreft de volgende zorgprocessen:

1. 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.
2. 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).

1.3.2 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.

1.3.3 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.

1.3.4 Reikwijdte Informatiestandaard

De reikwijdte van de informatiestandaard beslaat de functionele beschrijvingen en de dataset voor alle gegevensuitwisselingen binnen één of meerdere zorgprocessen.

1.3.4.1 Instellingen

In scope zijn de volgende instellingen:

1. universitair medische centra;
2. ziekenhuizen;
3. klinische revalidatiecentra;
4. dialysecentra;
5. radiotherapeutische centra;
6. epilepsiecentra;
7. audiologische centra;
8. overige zelfstandige klinieken.

1.3.4.2 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.

1.3.5 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.

1.4 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 Kwalificatie BgZ Medisch-specialistische zorg.

1.5 Begrippenkader

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 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 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 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 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: 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.

1.6 Juridische aspecten

Gegevens mogen niet zomaar worden uitgewisseld of gebruikt. Ook mag het medisch beroepsgeheim niet zomaar worden doorbroken. Daarvoor zijn “gronden” nodig (zoals wet- of regelgeving, overeenkomsten of toestemming). Dit is allemaal bepaald in wet- en regelgeving. De informatiestandaard ziet hier niet op toe. Deze paragraaf schets enkel de betekenis van de wet- en regelgeving voor uitwisseling van de BGZ.

1.6.1 Toestemming

Zie de Factsheet 'Toestemmingen voor het uitwisselen van medische gegevens tussen zorgverleners' van VWS voor meer informatie.

Per geval zal moeten worden afgewogen hoe de gegevens gedeeld kunnen worden, om te beoordelen of toestemming is vereist of niet.

In de meeste gevallen zullen de gegevens vooraf klaargezet worden voor gebruik via een "elektronisch uitwisselingssysteem". Dit is een systeem waarmee gegevens kunnen worden gedeeld die vooraf beschikbaar zijn gesteld voor later onbekend gebruik. In zo’n geval is uitdrukkelijke toestemming van de patiënt vereist.

Het kan ook voorkomen dat de gegevens zonder voorafgaande beschikbaarstelling of raadpleegbaarheid worden uitgewisseld. Er is dan geen sprake van voorafgaande beschikbaarstelling zonder dat bekend is welke arts specifiek op welk moment zal raadplegen. Er wordt dan dus pas uitgewisseld op het moment dat dit noodzakelijk is. Ook in dit geval zal uitdrukkelijke toestemming vereist zijn. (Uitdrukkelijke toestemming is niet altijd vereist voor het delen van informatie binnen de behandelrelatie, maar deze informatiestandaard gaat alleen over het delen van de BgZ buiten de behandelrelatie.)

1.6.2 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:

1. Er is sprake van eerder gegeven toestemming aan de dossierhouder. Bijvoorbeeld, een patiënt kan na behandeling in ziekenhuis A toestemming geven om later gegevens 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.
2. 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.

1.6.3 Geen toestemming

Wanneer de patiënt geen uitdrukkelijke toestemming heeft gegeven voor 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.)

1.6.4 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.

1.6.5 Onvolledigheid gegevens

Uitgangspunt bij het ontvangen van een BgZ is dat er nooit vanuit mag worden gegaan dat gegevens volledig zijn. Een patiënt 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 ...").

1.6.6 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.

2 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.

2.1 Algemeen

De informatiestandaard BgZ voor medisch-specialistische zorg betreft de BgZ2017 en BgZ2020.

2.1.1 BgZ

De BgZ kent de volgende hoofdstukken:

1. Demografie en identificatie
2. Financiële informatie
3. Behandelrestricties
4. Contactpersonen
5. Functionele status
6. Klachten en diagnoses
7. Sociale anamnese
8. Waarschuwingen
9. Allergieën
10. Medicatie
11. Medische hulpmiddelen
12. Vaccinaties
13. Vitale functies
14. Uitslagen
15. Verrichtingen
16. Contacten
17. Zorgplan
18. Zorgverleners

Deze hoofdstukindeling geldt voor BgZ2017 en voor BgZ2020.

2.1.1.1 BgZ 2017

Functionele beschrijving: BgZ_specificatie_obv_zibs_2017_v1.1

De datasets en transacties worden ontwikkeld in de ART-DECOR omgeving van Nictiz.

BgZ2017 dataset in ART-DECOR

2.1.1.2 BgZ 2020

Functionele beschrijving: BgZ2020-specificatie-obv-zibs-2020-v1.1

ART-DECOR specificatie wordt nog opgesteld.

2.1.2 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.

2.1.2.1 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 die het document samengesteld heeft.

In de technische uitwerking wordt beschreven hoe deze metagegevens zich verhouden tot standaarden als XDS, CDA en FHIR.

2.1.2.2 Metagegevens op zib-niveau

2.1.2.2.1 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.

2.1.2.2.2 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.

2.1.2.2.3 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.

2.2 Use case 1: Uitwisseling BgZ bij verwijzing of overdracht

2.2.1 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, of 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.

2.2.2 Bedrijfsrollen

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).

2.2.3 Proces en context

2.2.3.1 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:

1. een verwijsbrief;
2. de BgZ van de patiënt;
3. 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.

2.2.3.2 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 geeft uitdrukkelijke toestemming voor (digitale) uitwisseling van gegevens.
• Behandelend en ontvangend ziekenhuis kunnen digitaal de BgZ uitwisselen.

2.2.3.3 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.

2.2.3.4 Proces

1. De behandelend arts kiest een instelling en specialisme (en mogelijk een zorgverlener binnen die instelling) waarnaar verwezen wordt.
2. De behandelend arts rondt de verwijzing af.
3. 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.
4. Een arts in de ontvangende instelling ziet de BgZ in, en neemt (indien gewenst) alle of een deel van de gegevens over.

2.3 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.

2.3.1 Bedrijfsrollen

Rol	Toelichting
Nieuwe 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.

2.3.2 Proces en context

2.3.2.1 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.

2.3.2.1.1 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 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.

2.3.2.1.2 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.

2.3.2.2 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.

2.3.2.3 Trigger event

Het verzoek van een behandelend arts om eerder vastgelegde gegevens van een andere instelling in te zien.

2.3.2.4 Proces

1. De behandelend arts vraagt een BgZ op.
2. 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.
3. De BgZ wordt ter beschikking gesteld aan de huidige behandelend arts.
4. De behandelend arts raadpleegt de BgZ, en neemt (indien gewenst) alle of een deel van de gegevens over..

3 Informatieoverdracht

Bij de informatieoverdracht wordt beschreven hoe de use cases - uitwisselingen tussen personen en instellingen - corresponderen met transacties tussen de informatiesystemen.

Voor de systeemsapecten maken we gebruik van het uitwisselingsmodel van Registratie aan de Bron.

Voor een toelichting op het hele model, zie het uitwisselingsmodel bij Registratie aan de Bron.

In het uitwisselingsmodel worden de volgende stappen onderkend:

1. Vastleggen
2. Opslaan
3. Extraheren
4. Converteren
5. Uitwisselen (sturen/beschikbaar stellen)
6. Ontvangen/raadgplegen
7. Verwerken
8. Hergebruiken

Deze stappen laten zich vertalen naar rollen.

• Stap 1 betreft het zib-conform vastleggen van gegevens. Daarvoor worden eisen gesteld als Vastleggend Systeem.
• Stappen 2 en 3 zien we als technische stappen, waar geen nadere eisen aan gesteld worden.
• Stap 4 wordt uitgewerkt in het technische deel van de informatiestandaard.
• Stap 5 gaat over het uitwisselen van een BgZ, en is uitgewerkt als Sturend Systeem en Beschikbaarstellend Systeem.
• Stap 6 gaat over het verkrijgen van een BgZ, en is uitgewerkt als Ontvangend Systeem en Raaplegend Systeem en wordt uitgewerkt in het technische deel van de informatiestandaard.
• Stap 7 betreft de processen van inzien, overnemen en reconciliëren, en zijn uitgewerkt als Verwerkend Systeem.
• Stap 8 is het daadwerkelijk (her)gebruik van gegevens door een zorgprofessional.

3.1 Soorten gegevens en metagegevens

Bij het opleveren van gegevens kunnen er verschillende soorten gegevens zijn, afhankelijk van het moment en de wijze van vastlegging.

1. Historische gegevens: in 1998 is voor patiënt X opgeslagen dat deze in 1992 appendicitis heeft ondergaan, maar er zijn geen nadere gegevens vastgelegd.
2. 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 eventueel vastleggen: patiënt.
   • In zib Verrichting alleen VerrichtingType 'appendicitis' en VerrichtingStartDatum '2012' vastleggen.
3. 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) en datum gegevens vastleggen en identificatie brondocument.
4. Nieuw vastgelegde gegevens: de patiënt ondergaat een appendicitis in de instelling.
   • Metagegevens en de relevante gegevens van Verrichting (Uitvoerder, Datum etc.) vastleggen.

De verschillende soorten gegevens leiden tot andere eisen aan de uitwisseling. Zo is het niet realistisch dat historische gegevens alsnog voorzien worden van alle metagegevens die bij nieuw vastgelegde gegevens wel worden voorzien. Ook is het bij een anamnese niet gewenst van een zorgverlener te verlangen dat bij een Verrichting elders uit het verleden Uitvoerder, Lateraliteit, Indicatie etc. worden ingevoerd wanneer de zorgverlener alleen behoefte heeft jaartal en VerrichtingType vast te leggen.

3.2 Systemen en systeemrollen

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, zeker waar het betreft welke gegevens wel en niet over te nemen. (Zelfstandige klinieken met een beperkt aanbod zullen daar mogelijk ook andere keuzes willen maken dan algemene ziekenhuizen.) 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.

3.2.1 Vastleggend Systeem

Eis	Toelichting
Vastleggen als zibs	Het EPD moet nieuwe gegevens, die vastgelegd worden als gevolg van een behandeling in de eigen instelling, vastleggen als zibs voor zover de gegevens onderdeel kunnen zijn van een later aan te maken BgZ. (Aan zibs die niet in de BgZ zitten stelt deze informatiestandaard geen eisen.)
Toevoegen metagegevens	Het EPD moet nieuwe gegevens die vastgelegd worden als zibs voorzien van metagegevens, met tenminste: een persistente identificatie; een datumtijd; een verantwoordelijke zorgverlener, wanneer het een medisch gegeven betreft waar dit relevant is. Vastleggen gebeurt zoveel mogelijk automatisch, bijvoorbeeld door huidige datumtijd te gebruiken. De datumtijd en zorgverlener kunnen onderdeel zijn van de zib (zo kent de zib Verrichting een Uitvoerder en een VerrichtingStartDatum). Waar dat niet het geval is, worden de BasisElementen gebruikt. In dat geval kan de ingelogde zorgverlener Auteur zijn en de huidige datumtijd gebruikt worden.

3.2.2 Sturend Systeem

Eis	Toelichting
Sturen bij verwijzing	Het EPD moet een BgZ kunnen sturen bij verwijzing naar een andere zorginstelling of zorgverlener.
Zorginstelling kiezen	Een zorgverlener moet een andere zorginstelling kunnen kiezen om een BgZ mee te delen, met eventueel specialisme.

3.2.3 Beschikbaarstellend Systeem

Eis	Toelichting
BgZ beschikbaar stellen	Het EPD moet de mogelijkheid bieden om op een opvraging een BgZ beschikbaar te stellen.
Vasstellen toestemming	Het EPD moet kunnen vaststellen dat sprake is van een eerder gegeven toestemming die delen van het BgZ toestaat.

3.2.4 Sturend en Beschikbaarstellend Systeem

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.
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 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 een 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. Er moet geen eigen identificatie aangemaakt worden wanneer het medicatievoorschrift elders is opgesteld.
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, maar is zeker voor historische gegevens niet uit te sluiten.
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 is niet wenselijk.)

3.2.5 Raadplegend Systeem

Eis	Toelichting
BgZ opvragen	Het EPD moet de mogelijkheid bieden om een BgZ op te vragen bij een beschikbaarstellend EPD.
Kiezen BgZ	Een zorgverlener moet een te bevragen zorginstelling kunnen kiezen, ofwel een lijst tonen met alle beschikbare BgZ's in een repository.

3.2.6 Ontvangend Systeem

Eis	Toelichting
BgZ ontvangen	Het EPD moet de mogelijkheid bieden om een BgZ te ontvangen.
Verwittigen ontvangst	Het EPD moet de betrokken afdelingen (administratief en/of specialisme) kunnen verwittigen van een ontvangen BgZ, waarna die BgZ ingezien kan worden.

3.2.7 Verwerkend Systeem

Eis	Toelichting
Inzien	Een EPD moet alle informatie die via een BgZ ontvangen wordt 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.

Bij de verwerking van de informatie kan de informatie ingezien worden (met bijvoorbeeld een viewer die het document laat zien) of kan er informatie overgenomen worden.

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.

3.2.8 Inzien (Verwerkend Systeem)

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.) Inzien kan bijvoorbeeld met een "viewer"-functie waarbij het BgZ getoond wordt vanuit het eigen EPD. Inzien is ook nodig voor gevallen waarbij de ontvangende zorgverlener de BgZ niet over wil nemen.

Eis	Toelichting
Inzien	Een EPD moet alle informatie die via een BgZ ontvangen wordt kunnen tonen aan de zorgverlener. De informatie die getoond wordt, moet uit de gestructureerde zibs in de BgZ getoond worden waar deze aanwezig zijn. Het gaat niet om het inzien van een PDF of tekstuele secties uit een document.

3.2.9 Overnemen (Verwerkend Systeem)

Wanneer informatie uit een aangeleverde BgZ overgenomen wordt in het eigen EPD, kunnen er twee situaties optreden:

• alle informatie is nieuw (met name wanneer de patiënt nog niet bekend was), en,
• de informatie is deels of geheel al bekend.

In beide gevallen kan het nodig zijn te selecteren welke informatie overgenomen wordt. Bijvoorbeeld kunnen alle klachten en diagnoses overgenomen worden, of alleen een specifieke diagnose. Daarnaast kan het nodig zijn de informatie te reconciliëren: dubbele informatie weglaten of conflicterende informatie in overeenstemming brengen. Bij overnemen en reconciliatie is het gebruiksgemak van belang: de zorgverlener moet maximaal ondersteund worden bij het overnemen. Er moeten dus niet meer handelingen ingebouwd worden dan nodig.

Eis	Toelichting
Zibs overnemen	Een EPD dat gegevens overneemt neemt deze over als discrete zibs.
Zib-compliant opslaan	Een EPD dat zibs overneemt moet deze ook weer als zibs kunnen ontsluiten.
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.
Metagegevens opslaan	Bij iedere overgenomen zib worden metagegevens opgeslagen. Dit is minimaal: de instelling vanwaar de gegevens betrokken zijn; een datumtijd: bij voorkeur van de zib zelf, maar anders een datumtijd van het document of bericht waaruit de zibs komen; een identificatie, bij voorkeur een persistente identificatie van de zib zelf, maar wanneer de BgZ deze niet bevat, een document- of berichtidentificatie.
Zorgverlener opslaan	Daarnaast wordt de verantwoordelijke zorgverlener overgenomen wanneer deze in de zib of de metagegevens van de zib zit. Bij historische of van oorspronkelijk elders betrokken gegevens kan deze zorgverlener niet altijd gevuld zijn. Daarnaast gaat het alleen om gegevens van de zorgverlener waar dit medisch relevant is. Bijvoorbeeld een voorschrijver van medicatie, steller van een diagnose of uitvoerder van een verrichting is relevant. Administratief personeel dat gegevens zoals contactpersonen invoert is dat niet.

Bij het overnemen zijn processen behulpzaam: selecteren, ontdubbelen en duplicaatdetectie.

3.2.9.1 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.

Dat ontdubbelen kan, betekent niet automatisch dat het wenselijk is. Dat is een keuze die een zorginstelling in samenspraak met de leverancier van het systeem maakt. 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, Handmatige reconciliatie en Automatisch overnemen.

3.2.9.2 Duplicaatdetectie

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 inbouwen.

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.

3.2.9.3 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 toegepast.

3.2.9.4 Handmatige reconciliatie

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 toegepast. Bij het overnemen wordt de informatie gekopieerd met behoud van structuur en coderingen.

Er worden geen strikte eisen gesteld aan de wijze waarop een EPD dit inricht, omdat dit van systeem tot systeem anders kan zijn. Een mogelijke flow staat hieronder.

1. De zorgverlener opent een binnengekomen BgZ, naast het eigen dossier, zodat duidelijk zichtbaar is wat al bekend is en wat in de BgZ zit.
2. De zorgverlener kiest over te nemen gegevens, bijvoorbeeld:
   • de hele BgZ;
   • een of meer secties uit de BgZ (bijvoorbeeld "Klachten en diagnoses" en "Verrichtingen";
   • een specifieke zib (bijvoorbeeld alleen één bepaald probleem.
3. Na het aanvinken van de over te nemen secties of zibs kiest de zorgverlener voor het overnemen.
4. Bij het overnemen worden metagegevens van iedere overgenomen zib meegenomen.

Op deze wijze kan een zorgverlener de consistentie van het eigen dossier bewaken. Ook worden alleen die gegevens overgenomen die nodig zijn, en geen gegevens die niet relevant zijn voor het huidige zorgproces.

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.

3.2.9.5 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 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.

3.2.9.6 Vasthouden externe context

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)

3.3 Transacties en transactiegroepen

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.

Transactiegroep	Transactie	Systeemrol	Verwerkersrol
Delen BgZ	Sturen BgZ	Sturend Systeem	Gegevensverstrekkend Systeem
	Ontvangen BgZ	Ontvangend Systeem	Gegevensontvangend Systeem
Opvragen BgZ	Raadplegen BgZ	Raadplegend Systeem	Gegevensontvangend Systeem
	Beschikbaarstellen BgZ	Beschikbaarstellend Systeem	Gegevensverstrekkend Systeem

Tabel Overzicht transactiegroepen

De transacties 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.

3.3.1 Use cases en transactiegroepen

Beide use cases kunnen met beide transactiegroepen ondersteund worden.

Bij verwijzing kan het BgZ verzonden worden over een infrastructuur zoals veilige mail, maar ook in een repository geplaatst worden waar de ontvanger toegang toe heeft.

Bij opvragen BgZ ligt een repository de bevraagd kan worden (met de juiste toestemming en autorisatie) voor de hand. Maar waar deze optie (nog) niet beschikbaar is, kan contact opgenomen worden met de dossierhouder die vervolgens de BgZ stuurt. Omdat de te kiezen infrastructuur buiten scope is voor deze informatiestandaard, en er ook regionale oplossingen mogelijk zijn, wordt dit vanuit deze informatiestandaard niet verder ingeperkt.