'CPR'

'ACTIVE'

'CPR'

'ACTIVE'

'CPR'

'INACTIVE'

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.