pa:VDraft Toetsingscriteria
|
|
Aan deze pagina wordt momenteel gewerkt. |
Doel
Doel van de toetsingscriteria is het bieden van duidelijke kaders waar informatieproducten van Nictiz aan verwacht worden te voldoen.
Structuur
De toetsingscriteria zijn ontwerpregels die een concrete uitwerking vormen van de overkoepelende productarchitectuurprincipes. Deze ontwerpregels zijn afgeleid uit bestaande richtlijnen binnen en buiten Nictiz en vervolgens georganiseerd met de productarchitectuurprincipes als kapstok. De toetsingscriteria kennen een onderverdeling in verplichte ontwerpregels en aanbevelingen.
Meer informatie over de productarchitectuurprincipes is op een aparte pagina te vinden.
Taal
Principe 1.1:
- 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.
| Item | Level | Beschrijving | Bron |
|---|---|---|---|
| 1.1.1 | MUST | Waardelijsten in informatiestandaarden zijn gelijk aan de corresponderende waardelijsten in de zibs of zijn een inperking hiervan, maar geen uitbreiding. Uitzonderingen:
|
Waardelijsten in informatiestandaarden |
| 1.1.2 | MUST NOT | Informatiestandaarden voegen geen waardelijsten toe naast de in de zib gespecificeerde waardelijsten. | Waardelijsten in informatiestandaarden |
| 1.1.3 | MUST | Indien er aanpassingen nodig zijn in waardelijsten van de zib verloopt dat via de afgesproken governance. | Beheerproces van zibs |
| 1.1.4 | SHOULD | Indien een waardelijst in een informatiestandaard minder waarden bevat dan in de zib, dan beschrijft de informatiestandaard hoe geborgd wordt dat alleen de ingeperkte lijst wordt verwerkt en/of gedeeld. | Waardelijst in informatiestandaard |
| 1.1.5 | SHOULD | Er is een verplichting opgenomen voor systemen voor het meesturen van een weergavenaam bij terminologiecoderingen, tenzij er een andere werkwijze gehanteerd wordt als oplossing voor het gebruik van verschillende versies van codestelsels door systemen. | Advies Dynamische waardelijsten |
Toetsingscriteria terminologiekoppelingen
Nog toe te voegen
Principe 1.2:
- 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.
Toetsingscriteria
Nog in ontwikkeling
Logisch
Principe 2.1:
- Informatiestandaarden 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.
| Item | Level | Beschrijving | Bron |
|---|---|---|---|
| 2.1.1 | MUST | Datasets van informatiestandaarden zijn opgebouwd uit zibs. |
QA Instructie opstellen dataset |
| 2.1.2 | MUST | De vigerende versies van zibs conform het stelselbesluit worden toegepast. Uitzondering:
|
FHIR-besluit 2022 Interne memo Gebruik pre-adopts zib 2024 |
| 2.1.3 | MUST | Indien er geen geschikte zib is, wordt gebruik gemaakt van een ander bestaand informatiemodel indien beschikbaar, bijvoorbeeld uit datasets van andere informatiestandaarden of een internationaal model (bestaande DCM/CIM, een openEHR archetype of een FHIR Resource/Profile). | QA Instructie opstellen dataset Intern document Architectuurprincipes zibs 2.0 |
| 2.1.4 | MUST | Indien er geen geschikt bestaand informatiemodel is, worden relevante beschikbare ontwerppatronen en spelregels gevolgd uit internationale literatuur (zoals de HL7 CIMI style guide en openEHR editorial style guide) voor het opstellen van een nieuw informatiemodel. | Intern document Architectuurprincipes zibs 2.0 |
| 2.1.5 | SHOULD | Bij een functionele behoefte gerelateerd aan objectidentificatie, wordt voortgebouwd op eerdere inzichten. | Documenten project Objectidentificatie NICTIZ-34076 |
Principe 2:
- 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.
Toetsingscriteria
Nog in ontwikkeling
Principe 3:
- Een informatiestandaard 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.
| Item | Level | Beschrijving | Bron |
|---|---|---|---|
| 2.3.1 | MUST NOT | Een informatiestandaard voegt geen elementen of relaties toe aan een zib. | |
| 2.3.2 | MUST NOT | De kardinaliteit van elementen of relaties in een zib wordt niet verruimd in een informatiestandaard. | Wiki-pagina zibs en kardinaliteiten |
| 2.3.3 | MUST | Indien er aanpassingen nodig zijn in de zib verloopt dat via de afgesproken governance. | Beheerproces van zibs |
Principe 4:
- 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.
| Item | Level | Beschrijving | Bron |
|---|---|---|---|
| 2.4.1 | MAY | Een informatiestandaard kan de kardinaliteit van een zib inperken op basis van de informatiebehoefte in een usecase. | QA Instructie opstellen dataset Wiki-pagina zibs en kardinaliteiten |
Systeem
Principe 3.1:
- 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.
| 3.1.1 | De technische specificatie is gebaseerd op het functioneel ontwerp. | Nictiz FHIR Profiling Guidelines R4 |
| 3.1.2 | Elk data-element in het FO is gemapt naar FHIR. Het gaat hierbij om datasetconcepten met een data-definitie. Groeperende datasetconcepten hebben mogelijk geen mapping. |
" " |
| 3.1.3 | Alle verplichtingen en verwachtingen vanuit het FO zijn uitgewerkt in een profiel of in een tekst. | " " |
Principe 3.2:
- 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.
| 3.2.1 | De informatiestandaard lost één of meerdere usecases op. | QA Instructie opstellen dataset |
Principe 3.3:
- 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).
| 3.3.1 | De vigerende versies van FHIR conform het stelselbesluit worden toegepast. Zo niet, dan verloopt de overstap volgens de opgestelde migratieplannen. |
FHIR-besluit 2022 |
| 3.3.2 | De generieke profielen in het nl-core-package zijn gebruikt, direct of als basis voor usecase-specifieke profielen. | Nictiz FHIR Profiling Guidelines R4 |
| 3.3.3 | Indien een informatiestandaard specifieke profielen, transacties, eigen concepten etc. publiceert, zijn deze afgeleid op de relevante nl-core-profielen. | " " |
| 3.3.4 | Informatiestandaard-specifieke profielen zijn ingericht op het specifieke doel en niet op de generieke uitwisseling. | " " |
| 3.3.5 | Uitbreidingen aan de profielen in het kader van een informatiestandaard zijn aangemeld voor opname in het nl-core-package (tenzij ze echt niet generiek toepasbaar zijn). | " " |
Transactie
Principe 4.1:
- 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.
| 4.1.1 | FHIR wordt zuiver toegepast (met andere woorden: de instance heeft dezelfde betekenis zonder dat het profiel bekend is). | https://hl7.org/fhir/resource.html#profile-tags |
| 4.1.2 | Bij het maken van profielen of andere conformance resources worden de FHIR profiling guidelines gevolgd. | Nictiz FHIR Profiling Guidelines R4 |
| 4.1.3 | Profielen zijn gebaseerd of zijn compatibel met zib, nl-core, eu-core en indien relevant met IG's die als de facto standaard gelden (denk aan de IPS FHIR IG, IHE MHD, Structured Data Capture, mCode) | " " |
| 4.1.4 | Beschreven uitwisselpatronen en queries zijn gebaseerd of zijn compatibel met IG's die als als de facto standaard gelden (denk aan IHE MHD, mCode). | " " |
| 4.1.5 | Custom extensies worden vermeden wanneer FHIR core al een aanpak heeft om het concept te vertegenwoordigen. | " " |
Principe 4.2:
- 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.
Toetsingscriteria
Nog in ontwikkeling
Data of verwerking
Principe 5.1:
- 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.
| 5.1.1 | Indien er overlap is tussen informatiestandaarden in bepaalde (groepen) van gegevens (bijvoorbeeld medicatiegegevens), is de informatiestandaard zo ontworpen dat er geen tegenstrijdigheden ontstaan (o.a. ten aanzien van informatiemodellen, coderingen (waardelijsten) en technische representatie) | Stelselcriteria A4 Compatibiliteit |
Principe 5.2:
- 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.
Toetsingscriteria
Nog in ontwikkeling
