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 Wildfly applikationsserver. Alle komponenterne på platformen kører ovenpå denne applikationsserver og anvender en MariaDB database som persistentlag. Foran Wildfly applikationsserveren er der en loadbalancer. Valget af Wildfly 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.

Software Version
Java 8
Wildfly 8.2
MariaDB 10.1.19

1.2. Webservices

De eksternt vendte services på NSP udstilles for nuværende som SOAP/XML webservices typisk som identitetsbaserede web services, der overholder “Den Gode Web Service” (DGWS) eller OIO-IDWS standarderne. Du kan læse mere om DGWS hhv. OIO-IDWS her:

Disse sider redegør også for en række af de sikkerhedshensyn, overordnede sikkerhedsværn og hjælperedskaber, der er udviklet til NSP.

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 instans. 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 fire 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 Sundhedsdatastyrelsen (SDS). Alle opgaver på NSP udliciteres efter gældende EU-regler og er fordelt på et par håndfulde it-firmaer. NSP opereres af Sundhedsdatastyrelsen med bistand fra 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 SDS, 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ås 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æsenterer 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. NSP anbefaler anvendelsen af FOCES certifikater set i forhold til VOCES.

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

Certifikater udstedt af Nets til brug på NSP hører enten til under testmiljøet eller produktionsmiljøet. Et certifikat kan kun bruges i det miljø, det er udstedt 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. Id-kortet 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 id-kort indeholder blandt andet følgende oplysninger:
  • Anvenderidentitet - En streng der bruges til at identificere 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      OBS → SHA3?
  • 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 verificerer 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 anvendere 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 gyldigt 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. Stamdataregistre

NSP importerer stamdata fra et antal nationale registre og tilbyder adgang hertil gennem Stamdata-komponentens services. Følgende stamdataregistre er tilgængelig på NSP:

Anvendes sammen med basis produktet kopiregisterservicen. Stamdataregistrenes struktur ses her: Stamdataregistre og tilhørende datatyper.

Stamdataregistre Beskrivelse Ejer
Apotekere

Registeret indeholder stamdata for apoteker og tilknyttede apotekere. 

Se: Apotekere (version 1) og Apotekere (version 2) for mere information

SDS
Autorisation

Autorisationsregistret indeholder informationer om hvilke sundhedsfaglige uddannelser en given person har gennemgået og er blevet autoriseret til af Sundhedsstyrelsen.

Se: Autorisation for mere information. 

SDS
Begrænset Ordinationsret

Datasættet for begrænset ordinationsret består af en liste af autorisationsnumre for læger og tandlæger, og til hvert autorisationsnummer er der knyttet enten en angivelse af hvorvidt der er tale om en fuldstændig begrænset ordinationsret for lægen/tandlægen, eller der er angivet en række ATC-koder. Stamdata for begrænset ordinationsret anvendes dels i FMK og FMK-online, til at kontrollere at læger der har fået begræset eller fuldstændigt frataget deres ordinationsret ikke ordinerer disse lægemidler via FMK. Stamdata kan desuden anvendes i apotekssystemerne til at foretage samme kontrol, i de tilfælde hvor der udleveres medicin ud fra en recept på papir eller via telefon eller fax.

Se overblik over Begrænset ordinationret: Begrænset Ordinationsret overblik Se yderligere dokumentation: Begrænset ordinationsret

SDS
Bemyndigelse

Udstilling af data fra registrering af delegerede rettigheder imellem sundhedsfaglige personer til brug i sundheds-it systemer. 

Se: Bemyndigelse for mere information.

SDS
CPR

Oplysninger om borgere i Danmark, herunder navne, adresse, familerelationer og børn. Se yderligere beskrivelse: her

Se: CPR Udvidet for mere information.

SDS

Doseringsforslag og -enheder

Forslag til sundhedsprofessionel om dosering af præparat. Data leveres af Lægemiddelstyrelsen. Ønsker til doseringsforslag og rettelser kan sendes til medicinpriser@dkma.dk 

Se: Doseringsforslag og -enheder for mere information.

SDS
eCPR2

Oplysninger om eCPR2.

Se: eCPR2 for mere information.

SDS
Henvisningshotel

Oplysninger om henvisninger.

Se: Henvisningshotel for mere information.

SDS
LPR3

Oplysninger om lpr3 registreringer.

Se: LPR3 for mere information.

SDS
Magistrelle lægemidler I forbindelse med regionernes Apo2 projekt, er det målet at lave en fællesregional database med alle magistrelle præparater der anvendes i Danmark. Ved at samle disse i en database kan man sikre unikke id'er, således at information om patienters brug af disse præparater kan udveksles struktureret - også på tværs af sektore. For også at give de ikke regionale sundhedsparter (herunder primærsektor og hjemmepleje) adgang til disse stamdata, og dermed blive udstillet og vedligeholdt som et stamdataregister på NSP. Se Magistrelle Lægemidler SDS
Medicinpriser (taksten)

Taksten indeholder oplysninger om godkendte lægemidler, herunder priser, indholdsstoffer, indikationer, opbevaringsbetingelser, tilskudsregler mm.

Se: Taksten (medicinpriser) for mere information.

SDS
Sikrede (Sygesikringsregistret)

Register indeholder sygesikringsinformationer om den enkelte borger, herunder hvilken yder gruppe 1 sikrede er tilknyttet (”egen læge” relationen).

Se: Sikrede for mere information.

SDS
SKS-registeret Klassifikation af sygehusvæsnets forskellige institutioner (sygehuse og afdelinger,) og benyttes bl.a. til klassifikation af sundhedsfaglige ydelser i patientadministrative systemer og efterfølgende indberetning til Landspatientregistret.
Se: SKS for mere information.
SDS
Sundhedsvæsenets Organisationsregister (SOR)

Sundhedsvæsenets Organisationsregister (SOR) indeholder organisations- og adressedata, lokationsnumre, EDI meddelelsestyper, SHAK koder mv.  i det danske, grønlandske og færørerske sundhedsvæsen.

Det fulde SOR register eller seneste ændringer i SOR kan hentes. Servicen udstilles via KopiRegisterServicen KRS. Se: SOR - NSP services - Global Site (nspop.dk) for mere information.

SDS
Stærkevitaminer

Datasamling beskriver det godkendte sortiment af lægemidler af typerne stærke vitamin- og mineralpræparater, naturlægemidler samt radioaktive lægemidler, med oplysninger om bl.a. lægemidlernes form, styrke, indholdsstoffer, administrationsveje m.m. Se yderligere beskrivelse: her

Se: Stærke vitaminer (Naturmedicin og vitamin- og mineralpræparater) for mere information.

SDS
Tilknyttede behandlinger

”Tilknyttede behandlinger” er et datasæt, der består af præparater, der skal gives som supplement til en anden behandling med et lægemiddel. Datasættet blev indført, fordi det i forbindelse med ordination af visse specielle lægemidler, er et krav, at der som en del af behandlingen ordineres tilskudspræparater, som ikke er lægemidler og som derfor ikke er registreret med stamdata i "Medicinpriser". For at kunne registrere disse tilknyttede behandlinger stuktureret og kunne referere til dem med unikke id'er, vedligeholdes datasættet "tilknyttede behandlinger".
Datasættet indeholder kun generiske præparater, og der findes ikke tilhørende varenumre/pakninger. Tilknyttede behandlinger er primært relevante for systemer hvori en patients medicinering oprettes eller ændres. Dvs. først og fremmest systemer til praksislæger, speciallæger, tandlæger m.v. og EPJ-systemer. Datasættet er ikke på nogen måde følsomt, og kan derfor udstilles til alle interesserede. Registeret over tilknyttede behandlinger udstilles på NSP og vedligeholdes af Sundhedsdatastyrelsen. Se Tilknyttede behandlinger

SDS
Tilskudsblanket

Blanket til ansøgning om tilskud fra praktiserende læge til Sundhedsstyrelsen på vegne af borger. Løsningen bliver i 1. omgang integreret i FMK.

Se: Tilskudsblanket for mere information.

SDS
Vaccinationer

Datasamling understøtter DDV-service med vaccinations data.

Se: Vaccinestamdata for mere information.

SDS
Ydelser

Oplysninger om ydelser.

Se: Ydelser for mere information.

SDS
Yderregistret

Yderregistret indeholder oplysninger om ydere under sygesikringen. En yder udøver virksomhed i henhold til loven om offentlig sygesikring. Der kan indgå flere ydere under et yder nr. Yderregister indeholder desuden fiktive yder nr.

Se: Yder for mere information.

SDS


Service Beskrivelse Ejer

Register udtræk services


Services til at lave hele, delvis eller sammensatte udtræk af nationale registre p.t. enkeltopslag på Autorisation, CPR og DGWS CPR (Medcom standard)

Se NSP Service: Registerudtrækservices (SDM).

SDS

 

Registre der indgår i Fælles Stamkort

Sundhedsdataregistre Beskrivelse Ejer
Organdonorregister service (ODR) Formålet med organdonorregistret er at give både borgeren og relevante sunhedsfaglige aktører overblik over borgerens organdonor data. Servicen indgår i Fælles Stamkort. SDS
Livs- og behandlingstestamenteregistret service (TTS-BRS) Livs- og behandlingstestamenteregistret (LTR-BTR) er en service til registrering og udstilling af livstestamenteoplysninger for borgere. Servicen indgår i Fælles Stamkort. SDS
Stamkortregister service (SKR) Formålet med et Stamkortregistret er at give borgeren og relevante sundhedsfaglige aktører et fælles overblik over borgerens stamdata.  SDS



4.3. Forretningsservice

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

Service Beskrivelse Ejer
Bemyndigelsesservice (BEM)

Adgangen til Bemyndigelsesservicen (BEM) kan ske via den Nationale Service Platform (NSP). Adgangen forudsætter at det kaldende system er whitelistet af SDS.
Se  Bemyndigelsesservice (BEM) - Leverancebeskrivelse

SDS
Behandlingsrelationsservice (BRS)

Behandlingsrelationsservicen giver adgang til at verificere hvorvidt der findes en aktuel behandlingsrelation mellem en patient og en sundhedsperson.

Se Behandlingsrelationsservice (BRS) - Leverancebeskrivelse.

 SDS
Bivirkningsindberetningsservice (BIS)

Bivirkningsindberetningsservice anvendes til indberetning af bivirkninger observeret ved brug af lægemidler. 

Se Bivirkningsindberetningsservice (BIS) - Leverancebeskrivelse

LMST
Det Danske Vaccinationsregister (DDV)

Det Danske Vaccinationsregister er en elektronisk løsning, som giver borgere og sundhedspersonale et samlet overblik over historiske og planlagte vaccinationer, som er indberettet af lægerne.

Se Det Danske Vaccinationsregister (DDV) - Leverancebeskrivelse.

SDS
Dokumentdelingsservice (DDS)

Dokumentdelingsservicen fungerer som et adgangspunkt til dokumentdeling baseret på profiler under Cross-Enterprise Document Sharing (XDS) som defineret af sammenslutningen Integrating the Healthcare Enterprise (IHE). Dokumentdeling gennem XDS baseret på registrering af kilder, der ligger inde med dokumenter, der har forskellige egenskaber (metadata). Gennem DDS kan man søge i dette registry og få informationer om hvor man kan rekvirere dokumenter, der opfylder søgekravene. Derefter kan man - også gennem DDS servicen - rekvirere dokumenterne. I både søgning og rekvireringskaldene vil der bliver kontrolleret for borgerens frabedelse af indsigt, blive logget på MinLog, og der vil (for opslag fra sundhedspersoner) blive bestilt en automatisk opfølgning på aktuel behandlingsrelation. DDS er tilgængelig på alle NSP’er (cNSP+dNSP) samt på testmiljøerne.

For mere information: DDS information

SDS
Aftaledelingsservicen - Dokument Registrerings- og opdateringsservice (DROS) Etablering af infrastruktur til deling af aftaler i sundhedsvæsenet.

Det nyindkøbte registry skal erstatte det tidligere Healtshare Registry og danne grundlag for den eksisterende dokumentdelingsservice (DDS) udstillet på NSP’en. Det nyindkøbte repository er et statsligt repository til aftaledokumenter. Det nye repository stilles til rådighed for de aktører i sundhedsvæsenet, der ikke ønsker at indkøbe og drifte et IHE XDS registry selv.
Som en del af etableringen af de nye infrastrukturkomponenter er det nødvendigt at lave en række ændringer i den eksisterende dokumentdelingsservice, samt at introducere nye komponenter, der endnu ikke har været en del af den nationale infrastruktur. Aftaledeling er i Pilot for anvendere i Region Nord og Region Midts område.

For mere information: Dokument Registrerings- og Opdateringsservicen (DROS)

SDS
Identitetssløring (IDSAS)

IDSAS er en kommunikationstjeneste til nationale borgervendte løsninger til brug for udmøntning af sløring af sundhedspersoners navn og efternavn på baggrund af API. Se beskrivelse: Identitetssløring af ansatte i sundhedsvæsnet (IDSAS) - Leverancebeskrivelse samt Identitetssløring

IDSAS understøtter, at sundhedsvæsenets parter, på baggrund af hjemmel, kan registrere og opdatere borger-sløringer i servicen og hente aktuel sløringsstatus på baggrund af API.

SDS
Fælles Medicin Kort (FMK) Fælles Medicin Kort giver borgere og sundheds-personale adgang til oplysninger om borgernes medicin og vaccinationer..

Se NSP Service: FMK adgang.

SDS

Fødselsindberetningservice (FIBS)


Fødselsindberetningservice giver adgang til Kirkeministeriets fødselsanmeldelser (jordemoderservice) på NSP. Herunder gives mulighed for at indberette relation mellem barn, mor og evt. far. De indberettede data ender hos CPR-registeret via Kirkeministeriet.

Se NSP Service: Fødselsindberetningsservice (FIBS).

Kirkeministeriet
Fælles Stamkort (FSK) Fælles Stamkort skal understøtte, at alle relevante sundhedspersoner kan få en nem og sikker adgang til de samme stamoplysninger om de patienter, som de har i behandling. Med det Fælles Stamkort skal sundhedspersonalet på sigt let og hurtigt kunne tilgå relevante oplysninger bl.a. pårørendes kontaktoplysninger, personlige hensyn og patientens boligsituation. Det skal give patienter og pårørende tryghed for, at de rigtige oplysninger kan deles mellem de sundhedspersoner, som patienterne møder i deres behandlingsforløb. Læs mere Her SDS
Minlog

MinLog har til formål at registrere, opbevare og udstille registreringer af sundhedspersoners adgang til personfølsomme data. MinLog udstilles til borgere for at kunne give dem et indblik i, hvornår deres sundhedsdata tilgås af personale fra sundhedssektoren. Ligeledes er det muligt for en læge, der benytter uddelegering til en medhjælper, at se hvilke handlinger, medhjælpen har udført som lægens uddelegerede.

Se NSP Service: MinLog2 Leverancebeskrivelse.

SDS

National Adviseringsservice (NAS)

National Adviseringsservice er en generel adviseringsservice, som giver mulighed for at modtage adviseringer i forbindelse med patientens eller borgerens forløb. 

Se National Adviseringsservice (NAS) - Leverancebeskrivelse.

SDS
Min Spærring

Min Spærring er national service til henholdsvis administration og verifikation af borgeres spærringer.

Borgere kan spærre for adgang til deres sundhedsdata for specifikke sundhedspersoner, samt spærre for data fra bestemte afdelinger eller fra en bestemt tidsperiode.

Min Spærring er tilgængelig på alle NSP’er (cNSP+dNSP) samt på testmiljøerne. 

For mere information: Min Spærring

SDS
SOR Opdateringsservice (SORUS) Anvendes af regionernes SOR administratorer, der har behov for løbende at oprette og redigere  SOR data. Link til leverancebeskrivelse SOR Opdater Service (SORUS) - Leverancebeskrivelse - NSP services - Global Site (nspop.dk) SDS
SOR Opslags service (SORLS)

Via SORLS stilles en række operationer til rådighed i form af enkelt opslag (hent en SOR enhed med diverse forskellige tilhørende datatyper), SOR/SHAK mapninger og Søge operationer. Se beskrivelse: SOR Opslag Service (SORLS) - Leverancebeskrivelse - NSP services - Global Site (nspop.dk)

SDS

For yderligere information henvises der til "NSP services"

4.4. Basisservice

Følgende basisservice er tilgængelige på NSP:

Service Beskrivelse Ejer

GW


Gateway-service til caching af ID-kort på dedikerede NSP miljøer

Se Anvendelse af GW service ved brug af NSP.

For central GW til f.eks. brug for kommuner eller andre brugere på de centrale NSP´ere se også: NSP Gateway (NGW) - Leverancebeskrivelse.

GW til Privateplejehjem m.v. se Gateway til private plejehjem m.v. (NSP-GW) - Leverancebeskrivelse

SDS 
DCC

Viderestillingsservice til eksterne nationale services byggende på DGWS.

Se Viderestillingsservice (DCC) - Leverancebeskrivelse.

SDS

STS-services

Flere sikkerhedsservices til autentifikation af ID-kort baseret på OCES3/MitID Erhverv og billetomveksling mellem SOSI og MitID.

Se Sikkerhedsservices (STS) - Leverancebeskrivelse.

SDS

For yderligere information henvises der til "NSP services"

4.5. Støtteservice

Følgende støtteservice til testformål er tilgængelige på NSP:

Service Beskrivelse Ejer
DTG Dynamisk Testdata Generator  Web-klient, hvor en anvender kan logge ind og oprette personer samt tilknytte autorisationer og ydere hertil. Se Dynamisk Testdata Generator (DTG) - Leverancebeskrivelse SDS
NAS Test Publisher Testwebsnitflade til generering af NAS notificationer. Se NAS Test Publisher (NTP) - Leverancebeskrivelse  SDS
DRG Dynamisk Request Generator

DRG kan bruges til at opbygge og eksekvere requests dynamisk mod NSP komponenter.

Vha. templates og dynamiske formularer kan både tekniske og ikke-tekniske guides igennem at udfylde et request på passende vis, og se både selve requestet og svaret derpå.

 Dynamisk Request Generator (DRG) - Leverancebeskrivelse - NSP services - Global Site (nspop.dk)

NTS 


Verification af et DGWS 1.0.1 SOAP-request - kaldes NSP Test Service eller NTS i kort udgave.

Se NSP Test Service (NTS) - Leverancebeskrivelse.

 SDS


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ø. Tilsvarende stille der krav om dokumentation Dokumentationskrav til NSP-platformen

5.2. Seal.Java

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