Alle modelentiteter skal understøtte dobbelthistorik og angivelse af aktører

Nummer:
6.3
Version:
1.2.0
Høringsversion
Ændring
1. Afsnittet Registreringstid i Rationale tilføjes en sætning

 fra

"Registreringstid:

Tidsrummet fra versionen registreres i databasen, indtil den enten erstattes af en nyere version eller afregistreres"

til

"Registreringstid:

Tidsrummet fra versionen registreres i databasen, indtil den enten erstattes af en nyere version eller afregistreres. Det skal dokumenteres både hvornår data er ændret i kilderegisteret og hvornår data er opdateret på Datafordeleren."

2. Før afsnit to i Implikationer indsættes to afsnit:

"Det skal dokumenterer hvornår hvor grunddataregisteret registrerer ændringen i data. Dette regelsættes af modelreglerne. Hvis der har været en eller flere forudgående processer hos dataleverandører eller andre kildedatabaser, er disse processers tidspunkter ikke registreret  med de generelle egenskabers registreringstidspunkter.

Distribution af data via Datafordeleren tilføjer naturligvis en række yderligere temporale metadata: for eksempel det tidspunkt, hvor Datafordeleren har modtaget data fra grunddataregisteret samt det tidspunkt, hvor data er blevet hentet via en tjeneste på Datafordeleren. Specifikationen af disse tidspunkter regelsættes ikke i modelreglerne, men de indgår som metadata til en tjenestes dataleverance ."

3. Afsnit 2 i Implikationer ændres

 fra

"Alle versioner skal være karakteriseret ved hjælp af deres registreringstid og deres virkningstid. Disse tidsaspekter modelleres ved anvendelse af attributterne registreringFra, registreringTil, virkningFra og virkningTil. "

til

"Alle versioner skal være karakteriseret ved hjælp af deres registreringstid og deres virkningstid. Disse tidsaspekter modelleres ved anvendelse af attributterne registertidFra, registertidTil, virkningFra og virkningTil. "

4. Afsnit 3 i Implikationer ændres

 fra

"Enhver version af et stamdataobjekt identificeres entydigt af objektets unikke identifikation kombineret med attributten registreringFra."

til

"Enhver version af et stamdataobjekt identificeres entydigt af objektets unikke identifikation kombineret med attributten registrertidFra og objektets status"

5. Tabel-headers i afsnittet Registrering ændres
fra
'registreringFra', 'registreringTil'
til
'registertidFra', 'registertidTil'
6. Undtagelsen, som findes tilsidst i Implikationer, udgår:
"CVR's modeller er undtaget fra regel 6.3 fsva. attributterne registreringFra og registreringTil, da CVR ikke indeholder de pågældende data"
7. Der indføjes et afsnit: "Eksempler"

Et barn, "Philippa", fødes på Rigshospitalets barselafdeling den 14. december 2022 henimod midnat. Den involverede jordemoder er travlt optaget af en usædvanlig stor mængde komplicerede barnefødsler på dette tidspunkt, og kan ikke afsætte tid til at registrere fødslen i det Centrale Person Register, og alle sekretærer er på tvungen, forceret juleferie. Næste eftermiddag kan en studentermedhjælp kl 12:42  opdatere CPR vha CPRWEB.

Rigshospitalet - registreret i et organisationsregister - er registreringsaktør for opdateringen. Fødselsdatoen (der er tale om en dag) er verificeret af CPR-kontoret, som er virkningsaktør.

Et nyt personobjekt oprettes i CPR: : { registertidFra : 2022-12-15T12:42:00+01:00, registertidTil : Null, virkningFra : 2022-12-14, virkningTil : Null , registreringsaktør : http://data.gov.dk/id/organisation#Rigshospitalet, virkningsaktør : http://data.gov.dk/id/organisation#cprkontoret}

Se yderligere. tilsvarende eksempler i ovennævnte dokument

 

Ændringsargumentation

Det har været nødvendigt, at præcisere anvendelsen af registreringstidspunktet.

Nedenfor følger reglen, med de nævnte ændringer indføjet

Regel

Alle modelentiteter skal modelleres med angivelse af registrering, virkning og aktører

 
Rationale

Dobbelthistorik:

På tværs af grunddata er der behov for at implementere dobbelthistorik, for at kunne understøtte et samlet krav om revisionsspor. Dataobjekter skal med andre ord kunne rekonstrueres på en måde, hvor der er styr på objektets sammensætning eller tilstand til et givet tidspunkt. Formålet hermed er bl.a. at dokumentere det konkrete historiske beslutningsgrundlag i forbindelse med fx sagsbehandling.

Dobbelthistorik modelleres ved hjælp af bitemporale egenskaber. Det dobbelte består i, at to tidsaspekter “virkningstid” og “registreringstid” håndteres i sammenhæng.

 

Registreringstid:

Tidsrummet fra versionen registreres i databasen, indtil den enten erstattes af en nyere version eller afregistreres. Det skal dokumenteres både hvornår data er ændret i kilderegisteret og hvornår data er opdateret på Datafordeleren.

 

Virkningstid:
Tidsrummet, hvor en given version af data svarer til de forhold i virkeligheden, som versionen afbilder.

 

Aktører:

Oplysning om hvilke aktører, der er ansvarlig for datas indhold, tilfører sporbarhed i forbindelse med revision og anvendelse af data. Aktøren kan være en af en række forskellige typer, fx en organisation, et it-system, en arbejdsfunktion eller en konkret bruger.

 
Implikationer

Et data-objekt kan bestå af en række (1-*) versioner (ændres en enkelt attributværdi, betragtes dataobjektet som ændret og dermed versioneret). Alle versioner betragtes som dele af et “stamdataobjekt”, og har den samme Identifikation.

Det skal dokumenterer hvornår hvor grunddataregisteret registrerer ændringen i data. Dette regelsættes af modelreglerne. Hvis der har været en eller flere forudgående processer hos dataleverandører eller andre kildedatabaser, er disse processers tidspunkter ikke registreret  med de generelle egenskabers registreringstidspunkter.

Distribution af data via Datafordeleren tilføjer naturligvis en række yderligere temporale metadata: for eksempel det tidspunkt, hvor Datafordeleren har modtaget data fra grunddataregisteret samt det tidspunkt, hvor data er blevet hentet via en tjeneste på Datafordeleren. Specifikationen af disse tidspunkter regelsættes ikke i modelreglerne, men de indgår som metadata til en tjenestes dataleverance.

Alle versioner skal være karakteriseret ved hjælp af deres registreringstid og deres virkningstid. Disse tidsaspekter modelleres ved anvendelse af attributterne registertidFra, registertidTil, virkningFra og virkningTil. 

Enhver version af et stamdataobjekt identificeres entydigt af objektets unikke identifikation kombineret med attributten registertidFra og objektets status.

Når en bruger til et bestemt formål skal fremfinde den eller de relevante versioner af et objekt, kan objektets identifikation samt en kombination af registreringstid, virkningstid og/eller objektets status anvendes.

 

 

Virkningstidsrummet skal fortolkes sådan at virkningsintervallet er inklusiv starttidspunktet men eksklusiv sluttidspunktet.

Hvorvidt der kan være "huller" i Virkningstiden - perioder hvori virkeligheden ikke er afspejlet i data - er op til det enkelte datdomæne at beslutte og dokumentere.

 

 

Til hver version af et dataobjekt skal der knyttes aktører i betydningen:

  • Reference til den aktør, der afstedkommer iværksættelse af virkningsperioden
  • Reference til den aktør, der har foretaget registreringen

Værdien kan være en reference til fx en organisation, et system eller en sagsbehandler se afsnit afsnit 3.3.1 og regel 5.10

 

Fuld temporal rekonstruktion af dataobjekter forudsætter, at alle ændringer i dataojektet gemmes med de nødvendige tidsmarkeringer. Derfor indeholder denne regel et krav om, at data opbevares i registre, som er implementeret på en måde som gør dette muligt. En sådan implementering indbefatter dels en fysisk datamodel som tilføjer en ny række til datatabellen for hver ny version a data, på en måde så alle ændringer kan genfindes dels forretningsregler for, hvordan tidsmærkerne tilknyttes. Et dokument, som uddyber hvordan dette kan gøres i et RDB/SQL miljø  kan downloades her

 

 

 

Attributter:

 

Hver modelentitet med stereotypen DKObjekttype - modsvarende et forretningsobjekt - modelleres med følgende attributter:

 

Registrering:

registertidFra

BETYDNING

Tidspunktet hvor registreringen er foretaget

VÆRDI

Tidspunkt

DATATYPE

DateTime (ISO 8601), værdien må ikke være tom

KRAV

Obligatorisk

registertidTil

BETYDNING

Tidspunktet hvor en ny registrering er foretaget på dataobjektet, og hvor denne version således ikke længere er den seneste.

VÆRDI

Tidspunkt

DATATYPE

DateTime (ISO 8601), værdien kan være tom

KRAV

Obligatorisk

registreringsaktør

BETYDNING

Den aktør der har foretaget registreringen

VÆRDI

Angivelse af en aktør fx som en reference til en organisationsmodel (se regel 5.10)

DATATYPE

Domænespecifik aktør, værdien må ikke være tom

KRAV

Obligatorisk

 

Virkning:

virkningFra

BETYDNING

Tidspunktet hvorfra forvaltningsobjektet har virkning

VÆRDI

Tidspunkt - virkningsperioden inkluderer dette tidspunkt

DATATYPE

dateTime (ISO 8601), værdien må ikke være tom

KRAV

Obligatorisk

virkningTil

BETYDNING

Tidspunktet hvor forvaltningsobjektets virkning ophører

VÆRDI

Tidspunkt - virkningsperioden stopper umiddelbart før dette tidspunkt 

DATATYPE

dateTime (ISO 8601), værdien kan være tom

KRAV

Obligatorisk

virkningsaktør

BETYDNING

Den aktør der har afstedkommet forvaltningsobjektets virkning

VÆRDI

Angivelse af en aktør fx som en reference til en organisationsmodel (se regel 5.10)

DATATYPE

Domænespecifik aktør, værdien må ikke være tom

KRAV

Obligatorisk

 

Undtagelse

CVR's modeller er undtaget fra regel 6.3 fsva. attributterne registreringFra og registreringTil, da CVR ikke indeholder de pågældende data

Eksempler

Et barn, "Philippa", fødes på Rigshospitalets barselafdeling den 14. december 2022 henimod midnat. Den involverede jordemoder er travlt optaget af en usædvanlig stor mængde komplicerede barnefødsler på dette tidspunkt, og kan ikke afsætte tid til at registrere fødslen i det Centrale Person Register, og alle sekretærer er på tvungen, forceret juleferie. Næste eftermiddag kan en studentermedhjælp kl 12:42 opdatere CPR vha CPRWEB.

Rigshospitalet - registreret i et organisationsregister - er registreringsaktør for opdateringen. Fødselsdatoen (der er tale om en dag) er verificeret af CPR-kontoret, som er virkningsaktør.

Et nyt personobjekt oprettes i CPR: : {  registertidFra : 2022-12-15T12:42:00+01:00, registertidTil : Null, virkningFra : 2022-12-14, virkningTil : Null , registreringsaktør : http://data.gov.dk/id/organisation#Rigshospitalet, virkningsaktør : http://data.gov.dk/id/organisation#cprkontoret}

Se yderligere. tilsvarende eksempler i ovennævnte dokument

Permanent URL til denne artikel: http://arkitekturguiden.digitaliser.dk/node/940