QAReviewChecklist: verschil tussen versies

Uit Zorginformatiebouwstenen
Naar navigatie springen Naar zoeken springen
Geen bewerkingssamenvatting
Regel 1: Regel 1:
=Checklist: Zorgverlener Review ZIB=
# Inhoudelijke check extra/gewijzigde/wegvallen velden of extra/gewijzigde waarden.
# Worden de gegevenselement namen en omschrijvingen herkend door de Zorgverelener.
# Hoe zit de ZIB in de systemen/processen die de Zorgverlener gebruikt.
=Checklist: Architectuur QA Review ZIB=
=Checklist: Architectuur QA Review ZIB=
Het gaat hier om waar we inhoudelijk naar te kijken als Architect.<br/>
Het gaat hier om waar we inhoudelijk naar te kijken als Architect.<br/>
We mogen ervan uitgaan dat (medisch) inhoudelijke review al is geweest.<br/>
We mogen ervan uitgaan dat (medisch) inhoudelijke review al is geweest.<br/>
Regel 41: Regel 45:
# Is het in de naam duidelijk dat het een Sub-ZIB is? (e.g. door namespace nl.zorg.part te gebruiken)
# Is het in de naam duidelijk dat het een Sub-ZIB is? (e.g. door namespace nl.zorg.part te gebruiken)


==Ter inspiratie==
=Checklist: Model Review ZIB=
''tbd''
# Metadata
# "Lite" hoofdstukken gevuld
# Informatiemodel
## 1 rootconcept
## Geen loshangende concepten
## Alle gegevenselementen...
### hebben een ZIB datatype
### hebben een definitie
## ...
 
=Ter inspiratie=
Stan Huff Requirements for good models:
Stan Huff Requirements for good models:
# Accurate – corresponds to the real world
# Accurate – corresponds to the real world

Versie van 7 apr 2017 11:17

Checklist: Zorgverlener Review ZIB

  1. Inhoudelijke check extra/gewijzigde/wegvallen velden of extra/gewijzigde waarden.
  2. Worden de gegevenselement namen en omschrijvingen herkend door de Zorgverelener.
  3. Hoe zit de ZIB in de systemen/processen die de Zorgverlener gebruikt.

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.

  1. De eerste zin zou als vervanging kunnen dienen voor het element naam in een zin als korte omschrijving
  2. Moet extra richting geven aan het gebruik bovenop de naam en korte omschrijving
  3. Als het niet voor de hand liggend is moet uitgelegd waarom een element nodig is
  4. Zijn de teksten consistent
  5. Voorbeelden moeten in DCM::ExampleValue
  6. Voor de inhoudsdeskundige architect: Kloppen de definities van de elementen

Model en Elementen

Klopt het model; dwz:

  1. Zijn overal (de juiste) datatypen gebruikt
  2. Check de kardinaliteit
  3. Heeft het minimale model betekenis? Dus laat alle elementen weg met kardinaliteit 0..?
  4. Als er een verwijzing (reference) is, wijst die dan naar het rootconcept van de andere ZIB?
  5. 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

  1. "Hangt" de Constraint aan het betreffende Element

Examples

  1. Klopt het voorbeeld; Is het consistent met het model en is het duidelijk?`

Overige

  1. Is het echt een aparte bouwsteen waardig
  2. Is er al een bouwsteen waar we het concept in kwijt kunnen?
  3. Is er overlap met andere bouwstenen
  4. (geen verwijzing waar die er wel zou moeten zijn)
  5. Overige bevindingen, adviezen

Sub-ZIB (complexere data-types, part)

  1. In tegenstelling tot een volledige ZIB, zijn de Concept en Example hoofdstukken ingevuld
  2. Is het in de naam duidelijk dat het een Sub-ZIB is? (e.g. door namespace nl.zorg.part te gebruiken)

Checklist: Model Review ZIB

tbd

  1. Metadata
  2. "Lite" hoofdstukken gevuld
  3. Informatiemodel
    1. 1 rootconcept
    2. Geen loshangende concepten
    3. Alle gegevenselementen...
      1. hebben een ZIB datatype
      2. hebben een definitie
    4. ...

Ter inspiratie

Stan Huff Requirements for good models:

  1. Accurate – corresponds to the real world
  2. Unambiguous – only one meaning
  3. Understandable - People recognize the real world referent(s)
  4. Reproducible - Different modelers would model in the same way
  5. Parsimonious and harmonious use of terminology - Semantics of the model and terminology match
  6. Flexible - Evolve gracefully over time
  7. Consistent across domains – Specimen Collection and I&O Charting
  8. Practical – implementable in real systems
  9. Minimally complex – cover only what is needed
  10. Common queries are easy
  11. Fits with available technology (OO languages)

http://wiki.hl7.org/index.php?title=DSTU_QA_Guidelines