User-stories

Borger

Som borger på 22 år vil jeg informeres om muligheden for at vælge tandlæge via digital post, så jeg kan vælge tandlæge

Som borger på 22 år vil jeg huskes på muligheden for at vælge tandlæge via digital post, så jeg kan vælge tandlæge

Som borger på 22 år vil jeg informeres om at mit valg af tandlæge er blevet accepteret, så jeg kan komme til tandlæge behandling

Som borger på 22 år vil jeg informeres om at mit valg af tandlæge er blevet afvist, så jeg kan fortage et nyt tandlægevalg

Som borger på 22 år vil jeg selv kunne registrer min tandlæge, så jeg kan forsætte min behandling uden yderligere påmindelser

Som borger på 22 år ønsker jeg ikke at vælge tandlæge ("Opt Out") på alle stadier, så jeg kan undgår at vælge tandlæge

Som borger på 22 år vil jeg kunne fravælge påmindelser om tandlægevalg, så jeg kan undgår påmindelser om tandlægevalg

Som borger på 22 år vil jeg kunne ændre / fortryde valg af tandlæge, så jeg kan vælge en anden tandlæge

Som borger på 22 år vil jeg kunne give fuldmagt til valg af tandlæge, så andre kan vælge tandlæge på mine vegne

Som borger på 22 år vil jeg kunne orienteres om tekniske udfordringer, så jeg kan vælge en anden tandlæge

Som borger på 22 år vil jeg kunne ændre valg hvis tandlæge ikke svarede i tide, så jeg kan vælge en anden tandlæge

Tandlæge

Som tandlægeklinik vil jeg orienteres om nye klienter, så jeg kan behandle anmodningen om tilknytning til min klinik

Som tandlægeklinik vil jeg påmindelse om nye klienter, så jeg kan behandle anmodningen om tilknytning til min klinik

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

Som tandlægeklinik vil jeg afvise en ny klient, så jeg kan undgå at klienten bliver tilknyttet til min klinik

Som myndighed med ansvar for registret

Som myndighed ønskes borgere der ikke ønsker påmindelse fjernes fra registret efter slette regler, så det undgås at registret indeholde irrelevante oplysninger

Som myndighed ønskes døde borgere fjernet fra registret efter slette regler, så det undgås at registret indeholde irrelevante oplysninger

Som myndighed ønskes borgere der har valgt "Opt Out" fjernet fra registret efter slette regler, så det undgås at registret indeholde irrelevante oplysninger

Use Case

UC-01 – Vælg tandlæge via Digital Post / sundhed.dk

Mål
At informér og faciliter valg af tandlæge

Aktører

  • Primær: Borger (22 år)

  • Systemer/understøttende aktører: DDTV, DPA, DPK, Digital Post, MitID, Sundhed.dk, CPR/Adresseregister

Forudsætninger

  • 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 - udskrives 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 C.1 - Borger anmodes om at vælge ny tandlæge (22 år)

  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 A.1 - Borger ser muligheder og/eller kontrollerer status for tandlægeflytning

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

  9. Borger bekræfter valg A.2 - Borger vælger ny tandlæge

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

  11. Systemet viser kvittering på skærmen

Alternative/fejl flows

Forretningsregler (mangler 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 - Tandlæge 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: Nasure kliniksystem

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” B.1 - Tandlæge anmodes om optagelse

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

  3. Klinik klikker ”Accepter” B.4 - Tandlæge accepterer / afviser

  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

  • UC2-A1: Afvisning → Klinik vælger ”Afvis” med årsag (fx fuld kapacitet). Borger modtager Digital Post med begrundelse? og vejledning B.4 - Tandlæge accepterer / afviser

  • UC2-A2: Borger fortryder valg → Klinik modtager besked om at ignorere tidligere anmodning B.2 - Tandlæge modtager besked om at ignorere tidligere besked
  • UC2-A3: Tandlæge rykkes for svar → Klinik modtager rykker for svar B.3 - Tandlæge rykkes for svar 
  • UC2-A4: Udløbet anmodning – Anmodning ældre end gyldighedsvindue → vis besked; klinik kan ikke acceptere; borger må sende ny anmodning 

  • UC2-A5: 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 statusændring

Eftertilstand / succes-kriterier

  • Borger er registreret som klient hos klinikken i centralt register

  • Borger har modtaget kvittering via Digital Post


UC-03 - Status via sundhed.dk / digital post

Mål
At informér om valgt tandlæge 

Aktører

  • Primær: Borger (22 år)

  • Understøttende systemer: sundhed.dk og Digital post

Forudsætninger

  • Klinikken har behandlet klient anmodning

Trigger

  • Borger modtager Digital Post 

Hovedforløb (solskinsscenarie)

  1. Klinik har "Accepteret" Borgerens anmodning

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

  3. Systemet sender Digital Post-bekræftelse til borger (inkl. klinikoplysninger) C.3 - Borger orienteres om skift af tilstand
  4. Hændelsen auditeres (tid, bruger, gammel/ny status)

Alternative/fejlflows

  • UC3-A1: Borger → logger ind på sundhed.dk til "vælg tandlæge", ser opdateret tandlæge status (accepteret / afvist) 

  • UC3-A2: Afvisning – Klinik har valgt ”Afvis”. Borger modtager Digital Post med begrundelse? og vejledning om at fortage nyt valg af tandlæge UC-1

  • UC3-A3: Udløbet anmodning – Anmodning ældre end gyldighedsvindue → Digital post om at klinik ikke har svaret; borger må sende ny anmodning eller vælge anden tandlæge UC-1

  • UC3-A4: Teknisk fejl → rulle tilbage, vis venlig fejl, log, og giv mulighed for at prøve igen UC-1

Forretningsregler (mangler der nogen?)

  • Én aktiv tandlæge pr. borger ad gangen
  • Alle ændringer logges (audit trail)

  • Notifikation til borger ved statusændring

Eftertilstand / succes-kriterier

  • Borger er registreret som klient hos klinikken i centralt register

  • Borger har modtaget kvittering via Digital Post

UC-04 - Baggrundsjobs

Mål
At systemet interne processer håndteres

Aktører

  • Primær: system jobs

  • Understøttende systemer: DDTV

Forudsætninger

  • Din Digitale tandlæge vælger

Trigger

  • Daglige afviklinger starter automatisk på fastsatte tidspunkter

Baggrundsjobs

IDJobnavnTrigger tidspunktOpførsel
UC4-AJob til identifikation af borgere, der fylder 22 år"Startes ofte, flere gange dagligt"Når den er nået til at have behandlet alle der fylder 22 år inden for de næste 7 dage - stopper den med at afvikles, indtil næste dag
UC4-BJob til afsendelse af digital postSamme som UC4-AAlle der har status ready behandles
UC4-CJob til påmindelse af borgerSamme som UC4-AAlle der har status ready behandles
UC4-DJob til afsendelse af EDI-beskederEn gang i døgnet om nattenAlle med dentist Chosen afsendes til EDIPortalen
UC4-EOvervågning af baggrundsN/ATjekker løbende status
UC4-FJob til afsendelse af "se bort fra tidligere EDI"-beskederSamme som UC4-AAlle der har fortrudt valg at tandlæge, afsendes til EDIPortalen
UC4-GJob til sletning af data for afdøde borgere, samt borgere, der aldrig svarede?


Alternative/fejlflows

  • N/A

Forretningsregler (mangler der nogen?)

  • Alle ændringer logges (audit trail)

  • Notifikation til borger ved statusændring

Eftertilstand / succes-kriterier

  • Borger der har status - har fået tilsend brev eller Digitalpost

  • Borger der har været døde i 1 år er blevet slettet
  • Borger har modtaget kvittering via Digital Post vedr. accept eller afvisning

  • Tandlæger er blevet notificeret om nye klienter 

  • Tandlæger er blevet notificeret om tilbagekaldelse af klient
  • Driften er orienteret om DDTV services tilstand


  • No labels