Projektet gennemføres som et agilt projekt, og der udarbejdes således ikke en egentlig kravspecifikation til projektet. Nedenfor listes de elementer, som løsningen forventes at indeholde. Der henvises endvidere til arkitektur-afsnittet her projektsiden.

BEMÆRK: Projektet forventes ikke at kræve ændringer i eksisterende services eller komponenter på NSP!


Komponent / OmrådeKrav/ØnskerYderligere info
Komponentoverblik
  1. "Din Digitale TandlægeVælger" borgervendt NSP service (OIO-IDWS) med bagvedliggende database
  2. En række jobs, der håndterer:
    1. afsendelse af Digital Post til borgere (første henvendelse, påmindelse, accept/afvisningsbesked, fejl/udløb)
    2. afsendelse af EDI-beskeder til tandlæger
    3. slettejob til afdøde og udløbne
  3. En DGWS webservice vendt mod EDI-portalen til modtagelse af truffet valg hos tandlægerne
  4. Diverse housekeeping
    1. Slette tandlægevalg, et år efter borgeren er død
    2. Påmindelsesjob til at 'nudge' 22 årige til at foretage et valg
Se 1. Overordnet komponentdesign
DDTV Borgervendt NSP service (1)Der skal udvikles en OIO-IDWS webservice. Eneste kendte anvender af servicen er pt. Sundhed.dk,
og udstilles derfor i første omgang kun DCC'en på cNSP. Selve servicen skal ligge i NSP-backoffice.
  • metoder

Analysen hidtil indikerer, at servicen skal indeholde følgende metoder:

Se 3a. DDTV Borgervendt IDWS snitflade 
  • flows
Servicen skal indgå i en række kendte flows.Se DDTV processer og interaktioner
  • forventninger til trafik
Servicen er en "low trafic" service. Der forventes under 1000 kald per døgn, og
 der forventes ikke at skulle opbevares store datamængder i løsningen (total < 1TB, vækst < 36.5 MB/år)
  • husregler
Servicen og bagvedliggende komponenter skal overholde de gældende husregler for NSP komponenter
  • option: befuldmægtigede
Servicen bør udarbejdes, så den understøtter befuldmægtigede og evt. forældreadgang.
DDTV jobs (2)

Der skal udvikles jobs, der kan tage sig af følgende:

  1. Fremsøge personer, der fylder 22 år om X dage (X konfigureres) og oprette dem i DDTV databasen (dpStatus 'ready')
  2. Fremsøge personer i DDTV databasen, som har dpStatus 'ready' og sende Digital Post til dem. Hvilken besked, der skal sendes, afhænger af den nye status på DentistChoiceElementet (noDentist→Anmodning, dentistContacted→'Vi har kontaktet tandlæge ... for dig ...', detistRejected→Afslag, dentistAccepted→optagelsesbesked). DDTV databaseelementet skal opdateres med afsendelsesdato. Anvend som udgangspunkt Digital Post komponent på NSP.
    Speciel: hvis status på DentistChoiseElementet er dentistChosen skal der også sendes besked til tandlægen via EDI-portalen (og DDTV databasen skal opdateres).
  3. Fremsøge personer i DDTV databasen, som skal have en reminder, afsend disse og tilknyt Reminder-element i DDTV databasen.
  4. Fremsøg personer, der er døde for 1 år eller mere siden, og slet alle oplysninger i DDTV databasen for disse.
Se DDTV processer og interaktioner
  • forventninger til trafik
Der forventes under 1000 meddelelser per døgn. Jobs skal køre få gange i døgnet.
  • husregler
Komponenten skal overholde de gældende husregler for NSP komponenter
DDTV Tandlægevendt Webservice (3)Der skal udvikles en simpel DGWS webservice, der kan modtage 'accept' eller 'afvisning' af opfordring til at komme i tandpleje hos en bestemt tandlæge. Svaret baseret på en en GUID, der på serversiden resolver til borgeren + hhv. 'accept' eller 'afvis'). Resultatet gemmes i databasen. Servicen udstilles på cNSP'ens DCC og skal certifikat-whitelistes, så kun EDI-portalen kan nå den.Se DDTV processer og interaktioner
  • forventninger til trafik
Servicen er en "low trafic" service. Der forventes under 1000 kald per døgn. Servicen giver ikke anledning til , og
 der forventes ikke at skulle opbevares store datamængder.
  • husregler
Servicen og bagvedliggende komponenter skal overholde de gældende husregler for NSP komponenter