Opgaven er grundlæggende at etablere en lokal løsning, der benytter metoden createBlurring(patientID, patientIDClassification, endDateTime)[1]. createBlurring() metoden anvendes 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.

[1] Se beskrivelse af parametre, fejlbeskrivelser etc. i snitfladebeskrivelsen her: Guide til anvender - opret sløring


Figur 1: Registrering foretages gennem et simpelt DGWS niveau 3+ kald til NSP'ens IDSAS createBlurring(...) metode.

  1. Når en sundhedsfaglig opretter en sløring på en patient, sker dette i et lokalt system fx EPJ-system. Systemet kalder createBlurring.
  2. Kaldet udføres med et system IDKort, IDkortet indeholder et CVR nummer(Org-ID) samt Patient-ID og slut tidspunkt for sløringen.
  3. Oplysningerne registreres i databasen.


FagsystemFagsystemSTSSTSIDSASIDSASRekvirér SOSI ID-kort (kan caches)NewSecurityTokenService(OCES signatur ...)Autentifikationsbevis (SOSI-ID-Kort)createBlurring(SOSI ID-kort,CPR-nr,...)ok?

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.

Opgaven er grundlæggende at etablere en lokal løsning, der benytter metoderne createOrgBlurring(), listOrgBlurringsforCVR() og RemoveOrgBlurring() [2]. Metoderne anvendes både til at skabe, liste og nedlægge afdelings sløringer. 

[2] Se beskrivelse af parametre, fejlbeskrivelser etc. i snitfladebeskrivelsen her: Guide til anvender - afdelingssløring

Figur 2: Registrering og administration af afdelingssløringer. 


AdministrationssystemAdministrationssystemSTSSTSIDSASIDSASRekvirér SOSI ID-kort (kan caches)NewSecurityTokenService(OCES signatur ...)Autentifikationsbevis (SOSI-ID-Kort)createOrgBlurring(orgID, orgClassification)ok?

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:

  1. En sundhedsdatanetaftale og tilsvarende tilslutning[1].
  2. En NSP serviceaftale[2].
  3. En specifik databehandleraftale mellem jer som dataansvarlige for det registrerede og Sundhedsdatastyrelsen som databehandler.
  4. En ’whitelistning’ af det (eller de) system(er), som registrerer sløringerne.

Det er en god idé at få aftaleprocesserne igangsat som noget af det første, så I ikke senere bliver bremset af manglende aftaler.

Whitelist: Opret supporthenvendelse om ’whitelistning’ til IDSAS servicen på NSP. Der skal whitelistes til både Test og Produktion.
Find IDSAS i listen

Figur 3: Screenshot fra whitelist-siden.

Beskriv at det drejer sig om whitelistning ift. IDSAS. Du skal i processen være klar til at give oplysninger om det kaldende system mv.

Produktionopsætning særligt for regionerne: Læse mere her Region brug af dNSP i forbindelse med sløring og MinLog registrering


[1] Det har alle regioner i forvejen, men det skal sikres, at det integrerende system har sikker adgang til SDN.

[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å.

Det bliver for omstændeligt at beskrive i detaljer, hvordan du rekvirerer et IDKort (og du har sikkert også gjort det i andre sammenhænge), men du kan læse mere om det her:

Hvis det er et System-IDkort, du vil skabe, skal du bruge: /sts/services/NewSecurityTokenService, og i dit request skal du medsende et autentifikationsbevis baseret på et ”systemcertifikat”. Læs evt. mere om dem på https://www.mitid-erhverv.dk/avanceret/certifikater/.

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

I Webformen kan I ikke vælge ”Dynamisk Request Generator” så derfor udfyldes i stedet supplerende oplysninger med ønsket om at benytte DRG.

DRG giver et ret godt billede af, hvordan servicekaldene er opbygget og hvordan svarene ser ud, både når det lykkes og når det fejler:

”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):

https://www.nspop.dk/display/resources/Brugeroprettelse[1]

I Webformen skal I vælge ”Dynamisk Test Generator” og angive en passende begrundelse, f.eks.

[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”:

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

1.0

2023-09-21

Side oprettetSDS
1.1 

2023-10-16

Uddybning af registreringsflowAnni
1.2

2024-01-03

Tilføjelse af afdelingssløringJan
1.3

2024-03-14

Tilføjelser om anvendelse af dNSPAnni
1.4

2024-04-30

Tilføjelser i forhold til afdelingssløringAnni




  • No labels