...
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 VIPP Babyconnect Afsprakenstelsel 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. | |
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. | |
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. | |
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. | |
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 VIPP Babyconnect Afsprakenstelsel 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“. |