pa:Transactiebouwstenen

Het concept transactiebouwstenen is nog in ontwikkeling en de inhoud van deze pagina kan nog wijzigen op basis van feedback vanuit onder andere productteams en leveranciers. Onderstaande documentatie is bedoeld als richtlijn voor productteams die aan de slag gaan met het ontwikkelen van transactiebouwstenen en als instrument voor productarchitecten om de consistentie in de ontwikkeling van transactiebouwstenen te bewaken.

1 (Transactie)bouwstenen

1.1 Doelstelling van transactiebouwstenen

• Minimaliseren van variatie in de manier waarop bouwstenen worden toegepast in verschillende usecases of informatiestandaarden
• Verhogen van hergebruik van (setjes) bouwstenen
• Verhogen implementeerbaarheid van (setjes) bouwstenen
• Faciliteren incrementeel ontwikkelen en testen
• Verhogen databeschikbaarheid

1.2 Bibliotheek van transactiebouwstenen

Om dit doel te bereiken gaat Nictiz een bibliotheek van gemeenschappelijke transactiebouwstenen beheren waarmee verschillende use cases samengesteld kunnen worden.

1.3 Definitie van een transactiebouwsteen

Een transactiebouwsteen is een configuratie van een volledig informatiemodel van een klinisch concept gebaseerd op de zib, een mapping naar 1 of meerdere technische modellen en een set conformance regels. Transactiebouwstenen kunnen geimplementeerd worden in combinatie met minimaal 1 use case en zijn herbruikbaar in verschillende use cases in verschillende domeinen.

Onderstaande afbeelding is een visualisatie van een bouwsteen gebaseerd op een zib 2.0 informatiemodel inclusief een vertaling naar een nl-core FHIR profiel. De transactiebouwsteen is gebaseerd op versie X.Y.Z. van de zib en versie X.Y.Z. van de nl-core FHIR package. Systeemeisen omtrent registratie, uitwisseling, weergave en persistentie zijn gescheiden van het logische model en worden vastgelegd in een aparte "obligations" laag.

1.4 Inhoud van een transactiebouwsteen

1.4.1 Granulariteit

Een transactiebouwsteen heeft de grootte van één klinisch concept. Waar precies de grenzen liggen van een klinisch concept, is niet altijd duidelijk, en soms moet er een arbitraire afweging gemaakt worden in overleg met de verschillende stakeholders en productarchitectuurboard.

Als richtlijn geldt dat de grootte van een transactiebouwsteen wordt bepaald door de zib waar deze op gebaseerd is. Over het algemeen zal dit 1-op-1 overeenkomen, maar er zijn gevallen denkbaar waarbij meerdere zibs samenkomen in één bouwsteen. Denk aan nationaliteit en burgerlijke staat, die logischerwijs zal worden ondergebracht onder de bouwsteen Patient.

Andersom kan het voorkomen dat een enkele bouwsteen uitgewerkt wordt in meerdere technische modellen Denk hierbij bijvoorbeeld aan de zib Zorgverlener, die in FHIR vertegenwoordigd wordt met een Practitioner- en een PractitionerRole-resource.

Een vaak terugkerende discussie bij granulariteit van bouwstenen is de vraag hoe specifiek of generiek je moet zijn. Dit geldt met name voor observaties. Deze volgen vaak een algemeen patroon en voelt het als overspecificatie om ze afzonderlijk van elkaar uit te werken. Maar er zijn ook situaties waarbij er wel meer is dan een algemeen patroon, zoals een laboratoriumuitslag of een bloeddruk. Bij de keuze voor de afbakening van een bouwsteen proberen we hier pragmatisch mee om te gaan. Arbitraire keuzes zijn hierin onvermijdelijk. Deze keuzes moeten duidelijk vindbaar gedocumenteerd worden, zodat deze ook breed toegepast worden.

1.4.2 Onderdelen

Een transactiebouwsteen bestaat uit de volgende onderdelen:

• Logisch model
• Relaties met andere bouwstenen
• Zoekparameters
• Obligations
• Technische mapping
• Voorbeelden

1.4.2.1 Logisch model

De basis voor een transactiebouwsteen is een logisch model gebaseerd op de zib. In eerste instantie wordt de zib 2020 als uitgangspunt gebruikt, aangezien dit de huidige baseline is. In de toekomst zal dit mogelijk worden vervangen door de zib 2.0.

Om in deze fase tot een "volledig" logisch model te komen, dienen de volgende stappen gevolgd te worden:

1. Inventarisatie hoe de betreffende zib over alle domeinen is toegepast. Er wordt een analyse gedaan op de mogelijkheden om verschillen/uitbreidingen te harmoniseren en te generaliseren voor andere (toekomstige) usecases.
2. Analyse op soortgelijke modellering in FHIR en openEHR voor alle data-elementen die zijn toegevoegd aan de zib. Bij FHIR gaat het niet alleen om de core-spec, maar ook om populaire implementatiegidsen zoals de international patient summary, IHE MHD, eu-core, us-core, etc.
3. Model uitwerken in ART-DECOR in het project [hier naam project toevoegen]. In eerste instantie beginnen we vanuit één gemeenschappelijk project, maar dit kan later veranderen als dit niet goed blijkt te werken.
4. . Model beproeven in minimaal 3 usecases uit verschillende domeinen.

1.4.2.2 Relaties met andere bouwstenen

Uit bovenstaande analyse zou ook duidelijk moeten worden welke relaties er zijn met andere bouwstenen. Deze relaties moeten worden beschreven.

1.4.2.3 Zoekparameters

De volgende stap is uitzoeken welke zoekparameters er worden gebruikt in de verschillende domeinen/usecases. Het resultaat is een beschrijving van zoekparameters die voor deze bouwsteen minimaal ondersteund moeten worden, en/of hoe ze gebruikt moeten worden voor alle usecases.

1.4.2.4 Obligations

Systeemeisen (zoals eisen aan het systeem voor registratie, uitwisseling, weergave en verwerking) worden losgekoppeld van het informatiemodel. We beschrijven deze systeemeisen met behulp van "Obligations", gebaseerd op het Obligations Framework van FHIR.

Voorlopig starten we met een functionele uitwerking in Excel per usecase en extraheren hier een gemeenschappelijk deel uit dat voor de basisbouwsteen geldt. Voor de basisbouwsteen zijn in ieder geval de generieke actoren producer en consumer uitgewerkt. Voorbeelden van type systeemeisen zijn te vinden in de Obligation Codes-waardelijst, bv:

user-input

de mogelijkheid voor gebruikers om iets in te voeren

populate

de eis om een waarde in te vullen indien aanwezig

display

de eis om een waarde weer te geven

persist

de eis om een gegeven op te slaan

Enkel de type eisen die nu van toepassing zijn in de informatiestandaarden hoeven te worden gedefinieerd.

We hebben op het moment nog weinig ervaring met het gebruik van Obligations. Als duidelijk is of en hoe Obligations op effectieve wijze kunnen worden ingezet, zal hier ook ondersteuning voor in ART-DECOR moeten komen.

1.4.2.5 Technische mapping

Onderdeel van de transactiebouwsteen is de technische mapping naar FHIR. We gaan daarbij uit van de huidige baseline en mappen op de profielen uit het FHIR R4 nl-core package. Op het moment gebruiken we hiervoor een handmatig opgestelde ConceptMap.

Mochten elementen niet gemapt kunnen worden, dan wordt een voorstel gedaan voor uitbreiding van het nl-core-profiel.

Op termijn moet deze mapping in ART-DECOR ondersteund worden.

Let op: usecase-specifieke constraints komen niet in de bouwsteen, maar worden uiteindelijk op usecase-niveau gedefinieerd in usecase-specifieke profielen.

1.4.2.6 Voorbeelden

De volgende voorbeelden worden minimaal uitgewerkt in ADA (let op: voorwaarde is dat ADA is ingericht op het ART-DECOR-project waarin we gaan werken):

• 3 realistische voorbeelden (1 per use case)
• minimaal 1 maximaal gevuld voorbeeld

Deze voorbeelden worden (handmatig of - bij voorkeur - direct via XSLT) vertaald naar FHIR.

1.5 Kaders voor toepassing van een bestaande transactiebouwsteen

Iedere transactiebouwsteen krijgt een productteam als functioneel beheerder. Deze functioneel beheerder heeft als taak om de requirements van alle usecases voor de bouwsteen te accommoderen.

Bij het toepassen van een transactiebouwsteen in een specifieke usecase of informatiestandaard is het niet verplicht alle elementen te gebruiken (mits er vanuit de bouwsteen geen verplichting op zit), maar mogen geen elementen toegevoegd worden.

Indien een transactiebouwsteen onvoldoende toereikend is voor toepassing in een specifieke usecase of informatiestandaard dient hiervoor een wijzigingsverzoek te worden ingediend bij het team dat deze bouwsteen beheeft. Hiervoor zal een beheerproces ingericht worden.

1.5.1 Usecases

Een usecase kan samengesteld worden uit 1 of meerdere bouwstenen. De volgende regels gelden wanneer een bouwsteen op usecase-niveau wordt toegepast:

• Een usecase zal ieder verplicht element uit een bouwsteen gebruiken (SHALL)
• Een usecase zal conformeren aan de constraints en obligations gedefinieerd in een bouwsteen (SHALL)
• Een usecase mag optionele elementen uit een bouwsteen gebruiken (MAY)
• Een usecase mag geen nieuwe elementen aan een bouwsteen toevoegen (SHALL NOT)
• Een usecase mag striktere constraints en obligations definiëren in bouwstenen (MAY) mits hier een goede onderbouwde reden toe is