Page History
Datamodellen består af 2 relativt simple tabeller:
- DentistChoice indeholder en kæde (dobbeltkødet) af igangværende og afsluttede tandlægevalg. Der er Kæden fører historik på status-ændringer (bemærk: en ny reminder er ikke en statusændring), dvs. når status ændrer sig oprettes en kopi af elementet med ny status, der kædes sammen med den tidligere 'DentistChoice'. Kun ændringer til 'status' giver anledning til nyt element i kæden.
- Reminders indeholde tidspunkter og type på alle reminders til borgere, der er sendt ifm. et givet tandlægevalg.
Eksempel 1
...
- Simpelt tandlægevalg
Her ses et eksempel på en simpel kæde for en ung borger, der oprettes automatisk og umiddelbart derefter vælger en ny tandlæge:
Eksempel 2 - Tandlæge afviser
Her Nedenfor ses et eksempel på en ung borger, der blev oprettet i databasen lige inden vedkommende blev 22 år:
- DentistChoice1: Borger blev oprettet af det automatisk job, der skanner CPR for "snart 22 årige". Borgeren får ikke lige reageret med det samme og når at få 2 reminders. Ved anden reminder ønsker vedkommende ikke flere reminders. Det registreres i elementet (uden historik).
- DentistChoice2: Borger har valgt tandlæge hos Sundhed.dk. Besked til tandlægen er endnu ikke lagt på kø (sker natligt hos SDS). Bemærk: elementet er en kopi af DentistChoice1 med få tilføjelser. Bemærk også, at reminders ikke følger med i kæden.
- DentistChoice3: Det interne job hos SDS har lagt besked på kø, og der afsendes (meget snart) besked via EDI-portalen. Der genereres et requdestID, der gemmes med elementet.
- DentistChoice4: Tandlægen har desværre ikke plads, og melder det tilbage (via EDI-portalen) til NSP servicen. Status opdateres først til 'dentistRejected'.
- DentistChoice5: Umiddelbart efter sættes status til 'noDentist'. Borgeren orienteres om situationen og bedes vælge anden tandlæge. Der går en del tid inden borgeren får taget sig sammen, men denne gang sendes der ikke reminders, for det bad borgeren jo om ikke at få (DentistChoice1).
- DentistChoice6: Svarer til DentistChoice2 men bare med anden tandlæge.
- DentistChoice7: Svarer til DentistChoice3 men bare med anden tandlæge.
- DentistChoice8: Denne tandlæge har plads til borgeren, og status sættes nu til 'dentiskOK'.
, der efter et par reminders vælger en ny tandlæge. Denne tandlæge har desværre ikke plads, og borgeren må prøve igen, hvorefter det lykkes.
Eksempel 3 - Fejl i SOR => kommunikationsfejl
Her ses et eksempel på en ung borger, der blev oprettet i databasen lige inden vedkommende blev 22 år. Ved henvendelse til tandlægen (via EDI-portalen) opstod der en fejl (f.eks. fordi den pågældende tandlæge ikke eksisterer længere, men det er ikke opdateret i SOR). Derfor sendes en fejlbesked til borgeren via digital post, hvor borgeren opfordres til at vælge en ny tandlæge.
Eksempel 4 - Tandlæge tager for lang tid om at svare (timeout)
Her ses et eksempel på en ung borger, der blev oprettet i databasen lige inden vedkommende blev 22 år, men hvor tandlægen ikke reagerer i tide og henvendelsen "timer ud".
Eksempel 5 - Borger fortryder valg efter tandlægen er kontaktet
Her ses et eksempel på en ung borger, der blev oprettet i databasen lige inden vedkommende blev 22 år. Efter det initielle valg, og inden den første tandlæge har nået at svare, fortryder borgeren og vælger en ny tandlæge.
Eksempel 6 - Borger fortryder valg inden tandlægen er kontaktet
Her ses et eksempel på en ung borger, der blev oprettet i databasen lige inden vedkommende blev 22 år. Efter det initielle valg, og inden den første tandlæge er blevet kontaktet, fortryder borgeren og vælger en ny tandlæge.
