Page History
...
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)).
I modsætning til DDS, så er Tidligere var SFSK målrettet systembrugere og dækker det behov, der kan være for synkronisering af Fælles Stamkort i anvendernes fagsystemer, modsat DDS'en, men i de seneste versioner er der indført borgerkald og medarbejderkald via IDWS. Hensigten er at afkoble Fælles Stamkort fra DDS'en.
I de følgende afsnit kigger vi på SFSK og dens afhængigheder til andre NSP services og i form af tredjepartsbiblioteker.
...
- Sikkerhedsvalidere kald fra anvendersystemer
- Hente data i de bagvedliggende registre FSK Registry og FSK
- 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 dokumenthetningkaldes ved fremsøgning- og dokument-hentning
- BRS når en sunhedsfaglig sundhedsfaglig kalder servicen.
SFSK indgår i samspil med de øvrige NSP services på følgende måde:
...
Sikkerhedshåndtering i SFSK
BrugertyperBrugertyper
SFSK anvender det på platformen udstillede security-api til at validere de indkommende requests. Alle kald til SFKS skal være lovlige DGWS eller IDWS-kald. SFSK understøtter følgende brugertyper:
...
ID
...
Som en...
...
ønsker jeg at..
...
så jeg...
...
Sundhedsfaglig med national rolle
...
de brugertyper, der er beskrevet i SFSK - Brugerhistorier.
Uddybende beskrivelse af de enkelte brugertyper samt skema der identificere en brugertype ud fra Security API.
Bestemmelse og mapning til actor
Borger
Borgerkald sker
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. DGWS kald med 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..dk.
For IDWS-kald anvendes HsuidHeader ikke og forventes ikke medsendt. Brugertypen identificeres i stedet alene via Security API’et. Ved mapning af actoren ved IDWS er der kun brugertypen Borger.
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.
...
lave borgeropslag på vegne af borgeren.
For alle borgerkald laves der registreringer i minlog, men der kontrolleres ikke for behandlingsrelation
...
| Brugertypen IDWS: Borger | Verifikation | Mapning til SfskActor | ||
| SecurityContext | Ticket | Audience | Skal være der og skal være "https://fsk" | audience |
| Validity | Er valid | |||
| Message | Verificeres ikke - må gerne være der | |||
| ActingUser | Skal være der | |||
| IdentifierFormat | Skal være der og skal være CVRCPR | actorIdType | ||
| Identifier | Skal være der | actorId | ||
| PrincipalUser | Verificeres ikke - må gerne være der | |||
| Organisation | Verificeres ikke - må gerne være der | |||
...
Når der kaldes på vegne af en anden borger skal , laves der laves en minlog registrering og , men der kontrolleres ikke for behandlingsrelation.
...
Borger IDWS >> Brugertypen Borger på vegne af | Verifikation | Mapning til SFSK ServiceActor | ||
| SecurityContext | Actor | ActorType | Skal være der og være BORGER | |
| ActingUser | UserType | Skal være der og være Citizen | ||
| IdentifierFormat | Verificeres ikke - må gerne være der (Den er verificeres i mapning af actoren) | |||
| Identifier | Skal være der | actorId, hvis cprFraPayload ikke er der ellers actorId = cprFraPayload | ||
| GivenName | Verificeres ikke - må gerne være der | |||
| SurName | Verificeres ikke - må gerne være der | |||
| Credentials | Verificeres ikke - må gerne være der | |||
| Age | Skal være der hvis Relation er ChildCustodyHolder | |||
| Relation | Skal være der og enten være ProxyHolder, Guardian eller ChildCustodyHolder. Hvis ChildCustodyHolder skal Age være større end 15 (Age < 15) | Relation | ||
| Credentials.PowerOfAttorneyPrivileges | Hvis Relation ikke er til stede, kontrolleres det, om PowerOfAttorneyPrivileges er til stede og matcher værdien af egenskaben "sfsk.idws.citizen.powerofattorney.privileges". | Relation | ||
| PrincipalUser | Skal være der, hvis det er det er Iti43 kald. For at bestemme responsibleUser ved "Borger på vegne af". | |||
| Organisation | Verificeres ikke - må gerne være der | |||
| Client | Verificeres ikke - må gerne være der | |||
...
Der tjekkes for behandlingsrelation, når SFSK bliver kaldt af en sunhedsfarligsundhedsfaglig.
| 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 |
...
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 borgere søger dokumenter.
| Gliffy Diagram | ||||||||
|---|---|---|---|---|---|---|---|---|
|
...