Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Hvis status er 'ENTERED-IN-ERROR', så er denne og den foregående række ikke gyldige. Dvs. i scenarie nr. 6 har borgeren ikke et aktivt fravalg, mens i scenarie nr. 7 har borgeren et aktivt fravalg.


Beslutninger ift. arkitektur og jura

Følgende tabel er beslutninger, som har indvirkning på arkitekturen bag FGVHR

DatoEmneProblem, beskrivelse og beslutningAfklaret med
14.08.2023Optimistisk låsning ved skrivning til registeret

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

NSP
14.08.2023Historik på data i FGVHR

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: Ikke besluttet endnu, under afklaring i juridisk afdeling hos SDS - svar forventes inden 28/8-2023


25.05.2023Version af FHIR profil

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

NSP
27.03.2023Skrivning til Minlog

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.

SDS's Juridiske afdeling
23.01.2023Sundhedsfaglig adgang til borgerens registrering

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.

NSP
SDS's juridiske afdeling