Kommentarer til denne FAQ kan stiles til Helle Mørch på HELM@sundhedsdata.dk


1. Den nationale sundhedsføderation - Kort fortalt

Den nationale sundhedsføderation anvendes når en medarbejder skal tilgå en patients sundhedsdata via de nationale sundhedsportaler (eksempelvis Sundhed.dk, FMK-online, SEI2, Dansk PatientSikkerhedsDatabase, Den Nationale Henvisningsformidling mm.) eller via service-integration til nationale sundhedsservices (eksempelvis fra et EPJ-, EOJ- eller LPS-fagsystem).

De primære komponenter i den nationale sundhedsføderationer er SEB og SOSI STS.

SEB (Sundhedsvæsenets elektroniske brugerstyring) har to funktioner:

  1. IdP-Broker – sender bruger videre til login hos brugerens hjemme-IdP (NemLog-in, en regional-IdP eller den fælleskommunale IdP/Contexthandler).
  2. Bruger-rettigheds-administration.  Lokal administratorer kan tildele specifikke roller rettet mod en konkret web-applikation (fx rollen 'sagsbehandler' i DPSD), samt nationale roller rettet mod service-integration (dvs. en ikke sundhedsfaglig autoriseret medarbejder, der skal have adgang til patientdata qua arbejdsfunktionen. Fx sekretær).

SOSI STS udsteder adgangsbilletter (SOSI idkort). Et SOSI idkort er medarbejderens personlige adgangsbillet der medsendes ved service-integration og knapløsningsadgang. SOSI idkortet er et bevis for at medarbejderen: 

  • Er autentificeret
  • Har en sundhedsfaglig autorisation (læge, sygeplejerske, Social- og sundhedsassistent mm.)
  • eller national rolle (dvs. en ikke sundhedsfaglig autoriseret medarbejder, der skal have adgang til patientdata qua arbejdsfunktionen. Fx sekretær)

Den nationale sundhedsføderation er adskilt fra den fælles offentlige føderation (OCES/NemID/NemLog-in).

  • Den nationale sundhedsføderation benytter den fælles offentlige føderation til bruger-autentifikation (log-in)
  • Den nationale sundhedsføderation har eget adgangsrolle-koncept, egen sessionsmodel og egne adgangsbilletter (SOSI idkort).

2. Den fællesoffentlige føderation - Overgangen fra NemID/OCES2 til MitID/OCES3

Ved overgangen fra NemID/OCES2 til MitID/OCES3 ændres den fællesoffentlige føderation:

  • NemID erstattes af MitID
    • Medarbejdere oprettes i MitID Erhverv
  • OCES2 erstattes af OCES3 (MOCES2 erstattes af MOCES3 og FOCES2/VOCES2 erstattes af FOCES3/VOCES3)
  • NemLog-in understøtter ikke medarbejdersignatur (MOCES3)
  • Store brugerorganisationer kan etablere egne IdentityProviders (IdP’er)
  • NSIS (National Standard for Identiteters Sikringsniveauer) anvendes fremover og erstatter anvendelsen af NIST-autentifikationsniveauer
  • OIOSAML2 erstattes af OIOSAML3

Den nationale sundhedsføderation, som benytter den fællesoffentlige føderation til bruger-autentifikation, er blevet tilpasset til de ovenstående ændringer.

3. Hvad påvirkes/påvirkes ikke i den nationale sundhedsføderation ved overgangen til MitID/OCES3?

Et bærende princip har været at minimere forandringerne i den nationale sundhedsføderationen, som følge af overgangen fra NemID/OCES2 til MitID/OCES3.

Da den nationale sundhedsføderation benytter den fællesoffentlige føderation til bruger-autentifikation, så sker de største ændringer i forhold til bruger-autentifikation, samt i forhold til omveksling af adgangsbilletter(tokens) fra den fællesoffentlige føderation til adgangsbilletter, der kan benyttes i den nationale sundhedsføderationen. Tokens (SOSI idkort) og sikkerhedsprotokol (DGWS) anvendt indenfor sundhedsføderationen ændres ikke. Bogerrettede IDWS tokens og protokol ændres heller ikke.

Ovenstående er illustreret i nedenstående figur og uddybes i teksten nedenfor.



3.1. Medarbejder- og borger-autentifikation

Som illustreret på figuren så ændres konceptet for medarbejder- og borger-autentifikation, og dette påvirker alle brugerorganisationer indenfor sundhedsområdet.

Medarbejder-authentifikation:

De enkelte brugerorganisationer (en lægepraksis, et apotek, en kommune, en region mm.) skal anvende Nemlog-in som Identity Provider (IdP) eller etablere egen lokale IdP.

  • Små brugerorganisationer, som eksempelvis lægepraksis og apoteker, forventes at anvendes NemLog-in som IdP samt at anvende MitID Erhverv til brugeradministration. 
  • Regionerne realiserer egne lokale IdP’er til medarbejder-autentifikation. Et par af regionerne forventer at blive klar med en såkaldt NSIS registreret IdP. Resten af regionerne forventer i en overgang at erstatte deres MOCES2 infrastruktur med en MOCES3 infrastruktur. 
  • Kommunerne samarbejder, via Kombit, om at etablere en fælleskommunal NSIS registreret IdP (omtalt Context-handler), som den enkelte kommune IdP tilkobles.

Borger-autentifikation:

Borgere anvender NemLog-in som IdP, hvorfra de anvender deres nye MitID og MitID app som 2-faktor.

System-autentifikation:

Funktioncertifikaterne FOCES2 erstattes med FOCES3.

Virksomhedscertifikater VOCES2 erstattes med VOCES3.

3.2. SEB: IdentityProvider

SEB-IdP'en er en såkaldt broker, der forbinder en ServiceProvider (SP, den tjeneste brugeren tilgår - eksempelvis en webportal som Sundhed.dk, FMK-online, DPSD, SEI2, eller et fagsystem som EOJ eller LPS) med brugerens login-sted (brugerens hjemme-IdP, hvilket kan være NemLog-in, en regional IdP eller kommunernes Context-Handler).

Ved overgange til MitID opdeles SEB i en SEB-borger-IdP og en SEB-medarbejder-IdP. Med opsplitningen opnås en mere robust løsning, hvor medarbejderlogin ikke påvirkes af høj trafik på borgerlogin.

Figuren ovenfor illustrer opsplitningen i SEB-borger-IdP og SEB-Medarbejder-IdP. På højresiden ses SP'erne og på venstresiden ses hjemme-IdP'erne.

SEB-borger-IdP har kun en hjemme-IdP tilsluttet - Nemlig-in.

SEB-medarbejder-IdP har mange IdP'er tilsluttet. Det er op til den enkelte SP at beslutte, om medarbejderen altid skal sendes til en bestemt hjemme-IdP eller om medarbejderen skal kunne vælge imellem flere hjemme-IdP'er. Er det sidste tilfældet, så vil SEB præsentere medarbejderen for en liste over de IdP'er, som SP'en understøtter.

Følgende gælder for SP'ernes tilslutning til SEB-medarbejder-IdP og SEB-borger-IdP:

Web-portaler, som har været tilsluttet SEB-medarbejder-IdP, fra før MitID:

De fleste af de Web-portaler, som har været tilsluttet SEB-IdP'en fra før overgangen til MitID, de skal ikke lave ændringer i overgangen til MitID. De eksisterende snitflader til disse web-portaler bevares, hvor der et muligt.

Medarbejderen vil opleve en anden brugerrejse, da medarbejderen skal tage stillig til, hvilken hjemme-IdP de skal anvende til log-in. Tidligere havde SEB ingen brugergrænseflade og sendte automatisk brugeren videre til login i NemLog-in. I fremtiden vil medarbejdere skulle vælge hjemme-IdP (NemLog-in, en regional IdP eller  den fælleskommunale IdP/Contexthandler) via en grænsefalde i SEB. 

Nye Web-portaler, som ikke tidligere har været tilsluttet SEB-medarbejder-IdP:

Nye Web-portaler, som ikke tidligere har været tilsluttet SEB-IdP, de tilbydes en ny OIOSAML3-H-3.0 baserede integration til SEB.

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 Bootstraptoken (BST), der kan anvendes til SOSI STS’ens nye BST2SOSI snitflade.

Web-portaler tilsluttet SEB-borger-IdP:

Eksisterende og nye SP'er tilsluttet SEB-borger-IdP'en vil ikke opleve ændringer i forbindelse med overgangen til MitID.

Fagsystemer (i kommuner, lægepraksis og apoteker) skal tilsluttet SEB-medarbejder-IdP ved adgang til patientdata fra en en national sundhedstjeneste:

Fagsystemer skal anvende medarbejderens SOSI idkort (adgangsbillet) ved adgang til patientdata fra en national sundhedstjeneste (se step 7 på figuren nedenfor).

Enten skal fagsystemer selv hente SOSI idkortet, eller alternativt benytte fælles infrastruktur, der på forhånd har hentet SOSI idkortet, og eventuelt har placeret det i en Gateway, hvorfra flere fagsystemer kan deles om samme SOSI idkortet.

I det følgende antages at fagsystemet selv henter SOSI idkort.

Før overgangen til MitID, hentede fagsystemerne SOSI Idkort via SOSI STS grænsefladen NewSecurityToken. Grænsefladen tager et MOCES2 selvsigneret SOSI idkort og omveksler det til et STS signeret SOSI idkort, som er krævet af DGWS. Ved udfasningen af MOCES2 kommer SOSI STS grænsefladen NewSecurityToken til at understøtte MOCES3 i en midlertidig periode.

De fleste forventes dog at hente SOSI IdKort via den nye SOSI STS grænseflade BST2SOSI (se step 5-6 på figuren nedenfor). Denne grænseflade tager et Bootstraptoken (BST) som input og returnere et SOSI idkort. BST tokenet udleveres fra medarbejderens hjemme-IdP,  evt. via SEB-medarbejder-IdP (se step 2-4 på figuren nedenfor). SEB-medarbejder-IdP aktiveres via SAML WEB-SSO protokollen, og forudsætter en web-server i tilknytning til fagsystemet, samt at medarbejderen har adgang til en browser. 

3.3. Omveksling til SOSI idkort via SOSI STS

OIOSAML2SOSI snitfladen på SOSI STS’en udfases. Udfasningen bunder i at OIOSAML2SOSI snitfladen bryder med føderation-modellen og korrekt anvendelse af tokens. Sundhedsvæsenets sikkerhedsføderation (SOSI) er adskilt fra den fælles offentlige NemLog-in føderation. Et OIOSAML token fra NemLog-in til en webportal er målrettet trust-relationen mellem NemLog-in og webportalen. Men tokenet bør ikke anvendes udenfor denne trust-relation, og brug mod sundhedsføderationen (SOSI STS) udfases derfor.

BST2SOSI er en ny snitfladen på SOSI STS'en. Snitfladen kan omveksle et BST token modtaget fra SEB-medarbejder-IdP'en eller en lokale NSIS registreret IdP til et SOSI idkort.

NewSecurityToken snitfladen på SOSI STS'en ændres så den accepterer signering med MOCES3 tokens. Vær opmærksom på at understøttelse af MOCES3 bliver midlertid og forventes udfaset. VOCES3 (organisationscertifikater) udfases ikke.

SOSI2OIOSAML snitfladen på SOSI STS'en ændres ikke. Snitfladen anvendes i forbindelse med Knapløsninger (SikkerBrowserOpstart).

SOSI Gateway udvides med en snitfalde til udstedelse af SOSI IdKort ud fra et BST token.

3.4. SEB: Bruger-rettigheds-administration

En lokal brugerorganisation kan udnævne en lokal SEB administrator, som har til opgave at tildele roller til organisationens medarbejdere. Dette gøres via SEB administrationsgrænseflade. Der skelnes mellem nationale rolle og applikationsspecifikke roller. 

De nationale roller anvendes af medarbejdere på sundhedsområdet, der ikke har en sundhedsautorisation i autorisationsregisteret, men som skal have adgang til patientdata qua deres arbejdsfunktion. Fx en lægesekretær.

De applikationsspecifikke roller er roller målrettet en specifik SP tilsluttet SEB-medarbejder-IdP'en.

Bruger-rettigheds-administration via SEB ændres ikke. Dog tilføjes et enkelt 'Globalt medarbejder UUID' til medarbejderens konto i SEB. 'Globalt medarbejder UUID' er indført i forbindelse med MitID Erhverv.

3.5. Sikkerhedsprotokol anvendt til service-integration - DGWS / IDWS

Der laves ingen ændringer til Den Gode Web-service sikkerhedsprotokollen og SOSI idkort, som anvendes til service-integration fra et fagsystem til en sundhedsservice.

Bogerrettede IDWS tokens og protokol ændres heller ikke.

4. Som brugerorganisation, hvordan påvirkes jeg?

Den enkelte brugerorganisationer skal vælge MitID Erhverv eller etablere egen Identity Provider (IdP). Se afsnit Medarbejder- og borger-autentifikation.

5. Som systemejer af et fagsystem, hvordan påvirkes jeg?

Der laves ingen ændringer til Den Gode Web-service sikkerhedsprotokollen og SOSI idkort, som anvendes ved kald af sundhedsservice fra et fagsystem.

Men konceptet for login og hentning af SOSI idkort ændres, og du skal sikre dig at dit fagsystem tager højde for dette. Se afsnit Medarbejder- og borger-autentifikation, SEB: IdentityProvider og Omveksling til SOSI idkort via SOSI STS.

Din fagsystemsleverandør bør være opmærksom på ovenstående og bør kunne hjælpe med nødvendige tilpasninger.

Har din organisation flere fagsystemer som tilgår sundhedsdata, så overvej om fagsystemerne kan anvende samme løsning til login og hentning af SOSI idkort.

6. Som fagssystemsleverandør, hvordan påvirkes jeg?

Som fagssystemsleverandør skal du sikre at dit fagsystem har adgang til komponenter, der håndtere brugerlogin og hentning af SOSI idkortet. Enten skal du selv udvikle disse komponerer, eller alternativt skal du undersøge om markedet tilbyder løsninger eller om kunderne allerede har løsninger, som kan genbruges. 

Fagsystemsleverandøren bør du: 

  1. Identificer hvilke koncepter dine kunder benytter til bruger-autentifikation (Se afsnit  Medarbejder- og borger-autentifikation, SEB: IdentityProvider og Omveksling til SOSI idkort via SOSI STS).
  2. Beslut hvilke bruger-autentifikations-koncepter dit fagsystem skal understøtte og hvordan SOSI idkort hentes.
  3. Overvej om du selv skal udvikle hele konceptet eller dele kan indkøbes eller allerede er indkøbt af kunden.
  4. Lav de nødvendige tilpasninger til fagsystemet og implementer det ude hos kunderne.

Er dine kunder mindre sundhedsorganisationer (lægepraksis, apoteker mm.), så se vejledningen Hints: Brug af MitID Erhverv i adgang til patientdata fra nationale sundhedsservices.

OBS: Som fagsystemsleverandør bør du orientere dig i Teknisk overblik til anvendere for en mere teknisk gennemgang af ændringerne, samt links til eksempelkode.

OBS: Såvel den nuværende nationale sikkerhedsinfrastruktur baseret på OCES2/Medarbejdersignatur og den kommende MitID/OCES3 infrastruktur er baseret på ikke-trivielle teknologier og standarder. Som fagsystemsleverandør bør du derfor sikre dig at du har de fornødne kompetencer indenfor bl.a. SAML (fx WebSSO protokollen, holder-of-key tokens), WS-Security og X509Certifikater. NSP-supporten yder således ikke generel udviklingssupport, men håndterer alene indmeldte fejl og konfigurationsændringer (fx i forbindelse med whitelisting-anmodninger, se Whitelisting og overgang fra OCES2 til OCES3).

7. Som region, hvordan påvirkes jeg?

Som region er du både brugerorganisation og systemejer for et eller flere fagsystemer.

I rollen som brugerorganisation:

Regionerne realiserer egne lokale IdP’er til medarbejder-autentifikation. Et par af regionerne forventer at blive klar med en såkaldt NSIS registreret IdP. Resten af regionerne forventer i en overgang at erstatte deres MOCES2 infrastruktur med en MOCES3 infrastruktur. 

I rollen som systemejer af flere fagsystemer, der skal have adgang til patienters sundhedsdata via de nationale sundhedsservices:

Fagsystemer skal anvende medarbejderens SOSI idkort (adgangsbillet) ved adgang til patientdata fra en national sundhedstjeneste. Som systemejer skal du sikre, at dit fagsystem fortsat har adgang til SOSI idkort efter overgangen til MitID.

Enten skal fagsystemer selv hente SOSI idkortet, eller alternativt benytte fælles infrastrukturkomponenter, der på forhånd har hentet SOSI idkortet, og eventuelt har placeret det i en Gateway, hvorfra flere fagsystemer kan deles om samme SOSI idkortet.

Kontakt din fagsystemsleverandør, så du kan sikre at leverandøren har en plan for ovenstående.

8. Som kommune, hvordan påvirkes jeg?

Som kommune er du både brugerorganisation og systemejer for et eller flere fagsystemer.

I rollen som brugerorganisation:

Kommunerne samarbejder om at blive klar med en fælles kommunal NSIS registreret IdP (omtalt Context-handleren), som den enkelte kommune IdP tilkobles. Context-handleren tilknyttes SEB, som er indgangen til de nationale sundhedsservices (se afsnit Medarbejder- og borger-autentifikation og SEB: IdentityProvider).

I rollen som systemejer af flere fagsystemer, der skal have adgang til patienters sundhedsdata via de nationale sundhedsservices:

Fagsystemer skal anvende medarbejderens SOSI idkort (adgangsbillet) ved adgang til patientdata fra en national sundhedstjeneste. Som systemejer skal du sikre, at dit fagsystem fortsat har adgang til SOSI idkort efter overgangen til MitID.

Enten skal fagsystemer selv hente SOSI idkortet, eller alternativt benytte fælles infrastrukturkomponenter, der på forhånd har hentet SOSI idkortet, og eventuelt har placeret det i en Gateway, hvorfra flere fagsystemer kan deles om samme SOSI idkortet.

Figuren og den tilhørende tekst i afsnit Omveksling til SOSI idkort via SOSI STS illustrerer hvordan fagsystemer fremover selv kan hente SOSI Id-kort.

Kontakt din fagsystemsleverandør, så du sikre at leverandøren har en plan for ovenstående.

9. Som lægepraksis, apotek mm. (altså en mindre sundhedsorganisation), hvordan påvirkes jeg?

Ved overgangen til MitID forventes mindre sundhedsorganisationer at vælge:

  • at administrere organisationens medarbejdere via MitID Erhverv.
  • og dermed at organisationens medarbejdere skal logge på via NemLog-in ved adgang til den nationale sundhedsføderation.

De mindre organisationer har hidtil anvendt medarbejdersignatur (MOCES2) som autentifikationsmiddel, hvilket ikke længere er muligt.

Der er udarbejdet et vejledningen målrettet det som skal etableres for mindre sundhedsorganisationer. Se Hints: Brug af MitID Erhverv i adgang til patientdata fra nationale sundhedsservices.

Kontakt din fagsystemsleverandør, så du sikre at leverandøren har en plan for ovenstående.

10. Som web-portal tilsluttet SEB, hvordan påvirkes jeg?

Web-portaler som har været tilsluttet SEB-medarbejder-IdP fra før MitID:

De fleste af de Web-portaler, som har været tilsluttet SEB-IdP'en fra før overgangen til MitID, de skal ikke lave ændringer i overgangen til MitID. De eksisterende snitflader til disse web-portaler bevares, hvor der et muligt.

Medarbejderen vil opleve en anden brugerrejse, da medarbejderen skal tage stillig til, hvilken hjemme-IdP de skal anvende til log-in. Tidligere havde SEB ingen brugergrænseflade og sendte automatisk brugeren videre til login i NemLog-in. I fremtiden vil medarbejdere skulle vælge hjemme-IdP (NemLog-in, en regional IdP eller den fælleskommunale IdP/Contexthandler,) via en grænseflade i SEB. 

Nye Web-portaler som ikke tidligere har været tilsluttet SEB-medarbejder-IdP:

Nye Web-portaler, som ikke tidligere har været tilsluttet SEB-IdP, de tilbydes en ny OIOSAML3-H-3.0 baserede integration til SEB.

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 Bootstraptoken (BST), der kan omveksles til et SOSI idkort via  SOSI STS’ens nye BST2SOSI snitflade. SOSI idkort er den adgangsbillet som medsendes, når patientdata skal hentes fra en national sundhedstjeneste.

Web-portaler tilsluttet SEB-borger-IdP:

Eksisterende og nye SP'er tilsluttet SEB-borger-IdP'en vil ikke opleve ændringer i forbindelse med overgangen til MitID.

11. Som anvender af  virksomheds- og funktionscertifikater (VOCES2 og FOCES2), hvordan påvirkes jeg?

I OCES3 videreføres både VOCES og FOCES certifikater, men VOCES3 certifikater bliver nu kaldt 'organisationscertifikater' i sted for virksomhedscertifikater og FOCES3 certifikater bliver nu kaldt 'systemcertifikater'.

SOSI STS'en understøtter både VOCES3 og FOCES3 certifikater til dannelse af SOSI systemidkort.

VOCES2/FOCES2 skal udskiftes inden Digitaliseringsstyrelsen lukker for brugen af OCES2 certifikaterne.

Læs mere om udstedelse af VOCES3/FOCES3, tidspunkt for spærring af OCES2 certifikater og guide til overgang på https://mitid-erhverv.dk/avanceret/certifikater/.

Se også Whitelisting og overgang fra OCES2 til OCES3.

12. Som anvender af DGWS, hvordan påvirkes jeg?

Der laves ingen ændringer til Den Gode Web-service sikkerhedsprotokollen og SOSI idkort, som anvendes til service-integration fra et fagsystem til en sundhedsservice.

Vær opmærksom på, at der laves ændring til snitfladerne på SOSI STS, og dermed hvordan SOSI idkort udstedes (se afsnit Medarbejder- og borger-autentifikation, SEB: IdentityProvider og Omveksling til SOSI idkort via SOSI STS).

13. Som anvender af SEB til bruger-retttigheds-administration, hvordan påvirkes jeg?

Bruger-rettigheds-administration via SEB ændres ikke (se SEB: Bruger-rettigheds-administration).

14. Med integrationer til aftaledeling, fællesstamkort eller graviditetsmappen, hvordan påvirkes jeg?

De tre (Aftaledeling, Fællesstamkort eller Graviditetsmappen) er kendetegnet ved at have flere typer af integrationer til de nationale sundhedsservices.

  1. Der kører baggrundsjobs til opdatering af data i DokumentDelingsServicen, hvor sikkerhedsmodellen er baseret på VOCES2 eller FOCES2. Disse integrationer skal fremad anvendes VOCES3 eller FOCES3 (se Som anvendes af VOCES2 og FOCES2, hvordan påvirkes jeg?).
  2. Der er service-integrationer baseret på DGWS og SOSI idkort. DGWS ændres ikke, men der er ændringer til hvordan medarbejdere logger på og hvordan SOSI idkort hentes (se afsnit Medarbejder- og borger-autentifikation, SEB: IdentityProvider og Omveksling til SOSI idkort via SOSI STS ovenfor).
  3. Endeligt har Graviditetsmappen en administrativ web-portal, hvor login håndteres via SEB-medarbejder-IdP. Dine bruger vil enten logge på via en regional IdP, den  fælleskommunale IdP/Contexthandler eller NemLog-in. Det skal sikres at din brugerorganisation er tilsluttet SEB-medarbejder-IdP (se afsnit SEB: IdentityProvider).

15. Tilslutningsaftaler og whitelistning

SOSI STS

Kald til nogle SOSI STS omvekslingsgrænseflader kræver at anvender systemet er whitelistet. Dvs. ved kald af SOSI STS grænsefladerne BST2SOSI, BST2IDWS, JWT2IDWS og JWT2OIOSAML.

Yderligere indformation vedrørende whitelisting til SOSI STS findes her: SOSI STS whitelistning.

Whitelistning iværksættes ved henvendelse til NSP-ServiceDesk.

I produktion foregår kommunikation med både SOSI-STS og sundhedsservicen (fx FMK) over Sundhedsdatanettet. Aftaler oprettes i gennem MedComs aftalesystem for Sundhedsdatanettet på https://aftale.medcom.dk/. Se også http://services.nsi.dk/sdn og http://medcom.dk/systemforvaltning/sundhedsdatanet-sdn

SOSI-Gateway

Kald til SOSI-Gateway'ens createIdCardFromBST snitflade viderestilles til SOSI-STS'ens BST2SOSI snitflade og kræver at anvendersystemet whitelistes til SOSI STS grænseflade, se ovenstående.

SEB

Der skal indgås en tilslutningsaftale for adgang til SEB IdP. Kontakt SEB driftsforvaltningen på SEBDRIFT@sundhedsdata.dk.

Yderligere information vedrørerende tilslutningsaftale og udveksling af tilslutningsmetadata findes her: Tilslutning til SEB.

16. Whitelisting og overgangen fra OCES2 til OCES3

I den nationale sundhedsinfratstruktur anvendes der forskellige typer for whitelistings-mekanismer:

  1. Baseret på certifikatoplysninger fra FOCES/VOCES certifikater (certifikatoplysninger som ikke ændres ved almindelige fornyelse af certifikatet)
    → Adgang til SOSI-STS'ens omvekslingssnitflader er baseret på denne model, se SOSI STS whitelistning.
  2. Baseret på selve FOCES/VOCES certifikatet
    → SEB IdP tilslutninger etableres ud fra SAML metadata som indeholder selve certifikatet (den offentlig del), se Integration til SEB.
  3. Baseret på CVR oplysninger i SOSI system-idkortet
    → Adgang til dokumentdelingsservicen (Aftaler, stamkort, etc) og flere andre NSP services (CPR enkeltopslag, SOR opdateringsservice, etc.) er baseret på denne model.

Ved overgangen til OCES3 ændres formatet for DistinguishedName i certifikaterne, hvilket betyder at der for

  1. Whitelistinger baseret på certifikatoplysninger (ovenstående mekanisme 1) skal anmodes om en ny whitelisting ved NSP-ServiceDesk
  2. Whitelistinger som er baseret på selve certifikatet skal som ved almindelige fornyelse af certifikatet ligeledes opdateres når der skiftes til et nyt OCES3 certifikat. For SEB IdP'ens vedkommende se Koordinering af SEB-tilslutninger.
  3. Whitelistinger baseret på CVR-nummeret i SOSI idkortet ikke påvirkes af overgangen til OCES3

Som udgangspunkt bør man som systemleverandør først danne sig et overblik over hvilke FOCES2/VOCES2 certifikater man anvender i sin løsning og til hvilket formål / til hvilke integrationer. Dernæst bør man undersøge (fx via dokumentationen her på nspop.dk) hvorvidt den integration som benytter det pågældende certifikat har en whitelisting baseret på mekanisme 1 (certifikatoplysninger) eller 2 (selve certifikatet) og derfor skal opdateres i forbindelse med overgangen til OCES3.

  • No labels