1. (A) Registrering og administration - borgerspecifikke sløringer

Opgaven er grundlæggende at etablere en lokal løsning, der benytter metodencreateBlurring(patientID, patientIDClassification, endDateTime)[1]. createBlurring() metodenanvendes både til at skabe, ændre og nedlægge borgerspecifikke sløringer. Hvis du kalder servicen, og der allerede findes en sløringsregistrering for den pågældende patient, så erstattes den tidligere sløringsregistrering med det nye sluttidspunkt. Overskriver du en eksisterende sløring med en ny med sluttidspunktet ”nu”, er det det samme som at nedlægge sløringen.

...

@startuml
participant Fagsystem #72BEDB
participant STS #72BEDB
participant IDSAS #72BEDB

Activate Fagsystem #FF4E26
group Rekvirér SOSI ID-kort (kan caches)
Fagsystem -> STS: NewSecurityTokenService(OCES signatur ...)
Activate STS #FF4E26
return Autentifikationsbevis (SOSI-ID-Kort)
Deactivate STS
end
Fagsystem -> IDSAS: createBlurring(SOSI ID-kort,CPR-nr,...)
Activate IDSAS #FF4E26
return ok?
@enduml

2. Registrering og administration - afdelingssløringer (funktion på vej, 2024)

Tilsvarende opgave er det at registrere og administrere afdelingssløringer. Her vil brugerne typisk være administratorer.

...

Typiske skridt, hvis du skal tilrette et system til at kunne registrere sløringer

i – Aftaler og whitelisting

Der skal laves 4 forskellige aftaler med SDS for at kunne bruge IDSAS i produktion:

...

[2] ”NSP Serviceaftale”. Sådan en har alle regioner i forvejen.

ii –DGWS adgangsbillet

Hvis din bruger eller dit system ikke allerede har et gyldigt ID-kort, skal der rekvireres et sådant hos NSP’ens STS-service. Der er i skrivende stund (sept. 2023) kun krav om ”Den Gode Web Service” niveau 3 (system IDKort), men hvis servicen (i step 3) kaldes med et person IDKort (DGWS niveau4) virker det naturligvis også.

...

STS’en skal betragtes som endnu en DGWS service på NSP, så her skal der også whitelistes. Testmulighederne i de efterfølgende steps gælder også for STS’en, så her er der god hjælp/inspiration at hente. 

iii – Test requests og responses

”Dynamisk Request Generator” (DRG)

I har mulighed for at afprøve og skabe test-requests med ”Dynamisk Request Generator” (DRG). Hvis I ikke allerede har en bruger til DRG, kan I ansøge om en sådan her: https://www.nspop.dk/display/resources/Brugeroprettelse

...

• Link til DRG web klient (når du har et login): https://testkald.nspop.dk/drg/entry
• Eksempel på CreateBlurring, se appendiks 1 – Test af createBlurring() mfl.
• Eksempel på CreateOrgBlurring, se appendiks 3 – Test af createOrgBlurring(), mfl.
• Guide til anvendere af DRG: https://www.nspop.dk/display/public/web/DRG+-+Guide+til+anvendere

”Dynamisk Test Generator” (DTG)

Hvis I har behov for at skabe jeres eget testdatasæt (test-patienter, evt. hvis der er forældre eller børn/unge), kan I bruge ”Dynamisk Test Generator” (DTG):

...

[1] Samtlige regioner er oprettet som DTG-brugere, der oprettes kun et login pr. organisation.

iv – Brug af createBlurring(…), createOrgBlurring(...),listOrgBlurringsforCVR(...) og RemoveOrgBlurring(...)

Nu mangler I så bare at lave koden til at kalde metoden createBlurring(...) på NSP’ens IDSAS service. Servicen er en standard ”Den Gode Web Service” service, hvor adgangsbilletten indlejres i headeren og parametre mv. kommunikeres i body. Hvis I koder i Java eller .NET er der god hjælp at hente i ”SOSI bibliotekerne”:

• Java: https://www.nspop.dk/display/public/web/SEAL.JAVA+-+Guide+til+anvendere
• .NET: https://www.nspop.dk/display/public/web/SEAL.NET+-+Guide+til+anvendere

v - Test og Testmiljøerne på NSP

Der er gode muligheder for at teste din (færdige) løsning mod NSP’ens testmiljøer. Du finder yderligere information om testmiljøerne her:

...

Hvis I ikke allerede har adgang, kan I ansøge om adgang her: Bestillingsark for adgang til testmiljø der skal udfyldes og indsendes til SDS´s Nationale Servicedesk.

Tips og overvejelser

• Det er vigtigt, at den sundhedsfaglige ikke bremses i deres daglige processer, hvis der skulle være udfald i infrastrukturen.

Ændringslog

...