Inleiding

In de praktijk van OPEN bleek dat automatische duplicaat detectie (auto-detectie) niet altijd mogelijk is als een gegevensset of element daarvan meer dan één keer wordt verzameld. Het gevolg is dat een gegevensset meerdere keren wordt getoond.

In deze uitwerking komen aan bod:

• Probleemstelling
• Korte termijn oplossing binnen MedMij afsprakenstelsel
• Lange termijn oplossing in groter geheel van informatie-uitwisseling
• Veilig gebruik huidige situatie
• Acties

Gekoppeld aan Epic

Deze uitwerking is gekoppeld aan Epic AF-1274.

Hieronder de verkorte versie uit PIM:

Probleemstelling

Gegevens kunnen meerdere keren worden opgehaald, zonder dat duidelijk is dat het om dezelfde gegevens gaat. Hierdoor worden dezelfde gegevens mogelijk meerdere keren getoond in de PGO.

Mogelijk oorzaak

In de praktijk wordt niet goed omgegaan met OID/UID's die gebruikt horen te worden in de gegevensdiensten. Daarom kunnen gegevens wanneer ze meermaals worden opgehaald niet met zekerheid gematcht worden waardoor ze dubbel getoond worden in de PGO. We starten met vaststellen hoe we hier meer invloed op krijgen.

Oplossingsrichting (a priori)

OID/UID moet beter gebruikt gaan worden. Dit betekent wellicht dat informatiestandaarden dit directiever moeten beschrijven. Of dat er betere controle uitgevoerd moet worden op de toepassing van de beschreven informatiestandaard.

Probleemstelling

Het achterliggende  probleem is van algemeen aard; het persistent identificeerbaar blijven van gegevensentiteiten bij de business use cases verzamelen en (verder) delen via het persoonsdomein.

MedMij is in feite "slechts" een doorgeefluik van gegevens die het distribueren van die gegevens faciliteert. Als een bronsysteem een gegevenselement niet goed identificeert komt het via de doorgeefluik van MedMij ook als onvoldoende identificeerbaar in de gedistribueerde data in het zorgnetwerk van de persoon terecht.  

Figuur 3.1 reikwijdte van MedMij afsprakenstelsel in groen aangegeven in het uitwisselmodel van Registratie aan de bron.

Dit probleem is niet beperkt tot de informatie-uitwisseling tussen het persoonsdomein en professionele domeinen. Ook de informatie-uitwisseling tussen aanbieders krijgt er of zal er mee te maken krijgen.

Het OPEN programma had de de pech of geluk om tegen dit probleem aan te lopen.

Urgentie

Voor MedMij vormen de core business use cases verzamelen en delen de basis voor de informatie-uitwisseling met het zorgdomein en in de toekomst ook andere domeinen. 

Deze informatie-uitwisseling wordt gebruikt om te verwerken en (her)gebruiken in het zelf- of casemanagement in de applicaties van de persoon (PGO) en aanbieder(s).

Verwerking kan bestaan uit:

1. presenteren van gegevens om bijvoorbeeld te kunnen tonen tijdens een consult bij een andere zorgaanbieder.
2. duiden van de informatie van één of meer (zorg)aanbieders
3. verwerken tot integrale zorgplannen
4. (her)gebruiken in bepalen van bijvoorbeeld case-mixes door regionale systemen

Identificeerbaarheid ligt aan de basis aan de datakwaliteit van gedistribueerde data om vervuiling zoals meervoudig meenemen van dezelfde gegeven entiteit. 

Onvoldoende datakwaliteit levert een drempel voor meerwaarde creëren voor PGO-gebruik.

Bij het alleen presenteren van data (1.) zal dat nog geen onoverkomelijk probleem oplossen zoals nu tijdens OPEN is ontdekt. Je ziet hoogstens iets twee maal.

Voor verdere verwerking waar data ook kan via andere kanalen in de PGO kan komen of weer terug in het eigen systeem is een persistente identificatie van belang om verwerking automatisch en zonder extra voorbewerking/filtering  te kunnen uitvoeren.

De urgentie gaan echter groeien als de verwerkingen meer en meer bronnen gaan gebruiken en ook niet-oorspronkelijke gegevens uit andere bronnen verder delen.

Korte termijn oplossing in release 1.6

Een aandachtspunt bij het aansluiten van de bronsystemen van de aanbieders op een DVA is de datakwaliteit. Problemen onderkenen is de eerste stap

Het bepalen van de datakwaliteit kan deels worden ondervangen door testen, zoals auto detectie voor ontdubbeling, maar zal afhangen van de verwerking of de datakwaliteit voldoende is.

Op korte termijn kan dit aandachtspunt invulling krijgen door te beschrijven wat de gewenste situatie is ten aanzien van de eisen van de aan te sluiten bronsystemen wat betreft persistente identificatie, en te bepalen wat te doen bij afwijkingen. 

De gewenste situatie vanuit MedMij gezien is:

ID-1        Bronsystemen zijn verantwoordelijk voor het toewijzen van een persistente identificatie op elk uit te wisselen gegevensentiteit. Bronsystemen hanteren een methodiek die zorgdraagt voor wereldwijde unieke identificering.  

ID-2        Secundaire verwerkingssystemen behouden de door het oorspronkelijke bronsysteem (waar de betreffende gegevenselement is gecreëerd) toegewezen identificatie.  

ID-3        Bron - en secundaire systemen zijn verantwoordelijk voor het toepassen van persistente identificatie op alle elktronishce gegevens uitwisselingen tenzij dit expliciet is verboden.

ID-4        Elk al of niet bron systeem hanteert daarnaast persistent logische ids in dien nodig voor unieke identificatie binnen het technische. 

Denk aan een procedurele aanpak:

• opmerking wat de afwijkingen zijn t.a.v. ID-1 t/m ID-4 documenteren, maar kan live (de feitelijke situatie)
• oplossing alvorens live te gaan 
• afwijzen om aangesloten te worden

Hiermee wordt de aandacht gevestigd dat er ontwikkelingen zijn waar in de komende releases incrementeel nadere eisen komen.

Lange termijn oplossing in brede context

De fundamentele oplossing ligt buiten de reikwijdte van MedMij. Een waarschijnlijk scenario is dat het onderwerp wordt opgepakt bij het ontwikkelen van de standaarden voor generieke functies ten behoeve van de Wet Elektronische Gegevensuitwisseling In de Zorg (WEGIZ).

In het Plan van Aanpak Generieke Functies van NEN EGIZ is het onderwerp meta data geagendeerd.

De verwachting is dat het PvA eind april door het Informatieberaad wordt goedgekeurd waarna de norm ontwikkeld kan worden. Doorlooptijd is al gauw één jaar. In 2023 kan er mogelijk een norm zijn die per Maatregel van Algemeen Bestuur wettelijk kan worden gemaakt incl. een invoeringsdatum.

Deelnemers kunnen en worden gestimuleerd om deel te nemen in de ontwikkeling om daarmee de keuzes mede te bepalen rond de eisen en maatregelen ten aanzien van onder andere persistente identificatie van gegevensentiteiten. 

Veilig gebruik huidige situatie

Tot de tijd dat er éénduidige afspraken te maken zijn is een instructie nodig dat er bij de verwerking van gegevens rekening gehouden moet worden dat er nog geen betrouwbare persistente identificatie mogelijk is.

De verwerkers moeten daarom maatregelen te nemen om identificatie problemen te voorkomen.

Voorbeeld:

• Bij ingaan van een consult instrueren dat de persoon altijd de meest actuele gegevens ophaalt. 
• Een zorgverlener reconcilieert en ratificeert* zelf de validiteit van de door de patient aangedragen gegevens. (*term uit ISO13940)
• Een systeem gebruikt andere beschikbare meta data om gegevens uit meerdere bronnen te reconcilieren.

Acties

Een niet uitputtende lijst van gewenste acties voornamelijk buiten MedMij zijn:

1. Gewenste spelregels onafhankelijk van implementaties in technologieën definiëren. (ID-1 …) vanuit NEN EGIZ traject
2. Granulariteit definiëren (ook invloed op bijvoorbeeld NEN 7513 logging. Deze norm wordt dit jaar gereviseerd.)
3. Implementatie in HL7 V3 en FHIR beschrijven
4. Internationale ervaringen zoals OMG raadplegen
5. Handhaving (testen, etc.) definieren
6. Risico analyse (globaal) van effect op legacy, (alles  niet HL7 V3 en FHIR)
   1. HFMEA (health Failure Mode Effect Analysis) door deelnemers laten uitvoeren en aanbieders
   2. Uitkomsten gebruiken voor definiëren te bewandelen route  
7. Governance
   1. Bronleverancier(?) is verplicht een registratie aan te gaan in het Nictiz OID register en het toegewezen OID te gebruiken in het persistent identificeren van gegevens.
   2. Obslolence definiëren (de fax is pas net officieel als verouderd verklaard, kan dus hardnekkig zijn)
   3. Eventeueel wettelijk verplicht stellen via WEGIZ 
8. Workarounds definiëren en voorstellen van deelnemers evalueren
9.  Deadline stellen voor wanneer een bronsysteem niet meer op Medmij mag worden aangesloten nadat (wettelijke) afspraken rond persistente identificatie zijn gemaakt.

Vanuit MedMij wordt er aan bijgedragen.

Analyse technische implicaties

De experts van VZVZ en Nictiz hebben een analyse uitgewerkt waarin de de mogelijke keuzes, impact en dilemma's ten aanzien van legacy systemen omschreven.

Dit is het engels geschreven document om ook toegankelijk te zijn voor internationale stakeholders en is te vondeling op ..... link toevoegen 

Op basis van deze eerste analyse zijn de onderwerpen geïnventariseerd die nodig zin om de roadmap te kunnen bepalen van in eerste instantie bepalen wat de nadere invulling van de eisen zijn en o0lossingen in de praktijk te realiseren.

-onderstaande tekst wordt vervangen door het boven genoemde document- 

Uit analyse subtopic  AF-1296 voor huidige werkwijze gebruik OID in FHIR door Nictiz.

• Onderliggende feit is dat FHIR twee identifiers voor resources kent:  (PS de resource is de eenheid van gegevensuitwisseling in FHIR)
• Het attribuut “identifier” (een unieke en persistente business identifier, die door de oorspronkelijke bron wordt uitgegeven)
• Het attribuut “id” (een logische identifier die alleen uniek hoeft te zijn voor server waarbij de gegevens nu zijn opgehaald)

• De RESTful werkwijze van FHIR is gebaseerd op het gebruik van de “id” als referentie naar resources
• Binnen de HL7v3 standaard bestaat alleen een concept dat overeen komt de “identifier” binnen FHIR
• De oorspronkelijke vertaling door Nictiz van HL7v3 naar FHIR voor MedMij vulde alleen de “identifier”
• In principe kan “identifier” ook gebruikt worden als referentie en voor ontdubbelen, maar de meeste PGO’s ondersteunen dat niet
• Nictiz is niet echt consequent geweest door bij kwalificatie o.b.v. de eigen vertaling toe te staan dat de verplichte “id” niet gevuld was
• Er is aan de vertaling van Nictiz een mechanisme toegevoegd om een “id” te genereren vanuit de vanuit HL7v3 overgenomen “identifier”
• Deze aanpassing wordt nu getest in de testomgeving van het LSP+ DVZA, waarbij ook wordt gecheckt of gemelde issues echt opgelost zijn.
• Verwachting is dat medio januari 2022 de testresultaten bekend zijn en er een advies gegeven kan worden om dit in productie uit te rollen.
• Op basis hiervan kan besloten worden of de issues zijn opgelost of nog tot een story leiden bij ontwikkeling van het MedMij afsprakenstelsel

Technische Analyse

 (HL7 – FHIR)

Zie MedMij FHIR Implementation Guide

Twee onderdelen zijn van belang:

Aan sturende zijde:

• _lastUpdated
• .identifier (als document indentificatie)

OID’s worden gebruikt vanwege het gebruik van CDA componenten in bronsystemen. Deze laat alleen OID’s toe.

OID’s kunnen op basis van de FO worden samengesteld door:

• [gegevensset/dienst]
• datum van het document (welke datum wordt gebruikt wordt in de technische uitwerking bepaald - veelal zal dit een datum van aanmaak document zijn);
• de (verantwoordelijke) instelling die het document samengesteld heeft.

Van alle zibs OID’s samenstellen door:

• identificatie van het gegeven / de zib;
• auteur (de vastlegger);
• informatiebron (wie de informatie geleverd heeft);
• onderwerp (meestal: patiënt);
• datumtijd.[op basis van _lastUpdate of medical relevant datumtijd]

Naast het OID wordt begrijpbare tekst (“the narrative”) meegestuurd van bovenstaande velden. Hiervoor kunnen de velden worden gebruikt zoals ook voor logging worden gebruikt. Zie hiervoor NEN7513 gegevensvelden om eenduidigheid te krijgen.

Voor de herziening van de NEN7513:2017 naar NEN7513:2022 kan deze norm aangepast worden op de behoeftes van NEN EGIZ werkgroepen generieke functies en BgZ. Het is aan te bevelen deze suggestie in te brengen in de betreffende werkgroepen.

Aan ontvangende zijde kan hierdoor worden ontdubbeld door het gebruik van:

• de .identifier van het document
• alle zibs elementen afzonderlijk

Alleen op de .identifier voorkomt niet als dezelfde gegevens (meer precies dezelfde registraties) via verschillende routes worden ontsloten.

Op alle registraties op zib-niveau garandeert dat alle dubbele registraties kunnen worden gedetecteerd.

Punt van aandacht is het volgende volgens de Implementation guide:

Voorbeelden van identificaties die binnen een HL7 bericht in AORTA voorkomen zijn in de bijgevoegde implementatiehandleiding te vinden.

“Voor al deze identificaties geldt dat ze uniek en persistent moeten zijn. Dit betekent onder andere dat ze ook bestand moeten zijn tegen migraties en fusies van informatie- systemen.”

Disclaimer vanuit de implementatiehandleiding:

“Het is onmogelijk om vanuit HL7 Nederland, of welke instantie dan ook, centraal bij te houden welke OID’s gebruikt worden voor lokaal gegenereerde zorggegevens. Elke applicatie die een uniek nummer bepaalt per ingevoerde order of uitgevoerde activiteit zal daarvoor een eigen unieke en persistente OID moeten hanteren, om te zorgen dat bijvoorbeeld elke medicatieverstrekking te onderscheiden is van elke andere medicatieverstrekking.

Wat daarom nodig is, is een compromis met de volgende kenmerken:

• Forceer OID roots per applicatie, per zorgaanbieder of per softwareleverancier.
• Geef richtlijnen voor het uitdelen van nodes onder deze roots.
• Laat het beheer hiervan over aan de assigning authority (behorend bij de root). “

Bijlage Samenwerkingsverbanden (n.a.v. verzoek UMC Utrecht):

Afgezien van regionale belangen (regiovorming is een ontwikkeling) en het inrichten van shared services heb je als patiënt contact met zorgverleners.

Een zorgverlener heeft dat contact als onderdeel van een behandelovereenkomst gekoppeld aan een rechtspersoon die een behandelovereenkomst aan kan gaan, de zorgaanbieder.

Aangezien samenwerking steeds vaker voor gaat komen moeten we er wel rekening mee gaan houden. Zie de uitleg van de 4 fasen in samenwerking ook https://jvei.nl

De 4 fasen in samenwerking tussen zorgaanbieders:

1. Ad Hoc vanuit wet&regelgeving zoals verplichte informatie-overdracht tussen afzonderlijk zorgaanbieders (volgens het IGJ mag dat via de patiënt of zijn vertegenwoordiger)
2. Samenwerken in bijvoorbeeld een keten, maar als afzonderlijke zorgaanbieders,
3. Regionale coöperatie, en nog steeds als afzonderlijke zorgaanbieder,
4. Accountable organisatie (gaat de behandelovereenkomst aan, bijvoorbeeld op basis van een populatiemanagement contract met de verzekeraars)

In de PGO haal je gegevens op bij een zorgaanbieder, dat die toevallig op hetzelfde DVZA zitten (routering) en zelfs hetzelfde bronsysteem als onderdeel van shared services gebruiken maakt niet uit.

Uiteraard moeten we het identificeren van gegevens wel toekomstbestendig maken!

Bij het identificeren uit het zelfde bronsysteem van verschillende zorgaanbieders en daarmee verschillende juridische entiteiten is het daarom van belang om daaromtrent afspraken te maken.

Voorbeeld:

Personeel en dienstverband

Een professional kan in dienst zijn bij meerdere zorgaanbieders (dienstverband). Bij de (oorspronkelijke) bronvermelding is het daarom onvoldoende om alleen een BIG nummer te gebruiken. Het dienstverband is ook (juridisch) van belang.

De noodzaak om te weten wie in welk dienstverband een gegeven is gegenereerd of aangepast ontstaat bijvoorbeeld bij calamiteiten onderzoek van het IGJ.

Een andere reden om het dienstverband te weten is op welke kostenplaats een activiteit geboekt hoort te worden.

Bij het opstellen van de identificatie regels is het daarom belangrijk om ook logging (NEN7513) in beschouwing te nemen om 

Bijlage Aantekeningen

Analyse model

In deze analyse wordt de probleemstelling top-down geanalyseerd via de 5 lagen van het Nictiz interoperabiliteitsmodel.

• Van beleid de (visie, missie, doelstellingen en strategie)  op de PGO
• via de functionele eisen & wensen (FEW) voor de gebruikersprocessen,
• functioneel ontwerp voor de informatie(FO),
• technische ontwerp (TO) in HL7/FHIR van de applicatie
• en een toets op de infrastructuur.

Beleid

Het beleid is in hoofdlijnen vastgelegd in de visie, missie, doelstellingen en strategische thema’s.

Het issue wordt langs deze meetlat gelegd om de urgentie te duiden.

De visie van MedMij is:

• “Iedereen die dat wil moet kunnen beschikken over zijn gezondheidsgegevens in een zelfgekozen persoonlijke gezondheidsomgeving die voldoet aan de MedMij-afspraken. Die omgeving ontwikkelt zich tot cockpit van je zorg en gezondheid. Veilige, betrouwbare en gestandaardiseerde uitwisseling van gezondheidsgegevens zijn daarvoor noodzakelijke basisvoorwaarden.”

De betrouwbaarheid kan door duplicaten verminderen omdat het verwarrend kan werken.

De missie luidt:

• “Stichting MedMij wil:
  • continuïteit,
  • veiligheid en
  • betrouwbaarheid bieden

uitgaande van het afsprakenstelsel en de standaarden van MedMij.

Het is de missie van Stichting MedMij om het afsprakenstelsel voort te zetten en door te ontwikkelen vanuit gebruikersperspectief met oog voor andere perspectieven. Onafhankelijkheid, veiligheid en betrouwbaarheid zijn de kernwaarden van Stichting MedMij.” 

Het gebruikersperspectief is weergegeven vanuit de Patiëntenfederatie Nederland in onderstaand figuur:

De doelstelling is

• “Iedereen die dat wil kan zijn eigen gezondheidsgegevens levenslang veilig en betrouwbaar verzamelen, beheren en delen in een zelfgekozen persoonlijke gezondheidsomgeving (PGO) met MedMij-label. Die omgeving ontwikkelt zich tot cockpit van je zorg en gezondheid.”

De strategische thema’s zijn daarbij:

1. Gegevensuitwisseling op niveau
2. De kosten van gegevensuitwisseling niet hoger dan nodig
3. Gebruiksgemak van PGO’s naar een hoger niveau
4. Het aantal gebruikers op het MedMij netwerk neemt sterk toe (Opschaling)
5. Continuïteit en veiligheid

Om het gebruikersperspectief beter te duiden is een gedetailleerd gebruiksmodel als referentiekader nodig welke ook rekening houdt met de strategische thema’s en de andere belangrijke perspectieven zijn vooral de inspanningen van de deelnemende leveranciers en de ontwikkelingen rond de gegevensuitwisseling tussen (zorg)aanbieders zoals de WEGIZ.

De strategisch thema’s uitgewerkt voor het issue zijn:

• Gegevensuitwisseling op niveau voor eigen regie en zelfmanagement

De PGO is een applicatie die in de informatie moet voorzien voor het proces waarvoor het gebruikt wordt. Het proces van eigen regie en zelfmanagement kan kan goed gemodelleerd worden met casemanagement:

“Casemanagement is ingevoerd als instrument om de kwaliteit van zorg voor patiënten met complexe medische problematiek en complexe behandelingen te verbeteren. De casemanager is degene die de specifieke zorgbehoefte van de patiënt in kaart brengt en op basis daarvan – samen met de patiënt en zijn omgeving – keuzes maakt. Ook coördineert de casemanager vervolgens de zorg die vanuit verschillende (para)medische disciplines – bijvoorbeeld huisarts, wijkverpleging, specialist en fysiotherapeut – wordt aangeboden.”

In dit geval is de persoon zelf zijn eigen casemanager om op deze manier regie over zijn eigen zorg en gezondheid te voeren. Het onderwerp casemanagement is voor vele toepassingsgebieden uitgewerkt en kan daarmee een goede referentie dienen en kaders geven voor het gebruikersperspectief en de functionaliteit van een PGO.  

De gegevensuitwisseling wordt gebruikt in het eigen casemanagement en draagt bij aan de eigen regie van de persoon. Dubbelle gegevens kunnen verwarrend werken en daarmee het hier bedoelde niveau verlagen; wat ongewenst is.

• Kosten van het ontdubbelen bij gegevensuitwisseling niet hoger dan nodig
• Het gebruiksgemak van een PGO komt op een hoger niveau als ontdubbelen zoveel mogelijk automatisch geschied door middel van auto-detectie.
• Verhoogd gebruikersgemak komt ook ten goede voor de opschaling
• Onder voorwaarde dat continuïteit en veiligheid geborgd blijven.

Het issue van niet altijd in staat zijn om automatisch te ontdubbelen is hiermee als relevant aan te merken en rechtvaardigt de ‘hoge’ positie in de issue back-log.

Business analyse (zorgproces en informatie)

De functionele eisen en wensen (FEW) ten aanzien van ontdubbelen zijn af te leiden van het gebruik van de PGO in het zorg(gezondheids)proces van de persoon.

Een PGO is bedoeld om de persoon en/of zijn vertegenwoordiger te ondersteunen in de activiteiten om de regie over zijn zorg in wat meestal een zorgnetwerk is van meerdere aanbieders. Denk aan persoon, huisarts en apotheek als minimum zorgnetwerk; in de praktijk meestal is het meer tot bijvoorbeeld 27 aanbieders bij sommige diabetes type-2 patiënten (bron Diabetesvereniging).

Het is in de interacties van het zorgproces waar de informatie-uitwisseling plaatvind. Voor herstelgerichte zorg (cure) heeft het programma uitkomstgerichte zorg het volgende patiëntproces uitgewerkt.

Patiëntprocesmodel

Op dit moment ligt de meerwaarde van een PGO vooral in het verzamelen van gegevens (historie) in het voortraject als onderdeel van het zelfmanagement. Deze kunnen vervolgens naar behoefte worden gedeeld in de vervolgstappen in het patiëntproces; lokalisatie van gegevens en (her)gebruik onder eigen regie.

Naarmate PGO’s meer in de toekomst functionaliteit krijgen neemt het aantal interactiemomenten en frequentie toe zoals in onderstaand interactiemodel weergegeven.

Interactiemodel

Het gebruik van de PGO is geen onderdeel van het MedMij Afsprakenstelsel. Uiteraard is de bruikbaarheid van de gestructureerde gegevensuitwisseling in overeenstemming met informatiestandaarden een thema. Ongestructureerde gegevensuitwisseling zoals spraak al of niet via telefoon of beeldbellen, chat of e-mail vallen eveneens buiten het afsprakenstelsel.

Onderstaand uitwisselmodel voor gestructureerde gegevens wordt in de informatiestandaarden gehanteerd en is bevat de volgende stap naar het detailniveau om het issue verder te kunnen analyseren.

Gestructureerde gegevens (groene stippellijn) zijn gegevens die zijn geregistreerd conform de informatiestandaarden gebruikt in de gegevensdiensten die beschikbaar zijn in de Catalogus.

Het detailniveau om inzicht in het (1) vastleggen (registreren) van gegevens om te kunnen hergebruiken (8) is in onderstaand figuur weergegeven:

Vastlegging en hergebruik model

Ontdubbelen hoort bij de stap voorbereiden. Hier worden de al bekende registraties gedetecteerd. Voor auto-detectie zijn kenmerken nodig van het gegeven om te kunnen constateren of de gegevens al bekend zijn bij de ontvanger.

De kenmerken betreffen de registratie en niet de inhoud van de registratie. Aangezien de registratie van een toestand of gebeurtenis afhangt wie het waarneemt en invoert kan eenzelfde toestand of gebeurtenis verschillende worden geregistreerd!

Soms zijn een toestand of gebeurtenis onafhankelijk als feit te controleren bij het verwerken zoals de geboortedatum van de persoon, maar veel registraties zijn dat ook niet omdat ze op en oordeel zijn gebaseerd die subjectief kan zijn.

Samenvoegen (reconciliëren) van verschillende gegevens is daarom iets anders dan ontdubbelen. Het kan zijn dat er meerdere registraties zijn van dezelfde gebeurtenis. Het is aan de verwerker om deze gegevens te vergelijken en tot een conclusie te komen om er al of niet een nieuwe registratie van te maken.

Let op: indien er notificaties en abonneren wordt gebruikt en de dataprocessing automatisch verloopt kan er een feedback-loop ontstaan die zichzelf voedt. Nieuwe registratie -> notificatie -> verzamelen -> … verwerken … Nieuwe registratie -> etc.

De conclusie is dat dat elk opgeslagen registratie een uniek kenmerk moet hebben.

Applicatie analyse (gegevenselementen en unieke kenmerk):

De hiervoor genoemde eis is meegenomen in het functioneel ontwerp van de BgZ medisch-specialistische zorg in paragraaf 2.1.2 metagegevens die de kenmerken bevatten om registraties te kunnen ontdubbelen.

Er worden twee niveaus onderscheiden:

• Document-niveau
• Zib-niveau

Gegevensset (document-niveau):

• een documentidentificatie;
• datum van het document (welke datum wordt gebruikt wordt in de technische uitwerking bepaald - veelal zal dit een datum van aanmaak document zijn);
• de instelling die het document samengesteld heeft.

Opm: de aanmaakdatum van een document van dezelfde (onveranderde) zibs is niet geschikt om gegevensets op te ontdubbelen!

Een documentidentificatie waarin de laatste wijzigingsdatum/tijd van de onderliggende zibs is verwerkt maakt dit wel mogelijk.

(In de technische uitwerking van de .identifier zou het aangegeven moet  worden)

Zib-niveau:

In de huidige situatie o.b.v. ZIB 2017 zijn deze te vinden in de BasisElementen

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

• identificatie van het gegeven / de zib;
• auteur (de vastlegger);
• informatiebron (wie de informatie geleverd heeft);
• onderwerp (meestal: patiënt);

Daarnaast is bij uitwisseling met de BgZ van belang:

• (verantwoordelijke) instelling.

{bij meerdere dienstverbanden van een medewerker, hetzij bij dezelfde zorgaanbieder in een andere rol of verschillende zorgaanbieders al of niet in dezelfde rol geldt de rol en verantwoordelijke instelling, zie bijlage Samenwerkingsverbanden waarin de situatie van UMC Utrecht is omschreven.

De actualiteit van een gegeven kan middels datumtijd (of periode?) worden aangegeven om het moment (of periode) waarop de gegevens betrekking hebben aan te geven.

De gebruikte DatumTijd kan zijn:

• Datum en tijd van het aanbrengen van de wijziging (creatie of update) van de zib, en als zodanig gelogd conform NEN7513 (registratie datum en tijd)
• De medisch relevantie datum en tijd met betrekking tot de toestand of gebeurtenis van of rond de persoon. Deze datum heeft de voorkeur als deze bekend is. Bij metingen en uitslagen is dit gegeven te vinden in de zib zelf.

Bron van een registratie is altijd een persoon in een bepaalde rol en (dienst)verband. Mantelzorger is een verband met de patiënt, medewerker heeft een dienstverband met de verantwoordelijke instelling.

Bij een systeem of device als informatiebron is de verantwoordelijke persoon voor de inhoudelijke inzet het systeem of device de auteur

Een registratie staat los van de bronsystemen waarin het zich kan bevinden!

Toekomst obv ZIB2020

“2.1.2.2.2 BgZ en zibs 2020

In de zibs 2020 is de groep BasisElementen, die een impliciet onderdeel was van alle zibs, vervallen. In veel gevallen zijn de gegevens daarin (zoals Datum , Auteur etc.) al expliciet onderdeel van de betreffende zib, zoals de Uitvoerder van een Verrichting of MedicatieafspraakDatumTijd. Daarmee zijn metagegevens voor de zibs niet van toepassing: het zijn ofwel expliciete onderdelen van de zib, ofwel functioneel niet relevant. Op technisch niveau kunnen metagegevens wel aanwezig zijn, zie daarvoor de technische uitwerking.”

Deze wijziging vergt wellicht een geode begeleiding bij de deelnemers om hun applicaties aan te passen!