Page History
...
Denne vejledning er målrettet mindre sundhedsorganisationer (eksempelvis lægepraksis og apoteker), som ved overgangen til MitId MitID vælger: (*HELM*: Kan vi præcisere her om vejledningen retter sig mod virksomhederne og/eller deres fagsystemleverandører? Jeg antager at det primært er sidstnævnte)
- at administrere organisationens medarbejdere via MitId MitID Erhverv.
- at organisationens medarbejdere skal logge på via NemlogNemLog-in ved adgang til den nationale sundhedsføderation.
...
I en begrænset overgangsperiode kan de mindre organisationer anvende MOCES3 som autentifikationsmiddel. Men MOCES3 har en række begrænsninger i forhold til MOCES2, hvilket gør MOCES3 mindre attraktiv for mindre organisationer. (*HELM*: Skal det ikke også nævnes at de skal gøre yderligere for at kunne tilgå SEB services?)
- MOCES3 understøttes kun i en overgangsperiode
- MOCES3 stiller højere krav til opbevaring af certifikat i lokal infrastruktur
- MOCES3 kan ikke anvendes fra Nemlog-in.
Store organisationer indenfor sundhedsområdet (regioner og kommuner) forventes at etablere egne NSIS registrerede IdP'er, som giver mulighed for at udstede egne identifikationsmidler til organisationens medarbejdere. Etableringsomkostningerne ved denne model er høje og giver derfor primært mening for større organisationer.
Ovenstående gør at mindre at mindre organisationer forventes at anvende MitId MitID Erhverv og login via NemlogNemLog-in.
Den Denne vejledning kommer ikke ind på hvordan medarbejdere oprettes i MitId MitID Erhverv. Information vedrørende dette findes på NemlogNemLog-in migreringsportalen.
Vejledning har fokus på, hvordan et fagsystem tilslutter sig til en Nationale Sundhedsføderation (SEB og SOSI STS).
...
- En medarbejder tilgår organisationens fagsystem. Via fagsystemet ønsker medarbejderen at tilgå patientdata fra en national sundhedstjeneste, eksempelvis det Fælles MedicinKort (FMK). Fagsystemet skal have medarbejderens SOSI idkort for at kunne tilgå patientdata fra en national sundhedstjeneste (step 7 på figuren). SOSI idkort udstedes af SOSI STS’en via omveksling fra et Bootstraptoken (BST) (step 5-6 på figuren). Derfor skal fagsystemet hente medarbejderens BST (step 2-4), før fagsystemet kan hente patientdata fra en national sundhedstjeneste.
- SEB (Sundhedsvæsenets Elektroniske Brugerstyring) er en IdP-broker, som viderestiller medarbejderen til arbejdspladsens valgte IdentityProvider (IdP). For mindre sundhedsorganisationer, som benytter MitID identifikationsmidler, vil det være NemlogNemLog-in. SEB og Nemligog NemLog-in er web-applikationer, der der initieres via SAML WEB-SSO protokollen, og de forudsætter dermed, at medarbejderen har adgang til en browser. For et fagssystem, som ikke er web-baseret, skal der etableres web-server og funktionalitet der initierer, at medarbejderen via browser videresendes til SEB.
- SEB redirecter medarbejderen til NemlogNemLog-in, hvorfra brugeren logger på og efterfølgende sendes tilbage til SEB.
- SEB opbygger et OIOSAML-H-3.0 token og returnerer dette til web-serveren tilknyttet fagsystemet. OIOSAML-H-3.0 er et OIOSAML3 token udvidet med sundhedsattributter. Fra tokenet kan medarbejderens identitet og organisatoriske tilknytning aflæses (på CVR-niveau). Desuden kan medarbejderens sundhedsfaglige autorisationer, ydertilknytning og nationale sundhedsroller aflæses. Tokenet indeholder desuden et såkaldt Bootstraptoken, der kan anvendes til SOSI STS’ens nye BST2SOSI snitflade.
- Fagsystemet kalder SOSI STS’ens BST2SOSI snitflade for at omveksle BST tokenet til et SOSI IdKort. I kaldet er det muligt at ’claime’ den autorisation eller nationale rolle som medarbejderen ønsker at agerer agere på vegne af. Dette er kun relevant, hvis medarbejderen har flere autorisationer eller nationale roller. Om dette er tilfældet kan aflæses af OIOSAML-H-3.0 tokenet.
- SOSI STS validerer BST tokenet og returnerer et SOSI Idkort til fagsysemet.
Fagsystemet modtager medarbejderens SOSI IdKortetIdKort.
Med SOSI idkortet kan fagsystemet lave et Den Gode WebService (DGWS) kald til sundhedstjenesten, og sundhedstjenesten kan returnere de ønskede patientdata til fagsystemet. WebService (DGWS) kald til sundhedstjenesten, og sundhedstjenesten kan returnere de ønskede patientdata til fagsystemet. (*HELM*: Der er noget galt med nummereringen af 7 og 8. Hører 7 ikke til under 6, så pkt 8 bliver til pkt. 7?)
Ovenstående flow er nødvendigt, når medarbejderen skal tilgå patientdata fra en national sundhedstjeneste. Flowet er ikke nødvendig nødvendigt i forbindelse med medarbejderens initiale login til til fagsystemet, og sålænge så længe medarbejderen via fagsystemet, ikke tilgår patientdata fra en national sundhedstjeneste. I det OIOSAML-H-3.0 token, der returnes returneres i step 4 til fagsystemet, kan medarbejderens identitet aflæses og anvendes i en kontomapning mod fagsystemets interne brugerregister.
...
Via linket nedenfor findes en vejledning i integration til SEB:
Link til dokumentet 'Integration til SEB'.'Integration til SEB'. (*HELM*: Linket skal lægges ind - jeg er med på at vi afventer placeringen af den)
SEB tilslutningsaftale
Tilslutningsaftale for adgang til SEB IdP håndteres gennem aftalerammeværket for NSP-tilslutninger (se Bestillingsark for adgang til services på NSP).
...
I bilagsafsnittet nederst i nærværende vejledning ses et eksempel på et OIOSAML-H-3.0 token.
Nærstuder Det anbefales at nærstudere XML-elementet <AttributeStatement>, der indeholder information om:
- brugeren (navn, cpr, cpruudcpruuid) - anvendes evt. til at mappe til fagsystemets interne brugerkonto
- brugerens organisatoriske tilknytning (oragvnisations organisations navn, ridRID, professionel UUID)
- brugerens sundhedsfaglige autorisationer, ydertilknytning og nationale roller (encoded som Base64 og indlejret i attributten privilegesIntermediate) - decoded eksempel findes i bilaget.
- det bootstrapToken(BST) som kan omveksles til et SOSI IdKort (encoded som Base64 og indlejret i attributten bootstrapToken)
...
Afsnit '1.4.2 BST2SOSI billetomveksling' i vejledningen 'Snitfladeændringer i NSP-kommponenterkomponenter' viser et eksempel-BST, samt reguest og response fra BST2SOSI omvekslingskaldet.
...
Fagsystemet skal realisere noget logik, der automatisk eller ud fra brugerinput bestemmer den autorisation eller national rolle, som skal opsættes i SOSI IdKortet. Dette kan undgåesundgås, hvis det sikres, at brugerne altid kun har én autorisation eller én nationale rolle.
...
Fagsystemets VOCES-certifikat skal whitelistes til at må kalde SOSI-STS’ens BST2SOSI snitflade, dette gøres via henvendelse til NSP-ServiceDesk. . (*HELM*: skal der evt. præciseres at det skal være VOCES3, hvis det skal det? Hvis ikke det er et krav nu, bliver det det lige om lidt)
Sundhedsdatanet aftale mellem fagsystem og hhv. SOSI STS og sundhedsservice, der integreres til
...