Page History

...

Som tandlæge vil jeg acceptere en ny klient, så jeg kan få klienten kan blive tilknyttet til min klinik.

...

• Borger er 22 år og registreret med bopæl i DK.

• Borger er tilmeldt Digital Post eller fysisk post

• Borger har ret til at vælge tandlæge - udskrivning fra kommunal tandpleje

• Sundhed.dk har opdateret liste over tilgængelige tandlæger (inkl. priser).

Trigger

• Planlagt job (fx xxxx) identificerer borgere, der skal informeres (fx ved 22-års fødselsdag, flytning eller manglende tandlægevalg?).

Hovedforløb (solskinsscenarie)

1. DDTV identificerer borger som målgruppe for information.

2. Systemet genererer personlig Digital Post-besked med formål og dybt link til ”Vælg tandlæge” på sundhed.dk.

3. Systemet sender beskeden via Digital Post og logger afsendelse.

4. Borger modtager besked og åbner linket.

5. Borger autentificerer med MitID.

6. Sundhed.dk viser ”Vælg tandlæge”-siden, forudfyldt med borgerens kommune.

7. Borger søger/filtrerer og vælger ønsket tandlæge.

8. Systemet viser sammendrag (navn, adresse, evt. priser) og beder om bekræftelse.

9. Borger bekræfter valg.

10. DDTV opdaterer registrering (én aktiv tandlæge pr. borger).

11. Systemet viser kvittering på skærmen.

Alternative/fejl flows

• A1: Borger ikke tilmeldt Digital Post → Der udsendes fysisk brev/SMS/e-mail efter gældende regler; link peger til generisk landingsside med MitID-login

• A2: Borger ignorere Digital Post → Det fremsendes endnu en på mindelse (efter xxx dage) via Digital Post med dybt link til "Vælg tandlæge" på sundhed.dk

• A2A3: Allerede registreret tandlæge → Side informerer om eksisterende tandlæge og tilbyder ”Skift tandlæge” (samme flow som trin 7–11).

• A3A4: MitID-fejl/afbrudt login → Vis tydelig fejl og mulighed for at prøve igen.

• A4A5: Teknisk fejl ved registrering → Vis venlig fejl, log hændelsen, tilbyd at prøve igen senere og/eller kontakt.

Forretningsregler (uddragmangler der nogen?)

• Én aktiv tandlæge pr. borger ad gangen.

• Valg kræver stærk autentifikation (MitID).

• Registrering og ændringer auditeres (tid, aktør, gammel/ny tandlæge).

• Personoplysninger behandles efter GDPR (minimering, formålsbegrænsning).

Succes-kriterier/eftertilstand

• Borger er informeret og (hvis ønsket) korrekt registreret hos valgt tandlæge

• Kvittering er leveret (UI)

• Auditlog opdateret

UC-02 — Acceptere ny klient

Mål
At tandlæge/klinik aktivt accepterer en borger, så borgeren tilknyttes klinikken og kan bookes/behandles

Aktører

• Primær: Tandlæge eller klinikadministrator

• Understøttende systemer: Nasurekliniksystem

Forudsætninger

• Klinikken er tilmeldt systemet

Trigger

• Klinikken modtager notifikation (e-mail-dashboard) om ny klientanmodning 

Hovedforløb (solskinsscenarie)

1. Klinik åbner listen ”Afventende anmodninger”

2. Klinik vælger en anmodning og ser nødvendige oplysninger 

3. Klinik klikker ”Accepter”

4. Ved succes opdaterer systemet centralt register (DDTV) (tilknytning: borger → klinik)

5. Systemet viser kvittering til klinik og sender Digital Post-bekræftelse til borger (inkl. klinikoplysninger)

6. Hændelsen auditeres (tid, bruger, gammel/ny status)

Alternative/fejlflows

• A1: Afvisning – Klinik vælger ”Afvis” med årsag (fx fuld kapacitet). Borger modtager Digital Post med begrundelse og vejledning

• A2: Udløbet anmodning – Anmodning ældre end gyldighedsvindue → vis besked; klinik kan ikke acceptere; borger må sende ny anmodning

• A3: Teknisk fejl – Opdatering af centralt register fejler → rulle tilbage, vis venlig fejl, log, og giv mulighed for at prøve igen

Forretningsregler (mangler der nogen?)

• Én aktiv tandlæge-tilknytning pr. borger ad gangen

• Kun nødvendige persondata vises før accept (dataminimering, GDPR)

• Alle ændringer logges (audit trail)

• Notifikation til borger ved enhver statusændring

Eftertilstand / succes-kriterier

• Borger er registreret som klient hos klinikken i centralt register

• Borger har modtaget kvittering via Digital Post