Versions Compared

Old Version 2

changes.mady.by.user Jan Riis

Saved on

compared with

New Version Current

changes.mady.by.user Jan Riis

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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
Kømekanisme (Kafka) med to tilhørende topics og queue-listeners for hhv.
  1. række jobs, der håndterer:
    1. afsendelse af Digital Post
(genanvendelse af løsning fra fravalgsprojektet) til borgere
    1. til borgere (første henvendelse, påmindelse, accept/afvisningsbesked, fejl/udløb)
    2. afsendelse af EDI-beskeder
via EDI gateway (ny integration fra NSP backend) - simpel OIDC/REST baseret integration
    1. til tandlæger
    2. slettejob til afdøde og udløbne
  2. En DGWS webservice vendt mod EDI-portalen til modtagelse af truffet valg hos tandlægerne
  3. 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 etc.
Se 1. Overordnet komponentdesign
DDTV Borgervendt
  • En webserver til modtagelse af meget simple "signaler" (aktivering af prædefinerede links, + simpel "tak for svar" HTML side)
    • DDTV
    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
    DDTV NSP service snitfladebeskrivelse
    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
    beskedkomponent
    jobs (2)

    Der skal udvikles

    en beskedkomponent

    jobs, der kan

    modtage notifikationer på to topics:
    • DentistMessageTopic
    • CitizenMessageTopic

    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, detistRejected→Afslag, dentistAccepted→optagelsesbesked, comFailure→'kunne ikke kontakte tandlægen', timeOut→'Tandlægen har trods flere påmindelser ikke taget stilling' ). DDTV databaseelementet skal opdateres med afsendelsesdato. Anvend som udgangspunkt Digital Post komponent på NSP.
    3. Fremsøge de foretagne tandlægevalg (status=dentistChosen & requestID=null) og fremsende anmodning om optagelse via EDI-portalen.
    4. Fremsøge personer i DDTV databasen, som skal have en reminder, afsend disse og tilknyt Reminder-element i DDTV databasen.
    5. Housekeeping:
      1. Fremsøg personer der er døde for 1 år eller mere siden, og slet alle oplysninger i DDTV databasen for disse.
      2. Fremsøg personer der aldrig fik valgt en tandlæge (status noDentist og oprettelsesdato > 2 år siden) og fjern disse records samt evt. tilhørende reminders.
      3. Option: Find tandlægeanmodninger der aldrig blev svaret på fra EDI-portalen og skab "alarm" i alarm-status snitfladen (mål: reagere på  at der er noget galt med timeout mellem EDI portalen og DDTV DGWS snitfladen)
    Der skal til hver topic udvikles en listener, der på baggrund af oplysninger i notifikationen er
    i stand at bygge og afsende en besked til hhv. EDI-gateway og Digital Post gateway.
    		Se DDTV processer og interaktioner
    • forventninger til trafik
    		Der forventes under 1000 meddelelser per døgn
    , og der forventes ikke at skulle opbevares store datamængder i køen (< 10 MB/døgn)
    . Jobs skal køre få gange i døgnet.
    • husregler
    		Komponenten skal overholde de gældende husregler for NSP komponenter
    DDTV
    Webserver
    Tandlægevendt Webservice (3)Der skal udvikles en simpel
    webserver
    DGWS webservice, der kan modtage
    aktivering på prædefinerede links (indeholder udelukkende
    '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. Servicen må først udlevere borgerens CPR-nummer, navn og telefonnummer,
    og et resultat vises for brugeren på en simpel HTML-side.
    når/hvis tandlægen vælger 'accept'.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