Metamodel Features en GBx-systeemrol profielen
Onderstaande figuur toont het gehanteerde metamodel.
Centraal concept in het metamodel is een Feature. Er zijn verschillende typen features:
Service - deze omvat een stuk functionaliteit die wordt geboden door een Aanbieder (meestal een server, soms een client) en kan worden gebruikt door een Afnemer (meestal een client, soms een server).
Abstracte Service - deze omvat een generiek wijze van verwerking, die kan worden gebruikt binnen meerdere (concrete) services, bijvoorbeeld het kunnen verwerken van een willekeurige core FHIR interactie.
Subfeature - deze omvat een bepaald onderdeel of technisch aspect dat nodig is voor een of meerdere (Abstracte) Services, bijvoorbeeld het kunnen verwerken van een bepaalde HTTP header.
Een voorbeeld van een Feature is de getRoutingInfo interactie die wordt geboden door de Adressering Server. Deze Feature maakt ondermeer gebruik van het Subfeature “AORTA-ID HTTP Request Header”.
Ieder Feature behoort tot een groep. Een groep zegt iets over de aard van de functionaliteit die wordt geleverd, bijv. Adressering.
Van eenzelfde Feature kunnen meerdere, verschillende versies bestaan. Een versie van een Feature bestaat altijd in één of meerdere VZVZ Publicaties. Een bepaalde release van een VZVZ-component ondersteunt/biedt altijd een set van versies van Features, en doet dit binnen een bepaalde context, bijvoorbeeld “AoF release 0.8”.
Wanneer een Aanbieder een Feature wil aanbieden voor gebruik door Afnemers, dan kan het zo zijn dat hiervoor, door de Aanbieder, ook andere Features geboden of gebruikt moeten worden. Dit wordt weergegeven middels het concept AanbiederDependency. Voorbeeld: om Feature AORTA Token Exchange te kunnen aanbieden, is het ook nodig om Feature AORTA transactietoken te ondersteunen, en om Feature getRoutingInfo te kunnen afnemen.
Wanneer een Afnemer een Feature wil gebruiken, dan kan het zo zijn dat het gebruik ervan ook de juiste implementatie van een ander Feature vereist. Dit wordt weergegeven middels het concept AfnemerDependency. Voorbeeld: het gebruik van Feature AORTA Token Exchange vereist voor een Afnemer ook de juiste implementatie van Feature AORTA transactietoken.
Een ander belangrijk concept is het GBx-systeemrol profiel.
Er zijn verschillende typen GBx-systeemrol profielen:
Concreet - deze levert een specifiek resultaat.
Abstract - deze omvat een generieke wijze van verwerking(en) en kan worden vereist door een of meerdere andere concrete systeemrol profielen (bijv. voor zorgtoepassingen).
Een GBx-systeemrol profiel definieert, in de vorm van Dependencies, welke Features een GBx-applicatie moet ondersteunen, om bepaalde functionaliteit, in een bepaalde context, te kunnen gebruiken of aan te bieden. Voorbeeld: om een notified pull interactie te kunnen initiëren (NP Verzendend Systeem) binnen de context van AoF 2024, moet een systeem het Feature core-FHIR-interactie-broker kunnen gebruiken, en moet het systeem zelf het Feature core-FHIR-interactie aanbieden.
Bij een Dependency van een Feature op een ander Feature, of van een GBx-systeemrol profiel op een Feature wordt, middels een conformance, aangegeven met welke range van versies (van het Feature waarop de afhankelijkheid wordt genomen) de betreffende afhankelijkheid kan worden ingevuld.
Een versie-range binnen een Dependency kan op de volgende manieren worden gespecificeerd:
Lowest applicable version - aan de afhankelijkheid wordt voldaan wanneer de laagst mogelijke (of een hogere) versie in de aangegeven versie-range wordt ondersteund. Bijvoorbeeld: “Verplicht >=1.2.3”, “Optioneel >=2.3” of “ Verplicht >=3”;
Floating version - aan de afhankelijkheid wordt pas voldaan wanneer de hoogst beschikbare versie in de aangegeven versie-range wordt ondersteund. Bijvoorbeeld: “Optioneel >=1.2.*” verwijst naar de hoogste patch binnen de 1.2 minor versie, “Verplicht >=2.*” verwijst naar de hoogste patch binnen de hoogste minor in de 2 major of “Optioneel >=*” verwijst naar de hoogst beschikbare versie.
Tevens kan in de versie-range, voor Dependencies van GBx-systeemrol profielen op Features, zijn aangegeven of de Dependency een verplichtend of een optioneel karakter heeft. Wanneer het karakter niet is vermeld in de Dependency, dan wordt het vermeld in een Programma van Eisen (PvE) dat van toepassing is.
Een (sub)feature heeft een versienummer (<major>.<minor>.<patch>), conform de semver methodiek:
het <major> nummer wordt verhoogd bij een voor clients incompatibele wijziging;
het <minor> nummer wordt verhoogd bij het toevoegen van functionaliteit die compatibel is met de vorige versie;
het <patch> nummer wordt verhoogd bij een correctie (of tekstuele aanpassing) die die compatibel is met de vorige versie.
Wanneer de specificatie van een Subfeature wordt gewijzigd, dan ontstaat een nieuwe versie van het Subfeature. Hetzelfde geldt ook voor alle Features waar het betreffende Subfeature deel van uitmaakt.