Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Vind hier onze Servicedesk om een verzoek in te dienen m.b.t. onze producten en diensten! Klik hier om toegang aan te vragen of voor andere BITS/Jira gerelateerde vragen en/of opmerkingen.

Afspraken omtrent data-identificatie en voorkomen van dubbele data

Description

Bij onze implementaties van de Medmij standaarden komt vaak een soorgelijke vraag naar voren. Deze vraag is ietwat complex, dus ik probeer in zo veel mogelijk detail te treden.

Het Medmij framework draait om het ophalen en delen van medische data. Althans, in ieder geval voor UC Verzamelen en UC delen. Deze vraag geldt voor beiden use cases, maar laten we ons voor nu even limiteren tot UC Verzamelen.

Stel een gebruiker haalt zijn BGZ gegevens op bij zijn huisarts via zijn PGO. De PGO haalt deze gegevens op bij de DVZA en ontvangt de ZIBs als FHIR resources. Deze ZIBs slaat hij op in zijn systeem. We gaan er even vanuit dat deze resources in een FHIR server opgeslagen worden, waar ze nieuwe IDs krijgen die lokaal zijn aan de FHIR server van de PGO.

Deze zelfde gebruiker wil een week later opnieuw zijn BGZ gegevens ophalen bij zijn huisarts via dezelfde PGO. De PGO haalt opnieuw deze gegevens op en ontvangt de ZIBs weer als FHIR resources.

Nu komen we op het probleem. Deze FHIR resources kunnen nieuwe informatie bevatten en kunnen logisch geinterpreteerd worden als nieuwe versies van de resources die een week geleden opgehaald zijn. Het zou dus ook logisch zijn als de verouderde resources geupdate kunnen worden met deze nieuwe data. Dit ook om te voorkomen dat de data dubbel wordt geregistreerd, wat het geval zou zijn als deze nieuwe data simpelweg wordt geupload naar de FHIR server.

Zijn hier afspraken over vanuit Medmij? Hoe kan de PGO weten welke data in zijn FHIR server matcht met deze nieuw ontvangen data, zodat hij deze data kan updaten? Hoe kunnen we voorkomen dat data dubbel wordt geregistreerd?

Ik hoop dat dit probleem duidelijk is en dat we hier het gesprek over kunnen openen. Ik ben ook bereikbaar op 0638311061 om eventueel verduidelijking te geven.

Answer

None

Activity

Jari Maijenburg June 16, 2020 at 3:11 PM

Beste Niek,

De ID van een resource is alleen bedoeld als identificatie binnen hetzelfde systeem. Dat betekent dat er een behoorlijke overlap kan zijn tussen de IDs van resources in verschillende systemen, waardoor je niet kan vertrouwen dat de resource uniek geidentificeerd wordt met die ID. Daarnaast is het volgens mij ook niet verplicht om het ID veld in te vullen bij uitwisseling.

Wij hebben tot nu toe nog geen decentrale oplossing gevonden die we zouden kunnen implementeren, zonder afhankelijkheid van een aanpassing van het Medmij stelsel. Wij zijn van mening dat het voor het gebruik van het Medmij stelsel kritiek is dat we hier gezamelijk een oplossing voor verzinnen. Delen jullie deze mening, of denken jullie hier anders over?

Angelo Brouwers June 11, 2020 at 1:38 PM

Beste ,

 

Is het antwoord u zo duidelijk?

Als dit het geval is, zal ik dit ticket sluiten.

 

Met vriendelijke groet,

Angelo Brouwers

Niek van Galen May 29, 2020 at 3:13 PM

Beste ,

Excuses dat het antwoord lang op zich liet wachten!

Vanuit MedMij wordt hier niet specifiek iets over gezegd, maar wel in de FHIR-specificatie: http://hl7.org/fhir/stu3/managing.html#7.11.2

Vrij vertaald:

Als je van dezelfde server dezelfde Resource/id krijgt, kun je dat op je eigen omgeving bijwerken. Daarvoor moet je dus wel onthouden wat de oorspronkelijke Resource/id was naast de Resource/id die je er zelf hebt toegekend.

Ik hoop dat dit je vraag beantwoordt. Mocht je nog aanvullende vragen hebben: stel ze gerust.

Groeten,

Niek van Galen

Niek van Galen May 28, 2020 at 7:21 AM

Dag ,

We zijn er mee bezig, er dient wat overleg plaats te vinden om je een juist en volledig antwoord te kunnen geven.

Groeten,
Niek van Galen

Jari Maijenburg May 25, 2020 at 10:04 AM

Is hier al naar gekeken?

Resolved
Pinned fields
Click on the next to a field label to start pinning.

Details

Assignee

Reporter

Information standard

Alle

Informatiestandaard onderdelen

Technisch ontwerp

Priority

Better Excel Exporter

Created May 14, 2020 at 12:01 PM
Updated January 12, 2024 at 12:52 PM
Resolved June 4, 2020 at 7:58 AM

Flag notifications