QAReviewChecklist: verschil tussen versies
k (→Checklist: Architectuur QA Review ZIB.) |
(→Checklist: Architectuur QA Review ZIB) |
||
| Regel 1: | Regel 1: | ||
=Checklist: Architectuur QA Review ZIB= | =Checklist: Architectuur QA Review ZIB= | ||
| − | + | Het gaat hier om waar we inhoudelijk naar te kijken als Architect.<br/> | |
| − | We mogen | + | We mogen ervan uitgaan dat (medisch) inhoudelijke review al is geweest.<br/> |
'''N.B. Het gaat hier om de (technische) methodologische controle van de ZIB.''' | '''N.B. Het gaat hier om de (technische) methodologische controle van de ZIB.''' | ||
| Regel 12: | Regel 12: | ||
==Model en Elementen== | ==Model en Elementen== | ||
Klopt het model; dwz: | Klopt het model; dwz: | ||
| + | # Zijn overal (de juiste) datatypen gebruikt | ||
# Check de kardinaliteit | # Check de kardinaliteit | ||
# Als er een verwijzing (reference) is, wijst die dan naar het rootconcept van de andere ZIB? | # Als er een verwijzing (reference) is, wijst die dan naar het rootconcept van de andere ZIB? | ||
| Regel 19: | Regel 20: | ||
==Constraints== | ==Constraints== | ||
| + | # "Hangt" de Constraint aan het betreffende Element | ||
==Examples== | ==Examples== | ||
| − | # Klopt het voorbeeld; Is het consistent | + | # Klopt het voorbeeld; Is het consistent met het model en is het duidelijk?` |
==Overige== | ==Overige== | ||
# Is het echt een aparte bouwsteen waardig | # Is het echt een aparte bouwsteen waardig | ||
| − | # | + | # Is er al een bouwsteen waar we het concept in kwijt kunnen? |
# Is er overlap met andere bouwstenen | # Is er overlap met andere bouwstenen | ||
# (geen verwijzing waar die er wel zou moeten zijn) | # (geen verwijzing waar die er wel zou moeten zijn) | ||
# Overige bevindingen, adviezen | # Overige bevindingen, adviezen | ||
| + | ==Sub-ZIB (complexere data-types)== | ||
| + | # In tegenstelling tot een volledige ZIB, zijn de Concept en Example hoofdstukken ingevuld | ||
| + | # Is het in de naam duidelijk dat het een Sub-ZIB is? (e.g. door namespace nl.zorg.generic te gebruiken) | ||
==Ter inspiratie== | ==Ter inspiratie== | ||
Versie van 15 mrt 2017 om 11:15
Inhoud
Checklist: Architectuur QA Review ZIB
Het gaat hier om waar we inhoudelijk naar te kijken als Architect.
We mogen ervan uitgaan dat (medisch) inhoudelijke review al is geweest.
N.B. Het gaat hier om de (technische) methodologische controle van de ZIB.
Definities
Dit geld voor alle tekstuele definities, dus van het hoofdstuk "Concept", maar ook van de tekstuele toelichtingen bij het model en de elementen en de waardelijsten en waarden.
- Zijn de teksten consistent
- Voor de inhoudsdeskundige architect: Kloppen de definities van de elementen
Model en Elementen
Klopt het model; dwz:
- Zijn overal (de juiste) datatypen gebruikt
- Check de kardinaliteit
- Als er een verwijzing (reference) is, wijst die dan naar het rootconcept van de andere ZIB?
- Als er een verwijzing in zit moet er gecontroleerd worden of die in een ZIB zit en niet in beide (heen en weer). De verwijzing wordt doorgaans toegevoegd op de ZIB die "later" wordt gemaakt. Dus e.g. een Verrichting wordt meestal gedaan nav een Probleem en niet andersom. Een Verrichting kan dan een verwijzing hebben naar een Probleem.
Waardelijsten (ValueSets)
Constraints
- "Hangt" de Constraint aan het betreffende Element
Examples
- Klopt het voorbeeld; Is het consistent met het model en is het duidelijk?`
Overige
- Is het echt een aparte bouwsteen waardig
- Is er al een bouwsteen waar we het concept in kwijt kunnen?
- Is er overlap met andere bouwstenen
- (geen verwijzing waar die er wel zou moeten zijn)
- Overige bevindingen, adviezen
Sub-ZIB (complexere data-types)
- In tegenstelling tot een volledige ZIB, zijn de Concept en Example hoofdstukken ingevuld
- Is het in de naam duidelijk dat het een Sub-ZIB is? (e.g. door namespace nl.zorg.generic te gebruiken)
Ter inspiratie
Stan Huff Requirements for good models:
- Accurate – corresponds to the real world
- Unambiguous – only one meaning
- Understandable - People recognize the real world referent(s)
- Reproducible - Different modelers would model in the same way
- Parsimonious and harmonious use of terminology - Semantics of the model and terminology match
- Flexible - Evolve gracefully over time
- Consistent across domains – Specimen Collection and I&O Charting
- Practical – implementable in real systems
- Minimally complex – cover only what is needed
- Common queries are easy
- Fits with available technology (OO languages)
