Eisencatalogus¶

TW-F-AD-001: Publiceren endpoints voor adresinformatie¶

Omschrijving

De GTK Ontvanger en GTK Verzender MOETEN de technische adressen van het resource-endpoint, het notificatie-endpoint en het token-endpoint kenbaar maken aan de Twiin Beheerorganisatie.

Toelichting

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 (Zie ZORG-AB Transacties) maar dit is niet verplicht.

GTK Verzender en GTK Ontvanger kunnen bijvoorbeeld ook onderling afspraken maken over de wijze waarop technische adressen worden gecommuniceerd.

TW-F-AU-001: Systeem identifiers autorisatie-clients¶

Omschrijving

GTK Verzender en GTK Ontvanger MOETEN gebruik maken van dezelfde identifiers voor de systemen die opereren als autorisatie-clients (OAuth clients).

Toelichting

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.

TW-F-AU-002: Systeem identifiers autorisatie-servers¶

Omschrijving

GTK Verzender en GTK Ontvanger MOETEN gebruik maken van dezelfde identifiers voor de systemen die opereren als autorisatie-servers (authorization server token endpoints).

Toelichting

Het toekennen en gebruiken van identifiers van systemen is (nog) niet gebonden aan landelijke 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.

TW-F-AU-003: Aanmaken access token request voor resource endpoint¶

Omschrijving

De GTK Ontvanger MOET conform de specificaties een access token request voor toegang tot het resource-endpoint aan kunnen maken en aan GTK Verzender versturen.

Toelichting

Eventueel inclusief een eerder van GTK Verzender ontvangen authorization_grant, welke de digitale representatie van de veronderstelde toestemming (authorization_base) bevat.

TW-F-AU-004: Aanmaken access token request voor resource endpoint¶

Omschrijving

GTK Verzender MOET conform de specificaties een access token request van GTK Ontvanger voor toegang tot het resource server endpoint af kunnen handelen.

TW-F-IA-001: Identificatie op basis van uniek ID¶

Omschrijving

Zorgverleners MOETEN geïdentificeerd worden op basis van een uniek ID. Dit is een UZI of een ander uniek tot één persoon te herleiden nummer.

Toelichting

Wanneer een eigen ID wordt gebruikt MOET dit een unieke combinatie van persoons-ID en organisatie-ID opleveren en dat dit herleidbaar blijft (ook na, bijvoorbeeld, vertrek van zorgverlener), uitgegeven op het op het juiste betrouwbaarheidsniveau. Deze eis is van toepassing op alle Twiin-transacties.

TW-F-IA-002: Authenticatie op eIDAS-niveau hoog¶

Omschrijving

Zorgverlener/gebruiker (van het GTK) ZOUDEN (lokaal) geauthentiseerd MOETEN worden op eIDAS-niveau hoog

Toelichting

Door de keten heen kan hier nog geen bewijs van worden meegeven zodat andere partijen de zorgverlener ook met zekerheid kunnen authenticeren. Deze eis is van toepassing op alle Twiin-transacties.

TW-F-IA-003: Opzoekbaar maken publieke sleutel gebruikt voor ondertekening¶

Omschrijving

GTK Verzender en GTK Ontvanger MOETEN de publieke sleutel(s) die zij gebruiken voor de ondertekening van JWT’s via kid opzoekbaar maken voor GTK Ontvanger.

Toelichting

De wijze waarop de uitwisseling van publieke sleutels tussen GTK Verzender en GTK Ontvanger plaatsvindt is (nog) niet gebonden aan normatieve eisen. Het is aan GTK Verzender en GTK Ontvanger AANBEVOLEN om onderling en in afstemming met de gebruikte infrastructuur afspraken te maken over de wijze van uitwisseling van publieke sleutels.

TW-F-IA-004: Aanmaken client assertion¶

Omschrijving

GTK Verzender MOET een client assertion in de vorm van een authentication_grant kunnen aanmaken die voldoet aan de specificaties

TW-F-IA-005: Identifiers GTK¶

Omschrijving

GTK Verzender en GTK Ontvanger MOETEN gebruik maken van dezelfde identifiers voor de systemen die opereren als autorisatie-servers (authorization server token endpoints)

Toelichting

Het toekennen en gebruiken van identifiers van systemen is (nog) niet gebonden aan landelijke 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.Voor nu is afgestemd dat de systeem identifiers zelf gekozen moeten zijn, maar de vorm van een FQDN of OID mogen hebben. Zie aud-velden in Twiin-07 | Token Request

TW-F-LO-001: Loggen berichtuitwisseling¶

Omschrijving

Het GTK MOET alle berichtuitwisseling met andere GTK’s loggen.

Toelichting

Wat er functioneel gelogd moet worden is gespecificeerd in de norm NEN 7513:2024. Deze eis is van toepassing op alle Twiin-transacties.

TW-F-LO-002: Loggegevens uitwisselen¶

Omschrijving

Het GTK MOET loggegevens over uitwisselingen met andere GTK's kunnen aanleveren aan die GTK's.

Toelichting

Eis uit NEN7512:2022 6.2.9:

“De communicatiepartijen moeten afspraken maken over de wederzijdse inzage in de logbestanden en de termijn waarbinnen deze mogelijk wordt gemaakt.”

Zolang er nog geen landelijke procedures en afspraken zijn opgesteld over de uitwisseling van de logging tussen GTK’s zal dit in de (uitzonderlijke) gevallen wanneer dit toch nodig is op ad hoc basis gedaan moeten worden.

TW-F-NB-001: Threat intelligence program¶

Omschrijving

Het is AANBEVOLEN om een centraal loket in voor cybersecurityincidenten in te richten met een major impact voor alle Twiin Deelnemers.

TW-F-NB-002: ICT-gereedheid voor bedrijfscontinuïteit¶

Omschrijving

De Twiin Deelnemer MOET ICT-gereedheid voor bedrijfscontinuïteit hebben geborgd.

Toelichting

De Twiin Deelnemer ZOU een exitstrategie MOETEN opstellen om over te stappen naar een andere GTK Leverancier waarbij rekening gehouden is met:

• Een opzegtermijn die voldoende is om te migreren
• Logging, data en configuratiegegevens worden pas verwijderd na succesvolle migratie
• Een onafhankelijke partij controleert of alle data succesvol gemigreerd is

Daarnaast ZOU een Twiin Deelnemer een Disaster recovery plan MOETEN opstellen waarin is vastgelegd:

• Welke partijen zijn essentieel voor de bedrijfsvoering
• Alternatieven voor leveranciers en distributiekanalen
• Communicatiekanalen naar Twiin Deelnemers
• Stappenplan voor herstel.

TW-F-NB-003: Contractuele afspraken¶

Omschrijving

De Twiin Deelnemer MOET het volgende contractueel vastleggen met haar leveranciers:

• Afspraken over handelen bij cyberaanval
• Clausules bij overname
• Duidelijke afspraken over de dienstverlening
• SLA afspraken (uptime, RPO/RTO)
• Afspraken over datasoevereiniteit
• Afspraken over een exit strategie (zie ook M103)

TW-F-NB-005: Multi-factor authentication¶

Omschrijving

Alle systemen MOETEN met Multi Factor Authentication (MFA) beveiligd zijn.

Toelichting

Deze eis gaat specifiek over persoonsgebonden accounts die nodig zijn voor veilig netwerk. Bijvoorbeeld beheeraccounts op switches, firewalls en andere componenten.

TW-F-NB-006: Proactieve maatregelen¶

Omschrijving

De Twiin Deelnemer MOET een proactief beveiligingsbeleid voeren waarin de volgende eisen zijn opgenomen:

• Systemen worden jaarlijks gepentest met opvolging van de aanbevelingen.
• Gebruikers en beheerders krijgen periodieke awareness training.

Toelichting

De pentest MOET worden uitgevoerd volgens de MIAUW-methodiek of daarmee vergelijkbare industriestandaard, zoals de NIS2-richtlijnen, ISO27001, ENISA guidelines of OWASP-methodes

TW-F-NB-007: Data Loss Prevention¶

Omschrijving

Het is AANBEVOLEN om een Data Loss Prevention (DLP) tool uit te rollen.

TW-F-NB-008: Awareness¶

Omschrijving

Het is AANBEVOLEN om jaarlijks een awareness campagne te organiseren.

TW-F-NB-009: Beperk web-based content¶

Omschrijving

Toegang tot web-based content en systeemuitwisseling via webapplicaties MOET beschermd worden met de volgende maatregelen:Gebruik een Web Application Firewall (WAF) om inkomend en uitgaand webverkeer te inspecteren en aanvallen op webapplicaties te detecteren en blokkerenFilter en monitor HTTP(S)-verkeer op verdachte patronen, reputatie en ongeautoriseerde contentBlokkeer onveilige website bij de gateway (proxy).

Toelichting

Systemen beschermen om te voorkomen dat ze door malware worden gecompromitteerd en om toegang tot ongeoorloofde internetbronnen te voorkomen.

TW-F-NB-010: Scannen van kwetsbaarheden¶

Omschrijving

De Twiin Deelnemer en GTK Leverancier MOETEN een periodiek controleproces hebben m.b.t. reguliere scans van protocolstacks en m.b.t. encryptie, om vast te stellen dat systemen en protocolconfiguraties voldoen aan het Twiin Afsprakenstelsel.

TW-F-NB-011: High-availability¶

Omschrijving

De GTK Leverancier MOET door toepassing van voldoende beschikbaarheidsmaatregelen voor een beschikbaarheid zorgen die past bij de behoefte van de bediende zorgaanbieders, daarbij met name redundantie van systemen en datacenters meegewogen wordt. Per toepassing is er dan een gespecificeerde eis.

TW-F-NB-012: Veilig software ontwikkelen¶

Omschrijving

De GTK Leverancier MOET een security-by-default ontwikkelmethodiek gebruiken conform internationaal erkende best practices.

TW-F-NB-013: Account management¶

Omschrijving

De GTK Leverancier MOET beleid voor accountbeheer hebben met de volgende eisen:

• Accounts worden centraal beheerd
• Password policies zijn toegepast
• Multifactor authentication voor alle beheeraccounts zijn toegepast
• Principe Least Privilege voor alle accounts is gehanteerd

TW-F-NB-014: TLS inspectie¶

Omschrijving

TLS netwerkverkeer tussen GTK's MOET voldoen aan de volgende eisen:

• Aansluiten van alle componenten aan SIEM
• Inspecteer traffic ahv "Use cases"
• Gebruik uitsluitend PKIO-certificaten
• Gebruik CAA DNS-records
• Maak allow-list naar GTK's, op basis van certificaten

TW-F-NB-015: Beperk rechten bestanden en mappen¶

Omschrijving

Het principe "least-privilege" permissie MOET toegepast worden.

TW-F-NB-016: Beperk rechten Windows register¶

Omschrijving

Het register van Windows systemen MOET beveiligd zijn tegen ongeoorloofde wijzigingen met ten minste de volgende maatregelen:

• Forceer register permissie via Group Policies
• Monitor gevoelige registry keys (met een SIEM oplossing of via de eventlog).

TW-F-NB-017: Accounts met verhoogde rechten¶

Omschrijving

Accounts met verhoogde rechten MOETEN beveiligd zijn met ten minste tweefactorauthenticatie.

TW-F-NB-018: Wachtwoordbeleid¶

Omschrijving

Een GTK ZOU password policies MOETEN hebben voor complexiteit, uniciteit en geldigheidsduur.

Toelichting

Het wachtwoordbeleid ZOU de volgende eisen MOETEN bevatten:

• Minimale passwordlengte voor accounts: 12+ characters
• Passwordcomplexiteit vereist
• Password mag niet eerder gebruikt zijn
• Account wordt vergrendeld na 5 verkeerde inlogpogingen
• Account kan alleen handmatig weer worden vrijgegeven
• Maximale geldigheidsduur van een password is 1 jaar
• Check op gelekte wachtwoorden.

TW-F-NB-019: Operating System configuratie¶

Omschrijving

Alle systemen MOETEN gehardened zijn volgens een industriestandaard zoals CIS, STIG, Microsoft Security Baseline en afwijkingen MOETEN vastgelegd zijn.

TW-F-NB-020: Remote data opslag¶

Omschrijving

Logdata MOET centraal en buiten het netwerkcomponent/server opgeslagen worden op zodanige wijze op dat deze niet door (de beheerders van) de componenten waaruit deze afkomstig is, gewijzigd kan worden.

TW-F-NB-021: Netwerk segmentatie¶

Omschrijving

Netwerk segmentatie MOET toegepast zijn waarbij de volgende eisen zijn meegenomen:

• Internet-facing netwerkcomponenten staan in een DMZ
• Netwerkzones zijn logisch gescheiden door firewalls
• ACLs hebben "deny by default" policies
• Isoleer zoveel mogelijk datastromen

TW-F-NB-022: Netwerk intrusie detectie¶

Omschrijving

Intrusion detectie signatures MOETEN gebruikt worden om ongewenst verkeer te detecteren.

TW-F-NB-023: Beperk toegang tot netwerk resources¶

Omschrijving

Alle open poorten die niet voor het Veilig Netwerk noodzakelijk zijn MOETEN gefilterd worden.

TW-F-NB-024: Accountbeleid¶

Omschrijving

Er MOET beleid voor accountgebruik zijn dat helpt ongeautoriseerde toegang te beperken door regels te configureren en af te dwingen die bepalen hoe en wanneer accounts gebruikt mogen worden. Deze beleidsregels omvatten onder andere het afdwingen van accountvergrendeling, het beperken van inlogtijden en het instellen van time-outs bij inactiviteit.

Toelichting

Een correcte configuratie van deze regels vermindert het risico op brute-force aanvallen, diefstal van inloggegevens en ongeautoriseerde toegang, doordat de mogelijkheden voor kwaadwillenden om accounts te misbruiken worden beperkt. Deze mitigatie ZOU MOETEN worden geïmplementeerd via o.a. de volgende maatregelen:

Accountvergrendelingsbeleid waarmee na een bepaald aantal mislukte inlogpogingen (bijv. 3–5 pogingen) het account voor een bepaalde periode wordt vergrendeld (bijv. 15 minuten) of pas na ontgrendeling door een beheerder weer toegankelijk is.

Time-out bij inactiviteit en sessiebeëindiging: Sessies verlopen na een bepaalde tijd (b.v. 15 minuten)

Beleid voor wachtwoordverloop: Dwing regels af waarbij gebruikers hun wachtwoord na een bepaalde periode moeten wijzigen (bijv. elke 90 dagen) en voorkom hergebruik van oude wachtwoorden via wachtwoordgeschiedenis.

Accountverval en deactivering: Configureer gebruikersaccounts, vooral voor tijdelijke medewerkers of contractanten, zodat ze automatisch verlopen na een bepaalde datum of gebeurtenis (uitdiensttreding). Accounts die gedurende een bepaalde periode niet worden gebruikt, moeten automatisch worden gedeactiveerd.

• Sessies verlopen na een bepaalde tijd (b.v. 15 minuten)
• Accounts worden meteen disabled na uitdiensttreding
• Accounts worden na 30 dagen inactiviteit geblokkeerd.

TW-F-NB-025: Filter netwerk verkeer¶

Omschrijving

Het netwerkverkeer tussen de GTK's MOET gefilterd worden met de volgende eisen: - Sta alleen inkomend/uitgaand verkeer van/naar bekende GTK's toe - Zorg dat alle gepubliceerde DNS-records met relevantie voor Veilig Netwerk DNSSEC-ondertekend en valideerbaar zijn - DNS clients checken valideren DNSSEC.

TW-F-NB-026: Beperk uitvoerbare bestanden¶

Omschrijving

Het uitvoeren van ongeautoriseerde of malicious code MOET worden tegengegaan door: - Alleen toegestane applicaties en scripts toe te staan voor uitvoering. - Pogingen om deze beperking te omzeilen te monitoren.

TW-F-NB-027: Beperk verdacht gedrag van software¶

Omschrijving

Attack Surface Reduction (ASR) rules MOETEN op Windows servers geactiveerd zijn.

TW-F-NB-028: Versleutel vertrouwelijke informatie¶

Omschrijving

Gevoelige informatie MOET versleuteld worden via kanaalversleuteling conform de eisen in 10.1.12

Toelichting

De volgende best practices ZOUDEN geïmplementeerd MOETEN worden:

• Genereer private Keys uitsluitend in HSMs
• Wissel sleutels uit op een veilige manier
• Pas Bring Your Own Key toe bij leveranciers
• Gebruik quantum-safe encryptie
• Ondersteun crypto-agility.

TW-F-NB-029: Onnodige software¶

Omschrijving

Er MOET beleid zijn waar mee men software of functies identificeert die niet langer nodig zijn of die misbruikt kunnen worden, en ervoor zorgt dat ze worden verwijderd of correct worden uitgeschakeld.

Toelichting

Door mogelijk kwetsbare software, functies of diensten uit te schakelen of te verwijderen wordt het aanvalsoppervlak te verkleind en misbruik door aanvallers te voorkomen.

Deze mitigerende maatregel MAG worden geïmplementeerd via de volgende stappen:

• Verwijder verouderde (legacy) software. Schakel oudere versies van software uit of verwijder ze wanneer ze geen updates of beveiligingspatches meer ontvangen.
• Schakel ongebruikte functies uit. Zet onnodige besturingssysteemfuncties uit, zoals SMBv1, Telnet of RDP, als deze niet vereist zijn.
• Beheer applicaties die door gebruikers worden geïnstalleerd. Voorkom dat gebruikers niet-geautoriseerde software installeren via groepsbeleid of andere beheertools.

TW-F-NB-030: Credential bescherming¶

Omschrijving

Credentials MOETEN beschermd zijn door op Windows systemen Credential Guard te activeren en cached credentials uit te zetten.

TW-F-NB-031: Digitale ondertekening software¶

Omschrijving

Geïnstalleerde software MOET digitaal ondertekend zijn.

TW-F-NB-032: Veilig opstarten systemen¶

Omschrijving

Systemen ZOUDEN zodanig MOETEN worden geconfigureerd en beheerd dat de integriteit van het opstartproces wordt gewaarborgd. Vanuit een dergelijk beleid ZOU de volledige opstartketen - inclusief firmware, bootloader, besturingssysteem en kritieke systeemcomponenten - MOETEN worden beschermd tegen ongeautoriseerde wijzigingen. Deze eis is van toepassing bij zowel fysieke systemen als gevirtualiseerde omgevingen (zoals virtual machines, hypervisors en cloud-infrastructuren) indien de partijen hier zelf controle over hebben.

Toelichting

Het doel is het voorkomen van manipulatie tijdens het opstartproces door aanvallers die persistentie proberen te verkrijgen via firmware-, bootloader- of OS-aanpassingen. Deze mitigatie kan worden geïmplementeerd via o.a. de volgende maatregelen:

• Secure Boot afdwingen;
• Gebruik van Trusted Platform Modules (TPM);
• Toepassen van Bootloader Paswoorden;
• Runtime integriteitscontrole van kritieke bestanden en processen.

TW-F-NB-033: Auditlogging¶

Omschrijving

Logging MOET NEN7513 compliant zijn.

TW-F-NB-034: Applicatie isolatie en sandboxing¶

Omschrijving

High-risk applicaties MOETEN in een omgeving draaien, die gescheiden is van andere omgevingen (door virtualisatie, containers of dedicated server).

TW-F-NB-035: Antivirus en antimalware¶

Omschrijving

Alle componenten MOETEN een moderne EDR/XDR tool met gecentraliseerd beheer hebben draaien waarbij de logging/alerts uit deze tooling actief worden bekeken en opgevolgd.

TW-F-NB-036: Exploit bescherming¶

Omschrijving

Er MOETEN maatregelen geïmplementeerd zijn om software exploits te detecteren, blokkeren en mitigeren zoals Data Execution Prevention (DEP) en Address Space Layout Randomization (ASLR) op Windows systemen.

TW-F-NB-037: Update software¶

Omschrijving

Systemen MOETEN tijdig worden bijgewerkt om bescherming te bieden tegen bekende kwetsbaarheden door het toepassen van patches en updates die door leveranciers worden uitgebracht.

Toelichting

Regelmatige updates verminderen het aanvalsoppervlak en voorkomen dat aanvallers misbruik maken van bekende beveiligingslekken. Dit geldt voor besturingssystemen, applicaties, stuurprogramma’s (drivers) en firmware.

Het patchbeleid ZOU ten minste de volgende eisen MOETEN bevatten:

• Security Updates worden maandelijks geïnstalleerd
• Kritieke security updates (CVSS 1≥ 8) worden binnen 72 uur geïnstalleerd.

TW-F-NB-038: User Account Control¶

Omschrijving

De rechten van User accounts MOETEN beperkt zijn zodanig dat het Operating Systeem niet gewijzigd kan worden:

• Activeer user account control (UAC) op Windows
• Onder Linux wordt het werken onder root geminimaliseerd door het account root niet in te zetten voor reguliere werkzaamheden.

TW-F-NB-039: Data-backup¶

Omschrijving

Het backup-beleid ZOU de volgende eisen MOETEN bevattten:

• Alle data (inclusief logging) en configuratie worden gebackupt
• Backups worden dagelijks gecontroleerd of deze geslaagd zijn
• Backups worden tenminste 2x per jaar getest
• Backups worden Offsite bewaard
• Backups worden versleuteld (AES-256) opgeslagen
• Encryptie wordt toegepast voor transport

TW-F-NB-040: Software configuratie¶

Omschrijving

Het beleid rondom software MOET de volgende eisen bevatten:

• Software wordt via een configuration management tool geïnstalleerd en geconfigureerd
• Software wordt regelmatig gecheckt op kwetsbaarheden
• Van alle geïnstalleerde software is een Software Bill of Material (SBOM) beschikbaar.

TW-F-NB-042: Authenticeren met PKI¶

Omschrijving

Om zich te kunnen authenticeren, MOETEN alle systemen betrokken bij transacties in het kader van Twiin een geldig PKIo-certificaat overleggen. 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

Toelichting

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

TW-F-NB-043: mTLS¶

Omschrijving

Alle transacties in het kader van Twiin MOETEN zijn beveiligd met Mutual Transport Layer Security (mTLS).

TW-F-NB-044: Volgen TLS-richtlijnen NCSC¶

Omschrijving

GTK Verzender en GTK Ontvanger maken gebruik van TLS versies en -algoritmen die zijn geclassificeerd als beveiligingsniveau "goed" in de ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS), 2025-5 van het NCSC.

Zij MOETEN gebruik maken van de volgende cryptografische algoritmes:

• Certificate Verification: ECDSA, RSA en EdDSA*
• Key exchange: ECDHE* is afgewaardeerd van goed naar voldoende. Met X25519MLKEM768, SecP256r1MLKEM768, SecP384r1MLKEM1024 zijn er alternatieven, maar deze algoritmes zijn (relatief) nieuw en maken nog geen deel uit van de TLS standaarden. ECDHE moet daarom nog gebruikt worden.
• Bulk encryption: AES-256-GCM of ChaCha20-Poly1305
• Hash functions: SHA-512 of SHA-384 of SHA-256

Toelichting

Het is verplicht om alle algoritmen aan te bieden die in de genoemde richtlijnen als "goed" zijn geclassificeerd. Hiermee wordt er voor gezorgd dat wanneer onverhoopt een algoritme in veiligheidsniveau daalt er andere alternatieven overblijven van niveau goed.

*Deze algoritmen zijn afgewaardeerd naar beveiligingsniveau ‘voldoende’. Maar zijn geen (beschikbare) varianten die geclassificeerd zijn met beveiligingsniveau ‘goed’. Hierdoor is het noodzakelijk om ook deze algoritmen op het niveau ‘voldoende’ te gebruiken.

TW-F-NB-045: Versleuteling volgens TLS¶

Omschrijving

Transacties MOETEN in het kader van Twiin worden versleuteld volgens TLS, zoals bedoeld in eis TW-F-NB-043.

TW-F-NB-046: Controleren geldigheid TLS-certificaat¶

Omschrijving

GTK Verzender en GTK Ontvanger MOETEN minimaal ieder uur door middel van CRL of OCSP de geldigheid van de certificaten van systemen waarmee transacties plaatsvinden controleren.

TW-F-NB-047: CPS van het UZI-register¶

Omschrijving

Systemen die de geldigheid van het UZI-servercertificaat van de andere Systemen dienen te controleren, ZOUDEN MOETEN voldoen aan de verplichting van het Certification Practice Statement (CPS) UZI-register.

TW-F-NB-048: CPS van PKIo¶

Omschrijving

GTK Verzender en GTK Ontvanger MOETEN de geldigheid van een PKIo-servercertficaat controleren op basis van de afspraken in het Certification Practice Statement (CPS) PKIoverheid.

TW-F-NB-049: Gebruik CRL of OSCP¶

Omschrijving

Systemen die de geldigheid van het PKIo-servercertificaat van de andere Systemen dienen te controleren, MOETEN dit volgens van de meest recent gepubliceerde Certificaten Revocatie Lijst (CRL) of via het Online Certificate Status Protocol (OCSP), minimaal ieder uur, doen.

TW-F-NB-050: Ondertekening volgens DNSSEC¶

Omschrijving

GTK's in hun rol als DNS Server MOETEN er voor zorgen dat de name records behorende bij de hostnames van GTK’en zijn ondertekend volgens DNSSEC.

TW-F-NB-051: Controleren ondertekenning DNSSEC¶

Omschrijving

Elk GTK, in zijn rol als DNS resolver in het Domain Name System, MOET controleren of de ontvangen name records zijn voorzien van ondertekening volgens DNSSEC en valideert deze volgens DNSSEC. Indien deze controle en validatie niet beide slagen, ziet hij af van verbinding met de betreffende hostname.

Toelichting

Het gebruik van DNSSEC vermindert de kwetsbaarheid van het Domain Name System voor bijvoorbeeld DNS spoofing.

TW-F-NB-053: Beveiliging van beheeraccounts¶

Omschrijving

Beheeraccounts ZOUDEN met de volgende maatregelen beveiligd MOETEN worden: - Auditlogging - Just-In-Time access - 4-ogen principe bij changes - Zorg ervoor dat beheerders van een GTK geen onopgemerkte ongeoorloofde toegang tot zorgdata kunnen verschaffen of hebben en monitor hierop.

TW-F-T-001: Aansluiting op Mitz¶

Omschrijving

Een GTK ZOU een aansluiting op Mitz MOETEN hebben.

Toelichting

Een GTK die uitwisselingen ondersteunt waar uitdrukkelijke toestemming voor nodig is, ZOU een Mitz Connector Aansluiting MOETEN ondersteunen. Op het moment dat de onderliggende bronsystemen zelf de controle op de toestemming voor gegevensuitwisseling uitvoeren, is er geen noodzaak voor het GTK om dit ook te doen.

TW-P-NP-001: Aanbieden notificatie-endpoint¶

Omschrijving

De GTK Ontvanger MOET een notificatie-endpoint aanbieden aan de GTK Verzender.

Toelichting

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.

TW-P-NP-002: Aanbieden resource-endpoint¶

Omschrijving

De GTK Verzender MOET een resource-endpoint aanbieden aan GTK Ontvanger.

Toelichting

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.

TW-P-NP-003: Aanbieden token-endpoint¶

Omschrijving

De GTK Verzender en de GTK Ontvanger MOETEN een token-endpoint aan elkaar aanbieden.

Toelichting

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.

TW-P-NP-004: Aanmaken authorization_base¶

Omschrijving

De GTK Verzender MOET een digitale representatie van de in de context van een verwijzing veronderstelde toestemming aan kunnen maken (authorization_base).

Toelichting

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.

TW-P-NP-005: Aanmaken autorization_grant¶

Omschrijving

De GTK Verzender en GTK Ontvanger MOET een authorization_grant aan kunnen maken die voldoet aan de specificaties.

TW-P-NP-006: Aanmaken access token request voor notification-endpoint¶

Omschrijving

De GTK Verzender MOET conform de specificaties een accestoken-request voor toegang tot het notificatie-endpoint aan kunnen maken en aan GTK Ontvanger versturen.

TW-P-NP-007: Gelijke waardes in authentication_grant en access token request¶

Omschrijving

De GTK Verzender en GTK Ontvanger MOETEN ervoor zorgen dat het veld sub in de authentication_grant en het veld client_id in het access token request dezelfde waarde bevatten.

TW-P-NP-008: Afhandelen access token request voor notification server endpoint¶

Omschrijving

De GTK Ontvanger MOET in staat zijn om conform de specificaties een accestoken-request van GTK Verzender voor toegang tot het notificatie server endpoint af te handelen.

TW-P-NP-009: Controleren autorization_base¶

Omschrijving

De GTK Verzender MOET controleren of de grondslag (authorization_base) waarmee de GTK Ontvanger een verzoek doet daadwerkelijk is uitgegeven (aan de GTK Ontvanger).

Toelichting

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

Implicatie bij toepassing

Voor de zorgtoepassing BgZ betreft dit de Autorisatierichtlijn Basisgegevensset Zorg

TW-P-NP-010: Aanmaken Workflow-Taks¶

Omschrijving

De GTK Verzender MOET een Workflow-Task aan kunnen maken indien verzender geen Workflow-Task stuurt als payload van de Notification-Task.

TW-P-NP-011: Versturen notificatie-create-request¶

Omschrijving

GTK Verzender MOET een notificatie-create-request kunnen versturen.

TW-P-NP-012: Afhandelen notificatie-create-request¶

Omschrijving

De GTK Ontvanger MOET een binnenkomend notificatie-create-request kunnen afhandelen en een passende response te versturen.

TW-P-NP-013: Versturen notificatie-create-request bij updates¶

Omschrijving

De GTK Verzender MOET een notificatie-create-request kunnen versturen wanneer de dataset van de verwijzing is geüpdatet.

TW-P-NP-014: Afhandelen notificatie-create-request bij updates¶

Omschrijving

De GTK Ontvanger MOET in staat zijn om een naar aanleiding van een geüpdatete dataset binnenkomend notificatie-create-request af te kunnen handelen en een passende response te versturen.

TW-P-NP-015: Versturen annulering¶

Omschrijving

De GTK Verzender MAG een notificatie-update-request versturen wanneer GTK Verzender de notificatie wil annuleren of intrekken.

TW-P-NP-016: Afhandeling annulering¶

Omschrijving

GTK Ontvanger MOET een binnenkomend notificatie-update-request kunnen afhandelen en een passende response versturen.

TW-P-NP-017: Uitvoeren read-operaties¶

Omschrijving

De GTK Ontvanger MOET een read-operaties uit de notificatie-taak uit kunnen voeren op het resource-endpoint van GTK Verzender.

Toelichting

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

TW-P-NP-018: Afhandelen read-requests¶

Omschrijving

GTK Verzender MOET een binnenkomende read-requests af kunnen handelen en een passende response versturen.

TW-P-NP-019: Uitvoeren search-operaties resource-endpoint¶

Omschrijving

GTK Ontvanger MOET search-operaties uit de notificatie-taak uit kunnen voeren op het resource-endpoint van GTK Verzender.

Toelichting

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

TW-P-NP-020: Afhandelen search-requests resource-endpoint¶

Omschrijving

GTK Verzender MOET binnenkomende search-requests af kunnen handelen en een passende response versturen.

TW-P-NP-021: Uitvoeren read-operatie ophalen workflow-task¶

Omschrijving

De GTK Ontvanger MOET een read-operatie voor het ophalen van de Workflow-task uit kunnen voeren op het resource-endpoint van GTK Verzender.

Toelichting

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

TW-P-NP-022: Afhandelen read-operatie workflow-task¶

Omschrijving

De GTK Verzender MOET een binnenkomende read-request op de workflow-task af kunnen handelen en een passende response versturen.

TW-P-NP-023: Uitvoeren read-operatie uit workflow-task¶

Omschrijving

GTK Ontvanger MOET read-operaties uit de workflow-taak uit kunnen voeren op het resource-endpoint van GTK Verzender.

Toelichting

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

TW-P-NP-024: Afhandelen read-request¶

Omschrijving

GTK Verzender MOET binnenkomende read-requests af kunnen handelen en een passende response versturen.

TW-P-NP-025: Uitvoeren search-operaties op resource-endpoint¶

Omschrijving

GTK Ontvanger MOET search-operaties uit de workflow-taak uit kunnen voeren op het resource-endpoint van GTK Verzender.

Toelichting

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

TW-P-NP-026: Afhandelen search-operaties op resource-endpoint¶

Omschrijving

GTK Verzender MOET binnenkomende search-requests af kunnen handelen en een passende response versturen.

TW-T-BB-001: Tijdlijngegevens opvragen via ITI-38¶

Omschrijving

Om de tijdlijngegevens op te kunnen vragen MOET de GTK Vrager de IHE: ITI-38 Cross Gateway Query inclusief SAML token uit te kunnen sturen volgens specificaties zoals beschreven in de Zorgtoepassing Beeldbeschikbaarheid.

Toelichting

Zx.3.2 | BB: IHE ITI-38 | Cross Gateway Query Z2.3.5 | BB: IHE ITI-40 | Provide X-User Assertion - include van technische kern

TW-T-BB-002: Tijdlijngegevens beantwoorden via ITI-38¶

Omschrijving

GTK Antwoorder MOET eerst het meegestuurde token valideren dat door de GTK vrager is meegestuurd en vervolgens op de IHE: ITI-38 Cross Gateway Query antwoord geven in het juiste formaat en met de door Twiin beschreven specificaties met betrekking tot metadata.

Toelichting

Zx.3.2 | BB: IHE ITI-38 | Cross Gateway Query Z2.3.5 | BB: IHE ITI-40 | Provide X-User Assertion - include van technische kern Z2.4.1.1 | BB: Metadata

TW-T-BB-003: Documenten opvragen via ITI-39¶

Omschrijving

Om een of meerdere documenten op te kunnen vragen MOET de GTK Vrager de IHE: ITI-39 Cross Gateway Retrieve inclusief SAML token uit te kunnen sturen volgens specificaties zoals beschreven in de Zorgtoepassing Beeldbeschikbaarheid.

Toelichting

Zx.3.3 | BB: IHE ITI-39 | Cross Gateway Retrieve Z2.3.5 | BB: IHE ITI-40 | Provide X-User Assertion - include van technische kern

TW-T-BB-004: Documenten beantwoorden via ITI-39¶

Omschrijving

GTK Antwoorder MOET eerst het meegestuurde token valideren dat door de GTK vrager is meegestuurd en vervolgens op de IHE: ITI-39 Cross Gateway Retrieve antwoord geven in het juiste formaat en met de door Twiin beschreven specificaties met betrekking tot metadata.

Toelichting

Zx.3.3 | BB: IHE ITI-39 | Cross Gateway Retrieve Z2.3.5 | BB: IHE ITI-40 | Provide X-User Assertion - include van technische kern BB: Metadata Radiologisch verslag BB: Metadata Beeldvormend onderzoek Radiologie (DICOM)

TW-T-BB-005: Beelden opvragen via RAD-75¶

Omschrijving

Om een of meerdere beelden op te kunnen vragen MOET de GTK Vrager de IHE: RAD-75 Cross Gateway Retrieve Imaging Document set inclusief SAML token uit kunnen sturen volgens specificaties zoals beschreven in de Zorgtoepassing Beeldbeschikbaarheid.

Toelichting

Zx.3.1 | BB: IHE RAD-75 | Cross Gateway Retrieve Imaging Document Set Z2.3.5 | BB: IHE ITI-40 | Provide X-User Assertion - include van technische kern

TW-T-BB-006: Beelden beantwoorden via RAD-75¶

Omschrijving

GTK Antwoorder MOET eerst het meegestuurde token valideren dat door de GTK vrager is meegestuurd en vervolgens op de IHE: RAD-75 Cross Gateway Retrieve antwoord geven in het juiste formaat en met de door Twiin beschreven specificaties met betrekking tot metadata.

Toelichting

Zx.3.1 | BB: IHE RAD-75 | Cross Gateway Retrieve Imaging Document Set Z2.3.5 | BB: IHE ITI-40 | Provide X-User Assertion - include van technische kern

TW-T-BB-007: Opgevraagde documentformats verwerken¶

Omschrijving

De GTK Vrager zal MOET ontvangst van een opgevraagd document de vastgestelde formats kunnen verwerken.

Toelichting

Z2.4.1 | BB: Metadata

TW-T-BB-008: Document terugsturen in vastgesteld format¶

Omschrijving

De GTK Antwoorder MOET bij het opvragen van een document, het document terugsturen conform 1 van de vastgelegde formats.

Toelichting

Z2.4.1 | BB: Metadata

TW-T-BB-009: Onderzoeken aanleveren voor één tijdlijn¶

Omschrijving

Alle onderzoeken MOETEN binnen 1 tijdlijn gerangschikt te zijn: De GTK Antwoorder zal de gegevens (metadata) om de tijdlijn op te kunnen bouwen correct en volledig terug geven aan de GTK Vrager

Toelichting

Alle gegevens zijn langs één tijdlijn gerangschikt zodat de relaties tussen verschillende typen gegevens bestudeerd kunnen worden.

TW-T-BB-010: Logische tijdlijn presenteren¶

Omschrijving

Alle onderzoeken MOETEN binnen 1 tijdlijn gerangschikt te zijn: Er dient een logische tijdlijn gepresenteerd te worden

Toelichting

Alle gegevens zijn langs één tijdlijn gerangschikt zodat de relaties tussen verschillende typen gegevens bestudeerd kunnen worden.

TW-T-BB-011: Onderzoeken filteren binnen de tijdlijn¶

Omschrijving

De onderzoeken ZOUDEN MOETEN gefilterd te kunnen worden binnen de tijdlijn.

Toelichting

Resultaten op de tijdlijn dienen gefilterd te kunnen worden op onder andere lichaamsregio en modaliteit. Mogelijkheden voor filtering en sortering binnen de eigen werkomgeving van de tijdlijn van een patiënt werken voor interne en externe onderzoeken op de tijdlijn.

TW-T-BB-012: Tijdlijn openen binnen de werkomgeving¶

Omschrijving

Eenvoudig openen tijdlijn binnen de werkomgeving.

Toelichting

Binnen de digitale werkomgeving van de zorgverlener geeft de tijdlijn een geïntegreerd overzicht van één patiënt inclusief alle in Nederland uitgevoerde onderzoeken met bijbehorende beelden en verslagen. Er zijn daarvoor geen extra handelingen nodig door degene die in het zorgproces de tijdlijn nodig heeft en daartoe bevoegd is. Viewer via SSO beschikbaar vanuit eigen werkomgeving

TW-T-BB-013: Bevoegdheid op basis van behandelrelatie¶

Omschrijving

Bevoegdheid vloeit voort uit een behandelrelatie.

Toelichting

Bevoegdheid vloeit voort uit een bestaande behandelrelatie met de patiënt of een behandelrelatie, die op dat moment wordt aangegaan met een (spoed)verwijzing, verzoek om een herbeoordeling of second opinion, bespreking in een MDO, e.d. Aantoonbaar maken dat er een behandelrelatie is. Achteraf door goed te loggen, vooraf door met de juiste rol gegevens op te vragen, zodat de beschikbaar stellende instelling de autorisatie kan controleren.

TW-T-BB-014: Gegevens raadplegen op basis van rol¶

Omschrijving

Op basis van de rol kunnen meer of minder gegevens worden geraadpleegd.

Toelichting

Op basis van de rol van elke zorgverlener en betrokkenheid bij de patiënt kunnen meer of minder (medisch inhoudelijke) gegevens op de tijdlijn worden geraadpleegd.

TW-T-BB-015: Performance tijdlijn¶

Omschrijving

Performance tijdlijn: De tijdlijn is steeds compleet en actueel en met een snelheid beschikbaar, die past in het zorgproces en dit niet verstoort of vertraagt.

Toelichting

Het samenstellen van de tijdlijn verstoort het ‘proces’ niet. Gaat hier om metadata, niet om de beelden in diagnostische kwaliteit.

TW-T-BB-016: Radiologisch onderzoek eenmalig tonen¶

Omschrijving

Radiologisch onderzoek is eenmalig zichtbaar binnen de tijdlijn: Elk uitgevoerd radiologisch onderzoek van een patiënt wordt eenmalig weergegeven in één landelijk dekkende tijdlijn.

Toelichting

Onderzoeksdata die is gekopieerd/ geïmporteerd dient er niet toe te leiden dat in de tijdlijn dubbelingen worden weergegeven.

TW-T-BB-017: Performance spoedverwijzing¶

Omschrijving

Performance spoedverwijzing

Toelichting

Bij een spoedverwijzing zal rekening moeten worden gehouden met de tijd die het kost om beelden te maken in de producerende zorginstelling en deze te laten verschijnen in de tijdlijn van de gebruikende zorginstelling. Voor de maximale wachttijd bij spoed wordt aansluiting gezocht bij de het Kwaliteitskader Spoedzorgketen. Uit deze richtlijn kan voor de 2e lijns/medisch specialistische zorg een maximale wachttijd van 90-95% binnen 15 minuten worden gedestilleerd en 100% binnen 30 minuten.

TW-T-BB-018: Toestemming patiënt¶

Omschrijving

Toestemming patiënt: De patiënt dient expliciete of impliciete toestemming gegeven te hebben om de gegevens te tonen binnen de tijdlijn.

Toelichting

Aanvulling in kwaliteitsstandaard: Mocht de zorgverlener de tijdlijn willen raadplegen terwijl deze toestemming (nog) ontbreekt en/of impliciete toestemming (bijvoorbeeld op basis van een verwijzing) onvoldoende is voor een complete tijdlijn, dan moet de patiënt de gelegenheid krijgen alsnog expliciete toestemming te geven.

TW-T-BB-019: Breaking-the-glass toestemming patiënt¶

Omschrijving

Breaking-the-glass toestemming patiënt

Toelichting

Met een breaking-the-glass procedure moet de tijdlijn ook in noodsituaties en/of in verband met de patiëntveiligheid beschikbaar zijn te maken wanneer toestemming van de patiënt (nog) ontbreekt .

TW-T-BB-020: Radiologisch verslag¶

Omschrijving

Eisen Radiologisch verslag

Toelichting

Het verslag is een weerslag van alle informatie-elementen van het radiologisch zorgproces tot dat moment. Dit kan in volledig vrije vorm zijn of (deels) gestandaardiseerd en/of gestructureerd. Voor de tijdlijn radiologische onderzoeken is het verslag één geheel; het (tekst)document met de complete beoordeling van beelden door radioloog.

TW-T-BB-021: Addendum eigen onderzoek¶

Omschrijving

Addendum eigen onderzoek

Toelichting

Addendum moet in de tijdlijn bij het oorspronkelijke verslag terug te zien zijn. In een addendum op het verslag wordt door de radioloog een aanvullende bevinding beschreven op het eigen onderzoek, die is gedaan nadat het verslag is geautoriseerd. Hierbij kan worden gedacht aan een extra bevinding als antwoord op een aanvullende vraag, na een aanvullende scan of analyse, na overleg in het MDO of de toevoeging dat op een later onderzoek een bevinding is gedaan die in retrospectie ook op dit eerdere onderzoek te zien was. Een addendum wordt gemaakt op het verslag van de eigen zorginstelling. Een verslag kan meerdere addenda hebben.

TW-T-BB-022: Rectificatie op eigen onderzoek¶

Omschrijving

Rectificatie op eigen onderzoek

Toelichting

Wanneer na afronding van het onderzoek blijkt dat informatie in het verslag toch niet correct is, dan wordt door de radioloog een rectificatie gemaakt. Dit is een nieuw verslag bij een onderzoek van de eigen zorginstelling. De rectificatie vervangt het oorspronkelijke verslag, dat ook beschikbaar blijft.

TW-T-BB-023: Herbeoordeling onderzoek elders¶

Omschrijving

Herbeoordeling onderzoek elders

Toelichting

Wanneer een radioloog wordt gevraagd om een radiologisch onderzoek van elders (beelden en verslag) nogmaals te beoordelen, dan is er sprake van een herbeoordeling. Dit gebeurt bijvoorbeeld bij een doorverwijzing voor specifieke expertise en behandeling en ter voorbereiding van een MDO. Een herbeoordeling wordt beschouwd als een nieuw radiologisch onderzoek op de tijdlijn. In het herbeoordelingsverslag wordt gerefereerd aan één of meer gebruikte voorgaande onderzoeken.

TW-T-BB-024: Onderzoeksgegevens intern en extern¶

Omschrijving

Eisen onderzoeksgegevens intern en extern

Toelichting

Voor alle onderzoeken, intern én extern, worden de volgende onderzoeksgegevens getoond: Datum/tijd waarop het radiologisch onderzoek bij de patiënt is uitgevoerd cq waarop de beelden zijn gemaakt. Omschrijving van de verrichting cq van het uitgevoerde onderzoek (bijv. CT thorax, MRI knie, echografie mamma, röntgenfoto voet). Hier kan ook de verrichting ‘herbeoordeling’ staan. Idealiter is er een landelijke tabel van verrichtingen. Zolang dit niet landelijk wordt gebruikt én voor de onderzoeken die van voor de ingebruikname zijn, worden onderzoeken omschreven aan de hand van modaliteit en anatomisch gebied. Zorginstelling of organisatie waar het radiologisch onderzoek is uitgevoerd cq de producerende zorginstelling. Het producerend specialisme, in dit geval “radiologie”, is het verantwoordelijk medisch specialisme voor de uitvoering van het onderzoek. Status van het onderzoek (gepland, opgeroepen, gereed, afgerond, gewijzigd), die volgt uit de verschillende processtappen van het radiologisch proces.

TW-T-BB-025: Verslag als één geheel¶

Omschrijving

Eisen verslagen: het verslag als 1 geheel

Toelichting

Voor de tijdlijn en het gebruik in het zorgproces wordt het verslag als geheel beschouwd en niet een verzameling van losse informatie-elementen. De volledige tekst van een verslag (oud of nieuw, gestructureerd of niet) wordt weergegeven, bij voorkeur in de oorspronkelijke layout.

TW-T-BB-026: Functionele gegevens verslag¶

Omschrijving

Eisen verslagen: functionele gegevens

Toelichting

Het verslag heeft functionele gegevens die een zorgverlener wil weten over het verslag: Datum/tijd waarop het verslag is geautoriseerd cq beschikbaar is gekomen. Zorginstelling of organisatie waar het verslag van het radiologisch onderzoek is gemaakt. Naam van de radioloog die het verslag heeft geautoriseerd en – indien anders – ook de naam van de radioloog die het verslag heeft gedicteerd. Label van het verslag, waaraan is te zien of het verslag oorspronkelijk is of na autorisatie/beschikbaar komen is aangepast (addendum of rectificatie).

TW-T-BB-027: Verslag beschikbaar als document¶

Omschrijving

Eisen verslagen: beschikbaar als document

Toelichting

Het verslag dient ook als document beschikbaar gesteld te worden.

TW-T-BgZ-001: Toepassing autorisatierichtlijn BgZ¶

Omschrijving

GTK Verzender MOET borgen dat de autorisatierichtlijn BgZ is toegepast.

Toelichting

Concreet betekent dit dat alleen de in de richtlijn geautoriseerde rollen een andere partij mogen notificeren voor het ophalen van de BgZ.

De autorisatie op het versturen/ophalen van de BgZ sluit aan op de autorisatie voor een verwijzing, dit betekent dat, dat dit in onder mandaat kan worden uitgevoerd, zoals in de autorisatierichtlijn BgZ is beschreven. De mandaterende rol moet dan wél zelf geautoriseerd zijn om de BgZ te mogen versturen of opvragen.

De GTK Verzender mag vervolgens vertrouwen op de interne autorisatieregels bij de GTK Ontvanger (indien deze een valide authorization base heeft, zie ook TW-P-NP-009)

TW-T-BgZ-002: Access policy en autorisatiematrix¶

Omschrijving

GTK Verzender heeft het afgesproken access policy geïmplementeerd bij het verzenden van een notificatie. GTK Verzender MAG door gebruikers met de in de autorisatiematrix opgesomde rollen een BgZ laten verzenden

TW-T-BgZ-003: Workflow-task aanmaken¶

Omschrijving

GTK Verzender MOET een Workflow-task aanmaken die voldoet aan de BgZ FHIR Workflow Task implementation.

TW-T-BgZ-004: Workflow-task interpreteren¶

Omschrijving

GTK Ontvanger MOET een Workflow-Task die voldoet aan het BgZ Workflow Task Profile kunnen interpreteren.

TW-T-BgZ-005: Notificatie-task aanmaken¶

Omschrijving

GTK Verzender MOET een Notificatie-task aanmaken die voldoet aan het afgesproken profiel.

TW-T-BgZ-006: Notificatie-task interpreteren¶

Omschrijving

GTK Ontvanger MOET een Notificatie-task die voldoet aan het afgesproken profiel kunnen interpreteren.

TW-T-BgZ-007: FHIR-resources volgens BgZ beschikbaarstellen¶

Omschrijving

GTK Verzender MOET FHIR-resources conform de implementation guide van de informatiestandaard BgZ beschikbaar kunnen stellen.

TW-T-BgZ-008: FHIR-resources volgens BgZ interpreteren¶

Omschrijving

GTK Ontvanger MOET FHIR-resources conform de implementation guide van de informatiestandaard BgZ kunnen interpreteren.

TW-T-BgZ-009: Correspondentie beschikbaarstellen¶

Omschrijving

GTK Verzender MOET correspondentie/ niet-discrete data conform Z3 | COR: Implementatiewijzer Correspondentie beschikbaar kunnen stellen.

TW-T-BgZ-010: Correspondentie interpreteren¶

Omschrijving

GTK Ontvanger MOET correspondentie/ niet-discrete data conform Z3 | COR: Implementatiewijzer Correspondentie kunnen interpreteren.

TW-T-BgZ-011: Raadplegen binnen 1 jaar¶

Omschrijving

Het raadplegen van de gegevens MOET plaatsvinden binnen de geldigheidsduur van de verwijzing/overdracht: 1 jaar. Dit is het laatste moment in de tijd waarop nog op basis van de veronderstelde toestemming de informatie mag worden opgevraagd. De geldigheidsduur moet worden opgenomen in de Task. Daarna is de veronderstelde toestemming niet meer geldig bij de verwijzende/overdragende instelling en mag de informatie alleen op basis van de use case 'Opvraging BgZ bij eerdere behandelaar' en vooraf vastgelegde uitdrukkelijke patiënttoestemming worden opgevraagd via een elektronisch uitwisselingssysteem.

Toelichting

De geldigheidsduur van een verwijzing dan wel overdracht binnen de tweede lijn is gebaseerd op de geldigheidsduur die gehanteerd wordt tussen de eerste en tweedelijns verwijzingen, namelijk één jaar. Dit afgestemd met de volgende koepels FMS, NVZ, NFU en ZKN en wordt tot nader order gehanteerd als veldnorm.

TW-T-BgZ-012: Send Notification parameters¶

Omschrijving

Een GTK Verzender MOET, indien de beoogde GTK Ontvanger dit vereist, de definitionReference in de Send Notification vullen met de daardoor aangeleverde parameters

Toelichting

Deze parameters bieden de GTK Ontvanger de mogelijkheid om een binnenkomende notificatie intern verder te routeren. Het is aan de Twiin Deelnemer om deze lijsten te verspreiden onder de Twiin Deelnemers.

TW-T-BgZ-013: Beschikbaarheid GTK en systemen achter GTK¶

Omschrijving

Het GTK en systemen ‘achter het GTK’ MOETEN ieder een beschikbaarheid van minimaal 99,5% te hebben.

Toelichting

Dit percentage is gebaseerd op de vuistregel dat dit:

• Betrouwbaar genoeg is voor deze toepassing.
• De kosten beperkt houdt in vergelijking met hogere beschikbaarheidsniveaus (>99,9%), waarin deze exponentieel stijgen.

TW-T-BgZ-014: Informatie beschikbaarstellen conform BgZ-specificatie¶