Den gode registreringspraksis for tidsafhængige data

Herunder berigtigelser, historik og revisionsspor

Formål

Denne side fastlægger de obligatoriske retningslinjer for registrering af tidsafhængige data i STAR City.

Formålet er at sikre:

Ensartet registreringspraksis på tværs af forretningsdomæner og teams
Korrekt håndtering af aktuelle, fremtidige og historiske data
Fuld sporbarhed gennem revisionshistorik
Konsistent håndtering af berigtigelser og sletninger

Retningslinjerne gælder for alle forretningsdomæner og systemer i STAR City.

Grundprincipper

Følgende principper gælder for alle tidsafhængige entiteter:

Data registreres som enten:
- aktuelle
- fremtidige
- historiske
Historiske data må ikke overskrives uden revisionsspor.
Alle ændringer skal kunne spores til:
- hvem (organisation samt medarbejder eller system, fx. batchjob eller robot) der har foretaget ændringen
- hvornår ændringen er foretaget
Fejlregistreringer håndteres som berigtigelser.
Alle ændringer på en entitet skal registreres i en revisionshistorik.

Obligatoriske regler

1. Klassifikation af data over tid

Alle tidsafhængige entiteter skal kunne klassificeres som:

Aktuelle data
Data, der er gældende pr. dags dato.
Fremtidige data
Data, der er registreret, men først bliver gældende i fremtiden.
Historiske data
Data, der tidligere har været gældende, men ikke længere er det.

2. Opdatering og berigtigelse

Der skelnes mellem:

Opdatering

Bruges til entiteter, der forretningsmæssigt må ændres.
Ændringen registreres i revisionshistorikken.

Berigtigelse

Bruges ved fejlregistreringer.
Den eksisterende registrering rettes.
Der skal registreres revisionshistorik for berigtigelsen.

Eksempel:

Afholdte samtaler opdateres ikke forretningsmæssigt.
Fejl rettes via berigtigelse.

3. Revisionshistorik (revisionslog)

Alle entiteter skal have en revisionshistorik, der gør det muligt at fremsøge tidligere versioner.

Revisionshistorikken skal indeholde:

Kopi af entitetens data
Ændringstype:
- oprettelse
- opdatering
- berigtigelse
- sletning
Bruger
Tidspunkt for ændringen

Krav ved ændringer

Ved:

Oprettelse
→ registreres en kopi af entiteten ved oprettelsen
Opdatering
→ registreres en kopi af entiteten efter opdateringen
Sletning
→ registreres en kopi af entiteten ved sletningen med markering for sletning

4. Sletning af data

4.1 Sletning af hele entiteter

Ved sletning af en entitet:

Sletningen skal registreres i revisionshistorikken.
Revisionsloggen skal indeholde en kopi af entiteten ved sletningstidspunktet med:
- markering for sletning
- bruger
- tidspunkt

4.2 Sletning af værdier på en entitet

Når en værdi på en entitet fjernes (sættes til NULL):

Behandles det som en opdatering.
Ændringen skal registreres i revisionshistorikken med kopi af entiteten efter opdateringen.

Terminologi (fælles reference)

Aktuelle data

Data, der er gældende pr. dags dato eller i fremtiden.

Eksempel:

Kontaktgruppe med startdato (inkl. tidspunkt) i fortiden
Slutdato (inkl. tidspunkt) i fremtiden eller uden slutdato (slutdato = NULL)

Fremtidige data

Data med startdato i fremtiden og slutdato i fremtiden eller NULL.

Historiske data

Data med start- og slutdato i fortiden.

Eksempler fra forretningen

Kontaktgrupper

Aktuel kontaktgruppe:
- startdato (inkl. tidspunkt) i fortiden
- uden slutdato (slutdato = NULL), forretningsmæssigt kan en kontaktgruppe ikke have en slutdato i fremtiden.
Historiske kontaktgrupper:
- start- (inkl. tidspunkt) og slutdato (inkl. tidspunkt) i fortiden

Fravær

Aktuelle fravær:
- startdato i fortiden eller dags dato
- slutdato i dags dato, fremtid eller NULL
Fremtidige fravær:
- startdato i fremtiden
Historiske fravær:
- start- og slutdato i fortiden

Samtaler

Afholdte samtaler er ikke aktuelle.
Den senest afholdte samtale er den aktuelle i forhold til borgerens aftale.

Illustration af tidsafhængige data

Beskrivelse:
Diagrammet viser, hvordan fravær bevæger sig fra fremtidige til aktuelle og derefter historiske registreringer samt tilhørende revisionshistorik.

Teknisk reference

Se også: