Page History
...
Version | Dato | Ansvarlig | Beskrivelse |
1.0 | 29.6.2012 | Systematic | Initiel udgave |
1.1 | 11.3.2013 | Systematic | NPI registreringsservice tilføjet. Refaktorering af NPI Service gennemført i den forbindelse er afspejlet. |
1.1a | 19.4.2013 | Systematic | Udgave til release candidate 1 |
1.2 | 19.6.2013 | Systematic | Kvalitetssikret |
1.3 | 28.11.2014 | Systematic | Nationalt Patientindeks (NPI) erstattet med Dokumentdelingsservice (DDS) |
1.4 | 05.05.2015 | Systematic | Kodereferencer er opdaterede pga. navneskifte fra NPI til DDS |
1.5 | 18.11.2016 | Systematic | Afspejler adfærd for DDS 2.0.1. |
1.6 | 20.09.2017 | Systematic | Tilføjet 3.2.14 med bemærkning om binding til Apache CXF JAXWS-implementation aht. thread local request contexts. |
1.7 | 06.10.2017 | Systematic | ITI-57 UpdateDocumentSet tilføjet. |
1.8 | 26.10.2017 | Systematic | Tilføjet rationale for SLA-logning for udgående kald som fejlet ved forekomst af visse, indlejrede XDS-fejl. |
1.9 | 13.06.2018 | Systematic | Migreret til NSPOP SVN |
| 1.9 | 12.11.2018 | KvalitetsIT | Dokumentation lagt ind på Confluence |
| 2.0 | 21.01.2019 | KvalitetsIT | Afspejler adfærd for DDS 2.1.12 (tilføjet afsnit vedr. adgangsscenarier) |
| 2.1 | 05.06.2020 | KvalitetsIT | Opdateret efter IDWS implementering (https://jira.nspop.dk/browse/SDS-3898) |
Definitioner og referencer
...
overholder Den Gode Web Service 1.0.1 (med få undtagelser som beskrevet i [DDS Registry query snitflade]) samt OIO IDWS for borgeradgang
kræver anvendersystem autentificeret af STS’en på NSP
for sundhedsperson med minimum sikkerhedsniveau 4
for borger med minimum sikkerhedsniveau 3 eller IDWS borgerbilletter
kræver anvendersystem autoriseret, hvilket kontrolleres vha. whiteliste
kræver bruger identificeret ved brug af attributter i en ekstra header, HSUID-headeren.
returnerer SOAPFault ved autentifikations- og autorisationsfejl samt ved visse systemfejl.
...
| Borger (B1+B2) | Sundhedsperson (S1+S3) | Ikke-autoriseret bruger (IA-1) | |
|---|---|---|---|
| Brugertypen | Bestemmes i sikkerhedshandleren for komponenten. En OIO IDWS billet betyder, at brugeren er en borger. Hvis SOSI Idkort benyttes, så bestemmes brugertypen udfra HSUID headers attribut nsi:UserType (værdi 'nsi:Citizen') | Bestemmes udfra HSUID headers attribut nsi:UserType (værdi 'nsi:HealthcareProfessional') | Bestemmes udfra HSUID headers attribut nsi:UserType (værdi 'nsi:HealthcareProfessional' men uden autorisationsid) |
| SOSI id-kort | Niveau 3 (F/VOCES) | Niveau 3 (F/VOCES) eller 4 (MOCES) | Niveau 4 (MOCES) |
| OIO IDWS | Understøttet | Ikke understøttet | Ikke understøttet |
| Brugerens cpr nummer | Hvis OIO IDWS anvedes, så trækkes cpr nummeret ud af IDWS billetten. Hvis DGWS benyttes, så bestemmes det udfra Bestemmes udfraHSUID headers attribut nsi:ActingUserCivilRegistrationNumber | Bestemmes udfra HSUID headers attribut nsi:ActingUserCivilRegistrationNumber For sekrætærer (S3) er det den person, der arbejdes på vegne af, der er relevant. Denne findes i HSUID headers attribut nsi:ResponsibleUserCivilRegistrationNumber For scenariet S1 vil værdien af de to HSUID header attributter være ens. | Bestemmes udfra HSUID headers attribut nsi:ActingUserCivilRegistrationNumber |
| Brugerens autorisationskode | Ikke relevant | Bestemmes udfra HSUID headers attribut nsi:ResponsibleUserAuthorizationCode | Ikke relevant |
| Brugerens rolle | Ikke releavnt | Ikke relevant | Bestemmes ud fra national SEB rolle og læses i SOSI Id-kortet under attributten 'nsi:UserRole' |
...
Der er risiko for sammenblanding af patient-data/behandling af patient-data, hvis ikke CXF’s JAXWS-implementation anvendes.
Anvendelse af security API til validering af sikkerhedsbilletter
Valideringen af de indkommende sikkerhedsbilletter (OIO IDWS, SOSI Idkort) foretages udenfor selve komponenten vha det i security API.
Det er fortsat DDS egen opgave at validere, at den kaldende brugers kald er lovlige/giver mening og overholder de i DDS gældende forretningsregler.
Arkitekturdesign
Dette afsnit beskriver statiske såvel som dynamiske aspekter af systemarkitekturen, herunder baggrunden for de enkelte designvalg.
...
Figur 3: Implementationen af webservice-interfaces
Der findes to alternative WSDL filer for operationen ITI-18 på DDS Registry og ITI-43 for DDS Repository, der gør de muligt at kalde DDS med en OIO IDWS billet. Forretningslogikken for disse snitflader er den samme som de klassiske DGWS snitflader.
Behandling af opslag
DDSRegistryQueryImpl forestår autentifikation og autorisation af anvendersystem vha. DGWSProvider. Som forberedelse til autentifikation og autorisation af bruger af webservicen foretager DDSRegistryImpl parsning og validering af SOAP-headerens HSUID-header vha. ValidatedHsuidAttributes.
...