pa:Productarchitectuurprincipes

Doel

Verschillende producten van Nictiz (POB) worden onafhankelijk ontwikkeld wat soms leidt tot conflicterende specificaties. Doel van dit document is om schrijvers van geïntegreerde informatiestandaarden (specificaties) te helpen keuzes te maken die passen in een meer eenvormig specificatie landschap. Dit document is niet bedoeld om richting te geven aan het specificeren van logische modellen of waardelijsten. Nictiz e.a. hebben een groot aantal besluiten in het verleden genomen en een aantal principiële richtlijnen hoe nieuwe beslissingen genomen moeten worden. In dit document zullen deze voor zover mogelijk verzameld worden. Doel van dit werk is niet om nieuwe beslissingen te nemen, maar de bestaande beslissingen in context te representeren.

Structuur van de informatie

Specificatie Canvas

Voor de architectuur principes gebruiken we het specificatie canvas (https://nictiz.nl/publicaties/specificatiecanvas) als leidraad voor de structuur. Alternatief was het Nictiz vijflagen model (https://nictiz.nl/wat-we-doen/zorginformatiestelsel/interoperabiliteit/lagenmodel-3) geweest, dit model mist detail wat bijvoorbeeld het onderscheid tussen opgeslagen (verwerkte) en gecommuniceerde gegevens niet duidelijk maakt. Daarnaast mist het onderscheid tussen logische modellen en concepten.

Met de architectuur principes beschrijven we de middelste drie lagen van het specificatie canvas in detail en geeft aan hoe de onderste (infrastructuurniveau) laag betrokken kan worden. Het organisatieniveau wordt niet door Nictiz gecontroleerd en het infrastructuurniveau volgt uit de keuzes op systeem niveau.

Taal

Inleiding

Op taal en concept niveau is er door de SNOMED in gebruik bij Nederlandse zorgaanbieders grotendeels vastgelegd. Dit document geeft duidelijk richting aan wanneer er eenheid van taal op basis van SNOMED gebruikt dient te worden.

Definitie specificatie canvas

Informatiegebruikers zoals zorgaanbieders, patiënten en onderzoekers leggen hun taal vast in terminologieën en betekenismodellen. Binnen een eigen instelling, vakgroep of specialisme spreken en schrijven mensen een eigen taal. Een huisarts gebruikt een andere taal dan een internist en ook de patiënt spreekt en schrijft een eigen taal. Om te kunnen samenwerken groeit de behoefte aan een verbinding tussen de verschillende talen: een gemeenschappelijke taal of een vertaling.

Principes

Bij dit niveau horen de volgende principes;

• Gebruik bestaande concepten en waardelijsten; Rationale: door gemeenschappelijke taal te gebruiken is het mogelijk om tussen verschillende domeinen op een semantisch correcte manier gegevens te delen.
• Definieer welk deel van de dialoog geïmplementeerd wordt; gebruik hiervoor bestaande definities; voor zowel communicatie als ook verwerking. Rationale: door duidelijk te maken wat de verwachting is waarmee de gegevens opgeslagen of gedeeld worden kunnen alle partijen de correcte actie nemen.

Logisch

Inleiding

Dit document heeft niet de intentie om de principes te beschrijven die nodig zijn voor de definitie van een Logisch Model. Hiervoor is een document binnen de Nictiz beschikbaar Architectuur zibs 2.0 (Architectuur zibs 2.0 concept.docx). Dit document beschrijft het gebruik van de logische modellen.

Definitie Specificatie Canvas

Het logische niveau verbindt zorginhoud met techniek. De taal van de zorgverlener wordt hier gestructureerd voor verwerking in ICT-systemen. Het logische niveau blijft onafhankelijk van de systeemtechniek. Zo kan de techniek zich verder ontwikkelen zonder dat gebruikers hun taal daarop hoeven aan te passen.

Principes

Merk op dat dit document bedoeld is voor het gebruik van een logisch model en niet bedoeld is om richting te geven bij het definiëren van logische modellen.

Bij dit niveau horen de volgende principes:

• Informatie standaarden maken gebruik van bestaande logische modellen. Rationale: hergebruik van logische modellen leidt tot standaardisatie van gegevens en maakt hergebruik van deze gegevens voor andere doeleinden mogelijk.
• Logische modellen worden zowel voor verwerking(opslag) als ook deling gebruikt. Rationale: door opslag en deling dezelfde structuur te geven is de kans op verlies van semantiek minimaal.
• Een informatie standaard voegt geen elementen of relaties toe aan; of verruimt de kardinaliteit van elementen of relaties in een logisch model. Rationale: toevoegen van elementen zorgt ervoor dat ontvangers mogelijk de gegevens niet kunnen verwerken.
• Een informatiestandaard kan de kardinaliteit inperken voor een specifieke usecase. Rationale: bepaalde berichten of opslag kan voor een usecase alleen relevant zijn met bepaalde gegevens of relaties. Als deze optioneel zijn in het logische model, kunnen ze voor deze usecase met een specifiek minimumaantal worden opgenomen.

Systeem

Inleiding

Op systeemniveau ontstaan producten die direct implementeerbaar zijn. Op dit niveau komen de bovenliggende lagen samen en vormen deze voor een specifieke usecase een voor de zorg zinnige oplossing.

Definitie Specificatie Canvas

Systemen zoals elektronische patiëntendossiers (EPD’s), zorginformatiesystemen (XIS’en), generieke voorzieningen en apps scheiden binnen en buiten met een systeemgrens of koppelvlak. Op systeemniveau betreffen specificaties softwaresystemen en hun koppelvlakken of systeemgrenzen of API’s (application programming interfaces). De koppelvlakken specificeren wij zonder te zeggen hoe een systeem van binnen werkt (black-box principe).

Principes

• Producten (informatiestandaarden) zijn zelfstandig implementeerbaar Rationale: Een product is een verzameling van specificaties die verwijzen naar alle lagen en leveren een consistent product. Producten duiden de relatie tussen de verschillende lagen in context van een usecase.
• Voor elk product is er een usecase Rationale: Een product bestaat uit elementen uit zowel de concepten/dialogen als ook de logische modellen. Producten kunnen deze elementen niet uitbreiden, maar wel de kardinaliteit inperken. Producten lossen een specifieke usecase op.
• Producten voldoen aan technische besluiten. Rationale: Producten implementeren oplossingen en gebruiken hiervoor technische middelen. Deze middelen moeten passen bij besluiten zoals gemaakt (zoals het FHIR besluit).

Transactie Principes

Transactie (product) architectuur principes:

• Producten gebruiken (waar ze beschikbaar zijn) internationale standaarden. Rationale: leveranciers hebben typisch niet alleen te maken met de standaarden in Nederland, door internationale standaarden te gebruiken is de drempel voor een leverancier om de standaard te implementeren lager.
• Producten beschrijven geen details over de keuzes in de infrastructuur laag. Rationale: technische keuzes op de infrastructuur laag veranderen vaker en zijn in de meeste gevallen configuratie in de technische laag.

Data of verwerking Principes

Data (product) architectuur principes:

• Datastructuren zijn lang levend, aanpassingen zijn waar mogelijk toevoegingen. Rationale: Opslag is niet vluchtig zoals transacties, transformaties van structuren hebben het risico op gegevens verlies. Aanpassingen moeten zonder verlies van gegevens geconverteerd kunnen worden.
• Fysieke Dataopslag is vergevingsgezinder in het kader van ontbrekende gegevens dan transactie producten. Invoer voor usecases kan wel de kardinaliteit strenger definiëren. Rationale: De opslag moet voor meerdere usecases bruikbaar zijn en niet in alle usecases zullen alle gegevens altijd beschikbaar en/of verplicht zijn. Dat de gegevens voor de specifieke usecase verplicht zijn, betekend niet dat ze voor andere usecases ook verplicht zijn.