Mening gevraagd over mogelijke oplossingsrichtingen Objectidentificatie in PGO

Bij verschillende usecases is de behoefte naar voren gekomen om uitgewisselde gegevens uniek te kunnen identificeren. Dit is onder meer nodig om te detecteren of informatie al eerder is binnengehaald (en in de tussentijd mogelijk gewijzigd is) en om informatie in de tijd te kunnen volgen. Daarvoor is het nodig om informatie op het niveau van bv. individuele metingen, diagnoses, verslagen, contactmomenten en uitgevoerde behandelingen te kunnen herkennen. We noemen dit: informatieobjecten.
 
Om te voorkomen dat er voor elke usecase een eigen puntoplossing komt, wordt er binnen Nictiz nagedacht over uniforme richtlijnen voor het ontwikkelen van informatiestandaarden met betrekking tot objectidentificatie. Daar zijn nu twee oplossingsrichtingen in ontstaan. Via dit document willen we inzicht ophalen bij de directe gebruikers van informatiestandaarden over de beste oplossingsrichting. 
 
Er zijn bewust enkele details achterwege gelaten – denk aan de vraag wanneer iets precies een duplicaat is of welk technisch identifier-formaat er gebruikt dient te worden. Deze details worden uitgewerkt maar zijn, voor zover we kunnen zien, niet van belang voor de hoofdvraag in dit document. 
 
Belangrijk om te benadrukken is dat deze richtlijnen draaien om harmonisatie over informatiestandaarden heen. Het gaat niet om dwingende afspraken die losstaan van informatiestandaarden of implementatietrajecten, maar om een richtlijn bij het ontwikkelen van toekomstige (versies van) informatiestandaarden, met de mogelijkheid om beargumenteerd af te wijken als die niet voldoet. De intentie van de richtlijn is wel dat binnen informatiestandaarden zo veel mogelijk dezelfde uitgangsprincipes gaan gelden. 

De twee oplossingsrichtingen 

Oplossingsrichting 1: risicogebaseerd, met twee mogelijke regimes 
Uit een analyse door het architectuurteam van Nictiz zijn twee mogelijke regimes gekomen om informatie te identificeren: 

1. Op basis van de inhoud kan een vergelijking gemaakt worden. Dit wordt achteraf identificerengenoemd. 
2. Informatie-objecten kunnen bij uitwisseling worden voorzien van een wereldwijd unieke identifier, waarmee de vergelijking gemaakt kan worden. Dit wordt vooraf identificeren genoemd. 

Vooraf identificeren (met expliciete identifiers) wordt daarin als zwaarder beschouwd dan achteraf identificeren (door data te vergelijken). 

Daarnaast kwam uit de analyse naar voren dat het niet mogelijk en onwenselijk is om algemene afspraken over te maken over alle informatiestandaarden/usecases heen ten aanzien van eisen rond identificatie. Dit kan gebruikers onnodig belasten met identificatie-eisen die alleen voor een specifieke usecase nodig zijn. Daarnaast kunnen rigide algemene eisen maatwerk in de weg staan. Hoogover speelt ook het bezwaar dat er geen algemene afspraken te maken zijn; afspraken kunnen alleen gemaakt worden in de context van een specifieke usecase. 

Daarom leidt deze analyse tot het advies om per usecase een analyse te maken van de risico’s die ontstaan als informatie niet correct geïdentificeerd kan worden (bv. omdat informatie niet ontdubbeld kan worden). De kans óp gevaar samen met de impact ván dit gevaar bepalen vervolgens per bouwsteen of er eisen opgesteld moeten worden over identificatie. Per bouwsteen kan het resultaat dan worden: 

1. Geen eisen aan identificatie nodig 
2. Bepalen welke verplichte velden er gebruikt kunnen worden voor een inhoudgebaseerde vergelijking, en deze velden verplichten in de informatiestandaard (identificatie achteraf)
3. Eisen dat een expliciete identifier wordt toegevoegd, overgenomen door het ontvangende systeem en weer doorgestuurd bij verdere uitwisselingen. 

Oplossingsrichting 2: alles krijgt een expliciete identifier 
Hier tegenover staat een andere zienswijze. Bij uitwisselingen via HL7- en andere zorginformatiestandaarden is het triviaal om op bouwblok-niveau identifiers toe te kennen. In eerdere projecten waar identificatie een rol speelt hebben deelnemers bovendien expliciet aangegeven dat identifiers makkelijker in gebruik zijn dan vergelijkingen op basis van inhoud. 

Vanuit die optiek zou als strategie gekozen kunnen worden om vanuit informatiestandaarden altijd te eisen dat elk bouwblok een expliciete, wereldwijde unieke identifier krijgt, op technisch uniforme wijze. Net als bij oplossingsrichting 1 moet die identifier worden overgenomen door het ontvangende systeem en weer doorgestuurd worden bij verdere uitwisselingen. 

Voors en tegens 

Uniforme aanpak vs. maatwerk per usecase 
Vanuit het oogpunt van databeschikbaarheid en meervoudig gebruik is er een sterke wens om specificaties rond data uniform te hanteren over de verschillende usecases heen. Oplossingsrichting 1 kan tot gevolg hebben dat er per usecase verschillende eisen komen voor dezelfde bouwsteen ten aanzien van identificatie. In een extreem geval zou voor een bepaalde meting in de ene usecase een identifier vereist worden, terwijl er in de volgende usecase een registratiedatum vereist wordt, en er in de derde usecase helemaal geen extra vereisten zijn. Een bijkomend nadeel is dat informatie niet over usecases heen te gebruiken is. Oplossingsrichting 2 heeft deze nadelen niet. 

Uniform mechanisme vs. maatwerk per bouwsteen 
De eerste oplossingsrichting heeft verder tot gevolg dat er per bouwsteen verschillende mechanismen gehanteerd worden voor identificatie. Voor sommige bouwstenen wordt er geen identificatie verwacht. Voor andere werkt identificatie op basis van expliciete identifiers. Voor de laatste set wordt er een vergelijking op inhoud gedaan en moet per bouwsteen bepaald worden welke velden er gebruikt worden voor de vergelijking. Oplossingsrichting 2 heeft dit nadeel niet. 

Onnodige belasting met identificatie-eisen 
Niet in elke usecase is objectidentificatie nodig, of is identificatie van alle objecten nodig. De uniforme aanpak van oplossingsrichting 2 zou sommige gebruikers dus onnodig kunnen belasten met het toekennen, opslaan en ontsluiten van identifiers. Oplossingsrichting 1 heeft dit nadeel niet; identificatie-eisen worden alleen toegepast waar nodig. 

Mismatch in grenzen van datamodellen 
Binnen informatie-uitwisseling wordt doorgaans uitgegaan van zibs. In de regel zijn informatieobjecten daarom instantiaties van zibs. Daarnaast moet er rekening gehouden worden met bijvoorbeeld overdrachtsdocumenten waarin meerdere zibs gebundeld worden of andere overkoepelende concepten zoals orders of medicamenteuze behandelingen (náast identificatie op zib-niveau dus). 

De grenzen van zibs, FHIR-resources en interne datamodellen van XIS’en komen lang niet altijd goed overeen. De vulling van een zib zal soms uit meerdere databasetabellen moeten komen en kan uiteenvallen via meerdere FHIR-resources. Een enkele FHIR-resource vertegenwoordigt soms juist meerdere zibs. Hetzelfde kan gezegd worden voor de overkoepelende concepten. 

Wanneer expliciete identifiers gebruikt worden, zal een ontwikkelaar van een XIS daarom soms een mappingtabel moeten bijhouden tussen databaserijen, zib en FHIR-berichten. Bij oplossingsrichting 2 speelt dit nadeel altijd. Bij oplossingsrichting 1 hoeft dit niet het geval te zijn omdat er veel minder met expliciete identifiers gewerkt wordt. Het is echter niet uitgesloten. 

Gewenst maatwerk niet mogelijk 
De kans is groot dat er vroeg of laat usecases komen die specifieke eisen hebben aan identificatie die strijdig zijn met de eisen van andere usecases. Het is bijvoorbeeld denkbaar dat er voor DICOM-gebaseerde beelduitwisseling technische restricties aan identifiers zijn ten opzichte van FHIR-gebaseerde uitwisselingen.  

Zoals reeds beschreven in de inleiding is de richtlijn bedoeld voor harmonisatie waar mogelijk. Indien maatwerk nodig is in een specifieke situatie, blijft dat altijd mogelijk.