AFVENTER ENDELIG GODKENDELSE

Indholdsfortegnelse

Releases

En oversigt over de forskellige releases, og eventuelle kommentare omkring disse:

...

Release af version 3 af WSDL

Version 1 og version 2 er fjernet

...

Neden for kan dokumentationen for de aktive WSDL versioner findes.

Version 3

Nyeste version af systemet.

Endpoint

Opdater servicen kan tilgås på adressen:

[miljø url]/sor-opdatering/v3/SOROpdateringService

Sti til  TEST1-miljøet:

http://test1-cnsp.ekstern-test.nspop.dk:8080/sor-opdatering/v3/SOROpdateringService

Sti til TEST2-miljøet:

http://test2-cnsp.ekstern-test.nspop.dk:8080/sor-opdatering/v3/SOROpdateringService

WSDL filen for servicen kan hentes ved at tilføje "?wsdl" til enden af URL'en.

Endpoint til produktion - for Regioner

Regionen skal kontakte sin lokale netværksafdeling for at få oplyst adgang til dNSP.

Snitfladebeskrivelser

Fælles

Sikkerhed

Fælles for hele servicen, er at der bliver benyttet Den Gode Webservice (DGWS) til authentifikering, og der accepteres kun niveau 3 (VOCES og FOCES) eller 4 (MOCES) ID kort udstedt af SOSI-STS. Selvom at niveau 3 både indeholder FOCES og VOCES, så er det kun FOCES som er tilladt.

Namespaces

Alle kald til servicen vil benytte typer defineret under namespacet:

http://sundhedsdatastyrelsen.dk/SOROpdateringService/2019/10/08/

Alle typer benyttet i parametre og resultater i disse kald er defineret under namespacet:

SOR.Services.SOAPServices.V3

Koder

Flere felter benytter koder frem for tekst strenge til at signalere over for servicen, hvilken type enhed der er ønsket at blive oprettet, eller hvor at enheden er placeret. Eksempel på sådan er SystemTypeIdentifier under EanLocationCodeEntityType. Koderne for disse kan findes her:

http://filer.nsi.dk/sor/lookupdata/

Gyldighed

I de kald hvor at SorEntityType bliver returneret, der er den returnerede version ikke den gyldige version af enheden. Den returnerede version er hvad der vil blive gyldigt i fremtiden (tidligst dagen efter).

UserType

...

AddressInformationType

...

Feltet bruges kun til output - input i feltet bliver ignoreret.

...

AddressPostalType

...

SorIdentifierCollectionType

...

ArrayOfEanLocationCodeType

...

ArrayOfEdiIdentifierType

...

ArrayOfSorIdentifierType

...

ArrayOfPrioritizedEntitySpecialityType

...

ArrayOfReplacingInfoType

...

ArrayOfSorSecurityGroupExternalType

...

CountryIdentificationCodeType

...

CountryIdentificationSchemeType

...

Enumeration af landekode identifikations systemer. Kan have en af følgende værdier:

• iso3166-alpha2
• iso3166-alpha3
• un-numeric3
• imk

EanLocationCodeEntityType

...

EanLocationCodeStateType

...

Enumeration af nedarving status for lokationsnumre. Kan have en af følgende værdier:

• Undefined
• None
• Inherited
• Own

LocalAttributeCollectionType

...

PrioritizedEntitySpecialityType

...

ReplacingInfoType

...

SorEntityType

...

NAP projektet er ikke aktivt og NAP er derfor ikke pt. under support og vedligehold.
NAP er ikke opdateret til at understøtte MitID/NemLogin3 og det er derfor ikke længere
muligt at anvende den nuværende version på testmiljøerne.
En evt. genoptagelse af NAP projektet vil afhænge af konkret efterspørgsel.
Kontakt evt. Sundhedsdatastyrelsen ved interesse i NAP.

Introduktion

Formål

Dette dokument er en vejledning til anvendelse af den Nationale Afprøvningsplatform (NAP). 

På baggrund af dette dokument, er det muligt for leverandører af både lægepraksissystemer (LPS) og afprøvningsprojekter, at udvikle systemer som integrerer med NAP. 

Sammenhæng med øvrige dokumenter

Dette dokument er en del af den samlede dokumentation for NAP Platformen.

Dokumentet er udformet, så det i videst muligt omfang opfylder sit formål uafhængigt af de øvrige dokumenter.

Ønskes mere information omkring arkitektur og design findes dette på NAP Platform - Design og Arkitektur beskrivelse.

Ønskes mere information omkring installationsvejledning til anvender kan findes på NAP Platform - Installationsvejledning.

Kom i gang med NAP som projektudvikler

For at oprette et nyt projekt i NAP er der 3 trin:

1. Hent og byg NapJavaHost
2. Udvikling af dit projekt
3. Publicering af dit projekt på test miljøerne

I følgende beskrives opsætningstrinene for at komme i gang med NAP platformen mere detaljeret.

Nap-host-java

Start med at bygge nap-host-java (NapJavaHost - kildekode) med java 13 jdk  via følgende kommando `mvn clean install`. Kør så efterfølgende applikationen med  `java -jar ./target/NapHostJava-fat.jar`.

Når nap-host-java åbnes, vil der blive præsenteret en login dialog.  

Login ved at trykke på test1 og bruge default login credentials. Dette vil trække en SAMLAssertion fra STS på test1, som kan bruges i 30 min. Når der er brugt et gyldigt login, vil man se et eksempel på et værtssystem. 

Applikationen viser 4 faner, hvor 3 af dem har screenshots som billeder (for at simulere et værtssytem), men den fanen "Afprøvningsløsning", indeholder en chromium browser som åbner nap-lobby-web.

Her fra kan brugerens tilgængelig projekter ses.

Indtast et cpr nummer på en test person (Eksempelvis "2708599967", som er et hyppigt anvendt test cpr nummer), herefter kan der browses rundt i fanerne.

Udvikling af dit projekt 

Der ligger et udviklingsprojekt som hedder "Developer", som der hurtigt kan sætte gang i anvendelsen af NAP platformen som udviklingsmiljø.

Hvis dette projekt trykkes på, vil nap-java-host åbne en, hvilken som helst applikation der hostes på http://localhost:4600.

For at se eksempler på anvendelse af kontekstbroen til at kommunikere med hostsystemet henvises til NAP SDK - Guide til anvendere samt NAP Ref.Impl. - Guide til anvendere.

Publicering af dit projekt

Når dit projekt er klar til at blive testet i NSPs testmiljøer skal du have registret dit personlige / din virksomheds moces test certifikat som administrator i NAP.

Dette gøres ved at oprette en support sag på SDS´s Nationale Servicedesk.

Efterfølgende kan du bruge det certifikat til at logge ind på

NAP test1

hvorfra du kan tilføje metadata omkring dit projekt.

NapJavaHost understøtter tilføjelse af nye moces certifikater, hvis moces certifkaterne kun har 1 enkelt registreret autorisation.

Derfor kan du tilføje dit certifikat i nap-javahost-host, login på test1 i NapJavaHost, og se om projektet er tilgængeligt for dig og virker som forventet. 

Kom igang med NAP som værtssystem-/ LPS udvikler

I det følgende beskrives, hvordan man som værtssystem-/ LPS udvikler, integrerer NAP platformen i sit system. 

Integrationen med NAP

For at kommunikere med NAP'en, skal det givne værtssystem/LPS opsættes, således den kan lytte på specifikke beskeder fra SDK'et. 

I det nedenstående vil eksemplerne tage udgangspunkt i Java, og der kan derfor også tages udgangspunkt i nap-host-java, hvis der er brug for inspiration.

nap-java-host på SVN.

Opsætning af kommunikation med SDK.

For at kunne kommunikere med SDK'et, gøres brug af et Webview, som er en JavaFX komponent. Webviewet kan indlæse hjemmesider, samt der er mulighed for at indlejre javascript på den indlæste HTML side.

Det er vigtigt, at det er mulighed for at indlejre javascript i Webviewet, da det er den måde SDK'et fungere på. Endvidere skal Webviewet være kompatibel med en af de understøttede browser, som er beskrevet i NAP Platform - Yderligere dokumentation.

Læs mere om dette her NAP SDK - Guide til udviklere.

I nedenstående eksempel, tilføjes "NAPBridge" i variablen "NAP" på window, som er i global scope på den indlæste HTML side.

final JSObject window = (JSObject) webEngine.executeScript("window");
window.setMember("NAP", napBridge)

En implementering af NAP Bridge kan se således ud:

public class NAPBridge {
        private JSObject handler;

        /**
         * Transforming a JSON string into a NAPMessage and sending it to subscribers.
         * The handle to send messages to this host.
         * @param rawEventString A raw string representation of the NAP message
         */
        public void send(String rawEventString) {
            try {
                System.out.println(this.getClass().getName() + " send(): " + rawEventString);
                NAPMessage msg = objectMapper.readValue(rawEventString, NAPMessage.class);
                notifyListeners(msg);
            } catch (IOException ioException) {
                System.out.println(this.getClass().getName() + " " + ioException);
            }
        }

        /**
         * Sets the bridge to act as a callback.
         * This handle will be used to send messages out from the host.
         * @param handler JSObject representing the callback handle.
         */
        public void setCallback(JSObject handler) {
            System.out.println(this.getClass().getName() + " setCallBack(): " +  handler);
            this.handler = handler;
        }
    }

Et JS objekt, som bridge variablen, gør at man kan eksekvere javascript metoder og undersøge javascript properties. 

Der er implementeret to metoder, som er send() og setCallback(), det er disse to metoder som SDK'et wrapper og kalder. 

Send(), er et håndtag til at sende beskeder til hosten, der gør brug af et internt subscribe pattern, som notificerer dem, som lytter. En implementering observer / listener, kunne se således ud:

private void handleBridgeCallBacks(NAPMessage napMessage) {
        switch (napMessage.getEvent().getNAPEventType()) {
            case PatientOpen:
                sendCurrentPatient(txfCPR.getText(), napMessage.getDate(), napMessage.getId());
                break;
            case WebAppSelected:
                handleWebAppSelected(napMessage);
                break;
            case ProjectsRetrieved:
                filterProjectsRetrievedAndSendMessage(napMessage);
                break;
            case SessionClose:
                handleSessionClose(napMessage);
                break;
            case SessionError:
                handleSessionError(napMessage);
                break;
            default:
                System.err.println("Unexpected event type: " + napMessage.getEvent().getNAPEventType());
        }
}

Når der skal sendes en NAP besked fra værts applikation, kan der så gøres brug af bridgen. Call() tager imod en string, som angiver hvilken metode man vil kalde, her "handle", da det er den variable som SDK'et lytter på. Metoden tager en string som parameter, hvori indholdet er en JSON struktur der repræsenterer en NAPMessage.

 if(napBridge.bridge != null) {
     this.napBridge.bridge.call("handle", eventRawJSONString);
 }

NAP Test Web

Projektet har til hensigt at teste værtssystemers integration af NAP. Der udstilles en test suite indeholdende en test, der sender en NAP besked for samtlige events.

Der er separate tests cases, som kan køres enkeltvis eller samlet. Den er derfor oplagt til at teste et værksystems implementering af eventkataloget.

Dette afprøvningsprojekt ligger både på test1 og test2 og kan åbnes fra lobbyen i det givne miljø.

Test1: https://test1-nap.insp.nspop.dk:8443/testweb/

Bemærk, at testene fejler, hvis ikke applikationen er indlejret i en host, som har implementeret NAP bridge.

NAP Lobby Web

Når kommunikationen er opsat med SDK'erne, er det nu klart til at vise alle de projekter der er tildelt.

De forskellige typer events kan læses på NAP SDK - Guide til anvendere.

For at se de projekter der er tilgængelige, skal NAP Lobby Web åbnes i det nuværende system.

Sikkerbrowser opstart

Sikker Browser opstart af Nap Lobby Web følger protokollen "Sikker browser opstart version 2".

Lignende implementationer kan ses i FMK-online og læses her https://wiki.fmk.netic.dk/lib/exe/fetch.php?media=fmk:fmko:guide_til_anvendere_af_sbov2_1_2.pdf og her for eGraviditet *Graviditetsmappe Web Facade - Guide til anvendere.

Anvendelse af Sikker Browseropstart i fagsystem

En forudsætning for at kunne tilgå Nap Lobby Web via Sikker Browseropstart er, at fagsystem har dannet et SOSI idkort, der repræsenterer brugerens login-session på fagsystemet. Trækning og signering af SOSI idkort er er ikke beskrevet her, men er dokumenteret i https://www.digitaliser.dk/resource/456411/artefact/SOSIprogrammersguide.doc?artefact=true&PID=456417.

Givet at fagsystemet har dannet et idkort for brugeren, er de nødvendige skridt for at tilgå Nap Lobby Web via Sikker Browseropstart i kort form:

1. Idkortet omveksles til en SAML assertion via et webservicekald til SOSI STS. 2 http://test1.ekstern-test.nspop.dk:8080/sts/services/Sosi2OIOSaml 
2. Den modtagne SAML assertion indlejres i et SAML Response.
3. Fagsystemet udstiller en webapplikation for brugeren, som brugerens browser dirigeres til.
4. Denne webapplikation sender et response til brugerens browser, som indeholder en HTML 5 FORM, som automatisk POST’es til FMK-online ved load. Denne FORM indeholder ovennævnte SAML assertion i base64 enkoded form. 
5. https://test1-nap.insp.nspop.dk:8443/lobby/saml/SAMLAssertionConsumer accepterer den POST’ede SAML assertion, og brugeren er nu logget ind.

Disse skridt er beskrevet i større detalje i det følgende.

Den relevante API er generelt beskrevet i https://www.digitaliser.dk/resource/456411/artefact/SOSIprogrammersguide.doc?artefact=true&PID=456417.

Desuden findes et implementerings eksempel i https://svn.nspop.dk/src/components/nap/nap-host-java/trunk/.

Omveksling af SOSI idkort til SAML-assertion

SOSI idkortet omveksles til en SAML-assertion via et webservice-kald til STS. Se https://www.nspop.dk/display/public/web/STS+-+Medarbejder-Billetomveksling for beskrivelse af omveksling fra SOSI idkort til SAML assertion (afsnit 7 beskriver overordnet den relevante omveksling, afsnit 8 indeholder links til eksempelkode: IDcardToOIOSAMLExample.java.

Der skal ved omveksling angives et ”audience”.

Den relevante værdi for audience er for NSPs testmiljøer en af følgende:

1. https://saml.test1-nap.insp.nspop.dk/lobby
   

2. https://saml.test2-nap.insp.nspop.dk/lobby

Indlejring af SAML-assertion i SAML-response

Den modtagne SAML assertion skal efterfølgende indsættes i en SAML Response xml-struktur. Det opbyggede SAML Response skal have følgende form.

saml:EncryptedAssertion elementet repræsenterer svaret fra omvekslingen af idkort til SAML assertion i STS, og er her vist i forkortet form.

Post af SAML-response fra webapplikation i fagsystem

For at tilgå Nap Lobby Web via Sikker Browseropstart, skal brugerens browser POST’e en HTML FORM med det opbyggede SAML Response til eGradivitet.

Dette kan fx opnås ved at fagsystemet udstiller en webapplikation, der kan returnere et response med et onload script, der POST’er formen. Dette response kan opbygges således:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="content-type" content="text/html, charset=utf-8" />
<title>SAML 2.0 POST</title>
</head>
<body onload='document.forms[0].submit()'>
<form action='https://test1-nap.insp.nspop.dk:8443/lobby/saml/SAMLAssertionConsumer' method='post'>
<input type='hidden' name='SAMLResponse' value='wrappedSamlResponse'/></form>
</body>
</html>

SAMLResponse-parameterens tilhørende value er her vist forkortet i form, men skal indeholde en base64 enkodet repræsentation af det opbyggede SAML Response.

Indholdet af action attributten afspejler hvilket miljø, der ønskes brugt (test eller produktion).

Action attributten kan starte med en af følgende url’er,

Test 1: https://test1-nap.insp.nspop.dk:8443/lobby/saml/SAMLAssertionConsumer

Test 2: https://test2-nap.insp.nspop.dk:8443/lobby/saml/SAMLAssertionConsumer

Opstart af andre projekter fra Nap Lobby Web

Samme procedure for Sikker browser opstart gør sig gældende for andre afprøvningsprojekter, fx Nap Reference Web,  hvor urlen slutter på /saml/SAMLAssertionConsumer. 

Når et projekt klikkes i Lobby sendes en besked af typen WebAppSelected se https://www.nspop.dk/display/public/web/NAP+SDK+-+Guide+til+anvendere hvor i audience og url er beskrevet.

Opstart som standalone

Lobbyen kan også åbnes om standalone på Test1: https://test1-nap.insp.nspop.dk:8443/lobby

Hvor det er muligt at logge ind med moces certifikater. Dette er egnet til projektadministratorer for at oprette et projekt ellere redigere et projekt

SorSecurityGroupExternalType

...

Enumeration af security groups. Kan have en af følgende værdier:

• SorDecentralRole
• SorEditorRole
• SorGeoRole
• SorShakRole
• SorMoveEanRole
• SorEdiAdminRole

SorStatusType

...

SorTypeType

...

Enumeration af SOR typer. Kan have en af følgende værdier:

• IO
• HI
• OU

StatusType

...

VirtualAddressInformationType

...

CreateSorEntity

Security gruppe påkrævet: SorCentralRole, SorDecentralRole

...

CreateSorEntityRequestParameterType

...

CreateSorEntityResponseResultType

...

EditSorEntity

Security gruppe påkrævet: SorCentralRole, SorDecentralRole

...

EditSorEntityRequestParameterType

...

EditSorEntityResponseResultType

...

MoveSorEntity

Security gruppe påkrævet: SorCentralRole, SorDecentralRole

...

MoveSorEntityRequestParameterType

...

MoveSorEntityResponseResultType

...

ReplaceSorEntities

Security gruppe påkrævet: SorCentralRole, SorDecentralRole

...

ReplaceSorEntitiesRequestParameterType

...

ReplaceSorEntitiesResponseResultType

...

CloseSorEntity

Security gruppe påkrævet: SorCentralRole, SorDecentralRole

...

CloseSorEntityRequestParameterType

...

CloseSorEntityResponseResultType

...

EditEanLocationCodeSystemType

Security gruppe påkrævet: SorEdiCentralRole, SorEdiAdminRole

...

EditEanLocationCodeSystemTypeRequestParameterType

...

EditEanLocationCodeSystemTypeResponseResultType

...

EditEanLocationCodeCommunicationSupplier

Security gruppe påkrævet: SorEdiCentralRole, SorEdiAdminRole

...

EditEanLocationCodeCommunicationSupplierRequestParameterType

...

EditEanLocationCodeCommunicationSupplierResponseResultType

...

EditEanLocationCodeEdiAdministrator

Security gruppe påkrævet: SorEdiCentralRole

...

EditEanLocationCodeEdiAdministratorRequestParameterType

...

EditEanLocationCodeEdiAdministratorResponseResultType

...

EditEanLocationCodeRegion

Security gruppe påkrævet: SorEdiCentralRole, SorEdiAdminRole

...

EditEanLocationCodeRegionRequestParameterType

...

EditEanLocationCodeRegionResponseResultType

...

EditEanLocationCodeSystemSupplier

Security gruppe påkrævet: SorEdiCentralRole

...

EditEanLocationCodeSystemSupplierRequestParameterType

...

EditEanLocationCodeSystemSupplierResponseResultType

...

MoveEanLocationCode

Security gruppe påkrævet: SorEdiCentralRole, SorDecentralRole

...

MoveEanLocationCodeRequestParameterType

...

MoveEanLocationCodeResponseResultType

...

UpdateEdiTypes

Security gruppe påkrævet: SorEdiCentralRole, SorDecentralRole

...

UpdateEdiTypesRequestParameterType

...

UpdateEdiTypesResponseResultType

...

Fejlkoder

Alle operationer vil som udgangspunkt returnere et Status objekt som en del af svaret. Dette object indeholder altid to felter, ErrorCode og Message. Hvis ErrorCode er 0, så var kaldet en succes, ellers skete der en fejl i løbet af kaldet. Positive værdier er validerings fejl fra SOR's interne systemer, og Message vil have en beskrivelse af fejlen. Mere tekniske fejl vil blive lavet som en SOAP fault. De nedenstående er hvilke denne applikation definerer:

...

Andre fejlkoder kan forekomme, men disse kommer fra backenden, eller dens underliggende services.

Det skal pointeres, at MedCom's fault code kan findes under detail sektionen af den resulterende SOAP fault. Den påkrævede faultstring vil altid være "Server".

Eksempel på kald

Java frameworks

For en eksempel implementation i Java, kan der med foredel tages udgangspunkt i servicens integrationstest:

https://svn.nspop.dk/svn/capgemini/SORServices/NSP/sorus/trunk/SorUpdateService/src/test/java/dk/sds/nsp/sor/sorus/servlet/SorusV3ServletIT.java

Denne implementerer og bruge er JAX-WS klient for servicen, implementeret med Apache CXF. Klienten benytter også Seal.Java biblioteket til håndtering af SOSI ID kort og DGWS. Yderligere dokumentation på biblioteket kan findes her:

https://digitaliser.dk/group/374971

.NET frameworks

Seal.NET er .NET ekvivalenten til Seal.Java, og er dokumenteret her:

http://digitaliser.dk/group/375117

Der eksisterer ingen eksempel implementation i .NET, men bibliotek og WSDL er frit tilgængelig til at lave en sådan.