Document toolboxDocument toolbox

Dit is de consultatie versie van het Twiin Afsprakenstelsel Release 1.2.0

Z1.5 | BgZ: PvE

 

1. Validatie eisen

Eis

Categorie

Actor

Omschrijving

Toelichting inclusief aanvullende documentatie

Eis

Categorie

Actor

Omschrijving

Toelichting inclusief aanvullende documentatie

BgZ-1-authz-03

Autorisatie richtlijn

GtK ontvanger

De GtK ontvanger dient te controleren of de grondslag (authorization base) daadwerkelijk is uitgegeven aan de GtK verzender.

Wanneer de grondslag niet meekomt in de uitwisseling, is er geen sprake van het notified pull uitwisselpatroon en dient de GtK ontvanger op basis van de in de autorisatierichtlijn beschreven rollen het verzoek te autoriseren.

Autorisatiematrix: https://vzvz.atlassian.net/wiki/spaces/Twiincon/pages/331849379/Z1.4.4+%7C+BgZ%3A+Autorisatie#autorisatiematrix-BgZ

Transacties: https://vzvz.atlassian.net/wiki/spaces/Twiincon/pages/331847698 , https://vzvz.atlassian.net/wiki/spaces/Twiincon/pages/331847754

Autorisatierichtlijn:

BgZ-2a-TANP-01

TA NP

GtK ontvanger

GtK ontvanger dient een notificatie-endpoint aan te bieden aan GtK verzender.

Een endpoint kan worden gedeeld door meerdere Twiin Deelnemers (bijv. een endpoint per GtK/ SaaS-dienst) of er kan sprake zijn van een endpoint per Twiin Deelnemer.

Zie o.a.

BgZ-2a-TANP-02

TA NP

GtK verzender

GtK verzender dient een resource-endpoint aan te bieden aan GtK ontvanger.

Een endpoint kan worden gedeeld door meerdere Twiin Deelnemers (bijv. een endpoint per GtK/ SaaS-dienst) of er kan sprake zijn van een endpoint per Twiin Deelnemer.

Zie o.a.

BgZ-2a-TANP-03

TA NP

GtK verzender, GtK ontvanger

GtK verzender en GtK ontvanger dienen een token-endpoint aan elkaar aan te bieden.

Een endpoint kan worden gedeeld door meerdere Twiin Deelnemers (bijv. een endpoint per GtK/ SaaS-dienst) of er kan sprake zijn van een endpoint per Twiin Deelnemer.

Zie o.a.

BgZ-2a-TANP-04

TA NP

GtK verzender,

GtK verzender dient de technische adressen van het resource-endpoint en het token-endpoint kenbaar te maken aan de Twiin beheerorganisatie.

De wijze waarop technische adressen tussen GtK verzender en GtK ontvanger worden gecommuniceerd is (nog) niet gebonden aan normatieve eisen.

De Twiin beheerorganisatie publiceert de endpoints en technische adressen in ZORG-AB. Om de technische adressen van een andere partij te achterhalen kan er worden gekozen om ZORG-AB te raadplegen () maar dit is niet verplicht.

GtK verzender en GtK ontvanger kunnen bijvoorbeeld ook onderling afspraken maken over de wijze waarop technische adressen worden gecommuniceerd.

Zie o.a.

BgZ-2a-TANP-05

TA NP

GtK ontvanger

GtK ontvanger dient de technische adressen van het notificatie-endpoint en het token-endpoint kenbaar te maken aan de Twiin beheerorganisatie.

De wijze waarop technische adressen tussen GtK verzender en GtK ontvanger worden gecommuniceerd is (nog) niet gebonden aan normatieve eisen.

De Twiin beheerorganisatie publiceert de endpoints en technische adressen in ZORG-AB. Om de technische adressen van een andere partij te achterhalen kan er worden gekozen om ZORG-AB te raadplegen () maar dit is niet verplicht.

GtK verzender en GtK ontvanger kunnen bijvoorbeeld ook onderling afspraken maken over de wijze waarop technische adressen worden gecommuniceerd.

Zie o.a.

 

 

 

 

 

BgZ-2a-AA-01

BgZ Authn en Authz

GtK verzender

GtK verzender dient de publieke steutel(s) die zij gebruikt voor de ondertekening van JWT’s via kid opzoekbaar te maken voor GtK ontvanger.

De wijze waarop de uitwisseling van publieke sleutels tussen GtK verzender en GtK ontvanger plaatsvindt is (nog) niet gebonden aan normatieve eisen. GtK verzender en GtK ontvanger moeten daarom onderling en in afstemming met de gebruikte infrastructuur afspraken maken over de wijze van uitwisseling van publieke sleutels.

Zie

BgZ-2a-AA-02

BgZ Authn en Authz

GtK ontvanger

GtK ontvanger dient de publieke steutel(s) die zij gebruikt voor de ondertekening van JWT’s via kid opzoekbaar te maken voor GtK verzender.

De wijze waarop de uitwisseling van publieke sleutels tussen GtK verzender en GtK ontvanger plaatsvindt is (nog) niet gebonden aan normatieve eisen. GtK verzender en GtK ontvanger moeten daarom onderling en in afstemming met de gebruikte infrastructuur afspraken maken over de wijze van uitwisseling van publieke sleutels.

Zie

BgZ-2a-AA-03

BgZ Authn en Authz

GtK verzender

GtK verzender is in staat een client assertion in de vorm van een authentication_grant aan te maken die voldoet aan de specificaties

Specificaties:

BgZ-2a-AA-04

BgZ Authn en Authz

GtK verzender, GtK ontvanger

GtK verzender en GtK ontvanger dienen gebruik te maken van dezelfde identifiers voor de systemen die opereren als autorisatie-clients (OAuth clients).

Het toekennen en gebruiken van identifiers van systemen is (nog) niet gebonden aan normatieve eisen. GtK verzender en GtK ontvanger moeten daarom onderling en in afstemming met de gebruikte infrastructuur afspraken maken over de te gebruiken identifiers van systemen.

Zie iss-velden in

BgZ-2a-AA-05

BgZ Authn en Authz

GtK verzender, GtK ontvanger

GtK verzender en GtK ontvanger dienen gebruik te maken van dezelfde identifiers voor de systemen die opereren als autorisatie-servers (authorization server token endpoints).

Het toekennen en gebruiken van identifiers van systemen is (nog) niet gebonden aan normatieve eisen. GtK verzender en GtK ontvanger moeten daarom onderling en in afstemming met de gebruikte infrastructuur afspraken maken over de te gebruiken identifiers van systemen.

Zie aud-velden in

BgZ-2a-AA-06

BgZ Authn en Authz

GtK verzender

GtK verzender is in staat een digitale representatie van de in de context van een verwijzing veronderstelde toestemming aan te maken (authorization_base).

Omdat de authorization_base alleen door GtK verzender wordt verwerkt, worden de vorm en inhoud ervan bepaald door GtK verzender. GtK ontvanger mag niet afhankelijk zijn van het formaat of de inhoud van authorization_base. De vorm en inhoud van de authorization_base is (nog) niet gebonden aan normatieve eisen. Het bepalen van vorm en inhoud doet GtK verzender bij voorkeur in afstemming met de gebruikte infrastructuur.

Zie

BgZ-2a-AA-07

BgZ Authn en Authz

GtK verzender

GtK verzender is in staat een authorization_grant aan te maken die voldoet aan de specificaties

Specificaties:

BgZ-2a-AA-08

BgZ Authn en Authz

GtK verzender

GtK verzender is in staat conform de specificaties een acces token request voor toegang tot het notificatie-endpoint aan te maken en aan GtK ontvanger te versturen.

Specificaties:

BgZ-2a-AA-09

BgZ Authn en Authz

GtK verzender, GtK ontvanger

GtK verzender en GtK ontvanger dienen ervoor te zorgen dat het veld sub in de authentication_grant en het veld client_id in het access token request dezelfde waarde bevatten.

Specificaties: ,

BgZ-2a-AA-10

BgZ Authn en Authz

GtK ontvanger

GtK ontvanger is in staat conform de specificaties een acces token request van GtK verzender voor toegang tot het notificatie server endpoint af te handelen.

Specificaties:

BgZ-2a-AA-11

BgZ Authn en Authz

GtK verzender

GtK verzender heeft het afgesproken access policy geïmplementeerd voor het versturen van de notificatie.

Access Policy: GtK verzender mag alleen notificaties versturen van gebruikers met de in de autorisatiematrix opgesomde rollen:

BgZ-2a-AA-12

BgZ Authn en Authz

GtK ontvanger

GtK ontvanger is in staat een client assertion in de vorm van een authentication_grant aan te maken die voldoet aan de specificaties.

Specificaties:

BgZ-2a-AA-13

BgZ Authn en Authz

GtK ontvanger

GtK ontvanger is in staat conform de specificaties een acces token request voor toegang tot het resource-endpoint aan te maken en aan GtK verzender te versturen.

Inclusief eerder van GtK verzender ontvangen authorization_grant, welke de digitale representatie van de veronderstelde toestemming (authorization_base) bevat.

Specificaties:

BgZ-2a-AA-14

BgZ Authn en Authz

GtK verzender

GtK verzender is in staat conform de specificaties een acces token request van GtK ontvanger voor toegang tot het resource server endpoint af te handelen.

Specificaties:

BgZ-2a-AA-15

BgZ Authn en Authz

GtK verzender

GtK verzender heeft het afgesproken access policy geïmplementeerd op het resource server endpoint.

Access Policy: GtK verzender mag alleen data opleveren aan gebruikers met de in de autorisatiematrix opgesomde rollen:

 

 

 

 

 

BgZ-2a-NS-01

network security

GtK verzender, GtK ontvanger

GtK verzender en GtK ontvanger maken gebruik van mutual TLS (mTLS) versie 1.3.

Zie

BgZ-2a-NS-02

network security

GtK verzender, GtK ontvanger

GtK verzender en GtK ontvanger maken gebruik van de juiste PKIo-certificaten.

Gebruikte PKIo-certificaten dienen te zijn uitgegeven onder de CA “Staat der Nederlanden Private Services CA – G1”. Deze omvatten:

  • UZI-servercertificaat; of

  • PKIoverheid Private Services CA – G1 certificate

Het betreft de systemen in de rol van token-server en -client, notification-server en -client en resource-server en -client.

Zie

BgZ-2a-NS-03

network security

GtK verzender, GtK ontvanger

GtK verzender en GtK ontvanger maken gebruik van de juiste cryptografische algoritmes.

 

Verplicht gebruik van de volgende cryptografische algoritmes:

  • Certificate Verification: ECDSA of RSA

  • Key exchange: ECDHE

  • Bulk encryption: AES-256-GCM of ChaCha20-Poly1305 of AES-128-GCM

  • Hash functions: SHA-512 of SHA-384 of SHA-256

Zie

BgZ-2a-NS-04

network security

GtK verzender, GtK ontvanger

GtK verzender en GtK ontvanger controleren minimaal ieder uur door middel van CRL of OCSP de geldigheid van de certificaten van systemen waarmee transacties plaatsvinden.

Zie

BgZ-2a-NS-05

network security

GtK verzender, GtK ontvanger

Wanneer GtK verzender en GtK ontvanger de geldigheid van een UZI-servercertficaat controleren, doen zij dit op basis van de afspraken in het Certification Practice Statement (CPS) UZI-register.

Zie Certification Practice Statement (CPS) | Zorg CSP, artikel 4.5.2

CRL’s:

BgZ-2a-NS-06

network security

GtK verzender, GtK ontvanger

Wanneer GtK verzender en GtK ontvanger de geldigheid van een PKIo-servercertficaat controleren, doen zij dit op basis van de afspraken in het Certification Practice Statement (CPS) PKIoverheid.

Zie , hoofdstuk 2

 

 

 

 

 

BgZ-2b-trans-01

Transactions - BgZ interactions

GtK verzender

GtK verzender is in staat een Workflow-Task aan te maken

Transactie 1 van

 

BgZ-2b-trans-02

Transactions - BgZ interactions

GtK verzender

GtK verzender is in staat een notificatie-create-request te versturen

 

Transactie 2 van

Specificatie:

BgZ-2b-trans-03

Transactions - BgZ interactions

GtK ontvanger

GtK ontvanger is in staat een binnenkomend notificatie-create-request af te handelen en een passende response te versturen

Transactie 3 van

Specificatie:

BgZ-2b-trans-04

Transactions - BgZ interactions

GtK verzender

GtK verzender is in staat een notificatie-create-request te versturen wanneer de dataset van de verwijzing is geüpdatet

Transactie 4 van

Specificatie:

BgZ-2b-trans-05

Transactions - BgZ interactions

GtK ontvanger

GtK ontvanger is in staat een naar aanleiding van een geüpdatete dataset binnenkomend notificatie-create-request af te handelen en een passende response te versturen

Transactie 5 van

Specificatie:

BgZ-2b-trans-06

Transactions - BgZ interactions

GtK verzender

GtK verzender is in staat een notificatie-update-request te versturen wanneer GtK verzender de notificatie wil annuleren of intrekken.

Transactie 6 van

Specificatie:

BgZ-2b-trans-07

Transactions - BgZ interactions

GtK ontvanger

GtK ontvanger is in staat een binnenkomend notificatie-update-request af te handelen en een passende response te versturen.

Transactie 7 van

Specificatie:

BgZ-2b-trans-08.read

Transactions - BgZ interactions

GtK ontvanger

GtK ontvanger is in staat read-operaties uit de notificatie-taak uit te voeren op het resource-endpoint van GtK verzender.

Transactie 8 van

Specificatie:

De read-operaties zijn opgenomen in de notificatie-task onder Task.input:read-available-resources.

BgZ-2b-trans-09.read

Transactions - BgZ interactions

GtK verzender

GtK verzender is in staat binnenkomende read-requests af te handelen en een passende response te versturen.

Transactie 9 van

Specificatie:

BgZ-2b-trans-08.search

Transactions - BgZ interactions

GtK ontvanger

GtK ontvanger is in staat search-operaties uit de notificatie-taak uit te voeren op het resource-endpoint van GtK verzender.

Transactie 8 van

Specificatie:

De search-operaties zijn opgenomen in de notificatie-task onder Task.input:query-available-resources.

BgZ-2b-trans-09.search

Transactions - BgZ interactions

GtK verzender

GtK verzender is in staat binnenkomende search-requests af te handelen en een passende response te versturen.

Transactie 9 van

Specificatie:

BgZ-2b-trans-10

Transactions - BgZ interactions

GtK ontvanger

GtK ontvanger is in staat een read-operatie voor het ophalen van de Workflow-task uit te voeren op het resource-endpoint van GtK verzender.

Transactie 10 van

Specificatie:

De indicator voor de aanwezigheid van een workflow-task is opgenomen in de notificatie-task onder Task.input:get-worflow-task.valueBoolean (waarde is true).

BgZ-2b-trans-11

Transactions - BgZ interactions

GtK verzender

GtK verzender is in staat een binnenkomende read-request op de workflow-task af te handelen en een passende response te versturen.

Transactie 11 van

BgZ-2b-trans-12.read

Transactions - BgZ interactions

GtK ontvanger

GtK ontvanger is in staat read-operaties uit de workflow-taak uit te voeren op het resource-endpoint van GtK verzender.

Transactie 12 van

Specificatie:

De read-operaties zijn opgenomen in de workflow-task onder Task.input:read-available-resources.

BgZ-2b-trans-13.read

Transactions - BgZ interactions

GtK verzender

GtK verzender is in staat binnenkomende read-requests af te handelen en een passende response te versturen.

Transactie 13 van

Specificatie:

BgZ-2b-trans-12.search

Transactions - BgZ interactions

GtK ontvanger

GtK ontvanger is in staat search-operaties uit de workflow-taak uit te voeren op het resource-endpoint van GtK verzender.

Transactie 12 van

Specificatie:

De search-operaties zijn opgenomen in de workflow-task onder Task.input:query-available-resources.

BgZ-2b-trans-13.search

Transactions - BgZ interactions

GtK verzender

GtK verzender is in staat binnenkomende search-requests af te handelen en een passende response te versturen

Transactie 13 van

Specificatie:

 

 

 

 

 

BgZ-3-1

content

GtK verzender

GtK verzender dient een Workflow-task aan te maken die voldoet aan de BgZ FHIR Workflow Task implementation.

Profiel:

BgZ-3-2

content

GtK ontvanger

GtK ontvanger dient een Workflow-Task die voldoet aan het BgZ Workflow Task Profile te kunnen interpreteren.

Profiel:

BgZ-3-3

content

GtK verzender

GtK verzender dient een Notificatie-task aan te maken die voldoet aan het afgesproken profiel.

Profiel:

Referentiecodes:

BgZ-3-4

content

GtK ontvanger

GtK ontvanger dient een Notificatie-task die voldoet aan het afgesproken profiel te kunnen interpreteren.

Profiel:

Referentiecodes:

BgZ-3-5

content

GtK verzender

GtK verzender dient FHIR-resources conform de implementation guide van de informatiestandaard BgZ beschikbaar te kunnen stellen.

Profielen:

BgZ-3-6

content

GtK ontvanger

GtK ontvanger dient FHIR-resources conform de implementation guide van de informatiestandaard BgZ te kunnen interpreteren.

Profielen:

BgZ-3-7

content

GtK verzender

GtK verzender dient correspondentie/ niet-discrete data conform beschikbaar te kunnen stellen.

 

BgZ-3-8

content

GtK ontvanger

GtK ontvanger dient correspondentie/ niet-discrete data conform te kunnen interpreteren.

 

2. Aanvullende ketentest eisen

De eisen in dit hoofdstuk zijn niet nodig zijn voor de Twiin validatie van de zorgtoepassing. Deze eisen zijn wel nodig om te voldoen aan de ketentest, de informatiestandaard, de VIPP-eisen en eventuele andere functionele eisen.

Eis

Categorie

Actor

Omschrijving

Toelichting inclusief aanvullende documentatie

Eis

Categorie

Actor

Omschrijving

Toelichting inclusief aanvullende documentatie

BgZ-1-FO-03

FO Nictiz

GtK verzender

GtK verzender maakt informatie beschikbaar conform de BgZ specificatie op basis zibs versie 2017.

Specificatie: https://www.registratieaandebron.nl/pdf/BgZ_specificatie_obv_zibs_2017_v1.1.pdf

BgZ-1-FO-04

FO Nictiz

GtK ontvanger

GtK ontvanger kan informatie opvragen die voldoet aan de BgZ specificatie op basis zibs versie 2017.

Specificatie: https://www.registratieaandebron.nl/pdf/BgZ_specificatie_obv_zibs_2017_v1.1.pdf

BgZ-1-FO-05

FO Nictiz

EPD verzender

Voor het vastleggend systeem 'achter' de GtK verzender geldt: 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.

Specificatie:

BgZ-1-FO-06

FO Nictiz

EPD verzender

Voor het vastleggend systeem 'achter' de GtK verzender geldt: Het EPD moet nieuwe gegevens die vastgelegd worden als zibs voorzien van metagegevens.

Daarbij moet alle velden die gevuld zijn in de Metagegevens tabel gevuld worden voor nieuwe zibs. Velden die leeg zijn in de metagegevens tabel mogen gevuld worden, maar dat hoeft niet.

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.

Specificatie:

BgZ-1-FO-07

FO Nictiz

GtK verzender

GtK verzender moet een BgZ kunnen sturen bij verwijzing naar een andere zorginstelling of zorgverlener.

Specificatie:

BgZ-1-FO-08

FO (Nictiz)

GtK verzender

GtK verzender moet een verwijsbrief in document-formaat kunnen sturen bij verwijzing naar een andere zorginstelling of zorgverlener.

Specificatie:

BgZ-1-FO-09

FO Nictiz

Verwijzer

Een Verwijzer (zorgverlener) moet een andere zorginstelling kunnen kiezen om een BgZ mee te delen, met eventueel specialisme.

Specificatie:

BgZ-1-FO-10

FO Nictiz

GtK antwoorder

GtK antwoorder moet de mogelijkheid bieden om op een opvraging een BgZ beschikbaar te stellen.

Specificatie:

BgZ-1-FO-11

FO Nictiz

EPD verzender

Voor het vastleggend systeem 'achter' de GtK verzender geldt: Een EPD moet metagegevens toevoegen aan een BgZ.

Voor zibs die aangemaakt zijn na implementatie van de informatiestandaard zijn dat minimaal alle velden die gevuld zijn in de Metagegevens tabel. Voor historische zibs worden de metagegevens zo goed mogelijk gevuld.

Specificatie:

BgZ-1-FO-12

FO Nictiz

GtK verzender, GtK ontvanger

GtK verzender en GtK ontvanger moeten beschrijven welke secties en welke zibs van de BgZ wel en niet ondersteund worden.

Deze documentatie moet beschikbaar zijn bij kwalificatie en voor ketenpartners.

Specificatie:

BgZ-1-FO-13

FO Nictiz, meta gegevens

GtK verzender

GtK verzender dient, wanneer een gegevenselement van elders betrokken is en er zijn metagegevens op zib-niveau opgeslagen, deze metagegevens mee te zenden.

Bijvoorbeeld: medicatie is opgehaald van het LSP en de identificaties van de LSP-bevraging zitten in het EPD, dan dienen deze meegezonden te worden.

Specificatie:

BgZ-1-FO-14

FO Nictiz, meta gegevens

GtK verzender

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

Specificatie:

BgZ-1-FO-15

FO Nictiz, meta gegevens

GtK verzender

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

Specificatie:

BgZ-1-FO-16

FO Nictiz, meta gegevens

GtK verzender

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

Specificatie:

BgZ-1-FO-17

FO Nictiz, meta gegevens

GtK verzender

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

Specificatie:

BgZ-1-FO-18

FO Nictiz

GtK ontvanger

GtK ontvanger moet de mogelijkheid bieden om een BgZ op te vragen bij een beschikbaarstellend EPD.

 

Specificatie:

BgZ-1-FO-19

FO Nictiz

Nieuwe behandelaar

Use case “Opvraging BgZ bij eerdere behandelaar”: Een zorgverlener moet een te bevragen zorginstelling kunnen kiezen, ofwel een lijst tonen met alle beschikbare BgZ's in een repository.

Specificatie:

BgZ-1-FO-20

FO Nictiz

GtK ontvanger, EPD ontvanger

GtK ontvanger en de eventuele achterliggende systemen (zoals een EPD) moeten de mogelijkheid bieden om een BgZ te ontvangen.

 

Specificatie:

BgZ-1-FO-21

FO Nictiz

EPD ontvanger

Voor de systemen 'achter' GtK ontvanger geldt: Het EPD moet de betrokken afdelingen (administratief en/of specialisme) kunnen verwittigen van een ontvangen BgZ, waarna die BgZ ingezien kan worden.

Specificatie:

BgZ-1-FO-22

FO Nictiz

EPD ontvanger

Voor de systemen 'achter' GtK ontvanger geldt: Een EPD moet alle informatie die via een BgZ ontvangen wordt kunnen tonen aan de zorgverlener.

Specificatie:

BgZ-1-FO-23

FO Nictiz

GtK ontvanger, EPD ontvanger

GtK ontvanger en de systemen 'achter' GtK ontvanger moeten beschrijven welke mogelijkheden ze wel en niet bieden betreffende hergebruik.

Deze documentatie moet beschikbaar zijn bij kwalificatie en voor ketenpartners.

Specificatie:

BgZ-1-FO-24

FO Nictiz

EPD ontvanger

Voor de systemen 'achter' GtK ontvanger geldt: 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.

Specificatie:

BgZ-1-FO-25

FO Nictiz

EPD ontvanger

Voor de systemen 'achter' GtK ontvanger geldt: Een EPD moet in staat zijn een ontvangen of geraadpleegde BgZ over te nemen wanneer dat medisch relevant is.

Specificatie:

BgZ-1-FO-26

FO Nictiz

EPD ontvanger

Voor de systemen 'achter' GtK ontvanger geldt: Een EPD moet in staat zijn een ontvangen of geraadpleegde verwijsbrief over te nemen wanneer dat medisch relevant is.

Specificatie:

BgZ-1-FO-27

FO Nictiz

EPD ontvanger

Voor de systemen 'achter' GtK ontvanger geldt: Een EPD dat gegevens overneemt neemt deze over als discrete zibs.

Specificatie:

BgZ-1-FO-28

FO Nictiz

EPD ontvanger

Voor de systemen 'achter' GtK ontvanger geldt: Een EPD dat zibs overneemt moet deze ook weer als zibs kunnen ontsluiten.

Specificatie:

BgZ-1-FO-29

FO Nictiz

EPD ontvanger

Voor de systemen 'achter' GtK ontvanger geldt: Een EPD moet metagegevens op document-niveau op kunnen slaan.

Specificatie:

BgZ-1-FO-30

FO Nictiz

EPD ontvanger

Voor de systemen 'achter' GtK ontvanger geldt: Een EPD moet metagegevens op zib-niveau op kunnen slaan.

Wanneer deze aanwezig zijn, is opslaan van document-metagegevens optioneel.

Specificatie:

BgZ-1-FO-31

FO Nictiz

EPD ontvanger

Voor de systemen 'achter' GtK ontvanger geldt: Bij iedere overgenomen zib worden metagegevens opgeslagen.

Dit is minimaal:

  • de instelling vanwaar de gegevens betrokken zijn;

  • de gegevens die gevuld zijn in de Metagegevens tabel.

Specificatie:

BgZ-1-FO-32

FO Nictiz

EPD ontvanger

Voor de systemen 'achter' GtK ontvanger geldt: 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.

Specificatie:

 

 

 

 

 

BgZ-1-VIPP5-1

VIPP 5

GtK verzender

GtK verzender kan de BgZ en
correspondentie verzenden naar andere instellingen van Medisch
Specialistische Zorg.

Zie Handreiking VIPP5 assessments, bijlage II, paragraaf 1.5, alinea module 3

Zie

BgZ-1-VIPP5-2

VIPP 5

GtK ontvanger

GtK ontvanger kan de BgZ en
correspondentie ontvangen vanuit een andere instelling van Medisch
Specialistische Zorg.

Zie Handreiking VIPP5 assessments, bijlage II, paragraaf 1.5, alinea module 3

Zie

BgZ-1-VIPP5-3

VIPP 5

GtK ontvanger, EPD ontvanger

GtK ontvanger en de systemen achter GtK ontvanger (bijvoorbeeld het EPD) kunnen aangewezen of gekozen secties van de BgZ ontvangen en hergebruiken vanuit een andere
instelling van Medisch Specialistische Zorg.

Zie Handreiking VIPP5 assessments, bijlage II, paragraaf 1.5, alinea module 3

Zie

BgZ-1-VIPP5-4

VIPP 5

Twiin deelnemer

De Twiin deelnemer (zorgorganisatie) heeft procedures rondom het
uitwisselen van de BgZ en correspondentie met andere instellingen van
Medisch Specialistische Zorg beschreven en geïmplementeerd.

Zie Handreiking VIPP5 assessments, bijlage II, paragraaf 1.5, alinea module 3

Zie

 

 

 

 

 

BgZ-1-AVG-01

TA NP

Nieuwe behandelaar

De nieuwe behandelaar mag alleen de gegevens opvragen die relevant zijn voor de uitvoering van de nieuwe behandelrelatie.

De nieuwe behandelaar (en de zorgorganisatie waarvan zij/hij deel uitmaakt) is ervoor verantwoordelijk om dataverzoeken proportioneel te houden.

 

Het Twiin Afsprakenstelsel is onder Creative Common Licentie
CC BY-SA Naamsvermelding-GelijkDelen https://creativecommons.org/licenses/by-sa/4.0/legalcode.nl