Page History
...
I de tilfælde hvor ValidFrom i Modified passer på en ValidTo i et dataelement er det den Modified By der har sat det element til historisk (invalideret data).
Historik
Nationalt eCPR har fuld historik på samtlige ændringer. Historik håndteres ved, at der på samtlige overordnede dataelementer (navn, adresse, id’er osv.) findes et datointerval hvor registreringen er aktuel fra, givet ved en validFrom-dato. Er registreringen ikke længere aktuel findes der en validTo-dato, der angiver, hvornår registreringen ikke længere er aktuel.
Dataelementerne for id’er, navn, kontaktinformation og adresse kan desuden have en forretningsmæssig udløbsdato (Expiry). Dvs. det kan angives hvornår f.eks. et pas udløber, hvornår personen ikke længere kan kontaktes på en adresse m.v.
Samtlige historiske dataelementer er søgbare. Det er således også muligt at fremsøge f.eks. på et udløbet pasnummer eller en tidligere adresse.
Der findes en enkelt undtagelse fra ovenstående beskrivelse; operationen DeletePerson
| Footnote |
|---|
Servicen kan kun anvendes i Test til at slette fejlagtigt oprettede person-registreringer. |
, der sletter samtlige registreringer på personen, aktuelle og historiske.
ValidFrom/ValidTo
Når en opdatering er gennemført, vil de berørte data have et “ValidFrom”-element lig med tidspunktet hvor opdateringen skete. Hvis der sker efterfølgende opdateringer, vil den tidligere entitet beholdes, men får et “ValidTo”-element der angiver hvornår pågældende data ikke længere er gyldige, og der findes en ny modifier, som ikke har en “ValidTo”-værdi. Dvs. aktuelle værdier kendetegnes ved ikke at have ValidTo, og historiske værdier har ValidTo. Man kan betegne ValidFrom/ValidTo som en teknisk gyldighedsperiode. På Identifier, Name, Contact og Address kan man desuden angive en forretningsmæssig gyldighed via en “Expiry”-dato, som fx kan være udløbsdato for et EU-sundhedskort. Hvis Expiry er udløbet på opslagstidspunktet, vil denne dato stå som ValidTo, og elementet anses ikke længere som gyldigt.
ValidFrom, ValidTo, PID, OID, PrimaryOIDLabel og SecondaryOIDLabel har samme betydning på alle entiteter.
Expiry
Det er muligt at angive Expiry med varierende præcision i request. Der gælder følgende regler for, hvordan datoer med “lavere præcision” fortolkes:
...
<Envelope> <Header> </Header> <Body> <Fault> <faultcode>Server</faultcode> <faultstring xml:lang="en"> Fejl i request ifm. med opdatering af eCPR-data, Ulovligt format for fødselsdag (ÅÅÅÅ-MM-DD): [2020-04-130] </faultstring> </Fault> </Body> </Envelope>
...
| Footnotes Display |
|---|
...
Ændringslog
| 1.0 | 2023-11-07 | Side publiceret | SDS |