You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »



Denne "Kom Godt i Gang Guide" giver en overordnet introduktion til den Nationale Service Platform. Guiden henvender sig til it-faglige personer som skal til eller er i gang med at udvikle systemer, der skal integrere med komponenter på platformen. Platformsintroduktionen bør læses inden de komponentspecifikke guider læses.

1. Hvad er NSP

Den Nationale Service Platform er en teknisk platform, der sammen med en mængde standarder og aftaler gør det muligt at udbyde et antal services til offentlige og private it-systemer. I dette dokument vil de vigtigste elementer af NSP blive gennemgået og forklaret.

1.1. Den tekniske platform

NSP platformen består af en Linux distribution med en JBoss 6 applikationsserver. Alle komponenterne på platformen kører ovenpå denne applikationsserver og anvender en MySql database som persistentlag. Foran JBoss applikationsserveren er der en loadbalancer.Valget af JBoss dikterer at alle komponenter er skrevet i programmeringssproget Java (eller andre sprog der kan afvikles i en Java VM), der er dog ingen krav til hvilke sprog anvendere af platformen skal benytte.

SoftwareVersion
Java1.6
JBoss6
MySql5.5

1.2. Webservices

Alle webservices der udbydes på NSP overholder standarden "Den Gode WebService (DGWS)" fra MedCom. Alle forespørgelser og svar sendes som SOAP-XML over HTTP protokollen. Nogle af de webservices som identitetsservicen (STS) udbyder er dog undtaget fra reglen om DGWS.I NSP regi er SEAL.Java og SEAL.Net blevet udviklet for at hjælpe både anvendere og udstillere af services. SEAL pakker de mange XML og sikkerhedsstandarder ind i simple metoder, og sikrer en uniform serialisering og deserialisering af forespørgelser og svar.

1.3. Sundhedsdatanettet

NSP er placeret på sundhedsdatanettet og adgang hertil kræver derfor en godkendelse fra MedCom. Anvendelsen af Sundhedsdatanettet gør at konfidentialiteten og integriteten af forespørgelser og svar er sikret. Se evt. ”Kom på NSP – kort forløbsbeskrivelse".

1.4. Distribueret platform

NSP er ikke blot en enkelt platform, men derimod flere instanser distribueret rundt omkring i landet. Der findes en Central NSP (cNSP), regionale NSP'er (dNSP) og en såkaldt BackOffice instance (DoDi).De regionale og den centrale NSP er stort set ens, men deres anvendere er forskellige. Hver region har sin egen NSP som blandt andet anvendes af hospitalerne, hvorimod den centrale NSPs anvendere f.eks. er lægepraksiser og plejehjem.Denne distribuerede tilgang betyder at der er et flow af data fra BackOffice platformen til både cNSP og dNSP. F.eks. kommer opdateringer til stamdata ind i BackOffice fra flere kilder for derefter at flyde ud på NSP'erne.

1.5. Miljøer

Ud over produktionsmiljøet findes der to testmiljøer som anvendere kan få adgang til. Adgang kræver en aftale med NSP-operatøren samt oprettelse af testcertifikater mv. En guide til tilslutningsforløbet kan ses i " Adgang til fælles testmiljøer".

2. Hvem styrer NSP

Den Nationale Service Platform (NSP) ejes og styres af National Sunheds-It (NSI) der er en sektor under Statens Serum Institut (SSI). Alle opgaver på NSP udliciteres efter gældende EU-regler og er fordelt på et par håndfulde it-firmaer.NSP opereres af Capgemini A/S og driftes af Netic A/S. Support til anvendere og udstillere leveres af IBM, Netic A/S og Arosii A/S. Komponenterne på NSP ejes af NSI men er udviklet af flere forskellige leverandører.

3. Sikkerhed på NSP

En af de vigtigste aspekter af NSP er den sikkerhedsmodel der er lagt over alle komponenter på platformen. For at kalde en komponent på NSP skal en anvender medsende et id-kort signeret af en identitetsudbyder i hvert kald. De vigtigste aspekter af sikkerhedsmodellen gennemgåes i de følgende afsnit, og den samlede model er beskrevet i Den Gode Webervice.

3.1. Certifikater

Sikkerheden på NSP bygger på certifikater udstedt af Nets DanID. Der findes 3 forskellige slags certifikater som kan bruges på NSP:
  • Medarbejdercertifikater (MOCES)
  • Virksomhedscertifikater (VOCES)
  • Funktionscertifikater (FOCES).
Et certifikat består af en offentlig og en privat nøgle der tilsammen gør det muligt at signere et id-kort, således at en serviceudstiller kan verificere identiteten af anvenderen.

3.1.1. Medarbejdercertifikater

MOCES certifikater udstedes til en enkelt person ansat ved en virksomhed og repræsentere dennes relation til virksomheden. Hvert medarbejdercertifikat har et entydigt CVR/RID- nummer der er opbygget af virksomhedens CVR-nummer, samt et ressource identifikationsnummer. Dette CVR/RID-nummer indgår i ejerinformationen i certifikatet.

3.1.2. Virksomhedscertifikater

VOCES certifikater udstedes til selve virksomheden og er ikke knyttet til nogen person. Virksomhedens CVR-nummer indgår i ejerinformationen i certifikatet.

3.1.3. Funktionscertifikater

FOCES certifikater udstedes til en applikation, en enhed, en proces eller en service hos en virksomhed. De bruges primært til automatiske batch processor. Virksomhedens CVR-nummer indgår i ejerinformationen i certifikatet.

3.2. Infrastruktur (DanID og test/prod føderation)

Certifikater udstedt af Nets DanID til brug på NSP hører enten til under testmiljøet eller produktionsmiljøet. Et certifikater kan kun bruges i det miljø det er udstedet til.

3.3. Id-kort

Et id-kort er et xml-dokument der indeholder informationer om den person, virksomhed eller applikation, som foretager en forespørgsel mod en NSP-service. Id-kortet medsendes som en del af SOAP-headeren i alle kald der foretages mod en komponent på NSP. Idkortet anvendes af serviceudbyderen til at verificere identiteten af anvenderen, samt til at undersøge om vedkommende er berettiget til at få adgang til servicen.Der er to slags id-kort på NSP, et brugerid-kort og et systemid-kort. Brugerid-kortet anvendes sammen med et medarbejdercertifikat og systemid-kortet anvendes sammen med et virksomhedscertifikat eller et funktionscertifikat.Et idkort indeholder blandt andet følgende oplysninger
  • Anvenderidentitet - En streng der bruges til at identificerer subjektet
  • Gyldighed - Den periode hvor id-kortet er gyldigt
  • Virksomhedsoplysninger - Blandt andet CVR-nummer
  • Brugeroplysninger - Blandt andet CPR-nummer
  • Digest - Base64 enkodning af en SHA1 hashing af den kanoniske form af id-kortet
  • Signature - Base64 enkodning af RSA signering af digestet
  • Certificate - Den offentlige nøgle i det certifikat der blev brugt til signering
Ovenstående er illustreret i den følgende figur. SOAP Envelope with ID Card

3.4. Føderation og ombytning af id-kort

I stedet for at alle komponenter på NSP skal kunne verificere alle de certifikater som er udstedt til samtlige anvendere, er der indført en føderation hvor anvenderens id-kort bliver signeret af en identitetsudbyder (STS). Anvendelsen af en identitetsudbyder er skitseret nedenfor
  • Anvendersystemet bygger et id-kort og signere det med eget certifikat.
  • Id-kortet sendes til STS der tjekker korrektheden af udvalgte dele af id-kortet, samt signaturen
  • STS opbygger et nyt id-kort med de samme informationer og signere det med et certifikat der stoles på i hele føderationen
  • STS sender det nye id-kort retur til anvendersystemet
  • Anvendersystemet indsætter nu det nye id-kort i alle fremtidige forespørgelser mod NSP-komponenter
  • NSP-komponenten verificere at id-kortet er signeret af føderationens certifikat og stoler herefter på udvalgte dele af id-kortet
Federation sequence

4. Hvad findes der på NSP

4.1. Hjælp til anvendere

Ud over komponenter der udstiller kernefunktioner fra forskellige forretningsområder, er der to komponenter på NSP'en der hjælper anvendere med at kalde andre komponenter. De to komponenter er afkoblingskomponenten (DCC) og gatewayen (GW).

4.1.1. Afkoblingskomponenten

I stedet for at kalde de forskellige komponenters webservices direkte, tilbyder afkoblingskomponenten at fungere som en softwarerouter for anvenderen. Komponenten har en konfiguration der indeholder en mapning mellem SOAP Actions og endpoints (Se f.eks. mapningen for cNSP prod her Inventory - cnsp DCC ). På den måde er komponenten i stand til at viderstille et kald ud fra værdien af HTTP-headeren. Det anbefales at anvender altid kalder komponenternes webservices gennem afkoblingskomponenten.

4.1.2. Gatewayen

For at anvendere af NSP kan tilbyde Single Sign-on til slutbrugerne, er det nødvendigt at hvert enkelt it-system ikke skal udstede et id-kort for den samme bruger. Gatewayen tilbyder derfor at holde en cache af id-kort som alle anvendere kan deles om. Når en slutbruger logger på et it-system og udfører en handling der kræver et id-kort, sendes forespørgslen gennem gatewayen der indsætter det korrekte id-kort og vidersender til den valgte webservice. Hvis cachen ikke indeholder et valid id-kort for slutbrugeren må it-systemet oprette et nyt, som herefter gemmes i cachen. Gatewayen anvender WSAddressing standarden når den skal afgøre hvor en forespørgsel skal sendes videre til.

4.1.3. Forespørgsel

Følgende er en kort gennemgang af hvordan anvendelsen af DCC og GW kan foregå fra eksempelsystemet ABC til eksempelservicen XYZ:
  1. Annie logger på ABC og vil se information, som skal hentes fra en NSP-service.
  2. ABC laver et usigneret id-kort med Annies CPR-nummer som identifikation
  3. ABC sender et forespørgsel til DCC med SOAP Actionen http://nsi.dk/xyz/2013/08/09/MinService i HTTP-headeren
  4. DCC tilføjer WSAddressing elementerne "To" og "Action" og sender forespørgelsen videre til GW
  5. GW har ikke et valid id-kort for Annies CPR-nummer og sender derfor en fejlbesked tilbage
  6. ABC åbner en browser med den URL som indgår i fejlbeskeden
  7. Annie taster kodeordet for sit medarbejdercertifikat i browseren og får derved lagt et signeret id-kort i GW cachen
  8. ABC gentager kaldet fra 2) der igen vidersendes af DCC
  9. GW skifter det usignerede id-kort i forespørgelsen ud med det id-kort i cachen, der er signeret med føderationens certifikat
  10. GW vidersender forespørgelsen til XYZ
  11. ABC modtager svar fra XYZ og Annie slipper for at skrive sit kodeord igen ved næste kald fra ABC eller andre systemer der anvender GW
Hvis ABC ikke havde ønsket at åbne en browser for at få signeret sit id-kort udstiller gatewayen også webservicemetoder, som kan bruges til at få oprettet et id-kort direkte i cachen.

4.2. Stamdata

NSP importerer stamdata fra et antal nationale registre og tilbyder adgang hertil gennem Stamdata-komponentensservices. Følgende stamdataregistre er tilgængelig på NSP:
  • Autorisation - Indeholder informationer om hvilke sundhedsfaglige uddannelser en given person har gennemgået og er blevet autoriseret til af Sundhedsstyrelsen. Registret vedligeholdes af Sundhedsstyrelsen
  • Bemyndigelser - Indeholder registreringer af bemyndigelse mellem sundhedspersoner.
  • Personnumre (cpr) - Oplysninger om borgere i Danmark, herunder navne, adresse, familerelationer og børn.
  • Doseringer - Indeholder doseringsforslag, hvilket vil sige en rimelig dosering til en normalvægtig patient, der ikke lider af anden sygdom eller er under indflydelse af andre lægemidler, der kan have interaktion med det pågældende middel.
  • Patienter (lpr) - Landspatientregisteret indeholder oplysninger om borgernes indlæggelser, ambulante besøg samt besøg på skadestue.
  • Henvisninger (refhost) - Indeholder henvisninger til speciallægehjælp, fysioterapibehandling og psykologhjælp
  • Sikrede - Register indeholder sygesikringsinformationer om den enkelte borger, herunder hvilken yder gruppe 1 sikrede er tilknyttet (”egen læge” relationen).
  • Sundhedsvæsenets Klassifikations System (sks) - Indeholder kliniske og administrative klassifikationer til brug for dokumentation af patienter og sundhedsvæsenets ydelser. I SKS indgår danske udgaver af internationale klassifikationer
  • Organisationer (sor) - Indeholder en lang række organisatoriske informationer for organisatoriske enheder (f.eks. postadresser, besøgsadresser, virtuelle adresser og lokationsnumre), og er det primære register til organisatoriske stamdata for sundhedsdomænet.
  • Taksten - Indeholder oplysninger om godkendte lægemidler, herunder priser, indholdsstoffer, indikationer, opbevaringsbetingelser, tilskudsregler mv.
  • Tilskudsblanket - Indeholder et uddrag af "Taksten" om tilskudsblanketter, så det kan ses hvilket blanketter der bruges til hvilke tilskud.
  • Vaccinationer - Indeholder data om vaccinationer, sygdomme og relaterede lægemidler fra Det Danske Vaccinationsregisters (DDV)
  • Vitaminer - Indeholder informationer om såkaldte ”stærke vitaminer”.Dvs. vitamintilskud, naturlægemidler og andre præparater, der ikke er indeholdt i "Taksten".
  • Ydelser - Ydelser omfatter oplysninger om ydelsesdatoer til brug for Behandlingsrelationsservicen. Formålet er at give information om sikkerheden for at der har været en behandlingsrelation mellem en patient og en given sundhedsfaglig behandler.
  • Ydere - Indeholder oplysninger om ydere under sygesikringen. En yder udøver virksomhed i henhold til loven om offentlig sygesikring. Ved hjælp af Yderregistret er det muligt at få oplysninger om fx praksisadresse, speciale samt lægetype.

4.3. Komponenter

Følgende komponenter er tilgængelige på en NSP:

KomponentForkortelseDokumentationKildekode
National AdviseringsserviceNASLinkLink
BehandlingsrelationsservicenBRSLinkLink
AfkoblingskomponentenDCCLinkLink
FødselsindberetningsserviceFIBSLinkLink
Min logMINLOGLinkLink
Nationalt Patient IndexNPILinkLink
NSP Test serviceNTSLinkN/A
Stamdata modulSDMLinkLink
GatewayGWLinkLink
Security Token ServiceSTSLinkLink

I de følgende afsnit gennemgåes kort hver komponents webservices. For yderligere information henvises der til "Overblik over NSP services"

4.3.1. National Adviseringsservice

Følgende services er tilgængelige i NAS:

ServiceEndpointAdgangskrav
Notification broker service/notificationbroker/serviceIdkort
Subscription manager service/subscriptionmanager/serviceIdkort og whitelist
Id list service/idlist/serviceIdkort og whitelist
Pull point service/pullpoint/serviceIdkort og whitelist
Pull point factory service/pullpointfactory/serviceIdkort og whitelist

Pull point factory er i stand til at oprette pull points som derefter kan anvendes i Pull Point servicen til indhentning af adviseringer. Id list servicen anvendes til oprettelse og vedligeholdelse af Id lister. Subscription manager tilbyder operationer til abonnering på emner og Notification broker muligheden for at publicere adviseringer til abonnenter.

4.3.2. Behandlingsrelationsservicen

Følgende services er tilgængelige i BRS:

ServiceEndpointAdgangskrav
Behandlingsrelationsservice/brs-nsp/service/brsIdkort og whitelist
Generisk opsamlingsservice/gos/service/gosIdkort og whitelist
Notifikationsservice/gos/service/notificationIdkort og whitelist
CPR abonnementsservice/cprabbs/service/cprabbsIdkort og whitelist

Behandlingsrelationer kan slåes op via Behandlingsrelationsservicen. Opsamlinger bestilles i generisk opsamlingsservicen og notifikationsservicen. De kan derefter bruges til at tjekke eventuelle notifikationer som opsamlingen har givet anledning til. CPR abonnementsservicen kan bruges til at forespørge på eventuelle ændringer i CPR data for de CPR-numre man abonnerer på.

4.3.3. Afkoblingskomponenten

Følgende services er tilgængelige i DCC:

ServiceEndpointAdgangskrav
Afkoblingsservice/decouplingWhitelist

Afkoblingskomponenten virker som en software router der sender et request videre til en anden service baseret på den SOAP Action der angives.

4.3.4. Fødselsindberetningsservice

Følgende services er tilgængelige i FIBS:

ServiceEndpointAdgangskrav
Fødselsindberetningsservice/fibsIdkort

Fødselsindberetningsservicen fungere som en proxy til Kirkeministeriets jordemoder-service.

4.3.5. Min log

Følgende services er tilgængelige i MINLOG:

ServiceEndpointAdgangskrav
Minlogservice/minlogIdkort og whitelist
MinLog registreringsservice/minlog-registration/serviceIdkort og whitelist

Minlogservicen kan anvendes til at lave opslag i opsamlede logs i MINLOG systemet baseret på et CPR-nummer. MinLog registreringsservicen kan bruges til at oprette logs i MinLog systemet.

4.3.6. Nationalt Patient Indeks

Følgende services er tilgængelige i NPI:

ServiceEndpointAdgangskrav
NPIService/npiserviceIdkort og whitelist

NPIservicen gør det muligt at foretage opslag i Det Nationale Patient Indeks.

4.3.7. NSP Test service

Følgende services er tilgængelige i NTS:

ServiceEndpointAdgangskrav
Testservice/nts/serviceIdkort

Testservicen anvendes til at teste om en forespørgelse mod en anden komponent overholder standarden "Den Gode Webservice (DGWS)".

4.3.8. Stamdata modul

Følgende services er tilgængelige i SDM:

ServiceEndpointAdgangskrav
Stamdata kopiregisterservice/stamdata-batch-copy-ws/service/StamdataReplicationId-kort og whitelist
Stamdata autorisationsregister enkeltopslagsservice/stamdata-authorization-lookup-ws/service/AuthorizationServiceId-kort og whitelist
Stamdata Det Gode CPR Opslag (v.1.0.0)/stamdata-cpr-ws/service/DetGodeCPROpslagId-kort og whitelist
Stamdata Det Gode CPR Opslag (v1.0.2)/stamdata-cpr-ws/service/DetGodeCPROpslag-1.0.2Id-kort og whitelist
Stamdata CPR enkeltopslagsservice/stamdata-cpr-ws/service/StamdataPersonLookupId-kort og whitelist

Kopiregisterservicen gør det muligt for en anvender at hente en komplet kopi af et bestemt register. Enkeltopslagsservicen til Autorisationsregisteret og CPR registeret gør det muligt at lave enkelte opslag i disse registre.

4.3.9. Gateway GW

Følgende services er tilgængelige i GW:

ServiceEndpointAdgangskrav
Idkortservice/sosigw/service/sosigwIngen
Proxyservice/sosigw/proxy/soap-requestIngen

Idkortservice anvendes til at få udstedt og cachet et id-kort. Proxyservice bruges til at få udskiftet et usigneret id-kort med et der tidligere er blevet oprettet i cachen, og sende forespørgelsen videre til den ønskede webservice.

4.3.10. Security Token Service

Følgende services er tilgængelige i STS:

ServiceEndpointAdgangskrav
SecurityTokenService/sts/services/SecurityTokenServicebruger signeret Id-kort
NewSecurityTokenService/sts/services/NewSecurityTokenServicebruger signeret Id-kort
IdentityTokenService/sts/services/IdentityTokenServiceId-kort
OIOSaml2SosiService/sts/services/OIOSaml2SosiId-kort
Sosi2OIOSamlService/sts/services/Sosi2OIOSamlId-kort

SecurityTokenService og NewSecurityTokenService anvendes til at få udstedt et id-kort, IdentityTokenService omveksler et id-kort til en OIOIDWS-H Identity Token og de to sidste listede services bruges til at veksle mellem NemLogin tokens og id-kort.

5. Hvilke krav stilles der til komponenterne

5.1. Husregler

Da der er mange leverandører af komponenter til NSP er der blevet etableret et sæt husregler der beskriver en række krav, som stilles til udviklingen og dokumentationen af nye komponenter. Ideen med husreglerne er at skabe en homogen platform, hvor mange forskellige komponenter kan co-eksistere og fungere i et driftsmiljø.

5.2. Seal.Java

Da snitfladerne mod STS'en og selve føderationens struktur er defineret i Seal, er det anbefalet at komponentleverandører anvender Seal.Java til at verificere anvenderes id-kort samt til eventuelle kald til STS'en.
  • No labels