Den gode historik
Introduktion
Denne side er lavet med henblik på at skabe en fælles to-go reference for historik og de terminologier, som benyttes i STAR City. Det værende sig de terminologier og principper, som er gældende i alle forretningsdomæner og systemsiloer.
For yderligere forretningsmæssig information i forhold til historik henvises til PersonHistoryService.
Terminologier (fælles to-go reference)
Aktuelle data (aktuelle entiteter)
Det værende sig data (entiteter), der pr. dags dato er gældende for borgeren samt eventuelle data (entiteter), der kan blive gældende i fremtiden.
Eksempler:
Kontaktgrupper, hvor vi arbejder med følgende begreber:
Aktuel kontaktgruppe, hvor der er tale om den kontaktgruppe, som er gældende pr. dags dato (inklusiv aktuelt tidspunkt). Det værende sig den kontaktgruppe, hvor tidsstemplet for startdatoen er fortidig. Samtidig skal tidsstemplet for slutdatoen være fremtidig eller uregistreret (lig NULL).
Seneste kontaktgruppe, hvor der er tale om den aktuelle kontaktgruppe, hvis borgeren har en aktuel kontaktgruppe. Har borgeren ikke en aktuel kontaktgruppe, så er der tale om den kontaktgruppe, som borgeren seneste har befundet sig i, altså den kontaktgruppe med seneste tidsstempel i slutdatoen.
Fravær, hvor vi arbejder med følgende begreber:
Aktuelle fravær, hvor der er tale om de fravær, som pr. dags dato er aktive. Det værende sig fravær, hvor startdatoen (uden tidsstempel) er lig dags dato eller er fortidig samtidig med, at slutdatoen (uden tidsstempel) er uregistreret (lig NULL), er lig dags dato eller fremtidig. Bemærk, at fravær altid er gældende hele dagen, hvor det slutter.
Fremtidige fravær, hvor der er tale om de fravær, som er aktive og vil starte i fremtiden. Det værende sig fravær, hvor startdatoen (uden tidsstempel) er fremtidig samtidig med, at slutdatoen (uden tidsstempel) er uregistreret (lig NULL) eller er fremtidig. Bemærk, at fravær altid er gældende hele dagen, hvor det slutter.
Afholdte samtaler, afholdte samtaler er pr. definition ikke aktuelle, da de registreres efter afholdelsestidspunktet. Den senest afholdte samtale af en given samtaletype er den aktuelle i forhold til aftale med borger.
Historiske data (historiske entiteter)
Det værende sig data (entiteter), der tidligere har været gældende for en borger. Typisk vil det være data (entitieter), hvor slutdato, afholdelsestidpunkt m.m. er fortidig i forhold til dags dato.
Eksempler:
Kontaktgrupper, hvor det er kontaktforløbet, som borgeren har været igennem frem til aktuelle kontaktgruppe. Det værende sig de kontaktgrupper, hvor tidsstemplet for både startdatoen og slutdatoen er fortidige i forhold til dags dato (inklusiv aktuelt tidspunkt).
Fravær, hvor det er alle de fravær, som borgeren tidligere har haft. Det værende sig de fravær, hvor både startdatoen og slutdatoen er fortidige.
Afholdte samtaler, afholdte samtaler er pr. definition ikke aktuelle, da de registreres efter afholdelsen. Afholdte samtaler af en given type, der ligger før den seneste samtale af samme type, betragtes som historiske data.
Berigtigelser
Nogle dataentiteter registreres altid bagud i tiden og vil dermed betegnes som værende historiske data, eksempelvis afholdte samtaler. Til sådanne dataentititer vil der typisk ikke være behov for at lave opdateringer med mindre, der er tale om, at registreringer blev oprettet ved en fejl eller er fejlbehæftede. Når dette er tilfældet kan registreringerne berigtiges med kommentar herom, hvilket vil ske gennem en opdatering af registreringen. Der skal laves revisionshistorik i forbindelse med berigtigelser.
Revisionshistorik (revisionslog)
Det værende sig en log over alle ændringer, som er foretaget på de enkelte entiteter, så tidligere versioner af de enkelte entiteter kan fremsøges. Denne log indeholder også information om, hvem der har ændret data hvornår. Når der er mulighed for berigtigelser af entiteter vil en berigtigelse også indgå i revisionshistorikken.
Yderligere information om revisionshistorik og revisionslog kan findes på nedenstående sider:
Den fremtidige og anbefalede retningslinje for revisionshistorik er, at selve revisionshistorikken altid skal indeholde seneste version af entiteten. Det betyder, at revisionshistorikken ved:
Oprettelse, indeholder en kopi af entitetens data, som de så ud på oprettelsestidspunktet med markering for, at der er tale om en oprettelse, information om, hvem der oprettede entiteten samt tidspunkt herfor.
Opdatering, indeholder en kopi af entitetens data, som de så ud på opdateringstidspunktet med markering for, at der er tale om en opdatering, information om, hvem der opdaterede entiteten samt tidspunkt herfor.
Sletning, indeholdende en kopi af entitetens data, som de så ud på sletningstidspunktet med markering for, at der er tale om en sletning, information om, hvem der slettede entiteten samt tidspunkt herfor.
Eksempler:
Kontaktgrupper, hvor der til hver enkel kontaktgrupperegistrering (entitet) er tilknyttet en kollektion indeholdende tidligere versioner af kontaktgrupperegistreringen (entiteten). Hver tidligere version i kollektionen indeholder således data for kontaktgrupperegistreringen, som den så ud på det tidspunkt, hvor versionen blev dannet.
Fravær, hvor der til hver enkel fraværsregistrering (entitet) er tilknyttet en kollektion indeholdende tidligere versioner af fraværsregistreringen (entiteten). Hver tidligere version i kollektionen indeholder således data for fraværsregistreringen, som den så ud på det tidspunkt, hvor versionen blev dannet.
Afholdte samtaler, hvor der til hver enkelt registrering af en afholdt samtale (entitet) er tilknyttet en kollektion indeholdende tidligere versioner af registreringen for den afholdte samtale (entiteten). Hver tidligere version i kollektionen indeholder således data for registreringen af den afholdte samtale, som den så ud på det tidspunkt, hvor versionen blev dannet. Gældende for afholdte samtaler er, at de ikke forretningsmæssigt opdateres men i stedet berigtiges i de situationer, hvor der er sket fejlregistreringer.
Teknisk dokumentation:
Databasemodellen for revisionshistorik og revisionslog er nærmere beskrevet på Den gode database.
Illustration af terminologier
Sletning af data
Sletning af hele entiteter (både aktuelle data og historiske data)
Når en hel entitet indeholdende enten aktuelle data eller historiske data slettes, skal dette registreres i revisionshistorik. Det skal i disse situationer sikres, at revisionshistorikken indeholder to registreringer ved en sletning, der hver især indeholder følgende oplysninger for entiteten:
Registrering indeholdende en kopi af entitetens data, som de så ud på sletningstidspunktet med information om, hvem der seneste har rørt (oprettet eller opdateret) entiteten samt tidspunkt herfor.
Registrering indeholdende en kopi af entitetens data, som de så ud på sletningstidspunktet med markering for, at der er tale om en sletning, information om, hvem der sletter entiteten samt tidspunkt herfor.
Følges de anbefalede retningslinjer for revisionshistorik, så vil punkt 1 ikke skulle registreres for entiteten ved selve sletningen, da denne allerede blev registreret i forbindelse med, at entiten enten blev oprettet eller opdateret.
Sletning/fjernelse af en eller flere værdier på en entitet (både aktuelle data og historiske data)
Når en eller flere værdier slettes/fjernes fra en entitet, det værdende sig, når værdien på en eller flere properties sættes til blank/nulstilles (NULL), skal dette registreres i revisionshistorik. Dette vil ske gennem en opdateringen af entiteten. Det skal i disse situationer sikres, at revisionshistorikken indeholder en registrering med følgende oplysninger for entiteten.
Registrering indeholdende en kopi af entitetens data, som de så ud på opdateringstidspunktet med information om, hvem der seneste har rørt (oprettet eller opdateret) entiteten samt tidspunkt herfor.
Følges de anbefalede retningslinjer for revisionshistorik, så vil punkt 1 ikke skulle registreres for entiteten ved selve opdateringen, da denne allerede blev registreret i forbindelse med, at entiteten enten blev oprettet eller opdateret. Derimod skal der laves en registrering i revisionshistorikken indeholdende en kopi af entitetens data, som de ser ud efter opdateringen (efter sletning/fjernelse af værdier) med markering for, at der er tale om en opdatering, information om, hvem der opdaterer entiteten samt tidspunktet herfor.
Teknisk dokumentation
Hvordan historiske data og den historiske revisionslog bør udstilles til aftagere er nærmere beskrevet på Det gode servicelandskab - sammenhæng imellem typer af services og deres roller.