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.

(Transactie)bouwstenen

Doelstelling van transactiebouwstenen

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

Bibliotheek van transactiebouwstenen

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

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.

Inhoud van een transactiebouwsteen

Granulariteit

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 in sommige gevallen zal het noodzakelijk zijn meerdere zibs samen te voegen tot 1 bouwsteen. Denk bijvoorbeeld aan nationaliteit, welke logischerwijs zal worden ondergebracht onder de bouwsteen Patient. Daarnaast kan het ook voorkomen dat in een bouwsteen onderliggend meerdere technische modellen nodig zijn voor een volledige technische mapping van het concept. Denk hierbij bijvoorbeeld aan de zib Zorgverlener. Bij generieke patronen moeten we pragmatisch zijn in onze keuzes. Denk bijvoorbeeld aan een lab observatie waarvoor specifieke duiding nodig is versus een generiek observatiepatroon voor eenvoudigere observaties die op dezelfde wijze geimplementeerd kunnen worden. Soms zijn arbitraire keuzes hierin onvermijdelijk.

Onderdelen

Een transactiebouwsteen bestaat uit de volgende onderdelen:

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

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. Analyse hoe de betreffende zib over alle domeinen is toegepast en waar nodig harmoniseren 2. Analyse op soortgelijke modellering in FHIR en openEHR voor alle data elementen die zijn toegevoegd aan de zib 3. Model uitwerken in art-decor in het project [hier naam project toevoegen] (in eerste instantie beginnen we vanuit 1 gemeenschappelijk project, later zou dit indien gewenst eventueel anders ingedeeld kunnen worden, bijvoorbeeld per team of categorie) 4. Model beproeven in minimaal 3 use cases uit verschillende domeinen

Relaties met andere bouwstenen

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

Zoekparameters

De volgende stap is uitzoeken welke zoekparameters er worden gebruikt in de verschillende domeinen/use cases. Het resultaat is een beschrijving van zoekparameters die voor deze bouwsteen minimaal ondersteund moeten worden.

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. We starten met een functionele uitwerking in Excel per use case en extraheren hier een gemeenschappelijk deel uit dat voor de basis bouwsteen geldt. Voor de basis bouwsteen zijn in ieder geval de "generieke" actoren producer en consumer uitgewerkt. Voorbeelden van type systeemeisen zijn user-input, populate, display en persist. Enkel de type eisen die nu van toepassing zijn in de informatiestandaarden hoeven te worden gedefinieerd. Zodra duidelijk is of en hoe Obligations op effectieve wijze kunnen worden ingezet, zal hier ook ondersteuning voor in art-decor moeten komen.

Technische mapping

We starten met een technische mapping naar FHIR. Voor nu doen we dit handmatig in een ConceptMap. Uiteindelijk moet dit in art-decor ondersteund worden. We gaan uit van de huidige baseline, FHIR R4 en mappen waar mogelijk op de profielen uit het FHIR R4 nl-core package. Mochten elementen niet gemapt kunnen worden dan wordt gekeken naar FHIR core en/of een voorstel gedaan voor een extensie. Let op: use-case specifieke constraints komen niet in de basis bouwsteen, maar worden uiteindelijk op use case niveau gedefinieerd in use-case specifieke profielen voor validatie doeleinden.

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)
• 1 maximaal gevuld voorbeeld

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

Kaders voor toepassing van een bestaande transactiebouwsteen

Iedere transactiebouwsteen krijgt een productteam als eigenaar. Bij het toepassen van een transactiebouwsteen in een specifieke use case 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 use case of informatiestandaard dient dit te worden afgestemd met het team dat eigenaar is van deze bouwsteen. Hiervoor zal een beheerproces ingericht worden.

Use cases

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

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