ZIB ProcessPatterns

---

Inleiding

Zibs modelleren de informatie van klinische concepten. Ze beschrijven die elementen van het klinisch concept die voor vrijwel alle usecases relevant zijn.
Bij het gebruikt van zibs in met name informatiestandaarden ontstaat vaak de behoefte om additionele informatie toe te voegen die op zich niet een aspect van het klinisch concept beschrijven maar veeleer onderdeel zijn van het (vaak meer administratieve of logistieke) proces waarin het klinische concept in de usecase, die de informatiestandaard beschrijft, wordt toegepast.
Al vanaf het ontstaan van de zibs is de relevantie van deze informatie erkend.
In zib publicatie 2015 is daartoe de zib BasisElementen geïntroduceerd. De bedoeling van deze zib was om expliciet te maken dat er naast de elementen die in een zib gemodelleerd worden, een aantal elementen aan de orde is dat verondersteld wordt in iedere zib aanwezig te zijn. Vóór publicatie 2015 was deze veronderstelling impliciet.
De BasisElementen werden als generieke zib-elementen gepositioneerd, waarbij onvoldoende het onderscheid tussen klinische informatie en proces gebonden informatie werd benoemd.

Het expliciteren van de BasisElementen leidde daardoor tot veel vragen en zelfs tot verwarring.
De toepasbaarheid van de basiselementen was namelijk niet voor alle zibs even straight forward, soms waren vergelijkbare elementen al in de zibs aanwezig, en bovendien werden niet alle beschreven (meer technische) elementen meer als klinisch relevant gezien.

Daarom is de zib BasisElementen in publicatie 2020 komen te vervallen, waarbij de elementen die in de vervallen zib beschreven waren, uitsluitend daar waar het klinisch relevant was via het indienen van wijzigingsvoorstellen aan de afzonderlijke zibs konden worden toegevoegd.
Dit was aanleiding voor een groot aantal issues waarin werd voorgesteld vrijwel alle basiselementen aan een zib toe te voegen, zonder dat daarbij een duidelijke usecase benoemd werd.
Bovendien werd hiermee nog steeds geen oplossing geboden aan de behoefte om andersoortige informatie toe te voegen.

Verantwoording

Veel van de issues zijn terug te leiden tot een verschil in informatiebehoefte vanuit de informatiestandaarden enerzijds en de informatie die een zib modelleert anderzijds. Vanuit een EPD- of gegevensuitwisseling perspectief wordt de zib vaak gebruikt als het model van vastgelegde informatie of zelfs het model van een (deel van een) van een EPD record, terwijl de zib ‘slechts’ de informatie aspecten van het klinisch concept beschrijft en geen aspecten van b.v. het vastleggen van de informatie. Op conceptueel niveau is het vastleggen van de informatie geen noodzakelijke voorwaarde voor het bestaan van de informatie.
Een patiënt kan een aandoening hebben en de informatie daarover kan bestaan en gedefinieerd worden zonder dat deze informatie in enig EPD vastgelegd is. Dit verschil van benadering wordt wellicht het beste geïllustreerd door de veel voorkomende vraag om (generiek) een auteur toe te voegen, bijvoorbeeld aan de zib Probleem. Een (gezondheids)klacht van een patiënt bestaat op zich en kent geen auteur. De auteur is alleen relevant bij de vastlegging in een EPD en zal dus ook per vastlegging verschillen. Het is dus geen onderdeel van het concept, maar van het registratie proces. Voor een diagnose kan men echter wel een diagnosesteller benoemen, omdat de diagnose i.t.t een klacht door de zorgverlener op grond van een diagnostisch proces gesteld is en dus onlosmakelijk aan het concept Diagnose gekoppeld is. Daarnaast kan een vastgelegde diagnose vanzelfsprekend ook een auteur (die het in het dossier vastlegt) hebben. Omdat dit in veel gevallen dezelfde persoon is, wordt het verschil in rol om pragmatische reden vaak niet benoemd.
Bovenstaand voorbeeld brengt tevens naar voren dat een dergelijk generiek element onduidelijkheid over de betekenis introduceert, omdat het in meerdere contexten gebruikt wordt.

Procespatronen

Omdat voor informatie die in een EPD vastgelegd wordt, gegevens uit het registratieproces wel tot de informatiebehoefte behoren, zal het bovengenoemde geschil in benadering blijven leiden tot veel onduidelijkheid en daarmee tot veel discussie.
Dit is alleen op te lossen door te (h)erkennen dat het om verschillende soorten informatie gaat, dat aan beide behoefte is. Voor al deze informatie is een informatiemodel dus belangrijk, voor proces gebonden informatie evenzeer als voor klinische concepten. Door de proces gebonden informatie separaat te modelleren hoeft dat slechts éénmalig te gebeuren en wordt ook op dit vlak standaardisatie bewerkstelligd.

De voordelen van procespatronen boven een generieke set elementen (zoals de basiselementen) zijn evident:

• Procespatronen worden per definitie niet van toepassing verklaard op iedere zib in iedere usecase.

Het is aan de informatiestandaard om dat te bepalen. In de zib kan eventueel wel aangegeven worden of het procespatroon toepasbaar is.

• Omdat de gegevens expliciet gedefinieerd zijn als procesgegevens, wordt de al dan niet bestaande overlap met bestaande elementen in de zibs duidelijker, b.v. een voorschrijver is geen overlap met auteur, omdat de rollen uit verschillende processen komen. De definitie van de concepten worden hiermee ook minder ambigue. Als informatiestandaarden om moverende redenen de twee rollen willen samennemen, is dat aan de informatiestandaard. De zib blijft echter zo wel conceptueel zuiver.
• Omdat procespatronen per proces bepaald worden, ontstaat flexibiliteit: er kunnen meerdere procespatronen gedefinieerd worden, b.v. voor het registratie proces, voor het aanvraag proces, etc.

Praktische uitwerking

De procespatronen zullen voor het overgrote deel in de praktische uitwerking de zibs volgen:

• De vorm waarin de patronen gemaakt en gepubliceerd worden, zal zo veel mogelijk vergelijkbaar zijn met het zib formaat.
• De patronen zullen net als zibs versies hebben. In (pre-)publicaties zal vermeld worden welke versies tot een (pre-)publicatie behoren (eveneens net als bij zibs). Patronen zijn dus onderdeel van de (pre-)publicaties.

Zij worden dus ook vermeld op de publicatie-landingspagina als aparte groep (zoals subzibs in een aparte groep vermeld zijn).

• Procespatronen worden onder dezelfde voorwaarden als de zibs naar Art-Decor geëxporteerd.
• In de informatiestandaarden komen de zibs en de procespatronen samen. De usecase die aan de informatiestandaard ten grondslag ligt, is onderdeel van een proces. Dit proces bepaalt welke informatie naast de elementen van het klinisch concept gewenst zijn. Hiertoe worden de elementen uit het bijbehorende procespatroon toegevoegd aan de betreffende zib. Hiermee is het samenstellen van de informatiestandaard meer en meer het samenvoegen van gestandaardiseerde bouwstenen en –steentjes
• Het in de informatiestandaarden toevoegen van de patronen aan een zib komt neer op het toevoegen op zib rootconcept niveau van een container met de procespatroon elementen.
• Toevoegen van patronen heeft impact op de technische artefacten (CDA, FHIR), maar niet meer dan het toevoegen van die elementen in een individuele zib. In ieder geval zal het gebruik van patronen ervoor zorgdragen dat dit op een gestandaardiseerde wijze gebeurt.

Aangezien zowel CDA als FHIR meer over te dragen EPD-record fragmenten modelleren dan puur klinische concepten, komen de elementen uit de patronen vaak al native voor in de templates en resources.

• Hoewel procespatronen gemodelleerd worden als zibs, is het zelfstandig gebruik van deze procespatronen niet de bedoeling en weinig zinvol: registratiegegevens zonder een object van registratie.

Opmerkingen

• Procespatronen beschrijven proces gebonden informatie. Het zijn geen modellen van processen met hun processtappen.
• Informatie in een procespatroon kan wel degelijk klinisch relevant zijn, net zoals het proces waarmee het verbonden is, klinisch relevant kan zijn.
• Sommige zibs modelleren een klinische activiteit, zoals de zib Verrichting. Deze klinische activiteiten zijn niet de focus van de procespatronen, die vaak een meer administratieve of logistieke nadruk hebben