Indhold

Komponenter

Dette dokument dækker følgende komponenter på NSP:

• Din Digitale Tandlægevælger (DDTV)

Komponenten dækker 3 services som følger

• Type: IDWS SOAP Webservice

• Filnavn: ddtv-citizen-service.war 

• Url: <serverurl>/ddtv-citizen-service/2025/05/01

• Status-url: <serverurl>/ddtv-citizen-service/status

• Alarm-url: <serverurl>/ddtv-citizen-service/alarm
• DKS-config: <serverurl>/ddtv-citizen-service/dksconfig

• Type: DGWS SOAP Webservice

• Filnavn: ddtv-dentist-service.war

• Url: <serverurl>/ddtv-dentist-service/2025/05/01

• Status-url: <serverurl>/ddtv-dentist-service/status

• Alarm-url: <serverurl>/ddtv-dentist-service/alarm
• DKS-config: <serverurl>/ddtv-dentist-service/dksconfig

• Type: Webservlet
• Filnavn: ddtv-batch-service.war
• Url: <serverurl>/ddtv-batch-service

• Status-url: <serverurl>/ddtv-batch-service/status

• Alarm-url: <serverurl>/ddtv-batch-service/alarm

Konfiguration

Servicekonfiguration

Grundlæggende konfiguration af alle services foregår ved redigering i filen application.properties. For den enkelte service placeres filen i følgende WildFly modul:

/pack/wildfly8/modules/dk/nsp/ddtv/main/

Moduldefinition, som kan anvendes for alle services, findes i kildekoden under:

/etc/wildfly/modules/dk/nsp/ddtv/main/module.xml

I application.properties for DDTV-Citizen servicen kan følgende properties defineres:

I application.properties for DDTV-Dentist servicen kan følgende properties defineres:

I application.properties for DDTV-Batch servicen kan følgende properties defineres:

log4j konfiguration

Log4j konfiguration for alle services findes i samme bibliotek som servicekonfigurationen

Se yderligere opsætning i installationsvejledningen.

Whitelisting

Der foretages whitelisting ved check mod databasen. En ny whitelisting kan tilføjes med følgende SQL insert:

INSERT INTO WHITELIST (cvr, comment)
VALUES ('some-cvr-here', 'some-reason-for-whitelisting-here');

Overvågning

Alle DDTV services udstiller en overvågningsside, som findes i listen af komponenter.

Fortolkning af overvågningsside

Overvågningssiderne returnerer enten:

• HTTP 200, hvis servicen i øjeblikket kører fint.
• HTTP 500, hvis der er opstået en fejl der kræver indgriben.

Audit-logning

Hvert servicekald medfører en ny indgang i auditloggen, som kan være udfyldt med følgende komponenter, afhængig af konteksten:

{
    "time": "2025-09-19T09:04:46.985764854Z",
    "category": "dk.sds.nsp.audit.log",
    "audit": {
        "timestamp": "2025-09-19T11:04:44.736968533+02:00",
        "components": [{
                "component": "DDTV",
                "contexts": [{
                        "context": "applyForNewDentist",
                        "information": [{
                                "key": "patient-id",
                                "type": "RPI",
                                "value": "1811804807"
                            }, {
                                "key": "patient-id-source",
                                "type": "RPI",
                                "value": "OID:1.2.208.176.1.6.1.1"
                            }, {
                                "key": "actor-role",
                                "type": "NPI",
                                "value": "CITIZEN"
                            }, {
                                "key": "actor-id",
                                "type": "NPI",
                                "value": "1811804807"
                            }, {
                                "key": "actor-id-source",
                                "type": "NPI",
                                "value": "CPR"
                            }
                        ]
                    }
                ]
            }
        ]
    },
    "access": {
        "code": 200,
        "duration": 2247,
        "httpHeaders": {
            "Content-Type": "text/xml;charset=UTF-8",
            "SOAPAction": "http://sundhedsdatastyrelsen.dk/ddtv/2025/05/01/#ddtvApplyForNewDentist"
        },
        "httpHost": "localhost",
        "idCardAttributes": {
            "X509Subject": "CN=NSP Test Service Consumer,SERIALNUMBER=UI:DK-O:G:8d3fa047-c77e-47e4-bdd2-e91488610ce6,O=Sundhedsdatastyrelsen,2.5.4.97=NTRDK-33257872,C=DK",
            "dk:gov:saml:attribute:AssuranceLevel": "3",
            "dk:gov:saml:attribute:CprNumberIdentifier": "1811804807",
            "dk:gov:saml:attribute:SpecVer": "DK-SAML-2.0"
        },
        "method": "POST",
        "path": "/ddtv-citizen-service/2025/05/01/",
        "query": "",
        "port": 8080,
        "protocol": "http",
        "reqSize": 12564,
        "resSize": 6493,
        "soapHeaders": {
            "Audience": "https://fsk",
            "Issuer": "TEST1-NSP-STS",
            "NameID": "dk:gov:saml:attribute:CprNumberIdentifier:1811804807",
            "w3Action": "http://sundhedsdatastyrelsen.dk/ddtv/2025/05/01/#ddtvApplyForNewDentist",
            "w3MessageID": "ae528b36-4715-470b-a603-bc4b150a028b"
        },
        "threadId": "default task-1",
        "time": "2025-09-19T11:04:44.736899022+02:00",
        "stats": {
            "handlerDuration": 42,
            "RequestContentDuration": 3,
            "ResponseContentDuration": 0,
            "SecurityProtocolRequestDuration": 17,
            "SecurityProtocolResponseDuration": 20,
            "bufferAllocated": false,
            "usedBuffers": 2,
            "activeBuffersInPool": 2,
            "idleBuffersInPool": 0
        },
        "reqUUID": "f6567a23-dc35-46f2-8ad9-01314fa47750"
    }
}

Baggrundsjobs

Overvågning af baggrundsjobs

Der findes et status og et alarm-endpoint for hver baggrundsjob. De har følgende url'er:

• <serverurl>/batch-service/status
• <serverurl>/batch-service/alarm

De to status-endpoints kan svare følgende

• • Http-kode 200 og Database: OK 
  • Http-kode 500 og Database: Unavailable

De to alarm-endpoints er som udgangspunkt tomme og returnerer 200, men kan give en alarm-besked og status 500, hvis jobbet er i problemer.

Job til identifikation af borgere, der fylder 22 år

Jobbet startes via et HTTP GET kald til <serverurl>/batch-service/scan-citizens-job/start

Jobbets overordnede virkemåde er, at der hentes en liste med borgere med en relevant fødselsdato fra PersonInformation. For hver identificeret borger oprettes en record for borgeren i databasen med status NO_DENTIST (hvis ikke der allerede findes data for borgeren) samt dpStatus READY,som signalerer klar til afsendelse af digital post.

Særligt omkring dette job gælder dog, at da PersonInformation-metoden personsByBirthday kun tager én bestemt dato som parameter, er det vigtigt at jobbet ved hvor langt det er kommet, så der er mulighed for at indhente det forsømte ved at afvikle jobbet for en række datoer. Dette kunne f.eks. være relevant, hvis jobbet skulle have været sat på pause i en periode.  Til dette formål benyttes en BATCH_JOB_STATUS tabel i  databasen, som indeholder hvilken dato jobbet næste gang skal tage udgangspunkt i. 

I praksis gennemfører jobbet følgende trin:

1. Næste dato for afvikling indlæses fra BATCH_JOB_STATUS tabellen. Hvis dette er en fremtidig dato springes afviklingen over.
2. Ud fra dato, beregn den fødselsdato, der skal sendes til PersonInformation. Dette er 22 år før, justeret med 7 dage (konfigurerbart)
3. Brug PersonInformation-servicens personsByBirthday-metode for at hente cprnumre for alle personer født på denne dato.
4. Opret en DentistChoice record i databasen med status NO_DENTIST og digital post status ready (med mindre data for borgeren allerede findes). Dette signalerer at Digital Post jobbet skal sende informationsbrev til borgeren.
5. Afslut med at opdatere BATCH_JOB_STATUS tabellen til næste dato. Normalsituationen er, at dette bliver dato for i morgen, hvis jobbet er færdig med at afvikle for dags dato.

Bemærk: Såfremt det besluttes at starte jobbet fra en fortidig dato når servicen startes første gang, er dette muligt ved på forhånd at indsætte en dato i BATCH_JOB_STATUS tabellen. Eksempel: Såfremt der ønskes initialiseret med dem, der er fyldt 22 indenfor den sidste måned, så kan der oprettes en record med JOB_NAME=ScanCitizens og NEXT_DATE=dags dato - 1 måned.

Job til afsendelse af digital post

Jobbet startes via et HTTP GET kald til <serverurl>/batch-service/digital-post-job/start

Digital Post sendes via NSP-komponenten Digital Post Adapter.

I praksis gennemfører jobbet følgende trin:

1. Der indlæses en liste af DentistChoice records som har dpStatus (digital post status READY).
2. For hver gøres følgende:
   1. Send digital post via Digital Post Adapter. 
   2. Skift DentistChoice dpStatus til SENT, og marker tidspunkt for afsendelse.

Det brev der sendes kan være flere typer, afhængigt af DentistChoice status:

Job til påmindelse af borger

Dette job er beregnet til at sende påmindelsesbreve til borgere, der ikke har reageret på tidligere brev indenfor en vis periode (konfigurerbart).

Jobbet startes via et HTTP GET kald til <serverurl>/batch-service/remind-citizens-job/start

Jobbet fremsøger DentistChoice records fra i databasen, hvor følgende gælder

• Status = NO_DENTIST (der er ikke valgt tandlæge)
• dpStatus  = SENT (der er sendt digital post)
• Der er sendt digital post eller reminder for et stykke tid siden (konfigurerbart)
• Maksimalt antal reminders er endnu ikke sendt.
• Reminders er ikke fravalgt

For disse sendes ny Digital Post i form af et påmindelsesbrev. Digital Post sendes i praksis via NSP-komponenten Digital Post Adapter, på samme måde som Digital Post jobbet gør det.

Job til afsendelse af EDI-beskeder

Jobbet startes via et HTTP GET kald til <serverurl>/batch-service/edi-job/start

Jobbet fremsøger records fra i databasen, hvor følgende gælder

• Status = DENTIST_CHOSEN (der er valgt tandlæge)
• Der er ikke en nyere record for samme borger
• ddtvMayContactDentist er true (det er ikke fravalgt at kontakte tandlægen)

For disse sendes en EDI-besked om, at en borger har valgt en specifik tandlæge. I kaldet indgår en RequestID, som genereres i forbindelse med at EDI-beskeden sendes, og lagres i databasen. Når der senere bekræftes eller afvises via DGWS-servicen til tandlæger, vi denne RequestID blive anvendt til at slå op hvem borgeren var.

EDI-beskeder sendes i praksis via EDI-portalen med en snitflade til formålet udviklet af Nasure.

I praksis gennemfører jobbet følende trin:

1. Alle DentistChoice records med status DENTIST_CHOSEN som nyeste status for en person indlæses fra databasen (batchvist)
2. For hver gøres følgende:
   1. Der oprettes en RequestID som identificerer EDI beskeden
   2. Opret en ny DentistChoice med status DENTIST_CONTACTED
   3. Opret en EDIStatus i en separat tabel, som holder styr på EDI beskeder, der endnu ikke er modtaget Accept eller Reject for.
   4. Send EDI besked. Der medsendes lokationsnummer.

EDI-beskeder sendes i praksis via EDI-portalen, med en snitflade til formålet udviklet af Nasure.

Bemærk:

• Lokationsnummer skulle skulle have været slået op i SOR, men pga. aktuelle begrænsninger i SORES-servicen bruges i stedet lokationsnummer fra DentistChoice, som er medsendt fra Sundhed.dk
• Det vil være en begrænse afvikling af dette job til om natten, hvis dette er muligt, så en borger har mulighed for at vælge om i løbet af dagen, uden at tandlæger kontaktes unødigt.

Job til afsendelse af "se bort fra tidligere EDI"-beskeder

Jobbet startes via et HTTP GET kald til <serverurl>/batch-service/ignore-previous-edi-job/start

Jobbet fremsøger records fra EDIStatus-tabellen databasen, som indeholder data om "udestående" EDI-beskeder. For hver afgøres om en af følgende gælder. 

• Der er ikke nogle data for borgeren (opt out)
• Det er længere samme tandlæge, der er valgt (borgeren har valgt om i mellemtiden)

For disse sendes en EDI-besked om, at en borger har valgt om, og at der skal ses bort fra tidligere EDI. I kaldet indgår den RequestID, som blev sendt i forbindelse med den oprindelige EDI-besked.

EDI-beskeder sendes i praksis via EDI-portalen med en snitflade til formålet udviklet af Nasure.

Job til sletning af data for afdøde borgere, samt borgere, der aldrig svarede

Oprydningsjobbet startes via et HTTP GET kald til <serverurl>/batch-service/cleanup-job/start

Jobbet kaldes for at påbegynde en oprydning af følgende:

• Data for afdøde borgere. Alle registrerede data slettes 1 år efter borgeren personerne er afgået ved døden (konfigurerbart)
• Data for borgere, der har fået tilsendt Digital Post, men stadig ikke har reageret efter 2 år (konfigurerbart)
• Data for udestående EDI beskeder, dvs. sendte beskeder, der ikke er blevet besvaret med dentistAccept eller dentistReject efter 1 måned (konfigurerbart)