Page History

...

• Aftaledokument (Typekode: 56446-8): Skal slettes efter 2 år

Beregning af metadatas alder

Til at beskrive et dokuments alder anvendes følgende trin (det første trin, der giver mening at evaluere for en given DocumentEntry anvendes til at beslutte alderen for den pågældende):

1. Hvis en DocumentEntry har serviceStartTime og/eller serviceStopTime anvendes denne største af disse til at beskrive alderen (disse attributter er ikke tvungne i hverken IHE XDS profilen eller i den danske metadataprofil). For planer anvendes serviceStopTime (planens afslutning).
2. Hvis en DocumentEntry har en creationTime anvendes denne til at beskrive alderen (On-demand DocumentEntry har ikke en sådan, men for Stable DocumentEntry er den krævet).
3. NXRG forsyner en DocumentEntry med et tidsstempel på registreringstidspunktet. Hvis ingen af de ovenstående trin kan anvendes, så vil dette tidsstempel fungere som alderen for en DocumentEntry.

I forhold til sletning gælder følgende:

• DocumentEntries slettes efter reglerne skitseret ovenfor
• Alle associations til/fra slettede DocumentEntries slettes også
• "Tomme" SubmissionSets slettes: Et tomt submissionset er et submissionset uden tilhørende associations

Andre krav

NXRG indeholde metadata for dokumenter og en sletning i NXRG vil gøre det umuligt for anvendere at fremsøge referencer til disse dokumenter. Selve dokumentet ligger uden for NXRG - i et XDS repository. For at sletningen kan siges at være komplet, så skal disse XDS repositories notificeres i forhold til de slettede  dokumenter. Dette betyder, at det er vigtigt at opsamle identifikation på de slettede metadata, med det formål at formidle til det XDS Repository, hvor selve dokumentet befinder sig, at metadata er slettet. Det må så være op til det enkelte XDS Repository at foretage sin egen oprydning/arkiveringen med afsæt i disse oplysninger.

Cleanup service i OpenText XDS Registry

Der blev udviklet en cleanup service til OpenText XDS Registry. Dette dækkede kun aftaler og var bundet op på den teknologistak, der hører til OpenText. Det var derfor nødvendigt at lave en re-implementering af cleanup service i NXRG. Dette findes i kodebasen i dag, men der er fundet et par QA findings på denne funktionalitet. Inden der iværksættes arbejde med at rette op på disse findings vil det være relevant at kigge på et par andre begrænsninger i den gamle funktionalitet og overveje, om det kan gøres på en anden måde.

Der er følgende problemer med den aktuelle cleanup  service:

1. Mangelfuld bestemmelse af metadatas alder: I forhold til den ovenfor skitserede algoritme, så er det kun pkt 1 og 2, der er med i den nuværende cleanup service. Det betyder, at on-demand dokumenter uden service start time og service stop time aldrig slettes.
2. Håndterer kun aftaler: Der mangler generalisering til andre dokumenttyper og mulighed for at differentiere på regler for, hvor længe data opbevares. Der findes andre metadata i det nationale registry bl.a. 74465-8 Questionnaire Response Document, 53576-5 Personal Health Monitoring Report og 81215-6 Careplan. Måske andre på vej?
3. Rapportere slettede id'er ved fil-output: De slettede id'er logges. En videredistribution af oplysninger om de slettede data vil kræve  at disse logfiler opsamles og splittes op ved manipulation af filerne (det kunne være relevant at lave en liste pr. repository).

Forslag til ny Cleanup service

Med afsæt i de uhensigtsmæssigheder, som beskrevet ovenfor foreslås følgende ændringer:

1. Cleanup service skal have konfiguration pr dokumenttype: Det skal være muligt at definere max alder pr. dokumenttype
2. Opdeling i cleanup service i følgende services. Disse skal kun være tilgængelige for driften og have hvert deres endpoint:
   1. cleanup: I stedet for at foretage en fysisk sletning af document entries i dette job, bliver de i første omgang "slette-markerede". Det betyder, at de ikke kan fremsøges ved en ITI-18 operation (dette er ikke det samme som Deprecate status). De associations, der peger til/fra de slettemarkerede DocumentEntries, kan fysisk slettes i databasen i forbindelse med dette job. Der kan også foretages fysisk sletning af "tomme" SubmissionSets.
   2. deleted: Fremsøgningsservice, hvor man kan hente "slettemarkerede" DocumentEntries. Det kunne måske være en fordel at afgrænse på repositoryId for at kunne lave seperate lister til forskellige XDS Repositories.
   3. deleted/repository (forslag): Denne service kunne bruges til at fremsøge hvilke unikke repositories, der aktuelt findes "slettemarkerede" DocumentEntries for. Desværre er repositoryid ikke aktuelt et søgbart felt i NXRG. Man kunne udvide databasen med dette også enten lave en database-migrering til at få det fyldt ud, eller blot sætte feltet i forbindelse med sletning (cleanup), da det indtil videre kun er cleanup service, der har brug for oplysningen
   4. finalcleanup: Kald af denne service vil fysisk slette de DocumentEntries, der er "slettemarkerde" i databasen.

Forslag til at bruge NAS i forbindelse med Cleanup Service

I forhold til løsningen skitseret i forgående afsnit, så er problemet med at få distribueret "slettelister" til XDS Registries stadig til stede.

En anden mulighed er at anvende NAS til at publicere beskeder i forbindelse med sletningerne. En sådan slettebesked skal være forsynes med repositoryid (som id for beskeden, som mange beskeder i dag anvender cprnumre til patientrelaterede beskeder). På denne måde bliver det muligt at opsætte idliste, så et subscription kun kommer til at gå på slettebeskeder vedr. et bestemt XDS Repository.

I forhold til løsningen beskrevet ovenfor, så vil der stadig være brug for at lave en cleanup service i NXRG. I forhold til løsningen skitseret i forgående afsnit, så vil det være relevant at udstille den service beskrevet i pkt a cleanup. I forhold til beskrivelsen i forgående afsnit, så skal forretningslogikken for denne service inkludere en publicering af en slettebesked for den DocumentEntry, der skal slettes. Da slettebeskeden skal inkludere XDS Repository Id, så er problematikken beskrevet i pkt c også relevant i dette tilfælde, da XDS Repository Id ikke er blandt de søgbare felter. Den kan dog fiskes ud ved at parse den DocumentEntry XML, der er gemt i contenttabellen.

Så snart slettebeskeden vedr en DocumentEntry er publiceret til NAS, så kan cleanup service lave den fysiske sletning af DocumentEntry (pkt d).

Der findes i dag et slettejob til det nationale XDS Repository. Denne opererer på inputfiler til at slette de relevante dokumenter fra XDS Repository. Dette slettejobs skal ændres til at opsætte en subscription på slettebeskeder (med en idliste, der afgrænser til id for det nationale XDS Repository). Det vurderes, at denne opgave er overskuelig (jeg har ikke set koden)Sletning varetages af den separate service XDSCleanup. Der henvises til dokumentationen for denne service for en beskrivelse af reglerne for, hvordan og hvornår sletning af dokumentmetadata finder sted.

Eksterne services

Der er i dag eksterne services, der tilgår OpenText Registry direkte (dvs udenom de i forgående afsnit skitserede NSP services).

...