Consultatie
- Jorrit Spee (Unlicensed)
- Thomas Nap
VERSIE: 21-01-2021 STATUS: CONSULTATIE
Toelichting
Dit artikel bevat de commentaren die tijdens consultaties zijn binnen gekomen en beschrijft hoe deze zijn verwerkt.
Artikel | Onderwerp | Commentaar | Verwerking/antwoord |
|---|---|---|---|
Zou handig zijn om hier een link te geven waar je de PWD informatiestandaard kunt vinden | Link naar PWD informatiestandaard is toegevoegd aan begrip in versie 1.1. | ||
| De term ZIB zou een aparte toelichting verdienen, want daar is veel misverstand over.Een link naar het ZIB centrum zou handig zijn om de ZIBs te vinden. | In versie 1.1. van het artikel een link naar het zib centrum toegevoegd aan het begrip Zorginformatiebouwsteen (ZIB). | |
| (…) qua architectuur zijn een aantal aspecten (nog) niet beschreven wat wel zou moeten om het verhaal compleet te maken. Even los van de definitie van “afspraken” en een “afsprakenstelsel”. | De indiener van deze reactie heeft een document-export van het afsprakenstelsel beoordeeld. Deze bevatte niet alle informatie. De schematische weergaves van de relaties tussen de rollen op de verschillende architectuurlagen waren bijvoorbeeld weggevallen. Daarnaast is in afstemming met de indiener van de reactie de omschrijving van de rollen verder uitgebreid in de artikelen Organisatiebeleid, Informatie en Applicatie. | |
Afsprakenstelsel | Er wordt gesproken over het BabyConnect afsprakenstelsel maar zoals dit document is samengesteld zijn het niet alleen maar afspraken maar zijn het ook implementatiespecificaties van componenten en andere specificaties die niet het karakter van afspraken tussen partijen hebben maar meer richtlijnen en kaders voor realisatie en implementatie. | Het is een bewuste keuze dat in het hoofdstuk Referentiearchitectuur van het Afsprakenstelsel niet alleen afspraken maar ook implementatiespecificaties worden beschreven. Het doel hiervan is tweeledig: enerzijds het laten zien dat de afspraken uit het afsprakenstelsel technisch kunnen worden gerealiseerd en anderzijds het geven van richtlijnen en kaders voor de realisatie van interoperabiliteit van geboortezorg. | |
Gebruikersgroepen | “gebruikersgroepen, Nictiz” , werkgroep en redactieraad Eenheid van Taal geboortezorg, graag hier invoegen. | De deelnemers van de werkgroep en redactieraad Eenheid van Taal Geboortezorg zijn onderdeel van de gebruikersgroepen. Om die reden is het niet nodig ze apart te benoemen. Deze groepen worden benoemd in de uitwerking van de Innovatie- en Beheercyclus (in ontwikkeling). | |
Framework | het Framework 2018 - 2022 Realisatie Digitaal Infomatie Delen in Geboortezorg Nederland.
| Zin is aangepast naar: “Het Afsprakenstelsel Interoperabiliteit Geboortezorg staat niet op zichzelf maar is onderdeel van een groter geheel dat voldoet aan de kaders die worden gesteld door het Framework 2018 - 2022 Realisatie Digitaal Infomatie Delen in Geboortezorg Nederland en dat voortbouwt op de Zorgstandaard Integrale Geboortezorg en de Nederlandse informatiestandaard voor de geboortezorg PWD.” | |
| “Het doel is naadloos aansluitende zorg voor moeder en kind(eren) rond de zwangerschap en geboorte, inclusief de overdracht naar andere zorgverleners van de cliënte en haar kind, waaronder de jeugdgezondheidszorg, kinderarts en huisarts.”
| Het einde van de eerste alinea is aangepast naar: "Het doel is naadloos aansluitende zorg voor moeder en kind(eren) rond de zwangerschap en geboorte, inclusief de overdracht naar andere zorgverleners van de cliënte en haar kind, waaronder de jeugdgezondheidszorg, kinderarts en huisarts. Dit doel is in lijn met de in de landelijke Zorgstandaard Integrale Geboortezorg (link) beschreven transitie naar Integrale Geboortezorg waarbij de verschillende disciplines en organisaties in de geboortezorg integraal samenwerken." | |
Naamgeving gebruikersgroep | Hier stel ik voor eenheid van taal te gebruiken en gewoon landelijke registraties te gebruiken in plaats van “statistiekbeheerders”. De term statistiekbeheerders is nergens op gebaseerd, niet bekend in het veld en denigrerend voor hetgeen in de geboortezorg al die jaren is opgebouwd. | Op het moment wordt de naamgeving van gebruikersgroep 4 nader onderzocht. Zodra bekend is dat de naamgeving veranderd, zal dit worden verwerkt in het afsprakenstelsel. | |
Afkortingen | Afkortingen voluit weergeven. | De in het Afsprakenstelsel Interoperabiliteit Geboortezorg gebruikte afkortingen worden toegelicht in de Begrippenlijst. | |
FHIR | FHIR is niet IHE. FHIR is de vierde uitwisselingsstandaard van Health Level 7. | De referentiearchitectuur kent een drietal oplossingsrichtingen:
Zie ook het antwoord op de vraag met onderwerp FHIR vs IHE XDS. | |
Benaming oplossingsrichtingen | FHIR, FHIR icm IHE of IHE: bedenk een andere benaming voor IHE, FHIR is namelijk ook IHE. | De oplossingsrichting IHE is hernoemd naar IHE-XDS. IHE-XDS is een van de technische integratieprofielen van IHE (Integrating the Healthcare Enterprise). In de referentiearchitectuur worden met de oplossingsrichting IHE-XDS alle aan XDS gerelateerde standaarden bedoeld. FHIR – Fast Healthcare Interoperability Resources (hl7.org/fhir) – is een standaardenframework van HL7. De referentiearchitectuur kent een drietal oplossingsrichtingen:
| |
Bevraging Resource Server | Of met de rol ‘Resource Server’? - Het is hier niet duidelijk wie de Resource Server bevraagt. Doet de Query Builder dat? De viewer? De Translator wellicht? | Tijdens het proces Raadplegen wordt de Resource Server bevraagd. In het artikel Procesimplementatie Raadplegen staat een visuele representatie van de transacties tussen de verschillende rollen. Hierin wordt de Resource Server bevraagd door de RLV (Regionale Lokalisatievoorziening). Wanneer er gebruik wordt gemaakt van IHE-XDS bestaat een Resource Server uit een XDS-Registry en een XDS-Repository. | |
DV Persoon | De juridische rol MedMij DV Persoon (eigenlijk DVP in MedMij termen) is verantwoordelijk voor de PGO-server als koppelvlak met MedMij.
| a. Voor de leesbaarheid wordt in de referentiearchitectuur op de applicatielaag 1 actor "PGO" gebruikt. Hierbij wordt geen onderscheid gemaakt in bijv. de client- en server-zijde. Gedetailleerde specificaties hierover zijn te vinden in het MedMij afsprakenstelsel. | |
DV Persoon | De juridische rol MedMij DV Persoon is verantwoordelijk voor de invulling van de Applicatie-rol PGO conform het MedMij Afsprakenstelsel. → Dit is volgens mij niet juist. De DVP is toegespitst op de verplichte PGO server die als koppelvlak dient om aan te sluiten op de systeemarchitectuur welke voldoet aan Medmij. | Voor de leesbaarheid wordt in de referentiearchitectuur op de applicatielaag 1 actor "PGO" gebruikt. Hierbij wordt geen onderscheid gemaakt in bijv. de client- en server-zijde. Gedetailleerde specificaties hierover zijn te vinden in het MedMij afsprakenstelsel. We gebruiken voor het begrip "DV Persoon" de definitie van het MedMij Afsprakenstelsel: "1.4 Dienstverlener persoon: dit betreft een rol in het MedMij Afsprakenstelsel. De Dienstverlener persoon levert een PGO, een dienst aan de Persoon voor de regie op zijn gezondheid die minimaal gegevensuitwisseling met de Zorgaanbieder mogelijk maakt via het Netwerk en conform de afspraken van het MedMij Afsprakenstelsel." Zie ook MedMij Deelnemersovereenkomst Dienstverlener Persoon. | |
Functionaliteit FHIR Server | De communicatie is volledig gebaseerd op FHIR, waarbij de rol Resource Server en de rol Index Service worden gerealiseerd door middel van een FHIR-server. → Ik ben niet zo goed op de hoogte van de functionaliteit van een FHIR-server. Maar biedt die ook een index? | In versie 15-10-2020 van het artikel is de term Index Service niet meer in gebruik. Voor lokalisatie worden 2 rollen onderscheiden: Regionale Lokalisatievoorziening (RLV) en Landelijke Lokalisatievoorziening (LLV). Wanneer er voor de invulling van de RLV gebruik wordt gemaakt van een FHIR-server is het mogelijk om lokalisatiegegevens op te vragen via RESTful API-requests conform de FHIR-standaard. In de oplossingsrichting FHIR ondersteunen zowel RLV als LLV deze FHIR-requests. Onafhankelijk van de oplossingsrichting bevatten RLV en LLV de volgende metadata m.b.t. lokalisatie:
Hiermee kunnen de gegevens worden opgevraagd door bijvoorbeeld een zorgverlener in Amsterdam terwijl de gegevens in Groningen en Maastricht staan. Zie voor meer informatie de Procesimplementatie Raadplegen. | |
Autorisatie-informatie Index Service | Als de Viewer autorisatie-informatie krijgt uit de index-service dan verwacht ik bij de index-service een omschrijving van autorisatie-informatie beschikbaar stellen. | De Viewer ontvangt zelf geen Autorisatie informatie. Het raadplegende RLV (Regionale Lokalisatie Voorziening) bevraagt de LLV (Landelijke Lokalisatie Voorziening) naar de locatie van gegevens. De LLV stelt vervolgens een open vraag naar toestemming voor het inzien van de gegevens door de raadplegende zorgverlener. Alleen als het antwoord positief is, krijgt de raadplegende RLV lokalisatie-informatie terug. Op basis van dit antwoord wordt het proces vervolgt of afgebroken. Belangrijk is dat het ook kan zijn dat er voor een deel van de gegevens geen toestemming is. Voor meer informatie zie: Procesimplementatie Raadplegen. | |
MedMij DVZA | De verplichte authenticatie server voor DVZA volgens medmij staat niet benoemd. De resource server wel maar is daarin niet gerefereerd aan DVZA. | Het artikel Applicatie is voor versie 15-10-2020 aangepast voor een duidelijker overzicht en betere leesbaarheid. Onder het kopje MedMij DVZA wordt beschreven dat de DVZA bestaat uit een Resource Server en Autorization Server. De Authorization Server handelt de identificatie en authenticatie van de persoon af. Daarnaast handelt de Authorization Server de autorisatie van de PGO af voor het verzamelen van gegevens bij de zorgaanbieder en het delen van gegevens met de zorgaanbieder. Voor meer informatie hierover zie: MedMij Afsprakenstelsel. | |
Module B | Dus module B bevat ook de resource server? Die zit dus niet in module C? | Dat is correct. Module B bestaat uit twee rollen: Convertor (B1) en Resource Server (B2). Module C bestaat uit een index voorziening, verdeeld over de rollen RLV, LLV, Toestemmingsregister en Authenticatieserver. Door deze invulling blijft de data zo dicht mogelijk bij de bron. | |
Implementatieniveaus | Het heeft geen enkele zin om wel een convertor te implementeren om zib-jes te publiceren, maar die vervolgend niet te kunnen raadplegen. Laat dus bij niveau Start ook module B vervallen en publiceer alleen documenten en nog geen zibs. | Het is mogelijk dat de processen Publiceren en Raadplegen verschillende implementatieniveaus hebben. Wanneer het XIS van een Publicerende Zorgaanbieder gebruik maakt van een Convertor, bevindt deze zich nog op implementatieniveau Start. Een Raadplegende Zorgaanbieder kan tegelijkertijd gebruik maken van een Viewer die op dat moment op het implementatieniveau Midden of Eind functioneert. Daarnaast is het belangrijk om te beseffen dat één Raadplegende Zorgaanbieder in de Viewer de data van meerdere Publicerende Zorgaanbieders raadpleegt. Verschillende Publicerende Zorgaanbieders kunnen verschillende implementatieniveaus hebben. De verschillende implementatieniveaus zijn onderling interoperabel. Op deze manier zorgt de referentiearchitectuur ervoor dat applicaties met verschillende ontwikkelsnelheden onderling interoperabel zijn. Zie ook het antwoord op de andere vraag met onderwerp “Implementatieniveaus“. | |
Implementatieniveaus | Maak duidelijk dat het hier gaat om puur technische implementatieniveaus. Voor de gebruiker hebben ze niet of nauwelijks waarde. Alleen de stap van ‘Raadplegen documenten’ naar ‘Raadplegen documenten en zibs’ heeft functionele meerwaarde voor onze zorgprofessionals. Ik vraag me dan ook af of het zinvol is deze implementatieniveaus te onderscheiden. Het is iets voor de leveranciers en die kunnen dit zelf bedenken. | De implementatieniveau hebben zowel een technische als een organisatorische component. Implementatieniveaus onderscheiden zich in eerste instantie van elkaar op de Applicatie-laag. Per implementatieniveau wordt op een andere manier invulling gegeven aan de Applicatie-rollen uit de referentiearchitectuur. Iedere rol op de Applicatie-laag is verbonden met een juridische rol op de Organisatiebeleid-laag. Deze juridische rol is verantwoordelijk voor de invulling van de Applicatie-rol. Een verschillende invulling van Applicatie-rollen leidt daarmee tot een verschillende invulling van de juridische rollen. Daarmee hebben de implementatieniveaus zowel een technische als een organisatorische component en zijn ze dus relevant voor de verschillende doelgroepen van het afsprakenstelsel (zie artikel https://babyconnect.atlassian.net/wiki/spaces/VBC/pages/97813647). Voor leveranciers zijn de implementatieniveaus een hulpmiddel bij het bepalen en prioriteren van hun werkzaamheden wanneer zij willen voldoen aan de referentiearchitectuur. Door het definiëren van de implementatieniveaus in de referentiearchitectuur wordt een concrete invulling gegeven aan het groeimodel en wordt ervoor gezorgd dat applicaties met verschillende ontwikkelsnelheden onderling interoperabel zijn. | |
Rollen | Soms wel, soms geen aanduiding bij de rol (zorgproces, applicatie, juridisch, niets). Is niet duidelijk. | De artikelen “Organisatiebeleid“, “Zorgproces“, “Informatie“ en “Applicatie“ hebben sinds 15-10-2020 een duidelijkere structuur gekregen. Deze zijn nu consistent en beter leesbaar geworden. | |
Viewer | Hoe kan een Viewer informatie delen met anderen | Een Viewer bevat geen functionaliteit om gegevens te delen met anderen. In de Viewer kan een zorgverlener gegevens raadplegen en inzien. Wanneer een andere zorgverlener dezelfde gegevens wil inzien zal hij/zij deze gegev | |
XDS repository | Gaat het hier inderdaad om een XDS Repository? Of gaan we iets doen met de IHE profielen mXDE en QEDm? Daar is naast de Document Repository sprake van een ‘Clinical Data Source’. | Een XDS-Repository inclusief de IHE-profielen die deze ondersteunt, is één van de manieren om invulling te geven aan de rol Resource Server. De exacte invulling van rollen wordt door de referentiearchitectuur niet voorgeschreven. Om interoperabiliteit te bereiken bevat de referentiearchitectuur randvoorwaarden op generiek niveau en eisen op Rol-niveau. Hierin wordt ook verwezen naar andere landelijke ontwikkelingen die van invloed zijn op de referentiearchitectuur. In deze context betekent dit dat de invulling van de Resource Server dient te worden bepaald in afstemming met bijv. Twiin/Nuts en MedMij. Interoperabiliteit van geboortezorg is gebaseerd op het gebruik van zorginformatiebouwstenen (zibs). Onafhankelijk van de exacte invulling, dient de rol Resource Server in staat te zijn individuele zorginformatiebouwstenen toegankelijk en vindbaar te maken. | |
UZI | wordt hiermee een UZI-certificaat verplicht gesteld voor zorgaanbieders? | De referentiearchitectuur eist dat alle applicaties die betrokken zijn bij transacties in het kader van het Afsprakenstelsel Interoperabiliteit Geboortezorg beschikken over een geldig PKI-certficaat. Dit kan een UZI-servercertificaat of een PKIoverheid-servercertificaat zijn. | |
Whitelist | Meer informatie over aanpak/beheer Whitelist is t.z.t. welkom. | In de actuele versie van de referentiearchitectuur is geen Babyconnect-specifieke whitelist meer opgenomen. | |
Zibs | wie wordt hiermee bedoeld? ontwikkeld lijkt mij op dit moment door beschreven en gepubliceerd , althans de BGZ. Dit suggereert in mijn ogen dat het ook al is ingebouwd in de systemen.. | In versie 1.1 van het artikel is “zijn (…) ontwikkeld“ vervangen door “worden (…) beschreven en gepubliceerd". | |
Zorginformatie bouwsteen | Dit is een verkeerde voorstelling van een zib. Een zib is niets anders dan een conceptueel datamodel. Eigenlijk is dat ook een afsprakenset. Het staat los van hoe je het opslaat in jouw EPD. De meeste VISsen hebben dat ook niet 1 op 1 in hun systemen opgeslagen. Je moet de tekst veranderen in: hoe dat moet worden uitgewisseld. | In versie 16-11-2020 van het artikel is een tekst opgenomen die uitlegt wat in de referentiearchitectuur met zibs wordt bedoeld, namelijk: “FHIR-resources die voldoen aan FHIR-profielen die waar mogelijk zijn gebaseerd op zorginformatiebouwstenen”. | |
Gegevens publiceren met veronderstelde toestemming | Het proces geven toestemming beschrijft 3 vormen van toestemmingen:
Het is niet duidelijk hoe deze 3 vormen voor de Centrale repository behouden blijven. Er is geen link naar uitleg, die dat uit de doeken doet. Vooral als je uitgaat van het principe van RadB ( eenmalige registratie, meervoudig gebruik). Voorbeeld: de cliënt wordt overgedragen met overdracht-bericht. Dat is dan veronderstelde toestemming. Deze data komt ook in de CR terecht. Wordt er dat bijgehouden, dat deze data gepubliceerd is met veronderstelde toestemming? En wordt het dan geblokkeerd als je het wilt gebruiken voor een raadpleging waar expliciete toestemming nodig is? | Publiceren is het toegankelijk en vindbaar maken van data. Dit is onafhankelijk van de toestemming, verondersteld/impliciet of uitdrukkelijk/expliciet. In de referentiearchitectuur wordt niet uitgegaan van een centrale repository. Data blijft zo dicht mogelijk bij de bron (Zorgaanbieder Publicerend) en is vindbaar via de RLV en de LLV. Bij het raadplegen van gegevens wordt altijd gecontroleerd op toestemming door het bevragen van het toestemmingsregister. Dit wordt gedaan door middel van een open en een gesloten vraag. Zie procesimplementatie Raadplegen Wanneer een zorgverlener gegevens publiceert worden er geen gegevens over toestemmingen meegestuurd. Een client kan in MijnMitz haar uitdrukkelijke/expliciete toestemmingen registreren. Als een zorgverlener uitdrukkelijke/expliciete toestemming nodig heeft om gegevens te kunnen raadplegen en deze toestemmingen niet beschikbaar zijn zal de zorgverlener deze gegevens ook niet in kunnen zien. | |
Centrale repository | De kern van deze discussie is de status van deze centrale repository ten opzichte van een (eigen) zorgdossier. Is dit een zorgdossier of alleen een etalage? Wie is eigenaar of verantwoordelijk voor de Centrale Repository. Wie corrigeert eventuele foutieve zendingen? Mag je vanuit deze CR een overdracht ( bijv. naar JGZ) verzenden? | In de referentiearchitectuur wordt niet uitgegaan van een centrale repository. Data blijft zo dicht mogelijk bij de bron (Zorgaanbieder Publicerend) en is vindbaar via de RLV en de LLV. | |
Gids naar Gezondheidsgegevens | Is het de bedoeling dat er 2 keer een Gids naar gezondheidsgegevens is benoemd omdat deze 2 aparte rollen dienen te zijn? 1 die door Twiin wordt vervuld en een andere die niet door Twiin wordt vervult? | In de nieuwe versie van de referentiearchitectuur bestaat er nog 1 “Gids naar gezondheidsgegevens“. Dit is een rol op de informatielaag. Op de applicatie laag wordt de rol “Gids naar gezondheidsgegevens” vertaald naar de “Regionale Lokalisatie voorziening” en de “Landelijke lokalisatie voorziening”. Daarnaast vallen ook het “Toestemmingsregister” en de authenticatie van zorgverleners hieronder. | |
Opslag gegevens | Dit is dus een aparte opslag? Een kopie van de gegevens in een aparte repository? | In de nieuwe versie van dit artikel is de rol “Gegevensontsluiter“ komen te vervallen. In de referentiearchitectuur blijft data zo dicht mogelijk bij de bron. Om eenduidige en actuele gegevens te hebben wordt er geen kopie van gegevens opgeslagen. De “Bronhouder“ maakt de data toegankelijk en vindbaar. De resource server kan bij de zorgaanbieder staan of als dienst afgenomen worden door de zorgaanbieder. Tijdens het proces Raadplegen zal de data uit deze resource server geraadpleegd worden. Hier is dus geen aparte opslag voor nodig. | |
Toestemming | Ik denk dat de situatie in Nederland momenteel zo is, dat je alleen mag aanmelden als daarvoor toestemming is van de patiënt. De controle op toestemming, moet hier dus nog bij. | In het proces Publiceren hoeft geen toestemming vastgelegd te worden. Voor het publiceren van gegevens is geen toestemming vereist mits de Convertor en Resource Server onder beheer van de Zorgaanbieder vallen en de Index Service direct of indirect (bijvoorbeeld via een RSO) onder beheer van de gegevensproducerende Zorgaanbieder valt. Op het moment dat een zorgverlener gegevens wil raadplegen wordt er gekeken of de juiste toestemming (verondersteld/impliciet of uitdrukkelijk/expliciet) aanwezig is. Wanneer dit niet het geval is, kan de zorgverlener deze gegevens niet inzien. | |
Toestemming | Ook al (of juist) in het proces “publiceren” is van belang dat de patiënt toestemming heeft gegeven voor het publiceren van gegevens aan 1 of meerdere potentiële toekomstige opvragers. Dit kan o.b.v. inhoud van Mitz notificatiebericht. Dit is aanvullend op de toestemming-check op moment van delen van de gegevens. | Publiceren is het toegankelijk en vindbaar maken van data. Dit is onafhankelijk van de toestemming, verondersteld/impliciet of uitdrukkelijk/expliciet. In de referentiearchitectuur wordt niet uitgegaan van een centrale repository. Data blijft zo dicht mogelijk bij de bron (Zorgaanbieder Publicerend) en is vindbaar via de RLV en de LLV. Voor het publiceren van gegevens is geen toestemming vereist. Het aanmelden van gegevens in een index betekent niet dat een zorgverlener deze gegevens kan inzien. Wanneer een zorgverlener deze gegevens wil raadplegen wordt er gecontroleerd of hier toestemming voor is. Is dit niet het geval dan kan de zorgverlener deze gegevens niet inzien. | |
Toestemming | Maar zit in het publiceer proces het geven en vastleggen van toestemming voor gegevensuitwisseling met achterliggende zorgverleners? in een keten van systemen moet dit naar mijn mening geautomatiseerd worden doorgegeven. geen toestemming geven is ook niet delen tenslotte. | Publiceren is het toegankelijk en vindbaar maken van data. Dit is onafhankelijk van de toestemming, verondersteld/impliciet of uitdrukkelijk/expliciet. In de referentiearchitectuur wordt niet uitgegaan van een centrale repository. Data blijft zo dicht mogelijk bij de bron (Zorgaanbieder Publicerend) en is vindbaar via de RLV en de LLV. In het proces Publiceren hoeft geen toestemming vastgelegd te worden. Voor het publiceren van gegevens is geen toestemming vereist mits de Convertor en Resource Server onder beheer van de Zorgaanbieder vallen en de Index Service direct of indirect (bijvoorbeeld via een RSO) onder beheer van de gegevensproducerende Zorgaanbieder valt. Op het moment dat een zorgverlener gegevens wil raadplegen wordt er gekeken of de juiste toestemming (verondersteld/impliciet of uitdrukkelijk/expliciet) aanwezig is. Wanneer dit niet het geval is, kan de zorgverlener deze gegevens niet inzien. | |
Twiin tijdlijn | Bij TWIIN lijkt de tijdlijn ‘geschrapt’. Dan kan hij hier ook weg. | In de nieuwe versie van de referentiearchitectuur is de benaming “Twiin tijdlijn“ komen te vervallen. Echter is de functionaliteit van een Landelijke Lokalisatie Voorziening wel nodig voor de uitwisseling van gegevens. De Twiin tijdlijn was 1 van de opties die dit kon verwezenlijken. | |
Uitzondering procesgang | Wordt hier bedoeld dat de producent de gegevens verkeerd heeft ingevoerd? Schrijf dat dan op. | Deze formulering is in de nieuwe versie van dit artikel aangepast. | |
Uitzondering procesgang | Zit er een vertaalstap hiertussen? Waarom wordt dat niet stopgezet in het geval van deze uitzondering? | Er zit hier inderdaad een vertaalstap tussen die niet was opgenomen in de uitzondering. In de nieuwe versie van dit artikel is dit aangepast. In het geval van deze uitzondering wordt het proces van vertalen stopgezet. | |
Module D2 - vertaling naar leesbare taal | Waarom moet dat leesbare taal zijn? We hebben het toch gewoon over een query? Bv.: ‘Geef mij de integrale zwangerschapskaart’. | De functionaliteit die je in je vraag beschrijft, is ondergebracht in de applicatierol Query Builder (module D1). Deze dient inderdaad een vraag zoals ‘Geef mij de integrale zwangerschapskaart’ om te zetten naar een query naar zibs. De zibs die worden opgehaald uit de Resource Server bevatten nog coderingen (zoals SNOMED-CT of LOINC). Deze moeten dus nog worden vertaald naar een voor een zorgverlener leesbare taal (bijv. Nederlands of engels). Deze taak wordt uitgevoerd door de applicatierol Translator (module D2). Het moet uiteindelijk mogelijk zijn om deze codes te vertalen naar meerdere leesbare talen. | |
Stroomdiagram | 1.Inloggen bij zorgaanbieder en 7. Gegevens delen zijn erg makkelijke termen. Wat wordt er waar gedeeld? Wie heeft de credentials is beheer? | Voor de processen Delen en Verzamelen wordt er naar het MedMij Afsprakenstelsel verwezen. | |
Functie | Is bewust gekozen voor de functie presenteren in het PGO? Dus er wordt niets opgeslagen in een dossier zoals dat bij MedMij wel is beschreven? | Voor de processen Delen en Verzamelen wordt er naar het MedMij Afsprakenstelsel verwezen. | |
Rollen | De naamgeving van rollen afwijkend van MedMij terwijl de procesbeschrijvingen wel conform MedMij zijn, is verwarrend | Voor de processen Delen en Verzamelen wordt er naar het MedMij Afsprakenstelsel verwezen. | |
Rollen | In het stroomdiagram zijn rollen samengenomen. Dat leidt tot verwarring. Bij het ophalen van gegevens zijn er ook nog taken bij de gegevensontsluiter. Die missen hier (bijvoorbeeld controleren op autorisaties). | Voor de processen Delen en Verzamelen wordt er naar het MedMij Afsprakenstelsel verwezen. | |
Verwijzing MedMij | Kan hier niet enkel verwezen worden naar MedMij zonder een eigen variant te maken met het risico dat dit niet gesynchroniseerd kan blijven in de toekomst? | Voor de processen Delen en Verzamelen wordt er naar het MedMij Afsprakenstelsel verwezen. | |
Metadata bij GtK’s ophalen | Het is nog de vraag of een tijdlijnvoorziening nodzakelijk is, of in ieder geval voor alle informatie in deze usecase. Wellicht alleen voor beelden? Viewer kan bij de GtK (meta)data raadplegen en presenteren | De tijdlijnvoorziening maakt geen deel meer uit van de procesimplementaties. In de procesimplementaties is wel een lokalisatievoorziening opgenomen. Een GtK is een invulling van de rol “Regionale Lokalisatievoorziening” (RLV). Zoals de naam al doet vermoeden bevat een RLV alleen informatie voor lokalisatie binnen het samenwerkingsdomein van die RLV. Om ook data buiten het samenwerkingsdomein te kunnen raadplegen, heeft de RLV landelijke lokalisatie-informatie nodig. Deze kan een RLV opvragen bij de LLV (Landelijke Lokalisatievoorziening). De LLV kan aan de raadplegende RLV doorgeven welke RLV’s informatie hebben over de lokalisatie van de gegevens over een cliënt. | |
Implementatieniveau Start | Module B maakt zibs toegankelijk (Module B bevat functionaliteit van actor Resource Server) → Heeft geen zin als je ze in niveau Start niet kunt Raadplegen. | Allereerst is het goed te beseffen dat de verschillende implementatieniveaus onderling interoperabel zijn. Per zorgaanbieder kan het implementatieniveau immers anders zijn. Binnen 1 zorgaanbieder kan het implementatieniveau voor Publiceren verschillen van dat van Raadplegen. Een Zorgaanbieder kan gegevens over een cliënt Raadplegen, onafhankelijk van het implementatieniveau van het proces Publiceren van andere Zorgaanbieders. In versie 15-10-2020 is deze zin aangepast naar "Module B maakt FHIR resources toegankelijk (…)". Een FHIR-resource kan de FHIR-representatie van een zib zijn, of de FHIR-representatie van een document (bijv. o.b.v. de pdf/a-standaard). Een Zorgaanbieder met een proces Raadplegen op implementatieniveau Start kan gegevens over een cliënt gebaseerd op de pdf/a-standaard Raadplegen. | |
Sequentiediagram, tabel transacties | Voldoen aan de Twiin-eisen (GtK) zou voldoende moeten afdekken tussen XIS en GtK. Geen aanvullende Babyconnect zaken vereist. Deze bieden leveranciers wel handvatten, maar een Twiin-DVZA zou connectie tussen XIS en GtK dus ook moeten kunnen volstaan zonder aanvullende babyconnect-eisen | Bekeken vanuit publiceren: Bekeken vanuit raadplegen: | |
Tabel transacties | Wat Transactie 1 en Oplossingsrichting FHIR betreft is een SOAP request niet echt een geschikte tactiek ervoor. Dit zou gedaan worden via a REST API (nl, HTTP GET). | Transactie 1 betreft een veilige overdracht van XIS naar Convertor. Het is aan de leveranciers van XIS en Convertor om onderling afspraken te maken over hoe de transactie veilig wordt gerealiseerd. Dit kan meerdere manieren, bijvoorbeeld via SOAP of REST. | |
Uitzonderingen op sequentiediagram | In de processtap publiceren is aangegeven hoe in de happy flow gegevens beschikbaar komen en in een index worden gemeld. Is er ook proces om een fout te corrigeren? Bijvoorbeeld een fout in een BSN? Of terugtrekken toestemming? | De uitzonderingen op de procesgangen (Publiceren en Raadplegen) worden gespecificeerd op de informatie-laag van de referentiearchitectuur. Validatie van bijv. een BSN vindt plaats in het XIS (o.a. WID- en BSN-controle) voordat het proces Publiceren in gang wordt gezet. Wanneer een client een toestemming heeft ingetrokken is het voor een zorgverlener niet meer mogelijk om deze gegevens in te zien. | |
Opslag ongestructureerde data | Wat doet module B met ongestructureerde data zoals in dit voorbeeld Beelden? Waar worden die opgeslagen als module C slechts een index is in dit ontwerp? | Module B heeft als doel om input (zowel gestructureerde als ongestructureerde data) uit Module A (XIS) toegankelijk en vindbaar te maken. Module B zorgt ervoor dat de input door de Convertor wordt geconverteerd naar de juiste FHIR-resources en metadata, en dat deze door de Resource Server toegankelijk worden gemaakt. Zowel de Convertor als de Resource Server is onderdeel van Module B. Module C bevat geen data maar alleen metadata, o.a. lokalisatie en autorisatie. Omdat Module B onder eindverantwoordelijkheid valt van de Zorgaanbieder, wordt op deze manier invulling gegeven aan het DIZRA-principe “de data blijft bij de bron". | |
MedMij | Is niet volgens MedMij | De processen en procesimplementaties Verzamelen en Delen zijn conform de overeenkomstige MedMij use cases. De processen en procesimplementaties Raadplegen en Publiceren vinden plaats binnen het zorgaanbiedersdomein en vallen daarmee buiten de scope van het MedMij Afsprakenstelsel. | |
Informatiestandaard MedMij | Zijn de zibs conform informatiestandaarden MedMij? | Op het niveau van de procesimplementatie wordt met ‘zibs’ bedoeld: FHIR-resources die voldoen aan gestandaardiseerde FHIR-profielen die zo veel mogelijk zijn gebaseerd op zorginformatiebouwstenen. De zibs worden gedefinieerd in de Informatiestandaard Geboortezorg. De zibs die worden gebruikt in de MedMij-processen Verzamelen en Delen zullen worden vastgelegd in een MedMij-Gegevensdienst die zal worden aangemeld als MedMij-informatiestandaard. | |
PGO | In de oplossingsrichting ontbreekt PGO. Dit is veel meer een samenspel tussen Twiin en Mitz. | De procesimplementatie Raadplegen is geen oplossingsrichting op zich. Met dit proces kan een zorgverlener gegevens over/van een client opvragen. Het PGO is hierin niet nodig omdat een zorgverlener niet met een PGO werkt. Bij de processen Delen en Verzamelen is deze wel nodig omdat hierbij de client gegevens deelt en verzamelt. | |
FHIR oplossingsrichting | Voor de FHIR-gerichte oplossing, zou dit Patient.Search of Patient.$Match moeten worden ipv een IHE transactie. | Transactie aangepast naar FHIR: Get documentreference. Dit is verwerkt in de versie 17-11-2020 van het artikel. | |
FHIR patient location query | ITI-56 gaat over Patient Location Query terwijl ITI-57 is een Update Document Set transactie. Ik ga ervanuit dat er ITI-56 wordt bedoeld? | Transactie aangepast naar FHIR: Get document reference. Dit is verwerkt in de versie 17-11-2020 van het artikel. | |
Gebruik versies OAuth | Betreft dit OAuth or OAuth2? De twee zijn niet backwards-compatible dus het is belangrijk om aan te geven welke versie zou gelden. Epics voorkeur gaat uit naar OAuth2. | Het belangrijkst is dat voor de SSO-integratie gebruik wordt gemaakt van vigerende en veilige webtechnologiestandaarden. Het betreft hier bijvoorbeeld OAuth 2.0, SAML versie 2.0 of JWT. Dit is verwerkt in versie 15-11-2020 van het artikel. | |
Sequentiediagram | De flow is niet conform MedMij | De processen en procesimplementaties Verzamelen en Delen zijn conform het MedMij Afsprakenstelsel. De processen en procesimplementaties Raadplegen en Publiceren zijn conform het Afsprakenstelsel Interoperabiliteit Geboortezorg. Deze processen worden dan ook niet benoemd in het MedMij Afsprakenstelsel. | |
Sequentiediagram | Ik mis de authenticatie in de flow. | In het sequentiediagram van versie 17-11-2020 van het artikel is de transactie tussen het XIS en de viewer opgenomen. | |
Transacties oplossingsrichtingen | Is FHIR, geen IHE | Transactie aangepast naar “IHE-ITI-18 (Registry Stored Query“. Dit is verwerkt in versie 17-11-2020 van het artikel. | |
Transacties sequentiediagram | 4&5 mogelijk maken samen te voegen, het is nog de vraag of een tijdlijnvoorziening noodzakelijk is. Viewer kan bij de GtK (meta)data raadplegen en presenteren | Een tijdlijnvoorziening bevat de functionaliteit van indexvoorziening op landelijk niveau. Om de reden hebben we de actor naar LLV (Landelijke Lokalisatie Voorziening). Dit betekent dat deze bevraagd wordt naar de locatie van gegevens van een client op niveau van de regionale lokalisatie voorziening. Deze tijdlijn zorgt er tijdens het proces Raadplegen voor dat niet alle RLV’s moeten worden bevraagd. Dit bevorderdt de response tijd tussen het moment van bevraging en het presenteren van de gegevens in de Viewer. | |
Geboortezorgproces | wij snappen niet de keuze van 4 geboorteprocessen. Er is meer en wat vindt de moeder van deze processen? En het proces er na, kan de JGZ een rol spelen net als de huisarts etc. Dit geldt ook voor andere zorgprocessen. De JGZ kan op verschillende momenten in de zwangerschap aanbod komen, niet alleen voor DKTP vaccinatie, maar ook voor ondersteuning voor de ouder en het kind. | In de versie van 15-10-2020 van het artikel is het onderscheid tussen 4 verschillende types geboortezorgproces verwijderd en vervangen door 1 integraal geboortezorgproces. Hierdoor komt sterker naar voren dat het Afsprakenstelsel Interoperabiliteit Geboortezorg voor de inhoud van het zorgproces verwijst naar de Zorgstandaard Integrale Geboortezorg. Daarnaast is de schematische weergave van het integrale geboortezorgproces aangepast. | |
Inleiding | Bij de toelichting wordt aangegeven dat de de informatiebehoefte van de zorgverlener ten grondslag ligt. Hoe verhoud dit dan met de uitspraak uit hoofdstuk ‘Grondslagen’ waarin staat dat de patiënt centraal staat? | In de versie van 15-10-2020 is deze zinsnede vervangen door "De informatiebehoefte van de cliënt en de zorgverlener tijdens het integrale geboortezorgproces is het vertrekpunt voor gegevensuitwisseling“. |