Page History
...
| NSP | National Service Platform |
| SFSK | Synkroniseringsservice til Fælles Stamkort |
| DGWS | Den Gode WebService |
| BRS | Behandlingsrelationsservice |
| SEAS | Stamdata autorisation enkeltopslagsservice |
Overblik over SFSK
SFSK er en service til at gøre det muligt at fremsøge og hente Fælles Stamkort via snitflader, som de kendes fra Dokumentdelingsservice Registry og Repository (se DDS - Design- og Arkitekturbeskrivelse (Registry) og DDS - Design- og Arkitekturbeskrivelse (Repository)).
...
SFSK kan opfattes som en alternativ DDS, som har til formål at udstille data for anvenderne i forbindelse med Fælles Stamkort.
SFKS har til ansvar at:
- sikkerhedsvalidere Sikkerhedsvalidere kald fra anvendersystemer
- hente Hente data i de bagvedliggende registre FSK Registry og FSK
- foretage de nødvendige tjek i forhold til dataspærringer i MinSpærring i forbindelse med fremsøgning af stamkort (da SFSK kun skal anvendes af systembrugere giver filtrering i forhold til spærringer mod enkeltpersoner) ikke mening i SFSK
- foretage auditlogning
- Foretage auditlogning
- SEAS kaldes når der bliver kald som en "Sundhedsfaglig på vegne af", hvor autorisationskoden valideres
- Minlog skrive til ve fremsøgning af dokumenthetning
- BRS når en sunhedsfaglig kalder servicen.
SFSK indgår i samspil med de øvrige NSP services på følgende måde:
| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Relevante tredjepartsbiblioteker
...
SFSK anvender følgende NSP libraries:
- audit-api
- security-api
Løsningens opbygning
Nedenstående diagram viser den interne opbygningen af SFSK.
I designet er der lagt vægt på at definere en fornuftig struktur, hvor begge SFSK services er opbygget på en ensartet måde.
| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Ovenstående diagram viser, hvorledes en SFSK ITI-18 og ITI-43 services er opbygget.
Selve service interface og implementation er placeret i pakkerne dk.nsp.sfsk.ws(.impl). Klasserne i disse pakker er ansvarlige for at modtage requests fra anvenderne på de for SFKS definerede snitflader. Ved at anvende klasser i pakken dk.nsp.sfsk.security valideres det, at den indkommende sikkerhedsbillet er valid og overholder de, for SFKS, definerede krav (se sikkerhedshåndtering i SFSK nedenfor).
Klasserne i pakkerne dk.nsp.sfsk.ws(.impl) indeholder funktionalitet der har til formål at:
- Validere det indkommende request (se afsnit nedenfor vedr. validering)
- Konvertere de indkommende requests til domæneklasser (som defineret i biblioteket openehealth) til brug for selve forretningsservices i SFSK.
Hvis sikkerhedsvalideringen eller konverteringen i SFSK ikke er succesfuld, så returnerer SFSK passende fejlbesked til den kaldende anvender.
Ellers sendes kaldet videre til SFSKs forretningslag.
Klasserne i pakkerne dk.nsp.sfsk.serivce(.impl) indeholder forretningsfunktionaliteten (se de to afsnit ved Forretningsregler nedenfor)
Integrationen til MinSpærring er implementeret i separat modul og anvendelsen er afkoblet fra forretningslaget ved hjælp af interfaces (se dk.nsp.sfsk.components).
Kaldende fra SFSK proxy'es videre til backends ved implementation i pakken dk.nsp.sfsk.backend(.impl).
Implementationsklasser til kommunikation med backends og MinSpærring kan alle trække på moduler til håndtering af SFSKs eget SOSI Idkort i pakken dk.nsp.sfks.security.
Sikkerhedshåndtering og forretningsregler i SFSK
I det følgende beskrives sikkerhedshåndteringen og forretningsreglerne i SFKS. Først beskrives sikkerhedsprotokollen.
Dernæst beskrives flowet for de to services til hhv fremsøgning og hentning af dokumenter.
Sikkerhedshåndtering i SFSK
Brugertyper
SFSK anvender det på platformen udstillede security-api til at validere de indkommende requests. Alle kald til SFKS skal være lovlige DGWS kald. SFSK understøtter følgende brugertyper:
...
ID
...
Som en...
...
ønsker jeg at..
...
så jeg...
...
Sundhedsfaglig med national rolle
...
Sikkerhedshåndtering og forretningsregler i SFSK
I det følgende beskrives sikkerhedshåndteringen og forretningsreglerne i SFKS. Først beskrives sikkerhedsprotokollen.
Dernæst beskrives flowet for de to services til hhv fremsøgning og hentning af dokumenter.
Sikkerhedshåndtering i SFSK
Brugertyper
SFSK anvender det på platformen udstillede security-api til at validere de indkommende requests. Alle kald til SFKS skal være lovlige DGWS kald. SFSK understøtter følgende brugertyper:
ID | Som en... | ønsker jeg at.. | så jeg... |
|---|---|---|---|
| B1 | Borger | fremsøge dokumentreferencer til egne dokumenter | kan se mine egne data |
| B2 | Borger på vegne af | fremsøge dokumentreferencer til en anden borgers dokumenter | kan se data for denne person, som jeg har en relation til |
| SF1 | Sundhedsfaglig med autorisation | fremsøge dokumentreferencer til en borgers data | kan se data for denne borger |
| IA-1 | Sundhedsfaglig med national rolle | fremsøge dokumentreferencer til en borgers data | kan se dokumenter for denne borger af de typer, som min rolle giver mig adgang til |
| SY | Systembruger | fremsøge dokumentreferencer til en borgers data | kan se data for denne borger |
Uddybende beskrivelse af de enkelte brugertyper samt skema der identificere en brugertype ud fra Security API.
Bestemmelse og mapning til actor
Borger
Borgerkald sker fra sundhed.dk via system-id-kort udstedt af sundhed.dk.
Der medsendes også en HsuidHeader og indholdet af den afgør om det er et borgerkald eller en systembruger. Oplysningerne på billetten fra Security API'er er identisk med oplysningerne for en systembruger.
Sundhed.dk anvender i dag et systemopslag til at hente Fælles Stamkort, da DDS ikke understøttede borgeropslag via IDWS. Sundhed.dk er dermed trustet til at lave borgeropslag på vegne af borgeren.
For borgerkald laves der ikke registreringer i minlog og der kontrolleres ikke for behandlingsrelation.
| Brugertypen: Borger | Verifikation | Mapning til SfskActor | ||
| SecurityContext | Ticket | Audience | Verificeres ikke - må gerne være der | |
| Validity | Er valid | |||
| Message | Verificeres ikke - må gerne være der | |||
| ActingUser | Må ikke være der | |||
| PrincipalUser | Må ikke være der | |||
| Organisation | Identifier | Skal være der | actorId | |
| IdentifierFormat | Skal være der og skal være CVR | actorIdType | ||
Borger på vegne af anden borger
Fuldmagtsbaseret borgeropslag
Uddybende beskrivelse af de enkelte brugertyper samt skema der identificere en brugertype ud fra Security API.
Bestemmelse og mapning til actor
Borger
Borgerkald sker fra sundhed.dk via system-id-kort udstedt af sundhed.dk.dk. Sundhed.dk er trustet til at lave fuldmagtsopslag fra en borger på vegne af en anden borger.
Der medsendes også en HsuidHeader og indholdet af den afgør om det er et borgerkald eller en borger der kalder på vegne af en anden borger - eller om det er en systembruger. Oplysningerne på billetten fra Security API'er er identisk med oplysningerne for en systembruger.
Sundhed.dk anvender i dag et systemopslag til at hente Fælles Stamkort, da DDS ikke understøttede borgeropslag via IDWS. Sundhed.dk er dermed trustet til at lave borgeropslag på vegne af borgeren.
For borgerkald laves der ikke registreringer i minlog Når der kaldes på vegne af en anden borger skal der laves en minlog registrering og der kontrolleres ikke for behandlingsrelation.
| Brugertypen: Borger på vegne af anden borger | Verifikation | Mapning til SfskActor | ||
| SecurityContext | Ticket | Audience | Verificeres ikke - må gerne være der | |
| Validity | Er valid | |||
| Message | Verificeres ikke - må gerne være der | |||
| ActingUser | Må ikke være der | |||
| PrincipalUser | Må ikke være der | |||
| Organisation | Identifier | Skal være der | actorId | |
| IdentifierFormat | Skal være der og skal være CVR | actorIdType | ||
Borger på vegne af anden borger
Fuldmagtsbaseret borgeropslag fra sundhed.dk via system-id-kort udstedt af sundhed.dk. Sundhed.dk er trustet til at lave fuldmagtsopslag fra en borger på vegne af en anden borger.
Der medsendes også en HsuidHeader og indholdet af den afgør om det er en borger der kalder på vegne af en anden borger - eller om det er en systembruger. Oplysningerne på billetten fra Security API'er er identisk med oplysningerne for en systembruger.
...
Sundhedsfaglig med autorisation
Sundhedsfaglig opslag fra Sundhedsjournalen (og andre whitelistede fagsystemer) med medarbejderbaseret-id-kort (niveau 4). Sundhedsfaglige med autorisation, kan lave opslag på borgerens Fælles stamkort via Sundhedsjournalen
Der laves minlog registrering og der kontrolleres for behandlingsrelation.
| Brugertypen: Sundhedsfaglig med autorisation | Verifikation | Mapning til SfskActor | ||
| SecurityContext | Ticket | Audience | Verificeres ikke - må gerne være der | |
| Validity | Er valid | |||
| Message | Verificeres ikke - må gerne være der | |||
| ActingUser | UserType | Skal være HealthcareProfessional | actorType | |
| IdentifierFormat | Skal være CPR | actorIdType | ||
| Identifier | Skal være sat | actorId | ||
| GivenName | ||||
| Verificeres ikke - må gerne være der |
| SurName |
| Verificeres ikke - må gerne være der |
| Credentials.AuthorizationCode | Skal være sat | |||
| Credentials.NationalRole | Verificeres ikke - må gerne være der | |||
| PrincipalUser | Må ikke være der | |||
| Organisation | Identifier | Skal være der |
| IdentifierFormat | Skal være der og skal være CVR |
| Client | Verificeres ikke - må gerne være der |
Ikke-autoriseret sundhedsfagligSundhedsfaglig med autorisation
Sundhedsfaglig opslag fra Sundhedsjournalen (og andre whitelistede fagsystemer) med medarbejderbaseret-id-kort (niveau 4) . Sundhedsfaglige med autorisation, kan lave opslag på borgerens Fælles stamkort via Sundhedsjournalenhvor national rolle er tilknyttet (nspSundAssistR1 og nspSundAssistR2 giver adgang til Fælles Stamkort)
Der laves minlog registrering registering og der kontrolleres for behandlingsrelation.
| Brugertypen: Sundhedsfaglig med |
| national rolle | Verifikation | Mapning til SfskActor | ||
| SecurityContext | Ticket | Audience | Verificeres ikke - må gerne være der | |
| Validity | Er valid | |||
| Message | Verificeres ikke - må gerne være der | |||
| ActingUser | UserType | Skal være HealthcareProfessional | actorType | |
| IdentifierFormat | Skal være CPR | actorIdType | ||
| Identifier | Skal være sat | actorId | ||
| GivenName | Verificeres ikke - må gerne være der | |||
| SurName | Verificeres ikke - må gerne være der | |||
| Credentials.AuthorizationCode | ||||
| Må ikke være |
| der | ||
| Credentials.NationalRole |
| Skal være der - og skal matche national rolle der er opsat i properties i SFSK | ||||
| PrincipalUser | Må ikke være der | |||
| Organisation | Identifier | Skal være der | ||
| IdentifierFormat | Skal være der og skal være CVR | |||
| Client | Verificeres ikke - må gerne være der |
Ikke-autoriseret Sundhedsfaglig på vegne af anden sundhedsfaglig
Sundhedsfaglig opslag fra Sundhedsjournalen (og andre whitelistede fagsystemer) med medarbejderbaseret-id-kort (niveau 4) hvor national rolle er tilknyttet (nspSundAssistR1 og nspSundAssistR2 giver adgang til Fælles Stamkort)
Der medsendes også en HsuidHeader og indholdet af den afgør om det er en sundhedsfaglig der kalder på vegne af en anden sundhedsfaglig. Oplysningerne på billetten fra Security API'er er identisk med oplysningerne for en medarbejder.
Der laves minlog registering for begge sundhedsfaglige og der kontrolleres for behandlingsrelation
| Brugertypen: Sundhedsfaglig med national rollepå vegne af anden sundhedsfaglig | Verifikation | Mapning til SfskActor | ||
| SecurityContext | Ticket | Audience | Verificeres ikke - må gerne være der | |
| Validity | Er valid | |||
| Message | Verificeres ikke - må gerne være der | |||
| ActingUser | UserType | Skal være HealthcareProfessional | actorType | |
| IdentifierFormat | Skal være CPR | actorIdType | ||
| Identifier | Skal være sat | actorId | ||
| GivenName | Verificeres ikke - må gerne være der | |||
| SurName | Verificeres ikke - må gerne være der | |||
| Credentials.AuthorizationCode | Må ikke være der | |||
| Credentials.NationalRole | Skal være der - og skal matche national rolle der er opsat i properties i SFSK | |||
| PrincipalUser | Må ikke være der | |||
| Organisation | Identifier | Skal være der | ||
| IdentifierFormat | Skal være der og skal være CVR | |||
| Client | Verificeres ikke - må gerne være der | |||
Sundhedsfaglig på vegne af anden sundhedsfaglig
Systembruger
Systembaserede Sundhedsfaglig opslag fra Sundhedsjournalen (og andre whitelistede fagsystemer ) med medarbejderbaseretvia system-id-kort (niveau 4)
Der medsendes også en HsuidHeader og indholdet af den afgør om det er en sundhedsfaglig der kalder på vegne af en anden sundhedsfaglig. Oplysningerne på billetten fra Security API'er er identisk med oplysningerne for en medarbejder.
Der laves minlog registering for begge sundhedsfaglige og der kontrolleres for behandlingsrelation
. Fagsystemer kan enten lave systembaserede opslag, eller via systembaserede opslag opbygge en en lokal registerkopi af Fælles Stamkort, som holdes opdateret ud fra adviseringer fra underliggende registre
Der laves ikke minlog registrering (Det er fagsystemets ansvar at gøre dette) og der kontrolleres ikke for behandlingsrelation (Det er fagsystemets ansvar at gøre dette).
| Brugertypen: Systembruger |
| Verifikation | Mapning til SfskActor | |||
| SecurityContext | Ticket | Audience | Verificeres ikke - må gerne være der | |
| Validity | Er valid | |||
| Message | Verificeres ikke - må gerne være der | |||
| ActingUser | ||||
| Må ikke være der | ||||
| PrincipalUser | Må ikke være der | |||
| Organisation | Identifier |
| Skal være |
| der |
| actorId |
| IdentifierFormat | Skal være der og skal være |
| CVR |
| actorIdType |
Transformation af brugertyper
Ved kald til SFSK kan en systembruger i virkeligheden være et kald fra en anden brugertype. Det er informationer på HsuidHeaderen der afgør om den skal transformeres til en anden brugertype. Der findes følgende tranformationer:
| Gliffy Diagram | ||||||
|---|---|---|---|---|---|---|
|
System >> Brugertypen Borger | Verifikation | Mapning til SFSK ServiceActor | ||
HSUID Header | userType | |||
Skal være der og skal være |
Systembruger
Systembaserede opslag fra whitelistede fagsystemer via system-id-kort. Fagsystemer kan enten lave systembaserede opslag, eller via systembaserede opslag opbygge en en lokal registerkopi af Fælles Stamkort, som holdes opdateret ud fra adviseringer fra underliggende registre
Der laves ikke minlog registrering (Det er fagsystemets ansvar at gøre dette) og der kontrolleres ikke for behandlingsrelation (Det er fagsystemets ansvar at gøre dette).
CITIZEN | Brugertypen: Borger | |||
actingUserCivilRegistrationNumber | Skal være der | ActingUserCpr | ||
responsibleUserRegistrationNumber | Må ikke være der | |||
orgUsingIDType | Verificeres ikke - må gerne være der | |||
orgUsingIDName | Verificeres ikke - må gerne være der | |||
systemName | Verificeres ikke - må gerne være der | |||
systemVersion | Verificeres ikke - må gerne være der | |||
userAuthorizationCode |
Verificeres ikke - må gerne være der |
Transformation af brugertyper
Ved kald til SFSK kan en systembruger i virkeligheden være et kald fra en anden brugertype. Det er informationer på HsuidHeaderen der afgør om den skal transformeres til en anden brugertype. Der findes følgende tranformationer:
| Gliffy Diagram | ||||||
|---|---|---|---|---|---|---|
|
System >> Brugertypen Borger på vegne af | Verifikation | Mapning til SFSK ServiceActor | ||
HSUID Header | userType | Skal være der og skal være CITIZEN | Brugertypen: Borger på vegne af | |
actingUserCivilRegistrationNumber | Skal være der (valideres indirekte ved at relation med responsibleUser skal være tilstede) | ActingUserCpr | ||
responsibleUserRegistrationNumber | Skal være sat Skal være forskellige fra actingUserCivilRegistrationNumber | ResponsibleUserCpr | ||
relation | Skal være sat og en af følgende skal returnere true: isRelationChildCustodyHolder isRelationProxyHolder | relation | ||
orgUsingIDType | Verificeres ikke - må gerne være der | |||
orgUsingIDName | Verificeres ikke - må gerne være der | |||
systemName | Verificeres ikke - må gerne være der | |||
systemVersion | Verificeres ikke - må gerne være der | |||
userAuthorizationCode | Verificeres ikke - må gerne være der | |||
System >> Brugertypen System | |||||
| Verifikation | Mapning til SFSK ServiceActor | ||||
HSUID Header | userType | SkalMå ikke være der | og skal være CITIZENBrugertypen: BorgerSystem | ||
actingUserCivilRegistrationNumber | Skal Må ikke være der | ActingUserCpr||||
responsibleUserRegistrationNumber | Må ikke være der | ||||
orgUsingIDType | Verificeres ikke - må gerne være der | ||||
orgUsingIDName | Verificeres ikke - må gerne være der | ||||
systemName | Verificeres ikke - må gerne være der | ||||
systemVersion | Verificeres ikke - må gerne være der | ||||
userAuthorizationCode | Verificeres ikke - må gerne være der | ||||
System Medarbejder >> Brugertypen Borger Sundhedsfaglig på vegne af af anden sundhedsfaglig | Verifikation | Mapning til SFSK ServiceActor | |||||
HSUID Header | userType | Skal være der og skal være CITIZENHEALTHCAREPROFESSIONAL | Brugertypen: Borger Sundhedsfaglig på vegne af anden sundhedsfaglig | ||||
actingUserCivilRegistrationNumber | Skal være der (valideres indirekte ved at relation med responsibleUser skal være tilstede) | ActingUserCpr | responsibleUserRegistrationNumber | Skal være sat Skal være forskellige fra actingUserCivilRegistrationNumber | ResponsibleUserCpr | ||
responsibleUserRegistrationNumber | Skal være sat Skal være forskellige fra actingUserCivilRegistrationNumber | ResponsibleUserCpr | |||||
orgUsingIDType | Verificeres ikke - må gerne være der | ||||||
orgUsingIDName | Verificeres ikke - må gerne være der | ||||||
systemName | Verificeres ikke - må gerne være der | ||||||
systemVersion | Verificeres ikke - må gerne være der | ||||||
userAuthorizationCode | Skal være sat og | relation | orgUsingIDType | Verificeres ikke - må gerne være der | orgUsingIDName | Verificeres ikke - må gerne være der | systemName | Verificeres ikke - må gerne være der | systemVersion | Verificeres ikke - må gerne være der | userAuthorizationCode | Verificeres ikke - må gerne være der |
System >> Brugertypen System | Verifikation | Mapning til SFSK ServiceActor | HSUID Header | userType | Må ikke være der | actingUserCivilRegistrationNumber | Må ikke være der | responsibleUserRegistrationNumber | Må ikke være der | orgUsingIDType | Verificeres ikke - må gerne være der | orgUsingIDName | Verificeres ikke - må gerne være der | systemName | Verificeres ikke - må gerne være der | systemVersion | Verificeres ikke - må gerne være der | userAuthorizationCode | Verificeres ikke - må gerne være der |
Medarbejder >>
Brugertypen Sundhedsfaglig på vegne af anden sundhedsfaglig
HSUID Header
Brugertypen: Sundhedsfaglig på vegne af anden sundhedsfaglig
actingUserCivilRegistrationNumber
Skal være der
(valideres indirekte ved at relation med responsibleUser skal være tilstede)
responsibleUserRegistrationNumber
Skal være sat
Skal være forskellige fra actingUserCivilRegistrationNumber
orgUsingIDType
Verificeres ikke - må gerne være der
orgUsingIDName
Verificeres ikke - må gerne være der
systemName
Verificeres ikke - må gerne være der
systemVersion
Verificeres ikke - må gerne være der
userAuthorizationCode
Skal være sat og valideres med responsibleUser
Brugertyperne bliver til sidst valideret for:
- Alle roller, hvis hsuid header medsendt:
- hsuid rollen skal matche den på security context
- hsuid acting user cpr skal matche den aktøren
- Borger på vegne af
- Der skal være en relation
Kald af bagvedliggende services
Når SFSK kalder videre til de bagvedliggende services sker dette også vha DGWS. Dog trækker SFSK sit eget niveau 3 SOSI Idkort i den videre kommunikation med de bagvedliggende services. Identiteten af kaldet skifter således til at være et kald udført af SFSK, hvilket betyder at der kan udføres whitelisting i FSK til at tillade niveau 3 idkort fra det CVR nummer, som er identificeret i SFSKs Idkort.
SFSK har sin egen whitelistingtabel, hvor subject serialnumber for det kaldende certifikat skal være whitelistet. Se SFSK - Driftsvejledning for detaljer.
Der skal ikke være mulighed for værdispring i løsningen.
Flow i forbindelse med "Søg dokumenter" i SFSK
Når et kald er blevet sikkerhedsvalideret sker der en validerering af det indkommende request. Der tale om en simpel validering, der tjekker, om det indkommende ITI-18 request er lovligt i henhold til standarden IHE XDS.
Sekvensdiagrammerne nedenfor beskriver flowet i forbindelse med "søg dokumenter". Flowet minder om det tilsvarende flow i Dokumentdelingsservicen, men er simplere, da der ikke tjekkes for spærringer mod enkeltpersoner ligesom kaldet til Behandlingsrelationservice udelades.
| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Filtrering af data via MinSpærring
De fundne metadata filtreres ved at tjekke i MinSpærring verifikationssnitfladen, om der eksisterer spærringer mod mod et af de fundne dokumenter. Et dokument tjekkes ved at at kigge på alle organisationer (sor-koder), der har redigeret dokumentet, på alle relevante tidspunkter. Disse tidspunkter er ServiceStartTime og ServiceStopTime, hvis de er tilstede, samt CreationTime for dokumenter af typen Stable, og 'nu' (opslagstidspunktet) for dokumenter af typen OnDemand. Hvis der for en eneste af disse kombinationer af sor-kode og tidspunkt er angivet andet end positivt samtykke, så filtreres dokumentet fra.
...
valideres med responsibleUser | AuthorizationCode |
2 Kald til Behandlingsrelationsservice (BRS)
Der tjekkes for behandlingsrelation, når SFSK bliver kaldt af en sunhedsfarlig.
| Tjek for behandlingsrelation | Fremsøg stamkort | Hent stamkort |
| Borger | Der kontrolleres ikke for behandlingsrelation | Der kontrolleres ikke for behandlingsrelation |
| Borger på vegne af | Der kontrolleres ikke for behandlingsrelation | Der kontrolleres ikke for behandlingsrelation |
| Sundhedsfaglig m. autorisation | Der kontrolleres for behandlingsrelation | Der kontrolleres for behandlingsrelation |
| Sundhedsfaglig m. national rolle | Der kontrolleres for behandlingsrelation | Der kontrolleres for behandlingsrelation |
| Sundhedsfaglig på vegne af sundhedsfaglig | Der kontrolleres for behandlingsrelation | Der kontrolleres for behandlingsrelation |
| Systembruger | Der kontrolleres ikke for behandlingsrelation | Der kontrolleres ikke for behandlingsrelation |
svaret fra BRS anvendes ikke til at spærre for noget, da det ikke er sikkert, at evidensgrundlaget er på plads i BRS på opslagstidspunktet.
Følgende tabel viser, hvor oplysningerne i bestillingen af opfølging i BRS stammer fra:
| Felt i TreatmentRelationRequest | Hvor stammer oplysningen fra i kald mod DDS? |
|---|---|
| PatientCpr | Borgerens CPR nummer (som opslaget drejer sig om) |
| HealthcareProfessionalCpr | Opslaget stammer fra en sundhedsprofessionelle bruger, derfor anvendes der CPR nummer af af den sundhedsprofessionelle (som angivet i HSUID headeren nsi:ActingUserCivilRegistrationNumber). |
| AuthorisationIdentifer | Hvis kaldet indeholder en autorisationskode (som angivet i HSUID headeren nsi:ResponsibleUserAuthorizationCode), så medsendes denne |
| OrganisationIdentifier | Organisationen (som angivet i HSUID headeren nsi:OrgUsingID) |
| ExternalReferenceId | Udfyldes med defaultværdi for SFSK (som angivet i konfigurationsparameteren treatment.relation.external.reference.id) Nuværende værdi: tom |
| QueryableCvr | Udfyldes med defaultværdi for SFSK (som angivet i konfigurationsparameteren sfsk.dgws.cvr) Nuværende værdi: 30808460 |
| AcceptableRelations | Udfyldes med defaultværdi for SFSK (som angivet i konfigurationsparameteren treatment.relation.acceptable.relations)
|
| FollowupRelations | Udfyldes med defaultværdi for SFSK (som angivet i konfigurationsparameteren treatment.relation.followup.relations)
|
| RelationLookupTimeInterval | Fradato sættes til tidspunktet for opslaget + et offset i antal dage (som angivet i konfigurationsparameteren for SFSK treatment.relation.lookup.timeinterval.start.offset) Nuværende værdi: -1 Tildato sættes til tidspunktet for opslaget + et offset i antal dage (angivet i konfigurationsparameteren for SFSK treatment.relation.lookup.timeinterval.end.offset) Nuværende værdi: 1 |
| TimeLimit | Sættes til konfigurationsparameteren for SFSK treatment.relation.lookup.timeinterval.timelimit.offset) Nuværende værdi: 90 |
| ServiceProvider | Udfyldes med defaultværdi for SFSK (som angivet i konfigurationsparameteren sfsk.app.name) Nuværende værdi: sfsk Vendor sættes til konfigurationsparameteren for SFSK treatment.relation.serviceprovider.vendor Nuværende værdi: vender Version sættes til konfigurationparameteren for SFSK treatment.relation.serviceprovider.version Nuværende værdi: version |
Kald til Stamdata autorisation enkeltopslagsservice (SAES)
Når en sundhedsfaglig kalder som "Sundhedsfaglig på vegne af", vil SAES blive kaldt for at validere den sundhedsfaglige autorisationskode.
Hvis autorisationen ikke valideres til at være ok, fejler kaldet, og en passende fejlbesked returneres.
Berigelse af brugertyper
Ved kald med en sundhedsfaglig brugertype skal der laves registrering i minlog og BRS skal kaldes. Disse kald skal der medsendes oplysninger om SOR/SHAK/Ydernr og de findes i den medsendte Hsuidheader.
- Sundhedsfaglig alm og på vegne af:
- organisationIdtype fra hsuid
- organisationId fra hsuid
Validering af brugertyper
Brugertyperne bliver til sidst valideret for:
- Alle roller, hvis hsuid header medsendt:
- hsuid rollen skal matche den på security context
- hsuid acting user cpr skal matche den aktøren
- Borger på vegne af
- Der skal være en relation
Kald af bagvedliggende services
Når SFSK kalder videre til de bagvedliggende services sker dette også vha DGWS. Dog trækker SFSK sit eget niveau 3 SOSI Idkort i den videre kommunikation med de bagvedliggende services. Identiteten af kaldet skifter således til at være et kald udført af SFSK, hvilket betyder at der kan udføres whitelisting i FSK til at tillade niveau 3 idkort fra det CVR nummer, som er identificeret i SFSKs Idkort.
SFSK har sin egen whitelistingtabel, hvor subject serialnumber for det kaldende certifikat skal være whitelistet. Se SFSK - Driftsvejledning for detaljer.
Der skal ikke være mulighed for værdispring i løsningen.
Flow i forbindelse med "Søg dokumenter" i SFSK
Når et kald er blevet sikkerhedsvalideret sker der en validering validerering af det indkommende request. Der er tale om en simpel validering, der tjekker, om det indkommende ITI-43 18 request er lovligt i henhold til standarden IHE XDS.
Sekvensdiagrammerne nedenfor beskriver flowet i forbindelse med "hent dokumenter"Sekvensdiagrammerne nedenfor beskriver flowet i forbindelse med "søg dokumenter". Det er kun når sundhedsfaglige søger dokumenter der laves kontrol for behandlingsrelation. Minlog registreringer laves når sundhedsfaglige og borger på vegne af en anden borger søger dokumenter.
| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Afklaringer
...
|
Flow i forbindelse med "Hent dokumenter" i SFSK
Når et kald er blevet sikkerhedsvalideret sker der en validering af det indkommende request. Der er tale om en simpel validering, der tjekker, om det indkommende ITI-43 request er lovligt i henhold til standarden IHE XDS.
Sekvensdiagrammerne nedenfor beskriver flowet i forbindelse med "hent dokumenter". Det er kun når sundhedsfaglige henter dokumenter der laves kontrol for behandlingsrelation.
| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
...