BgZ:V1.1.0 Ontwerp BgZ MSZ

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.

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.

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:

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

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.

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

1. universitair medische centra;
2. ziekenhuizen;
3. klinische revalidatiecentra;
4. dialysecentra;
5. radiotherapeutische centra;
6. epilepsiecentra;
7. audiologische centra;
8. 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 Kwalificatie BgZ Medisch-specialistische zorg.

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 (EPD)​	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.

Toestemming

Voor uitwisselen van medische gegevens is een grondslag nodig. Toestemmingen daarvoor zijn niet specifiek voor de BgZ, maar spelen bij iedere vorm van uitwisseling van medische gegevens.

• Zie de Factsheet 'Toestemmingen voor het uitwisselen van medische gegevens tussen zorgverleners' van VWS voor meer informatie over toestemmingen.
• Zie de 'Richtlijn omgaan met medische gegevens' van de KNMG voor algemene aanwijzingen voor delen van medische gegevens door specialisten.

Dataset

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

BgZ

BgZ 2017

Functionele beschrijving: BgZ_specificatie_obv_zibs_2017_v1.1

De datasets en transacties worden ontwikkeld in ART-DECOR.

BgZ 2020

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

De datasets en transacties worden ontwikkeld in ART-DECOR.

Dataset BgZ 2017 en BgZ 2020

0	BgZ 2017		Version	BgZ 2020		Version
1. Demografie en identificatie		Demographics and identification
	Patient	Patient	3.1	Patient	Patient	3.2
	BurgerlijkeStaat	MaritalStatus	3.0	BurgerlijkeStaat	MaritalStatus	3.1
2. Financiële informatie		Financial information
	Betaler	Payer	3.1	Betaler	Payer	3.1.1
3. Behandelrestricties		Treatment Directives
	BehandelAanwijzing	TreatmentDirective	3.1	BehandelAanwijzing2	TreatmentDirective2	1.0
	Wilsverklaring	AdvanceDirective	3.1	Wilsverklaring	AdvanceDirective	3.1.1
4. Contactpersonen		Contact persons
	Contactpersoon	ContactPerson	3.1	Contactpersoon	ContactPerson	3.4
5. Functionele status		Functional Status
	FunctioneleOfMentaleStatus	FunctionalOrMentalStatus	3.1	FunctioneleOfMentaleStatus	FunctionalOrMentalStatus	3.2
				FunctieHoren	HearingFunction	3.2
				FunctieZien	VisualFunction	3.1
				Mobiliteit	Mobility	3.3
				Taalvaardigheid	LanguageProficiency	3.2
6. Klachten en diagnoses		Complaints and diagnoses
	Probleem	Problem	4.1	Probleem	Problem	4.4
7. Sociale anamnese		Social anamnesis
	Woonsituatie	LivingSituation	3.1	Woonsituatie	LivingSituation	3.3
	DrugsGebruik	DrugUse	3.2	DrugsGebruik	DrugUse	3.3
	AlcoholGebruik	AlcoholUse	3.1	AlcoholGebruik	AlcoholUse	3.2
	TabakGebruik	TobaccoUse	3.1	TabakGebruik	TobaccoUse	3.2
	Voedingsadvies	NutritionAdvice	3.1	Voedingsadvies	NutritionAdvice	3.2
8. Waarschuwingen		Alerts
	Alert	Alert	3.2	Alert	Alert	4.1
9. Allergieën		Allergies
	AllergieIntolerantie	AllergyIntolerance	3.2	AllergieIntolerantie	AllergyIntolerance	3.3
10. Medicatie		Medication
	MedicatieGebruik2	MedicationUse2	1.0.1
	Medicatieafspraak	MedicationAgreement	1.0.1
	Toedieningsafspraak	AdministrationAgreement	1.0.1
				MedicatieContraIndicatie	MedicationContraIndicaton	1.0
11. Medische hulpmiddelen		Medical devices
	MedischHulpmiddel	MedicalDevice	3.1	MedischHulpmiddel	MedicalDevice	3.3.1
12. Vaccinaties		Immunizations
	Vaccinatie	Vaccination	3.1	Vaccinatie	Vaccination	4.0
13. Vitale functies		Vital signs
	Bloeddruk	BloodPressure	3.1	Bloeddruk	BloodPressure	3.2.1
	LichaamsGewicht	BodyWeight	3.1	LichaamsGewicht	BodyWeight	3.2
	LichaamsLengte	BodyHeight	3.1	LichaamsLengte	BodyHeight	3.1.1
14. Uitslagen		Results
	LaboratoriumUitslag	LaboratoryTestResult	4.1	LaboratoriumUitslag	LaboratoryTestResult	4.6
15. Verrichtingen		Procedures
	Verrichting	Procedure	4.1	Verrichting	Procedure	5.2
16. Contacten		Encounters
	Contact	Encounter	3.1	Contact	Encounter	4.0.1
17. Zorgplan		Care plan
	OverdrachtGeplandeZorgActiviteit	PlannedCareActivityForTransfer	3.1
				MedicatieToediening	MedicationAdministration	1.1.1
				MedischHulpmiddel	MedicalDevice	see above
				Verrichting	Procedure	see above
				VerpleegkundigeInterventie	NursingIntervention	3.2
				Vaccinatie	Vaccination	see above
				Contact	Encounter	see above
18. Zorgverleners		Health professionals
	Zorgverlener	HealthProfessional	3.2	Zorgverlener	HealthProfessional	3.5

Scope van de BgZ voor medisch-specialistische zorg

De scope van de BgZ is in de BgZ2020 preciezer beschreven dan in de BgZ2017. Deze precisering dient gevolgd te worden. Daarnaast zijn aanvullende inzichten opgenomen in andere documenten, deze zijn hier toegevoegd. TODO:

• problemen, actueel en relevant zie handreiking
• sociale anamnese: alleen laatste uitvraag of alle?
• medicatie, hoe lang
• verrichtingen, alleen van belang (niet: alle diagnostische verrichtingen ooit)
• alerts, b.v. MRSA besmetting die niet meer actueel is

Demografie en identificatie

Laatst bekende gegevens.

Contactpersonen

Eerste relatie/contactpersoon, indien beschikbaar.

Behandelrestricties

Laatst bekende gegevens.

Functionele status

Van elke functionele/mentale status de laatst bekende, indien beschikbaar.

Klachten en diagnoses

Volgens de BgZ2020: Alle bekende problemen van alle probleemtypen, van alle toegestane coderingen van 'ProbleemNaam'.

In de handreiking FMS is dit nader gepreciseerd voor niet-actuele problemen: "Het probleem is opgelost of verdwenen en zal geen consequenties hebben voor toekomstige zorg. Deze problemen worden verwijderd van probleemlijst en kunnen desgewenst worden opgenomen in een historisch overzicht."

VRAAG: hoe zit dit voor de BgZ-uitwisseling? Kunnen we volstaan met probleemlijst (dus actueel + niet actueel maar wel relevant voor toekomstige zorg) of moet het historisch overzicht daar ook in? ((dus niet actueel+ niet relevant voor toekomstige zorg)

VOORSTEL: alleen de bijgewerkte probleemlijst, dus actueel en niet actueel maar wel relevant voor toekomstige zorg

Sociale anamnese

Laatst bekende woonsituatie. Alle bekende middelengebruik en voedingsadviezen.

VRAAG: Kwaliteitsstandaard (draft) spreekt van: “Laatst bekende ...”

VOORSTEL: Alleen de laatste samenhangende uitvraag door een zorgverlener. Wanneer die uitvraag gedaan is in detail (b.v.: "rookte pakje per dag van 2012 tot 2020, rookt niet vanaf 2020") worden die details uitgewisseld, maar eerdere uitvragen worden niet uitgewisseld.

Waarschuwingen

Alle bekende alerts, indien beschikbaar.

VRAAG: Blijven alle alerts wel relevant? B.v. MRSA van lang geleden?

VOORSTEL: Alerts die niet meer van belang zijn voor toekomstige zorg worden niet uitgewisseld.

Allergieën

TODO: overleg CiO

Medicatie

TODO: Overleg MP

Medische hulpmiddelen

BgZ zegt: Alle bekende medische hulpmiddelen, indien beschikbaar.

VRAAG: Veel hulpmiddelen zijn na gebruik niet meer relevant, b.v. krukken of een rolstoel die niet meer gebruikt wordt.

VOORSTEL: ...

Vaccinaties

Alle bekende vaccinaties, indien beschikbaar.

Vitale functies

Laatst bekende bloeddruk, indien beschikbaar.

Uitslagen

Alle bekende klinische chemie bepalingen, van elke klinische bepaling de laatst bekende uitslag, indien beschikbaar. Hieronder valt ook bloedgroeptypering (normaliter/vaak vallend onder klinische chemie).

Verrichtingen

BgZ: Alle bekende verrichtingen, indien beschikbaar.

Kwaliteitsstandaard (draft): “Alle bekende therapeutische of diagnostische verrichtingen ... “

VRAAG: is dit laatste niet veel te breed?

• Diagnostische verrichtingen zijn ook alle echo’s, foto’s, labonderzoeken etc. etc. van jaren her.
• Er is in de zib geen mechanisme om hier iets aan te doen, b.v. actuele of relevante verrichtingen tonen
• Focus voor discussie even op therapeutische en recente diagnostische verrichtingen.

Contacten

Alle bekende contacten.

Metagegevens

Uitgangspunten

Bij het overnemen van gegevens van elders is sprake van reconciliatie en ontdubbelen: er moet na overnemen sprake zijn van een consistente set gegevens zonder (te veel) dubbele gegevens. Helemaal is dat niet te voorkomen, wel is het zaak dat zoveel mogelijk te voorkomen.

Daarbij spelen twee zaken:

• van duplicaatgegevens hoeft maar een voorkomen getoond of overgenomen te worden;

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 EPD van B. 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.

• van gegevens die wijzigen in de tijd is de meest recente van belang.

Voorbeeld: een patiënt komt in ziekenhuis A, waar een BgZ wordt opgevraagd van ziekenhuis B. In de BgZ is sprake van kortademigheid in de probleemlijst, beginnend op 15-11-2012 met status 'Actueel'. Dit wordt overgenomen in het EPD van ziekenhuis A. Een jaar later komt de patiënt opnieuw in ziekenhuis A, waar weer BgZ wordt opgevraagd van ziekenhuis B. Daar is vastgelegd dat de kortademigheid 'Niet actueel' is. Alleen de laatste situatie is van belang.

Gegevens kunnen vergeleken worden door:

• het gegeven zelf, bijvoorbeeld tweemaal het emailadres "patient@example.com" is hetzelfde emailadres;
• een identificatie, wanneer twee gegevens betreffende een pacemaker hetzelfde productID hebben, kan ervan uitgegaan worden dat dat dezelfde pacemaker betreft;
• een deel van de gegevens, bijvoorbeeld twee gegevens over een contact met dezelfde zorgverlener op dezelfde datum kunnen beschouwd worden als hetzelfde contactmoment.

Doel van de sectie metagegevens is aan te geven welke metagegevens minimaal vastgelegd moeten worden om ontdubbelen en reconciliatie mogelijk te maken. Hoe en wanneer dat precies plaatsvindt wordt niet voorgeschreven. Overnemen van gegevens is een mogelijkheid, en kan niet verplicht worden zonder te weten of dat overnemen medisch relevant is.

Metagegevens kunnen op document- en zib-niveau aanwezig zijn.

Metagegevens op documentniveau

Wanneer de BgZ uitgewisseld wordt als document, zijn metagegevens voor het document zelf verplicht. 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.

Metagegevens op zib-niveau

Zibs die uitgewisseld worden kennen een context, waarvan een deel in de BasisElementen zit. Dit zijn de BasisElementen in zibs 2017:

• Identificatienummer van het gegeven / de zib;
• Auteur (de vastlegger);
• Informatiebron (wie de informatie geleverd heeft);
• Onderwerp (meestal: patiënt);
• DatumTijd (dit is de medisch relevante datum en tijd).

Daarnaast is bij uitwisseling met de BgZ van belang:

• (verantwoordelijke) instelling.

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.

In latere versies van de zibs zijn er RegistratieGegevens toegevoegd. Deze bevatten naast de gegevens uit de basiselementen ook andere, zoals:

• RegistratieDatumTijd;
• RedenAfwezigheidGegevens;
• KopieIndicator.

Waar nodig gebruikt deze informatiestandaard deze gegevens al.

Daarnaast is er een:

• GegevensBron.

Dit is de bron waarvan gegevens betrokken zijn, bijvoorbeeld de zorginstelling waar de gegevens bij opgevraagd zijn of die gegevens verzonden heeft. Dit zal altijd een ZorgInstelling zijn. Dit gegeven zit niet in de zibs, omdat het pas in de transactie tot stand komt. Een EPD kan dit wel opslaan bij het uitvoeren van de transactie.

De RegistratieDatumTijd is een ander gegeven dan de DatumTijd. De laatste is de medisch relevante datum en tijd, bijvoorbeeld begindatum van een Probleem. De RegistratieDatumTijd is het moment van vastleggen en kan gebruikt worden om de meest recente registratie van hetzelfde Probleem te vinden.

In de sectie metagegevens wordt vastgelegd welke metagegevens uitgewisseld moeten worden om reconciliatie van gegevens uit twee bronnen (veelal een BgZ en het eigen EPD) mogelijk te maken. De mee te zenden gegevens zijn normatief. In de sectie 'Overnemen' wordt beschreven hoe de reconciliatie dan plaats kan vinden. Dat zal veelal niet normatief zijn: hoe een EPD omgaat met gegevens is ook een afspraak tussen leverancier en afnemer.

Metadata tabel

TODO:

• Nederlands maken (Engelse kolommen mag wel).
• Toevoegen registratiedatum en identificatie.

Metadata are often already present in the HCIMs themselves: in that case there is no need to add them to the HCIM again. In other cases, the metadata is not relevant. The table below lists the various Basic Elements against the HCIMs.

Id	Zib	HCIM	Identificatienummer	DatumTijd
NL-CM:0.1.1	Patient	Patient	PatientIdentificationNumber	DateOfBirth
NL-CM:1.1.1	Betaler	Payer	BankCode+AccountNumber OF IdentificationNumber+InsurantNumber	StartDateTime+EndDateTime
NL-CM:2.1.1	BehandelAanwijzing	TreatmentDirective	Noodzakelijk	VerificationDate
NL-CM:7.15.1	Wilsverklaring	AdvanceDirective	Noodzakelijk	LivingWillDate
NL-CM:3.1.1	Contactpersoon	Contactperson	Niet Relevant	Niet Relevant
NL-CM:4.26.1	FunctioneleOfMentaleStatus	FunctionalOrMentalStatus	Noodzakelijk	StatusDate
NL-CM:5.1.1	Probleem	Problem	Noodzakelijk	ProblemStartDate
NL-CM:7.8.1	Woonsituatie	LivingSituation	Optioneel	Niet Relevant
NL-CM:7.4.1	DrugsGebruik	DrugUse	Noodzakelijk	StartDate
NL-CM:7.3.1	AlcoholGebruik	AlcoholUse	Noodzakelijk	StartDate
NL-CM:7.2.1	TabakGebruik	TobaccoUse	Noodzakelijk	StartDate
NL-CM:7.11.1	Voedingsadvies	NutritionAdvice	Noodzakelijk	Niet Relevant
NL-CM:8.3.1	Alert	Alert	Noodzakelijk	StartDateTime
NL-CM:8.2.1	AllergieIntolerantie	AllergyIntolerance	Noodzakelijk	StartDateTime
NL-CM:9.6.9580	Medicatieafspraak	MedicationAgreement	Noodzakelijk	MedicationAgreementDateTime
NL-CM:9.8.20132	Toedieningsafspraak	AdministrationAgreement	Noodzakelijk	AdministrationAgreementDateTime
NL-CM:9.11.21338	MedicatieGebruik	MedicationUse2	Noodzakelijk	MedicationUseDateTime
NL-CM:10.1.1	MedischHulpmiddel	MedicalDevice	ProductID	StartDate
NL-CM:11.1.1	Vaccinatie	Vaccination	ProductCode+VaccinationDate	VaccinationDate
NL-CM:12.4.1	Bloeddruk	BloodPressure	BloodPressureDateTime	BloodPressureDateTime
NL-CM:12.1.1	Lichaamsgewicht	BodyWeight	WeightDateTime	WeightDateTime
NL-CM:12.2.1	Lichaamslengte	BodyHeight	HeightValue OF HeightDateTime	HeightDateTime
NL-CM:14.1.1	Verrichting	Procedure	Noodzakelijk	ProcedureStartDate
NL-CM:15.1.1	Contact	Encounter	ContactType + StartDateTime	StartDateTime
NL-CM:17.1.1	Zorgverlener	HealthProfessional	HealthProfessionalIdentificationNumber	Niet Relevant

In deze tweede tabel is te zien welke metadata gebruikt kunnen worden voor de 'auteur', 'onderwerp' en 'informatiebron'.

Id	Zib	HCIM	Auteur	Onderwerp	Informatiebron
NL-CM:0.1.1	Patiënt	Patiënt	Niet Relevant	Patiënt	Niet Relevant
NL-CM:1.1.1	Betaler	Payer	Niet Relevant	Patiënt	Niet Relevant
NL-CM:2.1.1	BehandelAanwijzing	TreatmentDirective	Optioneel	Patiënt	Patiënt OF diens vertegenwoordiger
NL-CM:7.15.1	Wilsverklaring	AdvanceDirective	Optioneel	Patiënt	Patiënt OF diens vertegenwoordiger
NL-CM:3.1.1	Contactpersoon	Contactperson	Niet Relevant	Contactpersoon	Niet Relevant
NL-CM:4.26.1	FunctioneleOfMentaleStatus	FunctionalOrMentalStatus	Optioneel	Patiënt	Noodzakelijk
NL-CM:5.1.1	Probleem	Problem	Optioneel	Patiënt	Noodzakelijk
NL-CM:7.8.1	Woonsituatie	LivingSituation	Niet Relevant	Patiënt	Optioneel
NL-CM:7.4.1	DrugsGebruik	DrugUse	Optioneel	Patiënt	Noodzakelijk
NL-CM:7.3.1	AlcoholGebruik	AlcoholUse	Optioneel	Patiënt	Noodzakelijk
NL-CM:7.2.1	TabakGebruik	TobaccoUse	Optioneel	Patiënt	Noodzakelijk
NL-CM:7.11.1	Voedingsadvies	NutritionAdvice	Optioneel	Patiënt	Noodzakelijk
NL-CM:8.3.1	Alert	Alert	Leeg OF gelijk aan de Bron	Patiënt	Noodzakelijk
NL-CM:8.2.1	AllergieIntolerantie	AllergyIntolerance	Leeg OF gelijk aan de Bron	Patiënt	Verplicht
NL-CM:9.6.9580	Medicatieafspraak	MedicationAgreement	Leeg OF gelijk aan de Bron	Patiënt	Prescriber::HealthProfessional
NL-CM:9.8.20132	Toedieningsafspraak	AdministrationAgreement	Leeg OF gelijk aan de Bron	Patiënt	Supplier::HealthProfessional
NL-CM:9.11.21338	MedicatieGebruik	MedicationUse2	Leeg OF gelijk aan de Bron	Patiënt	Prescriber::HealthProfessional
NL-CM:10.1.1	MedischHulpmiddel	MedicalDevice	Leeg OF gelijk aan de Bron	Patiënt	HealthProfessional
NL-CM:11.1.1	Vaccinatie	Vaccination	Leeg OF gelijk aan de Bron	Patiënt	Administrator::Healthprofessional
NL-CM:12.4.1	Bloeddruk	BloodPressure	Leeg OF gelijk aan de Bron	Patiënt	Noodzakelijk
NL-CM:12.1.1	Lichaamsgewicht	BodyWeight	Leeg OF gelijk aan de Bron	Patiënt	Noodzakelijk
NL-CM:12.2.1	Lichaamslengte	BodyHeight	Leeg OF gelijk aan de Bron	Patiënt	Noodzakelijk
NL-CM:14.1.1	Verrichting	Procedure	Leeg OF gelijk aan de Bron	Patiënt	Performer::HealthProfessional
NL-CM:15.1.1	Contact	Encounter	Leeg OF gelijk aan de Bron	Patiënt	ContactWith::HealthProfessional
NL-CM:17.1.1	Zorgverlener	HealthProfessional	Niet Relevant	Zorgverlener	Niet Relevant

Toe te voegen metagegevens

Identificatienummer	Een identificatienummer mag altijd toegevoegd worden (de technische uitwerking in CDA en FHIR kent vaak een attribuut voor identificatie, dit mag altijd gevuld worden. Maar voor reconciliatie is het vaak niet nodig. Wanneer het verplicht gevuld moet worden, is hieronder beschreven.
Auteur (de vastlegger)	In het kader van de BgZ is het zelden van belang wie de gegevens heeft ingevoerd. Waar dat wel het geval is, wordt dit aangegeven.
Informatiebron (wie de informatie geleverd heeft)	Bij de BgZ is het wel van belang wie verantwoordelijk is voor de informatie. Dat betekent niet dat de informatiebron altijd verplicht is: wie de bron is van het emailadres van een patiënt, doet er niet toe. Ook kan er bij een sociale anamnese vanuit gegaan worden dat de bron de patiënt is, of een mantelzorger. Dit verplicht uitwisselen voegt onvoldoende toe. Belangrijker is het bij medisch handelen of oordelen, zoals bij voorschrijven of stellen van een diagnose. Wanneer het verplicht gevuld moet worden, is hieronder beschreven.
Onderwerp	Het onderwerp is in de BgZ altijd de patiënt. Deze moet altijd toegevoegd zijn, ofwel expliciet door deze op te nemen in een zib, of impliciet door gegevens van een bepaalde patiënt op te vragen. Omdat deze altijd verplicht is, is dit hieronder per hoofdstuk benoemd.
DatumTijd (dit is de medisch relevante datum en tijd)	De medisch relevante datum en tijd is al onderdeel van de zib, wanneer van belang, en in andere gevallen niet relevant. Dit hoeft dus niet als metatagegeven toegevoegd te worden.
RegistratieDatumTijd	De datum en tijd waarop een gegeven is vastgelegd of gewijzigd, is maar zelden een onderdeel van de zib. Wanneer het verplicht gevuld moet worden, is hieronder beschreven.

Demografie en identificatie, Financiële informatie, Contactpersonen

Een deel van de informatie wordt betrokken uit andere bronnen (SBV-Z, Vecozo). Voor een deel van de gegevens (zoals het email-adres of mobiele nummer van de patiënt) of andere financieringsbronnen dan de verzekering geldt dat niet. Het betreft echter weinig gegevens, die niet vaak wijzigen.

Geen speciale voorzieningen, bij conflicterende gegevens patiënt of mantelzorger vragen.

Metagegeven	Al aanwezig	Toevoegen	Toelichting
Identificatienummer	Identificatienummer (NL-CM:0.1.7)	-
Informatiebron	-	Nee	De patiënt of een mantelzorger zal de bron zijn. Dit expliciet vastleggen heeft weinig meerwaarde.
RegistratieDatumTijd	-	Optioneel

Behandelrestricties

Geen speciale voorzieningen. Alle beschikbare informatie tonen. Daarbij indien mogelijk sorteren op datum.

Functionele status

Geen speciale voorzieningen. Als er gegevens uit meerdere bronnen zijn: sorteren op StatusDatum en de laatste uitvraag tonen. Resultaten van oudere uitvragen kunnen eventueel nog opgeslagen worden als historie.

Klachten en diagnoses

Hierover volgt een besluit na overleg met stakeholders in de medisch-specialistische zorg.

Sociale anamnese

Zibs Woonsituatie, Drugsgebruik, Alcoholgebruik, Tabakgebruik, Voedingsadvies

De sociale anamnese kan vaker afgenomen worden. De uitvraag zal meestal een samenhangende uitvraag door de zorgverlener zijn. Bij reconciliatie is het dan van belang te weten wat de laatst bekende situatie is.

Waarschuwingen

Alle Alerts moeten worden getoond. Geen registratiedatum opnemen. Ook niet filteren op datum. Filteren kan met AlertNaam en/of BeginDatum.

Allergieën

Dit betreft de Zib AllergieIntolerantie. Richtlijnen voor het vastleggen van gegevens in deze zib worden gegeven vanuit de informatiestandaard Contra-indicatie en Overgevoeligheden (CiO). Kijk hier voor de laatste versie van de Informatiestandaard CiO .

Medicatie

Dit betreft de zibs Medicatieafspraak, Toedieningsafspraak en MedicatieGebruik2. Richtlijnen voor het vastleggen van gegevens in deze zibs worden gegeven vanuit de informatiestandaard MedicatieOverdracht. Kijk hier voor de laatste versie van de informatiestandaard MedicatieOverdracht .

Medische hulpmiddelen

Dit betreft de zib MedischHulpmiddel. Ontdubbelen kan met ProductID, onderdeel van de zib MedischHulpmiddel. Deze zib bevat ook de elementen BeginDatum, EindDatum, Zorgverlener en Locatie::Zorgaanbieder. Deze gegevens volstaan voor het reconciliëren. Het advies voor het reconciliëren is om eerst te ontdubbelen op ProductID. Na het ontdubbelen de meest volledige gegevens tonen. .

Vaccinaties

Dit betreft de zib Vaccinatie. Ontdubbelen kan met een combinatie van ProductCode en VaccinatieDatum, allebei onderdeel van de zib Vaccinatie. Na het ontdubbelen de meest actuele gegevens tonen.

Vitale functies

Dit betreft de zibs Bloeddruk, Lichaamsgewicht en Lichaamslengte. Ontdubbelen kan in alle drie de zibs met DatumTijd. Alleen de meest recente waarden tonen. Oudere informatie kan worden bewaard als historie.

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.

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.

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

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

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:

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.

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

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.

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.

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.

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.

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.

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.

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.

Trigger event

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

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

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

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.

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.

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.

Metagegevens bij vastleggen

TODO

• Toevoegen registratiedatum
  • Sociale anamnese
  • Probleem
  • ..etc.
• toevoegen identifier
  • Probleem
  • Verrichting
  • ..etc.

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.

Beschikbaarstellend Systeem

Eis	Toelichting
BgZ beschikbaar stellen	Het EPD moet de mogelijkheid bieden om op een opvraging een BgZ beschikbaar te stellen.

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

Historische informatie en zib-compliancy

TODO: AI

• afwijkende codes
• tekstuele weergave
• etc.

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.

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.

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.

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.

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

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.

Voorbeeld: Instelling A levert een BgZ aan instelling B waarin staat dat de patiënt in 2012 een appendicitis heeft ondergaan. Er zitten geen nadere metagegevens bij de zib (waarschijnlijk omdat het oudere gegevens betreft waarvoor dit niet is vastgelegd). Een arts van instelling B wil dit gegeven overnemen. Het systeem neemt de Verrichting over, en legt als bron het BgZ document waaruit het gegeven gekomen is vast, met documentidentificatie, documentdatum en de instelling waarvan het document betrokken is.

Voorbeeld: Instelling A levert een BgZ aan instelling B waarin staat dat de patiënt in 2018 een appendicitis heeft ondergaan, met Uitvoerder, VerrichtingStartdatum en een identificatie van de Verrichting. Een arts van instelling B wil dit gegeven overnemen. Het systeem neemt de Verrichting over, en legt als bron de metadata van de zib zelf vast, en daarnaast de instelling waarvan het gegeven betrokken is. Vastleggen van documentidentificatie en documentdatum van de hele BgZ is optioneel.

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

Metagegevens bij overnemen

TODO

Ontdubbelen en duplicaatdetectie

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

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.

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 EPD van B. 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.

Ontdubbelen kan een rol spelen bij Tonen in context, Handmatige reconciliatie en Automatisch overnemen. Ontdubbelen is afhankelijk van de mogelijkheid tot automatische duplicaatdetectie. Hier worden de mogelijkheden aangegeven. 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.

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.

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

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.

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 mogelijkheid bestaat externe diagnoses aan te vinken voor “overnemen in eigen EPD”. Daarbij wordt de arts die de diagnose gesteld heeft als auteur bewaard.

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

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 is dit 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.

Voorbeeld: patiënt wordt van ziekenhuis A verwezen naar ziekenhuis B. De patiënt is in het EPD nog niet bekend. Demografische gegevens zoals burgerlijke staat en contactpersonen (bijvoorbeeld mantelzorgers) worden overgenomen uit de BgZ in het eigen EPD.

Vasthouden externe context

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)

Transacties en transactiegroepen

De transacties zijn beschreven in ART-DECOR. De "systeemrol" beschrijft de rol van een informatiesysteem in het delen van informatie.

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

Tabel Overzicht transactiegroepen

De transacties zeggen niets over de technische uitwerking, maar alleen over de trigger en de daaruit voortvloeiende transactie. Voor de inhoud van de transacties onder "Delen BgZ" kan de transactiedataset onder "Opvragen BgZ" gebruikt worden.

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.

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 die bevraagd kan worden 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.

Release notes

In onderstaande tabel staan de wijzigingen voor deze informatiestandaard.

Versie	Datum	Omschrijving
1.1	te plannen	In ontwikkeling
1.0.1	23 februari 2022	Patchversie: verwijzingen naar de live DECOR omgeving vervangen door de publicatie toevoegen release notes
1.0	24 november 2021	Eerste versie.