Formål: Benyttes til at fylde operationer på stakken, når stakken er tom.

Java klasse: FgvhrDeceasedCleanupSupplier

Batching: For hvert af tallene 00-99, oprettes en "prefix baseret operation"  for både consent og for digital post

Shuffles: nej

Andet: -

Prefix baseret

operation 

(Concent og Digital post)

Formål: Givet et tal mellem 00 og 99, hentes alle borger id'er af typen cpr fra  som starter med disse cifre.

Java klasse: FgvhrDeceasedPatientIdPrefixCleanupSupplier/ FgvhrDeceasedPatientIdPrefixCleanupDigitalPostSupplierTest

Batching: Opretter en mængde "borger id baseret operation", hver med et konfigurerbart antal af disse borger id'er

Shuffles: ja

Andet: -

henter fra citizen_consent

henter fra letter

Borger id baseret operation

(Concent og Digital post)

Formål: Givet en liste af borger id'er, tages de id'er der tilhører afdøde borgere. Dette afgøres ved kald til PersonInformation.

Java klasse: FgvhrDeceasedPatientIdBatchCleanupSupplier/ FgvhrDeceasedPatientIdBatchCleanupDigitalPostSupplierTest

Batching: Opretter eet "oprydningsjob" med de afdøde borgers id

Shuffles: nej

Andet: -

anvender et år som grænse til at afgøre,
om en person er afdød

anvender "nu" som grænse til at afgøre, 
om en person er afdød

Oprydningsjob

(Concent og Digital post)

Formål: Givet en liste af borger id'er slettes i databasen fravalg (citizen_consent, letter, substitution_values og recipient_details) for denne liste af id'er af typen cpr

Java klasse: FgvhrCleanupOperation/ FgvhrCleanupDigitalPostOperation

Batching: na

Shuffles: na

Andet: --

sletter i citizen_consent

sleter i letter og substitution_values

Formål: Benyttes til at fylde operationer på stakken, når stakken er tom

.

Java klasse:

FgvhrDigitalPostSendLetterSupplier

Batching:

for hver letter oprettes et "Afsendelses job"

Shuffles: nej

Andet: -

Formål: Givet

et letter sendes dette med den digitale post komponent

Java klasse:

FgvhrDigitalPostSendOperation

Batching: na

Shuffles: 

na

Andet: Et letter låses mens det behandles så andre jobs ikke tager fat i det

Problem: Titel/rolle skal sendes med ved logning i MinLog. Dette overholder FGVHR ikke. Derudover er der vedtaget en mapning fra Uddannelseskoder og Nationale Roller på tværs af NSP-komponenter, som skal anvendes, når titlen logges.

Beskrivelse: Logningen skal ændres til at medtage titel/rolle.

Beslutning: Rettes med SDS-8569.

Problem: Det er blevet besluttet, at alle NSP-komponenter fremover skal logge alle borgers opslag på egne data i minlog. Dette påvirker selvfølgelig også FGVHR.

Beskrivelse: FGVHR skal rettes, så den også logger borgeres egne opslag på egne data.

Beslutning: Rettes med SDS-7992.

Problem: Er der behov for optimistisk låsning, således der ikke sker en oprettelse/ændring af data bagom ryggen på den visning man nu ser?

Beskrivelse: Der er kun to klienter som kan skrive data til register for fravalg. Den ene er borgeren selv via sundhed.dk, den anden er en administrativ medarbejder via NADM snitfladen. Administrative medarbejdere indtaster borgerens data fra papirblanketter indsendt fra de borgere som ikke er kyndige med det digitale. Sandsynligheden for at en borger skriver egne data via sundhed.dk på samme tid en administrativ medarbejder skriver borgerens data via NADM er defor minimal.

At indføre optimistisk låsning på nuværende tidspunkt, kræver en ændring til læse- og registreringssnitfladen, da der skal indføres en ekstra kolonne i databasen, eksempelvis "replaces_uuid" som fortæller hvilken række som erstattes. Derved kan registeret se om der er kommet ny data ind i mellemtiden for borgeren inden der skrives.
Problemstillingen er at snitfladerne er udsendt (pr. 1/7-2023) og en ændring af snitfladen på nuværende tidspunkt kan resultere i en samlet forsinkelse af projektet. Risikoen for at der skrives data bag om ryggen på enten borgeren eller den administrative medarbejder er så lille at vi ikke skal indføre ændringen ift. optimistisk låsning for borgerens registrering af fravalg.

Beslutning: Der indføres ikke optimistisk låsning ved skrivning ift nuværende snitflade

Problem: Må borgerens historiske registrering af fravalg samt tilbagetrækninger opbevares i FGVHR?

Beskrivelse: "Fravalgs-registeret" er lige nu designet til at opbevare al historik på borgerens registrerede fravalg, og ikke kun den aktuelle registrering. Data slettes først et år efter borgeren er registreret som afdød i CPR-registeret.

Det betyder at for en borger som har registreret fravalg, og senere trækker registreringen tilbage, vil man kunne se i registeret hvornår disse transaktioner er foretaget.
Det er muligt at se alle historiske registreringer via den administrative brugergrænsefladen (NADM)

Årsagen til at historik bør være tilgængelig i FGVHR er oplysningernes følsomhed, således der aldrig kan dannes tvivl om hvad borgerens registrering har været på et hvilket som helst tidspunkt.
Et scenarie som skal tænkes ind er borgere som registrerer et fravalg, fortryder registreringen, for derefter at registrere sig igen o.s.v. Der vil det være vigtigt at kunne dokumentere at disse handlinger er foretaget.

Beslutning: Juridisk afdeling godkender at historikken opbevares omkring fravalg af genoplivningsforsøg. De mener derfor, at der ikke er et problem med hjemlen til opbevaring af disse data. Der har tidligere været henvendelser på VAR og Organdonor omkring dette, hvor de også kom frem til, at fravalg og tilvalg er vigtig historisk. Særligt ift. klagesager hos STPK - hvis fx en pårørende påstår, at deres familiemedlem ikke var registeret på tidspunktet, fordi de havde overbevist dem, om ikke lade sig registrere og bede om genoplivningsforsøg ved hjertestop, men så har familiemedlemmet ændret valget igen lige op til dødsfaldet.

Om data skal vises for borgeren er ikke givet. Derfor skal historik udelukkende udstilles til den administrative brugergrænseflade for nuværende.

Problem:  Den 26.03.2023 blev FHIR release 5 frigivet, skal FGVHR's snitflade opdateres tilsvarende?

Beskrivelse: Oprindeligt er snitfladen til FGVHR profileret efter version 4: http://hl7.org/fhir/R4/consent.html  i mellemtiden 26/3 er FHIR release 5 blevet frigivet http://hl7.org/fhir/R5/consent.html

Der er nogle mindre forskelle, bl.a. på kardinaliteter og på datatyper og konstantværdier, så spørgsmålet er om SDS vil understøtte Release 4 af modellen, eller den Release 5?

Beslutning: Da der er tale om mindre justeringer baseret på en R4-R5 sammenligning, og vi samtidig kan sige, at hvis R5 havde været til rådighed, da vi lavede den første modellering, så havde vi vel valgt R5 uden at blinke ret meget, så peger de to ting tilsammen på, at vi skal basere os på version 5.
Eneste argument for at blive på R4 ville være, hvis vi allerede havde noget andet, der anvendte/refererede til Consent i R4, ifølge NSP er det dem ikke bekendt.

Beslutning: Snitfladen opdateres til FHIR release version 5

Problem: I hvilke situationer skal FGVHR skrive til Minlog?

Beslutning:

1. Der skrives til borgerens Minlog når registrereringen oprettes/slettes - uanset om det er borgeren selv der ændrer via sundhed.dk, eller om det er en administrativ medarbejder som behandler en papirblanket.
2. Der skrives til borgerens Minlog når en administrativ medarbejder henter oplysninger om en borgers registrering i FGVHR
3. Der skrives ikke til Minlog når registreringen læses af borgeren selv.
4. Der skrives ikke til Minlog når status hentes via Fælles Stamkort grænsefladen

Det vil forventeligt være meget få logninger, og desuden vil enhver tvivl om hvornår noget er ændret, derfor udvides den sædvanlige logning med retistreringer fra borgeren selv.

Problem: Der er efterspurgt adgang til borgerens registrering uden om Fælles Stamkort, eksempelvis via replikering - kan det tillades?

Beslutning: Status om borgerens fravalg for genoplivningsforsøg ved hjertestop udestilles kun til sundhedsfaglige systemer via Fælles Stamkort.