zib-compliance externe interface Wat betekent het voor de interoperabiliteit als systemen zibs niet op dezelfde manier hebben geïmplementeerd?

Christine van der Aa

Moderator
RadB
Redactie
Werkgever
Werkzaam binnen een van de programma's
Dat betekent in de meeste gevallen dat de interoperabiliteit tussen systemen en daarmee ook het mogelijk hergebruik van gegevens door gebruikers van beide systemen niet optimaal is.
Kijkend naar de definitie van de zibs is het heel legitiem dat zibs verschillend in systemen worden ingericht. Zo hebben heel veel gegevenselementen van zibs kardinaliteit 0..1, 0..n of 0..* Dat betekent dat die gegevenselementen op basis daarvan niet geïmplementeerd hoeven te worden, of als ze wel geïmplementeerd zijn, dat ze niet gebruikt hoeven te worden door de gebruiker van het systeem. Bij het ontwerp van de zibs is er bewust voor gekozen om de kardinaliteit van gegevens(elementen) maar heel beperkt op 1..1, 1..n of 1..* te maken om zorgverleners niet onnodig te verplichten om gegevens vast te leggen die voor hun eigen zorgproces niet relevant zijn.
Daarnaast kunnen bijvoorbeeld voor bepaalde gegevenselementen verschillende subsets van waardelijsten gebruikt worden in verschillende systemen.

Al deze verschillen kunnen ertoe leiden dat gegevens(elementen) uit het ene systeem niet door het andere systeem ontvangen en/of verwerkt kunnen worden en dus ook niet hergebruikt door de gebruiker. Of dat een probleem vormt, is afhankelijk van de specifieke casus waarvoor hergebruik wenselijk is. Als partijen die betrokken zijn bij een bepaalde casus het erover eens zijn dat het wenselijk is om bepaalde gegevens(elementen) voor die casus wel voor hergebruik beschikbaar te maken kunnen er op procesniveau afspraken gemaakt worden om die gegevens(elementen) wel te implementeren en te gebruiken. De extra eisen die dit stelt aan de systemen kunnen worden vastgelegd in een informatiestandaard die wordt opgesteld voor een specifieke casus.
 
Worden hier niet twee begrippen door elkaar gehaald? De kardinaliteit zegt iets over hoe de gegevenselementen binnen het model zich tot elkaar verhouden. De conformiteit over of een gegevenselement gevuld moet zijn (of niet).

Nu lijkt het net of dat gegevenselementen die een kardinaliteit van 0..1, 0..N of 0..* hebben niet geïmplementeerd hoeven te worden in de systemen. De elementen zijn echter niet voor niets gemodelleerd in de zib, dus ze hebben een functie! Alleen zijn ze niet in alle situaties (use cases) van toepassing. Echter als ze wel van toepassing zijn, dan komen ze maar maximaal één keer (resp. N of oneindig keer) voor. In de systemen moeten ze in de gevallen dat ze van toepassing zijn wel degelijk geregistreerd, opgeslagen en uitgewisseld kunnen worden.

Daarnaast kunnen we met elkaar afspraken maken over wat er wanneer in welke gevallen verplicht of optioneel vastgelegd en uitgewisseld moet worden. Er zit natuurlijk wel een relatie tussen deze twee begrippen, maar het is niet één op één hetzelfde. Het is goed mogelijk dat een gegevenselement een kardinaliteit van 0..1 heeft, maar in bepaalde use cases we toch met elkaar afspreken dat we deze verplicht registreren én uitwisselen.
 

Michael van der Zel

New member
Reg. Oncologienetw.
Werkgever
Universitair Medisch Centrum Groningen
... en het komt ook voor dat we verplichte velden maskeren, e.g. voor aanlevering aan register of voor research.
 

Christine van der Aa

Moderator
RadB
Redactie
Werkgever
Werkzaam binnen een van de programma's
... en het komt ook voor dat we verplichte velden maskeren, e.g. voor aanlevering aan register of voor research.
@Michael van der Zel , hoe gaat dat maskeren dan in zijn werk? Is dat iets wat jullie voor elke aanlevering apart moeten inrichten? En zou elke instelling met Epic dan zoiets zelf moeten inrichten of is het gewoon een feature van Epic?
 

Michael van der Zel

New member
Reg. Oncologienetw.
Werkgever
Universitair Medisch Centrum Groningen
Oej. Zo gaat deze thread wel een ander onderwerp krijgen, namelijk maskeren tbv onderzoek.
Dan moet je eigenlijk ook pseudonimiseren en anonimiseren meenemen.
@Christine van der Aa Kan je dit stuk van de thread verplaatsen naar een ander onderwerp?

Ik (wij) denken dat aanleveringen middels een stuk infrastructuur moet lopen. In die infrastructuur ga je de benodigde maskering (en pseudo) doen. Dat kan je generiek inrichten, middels "maskering profielen" en dan uitvoeren middels b.v. Google (https://cloud.google.com/healthcare-api/docs/concepts/de-identification) of Microsoft (https://github.com/microsoft/Tools-for-Health-Data-Anonymization) tooling.
 
Bovenaan