Datamodellen består af 2 relativt simple tabeller:

• DentistChoice indeholder en kæde (dobbeltkødet) af igangværende og afsluttede tandlægevalg. Der er 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'.
• Reminders indeholde tidspunkter og type på alle reminders, der er sendt ifm. et givet tandlægevalg.

Eksempel 1

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'.