SEI2 snitfladebeskrivelse (IDWS)

(1)

1 / 30

SEI2 snitfladebeskrivelse (IDWS)

SEI2 (Sundhedsdatastyrelsens Elektroniske Indberetning 2)

(2)

2 / 30 INDHOLDSFORTEGNELSE

1 Introduktion ... 3

1.1 Anvendte termer og forkortelser ... 3

2 3. parts integration via webservices ... 5

2.1 Generelt ... 5

2.2 3. parts løsninger via IDWS ... 5

2.2.1 Miljøer ... 6

2.2.2 WSDL dokumentation ... 7

2.2.3 SchemaReport - SOAP Envelope Request (Webservice Request) ... 8

2.2.4 SchemaReport - SOAP Envelope Response (Webservice Retursvar) ... 13

2.2.5 SchemaCancel - SOAP Envelope Request (Webservice Request) ... 16

2.2.6 SchemaCancel - SOAP Envelope Response (Webservice Retursvar) ... 19

2.2.7 SchemaPrefillMRSA - SOAP Envelope Request (Webservice Request) ... 20

2.2.8 SchemaPrefillMRSA - SOAP Envelope Response (Webservice Retursvar) ... 24

2.2.9 SchemaGetStatusMRSA - SOAP Envelope Request (Webservice Request) ... 26

2.2.10 SchemaGetStatusMRSA - SOAP Envelope Response (Webservice Retursvar)... 28

(3)

3 / 30

1 Introduktion

Formålet med dette dokument er at beskrive snitflader til SEI2 løsningen.

- Integration fra 3. parts systemer, som sender skemaer ind i SEI2 via udstillede webservices

For brugervejledninger mv henvises til SDS egne dokumenter.

SEI2 systemets funktionaliteter er bygget på standard ERP-systemet kaldet Microsoft Dynamics 365 for Finance and Operations (D365). Integrationer til/fra SEI2 er således, hvor muligt, bygget på de eksiste- rende værktøjer/frameworks som er tilgængelige i D365. I dette dokument kan der derfor være henvis- ninger til D365 dokumentation, som vedligeholdes af Microsoft og ikke er nærmere beskrevet i dette dokument. Den dokumentation vil være på engelsk.

1.1 Anvendte termer og forkortelser

Følgende termer/forkortelser er anvendt i dokumentet.

Term Beskrivelse

SDS Sundhedsdatastyrelsen, som har bestilt og skal anvende løsningen ADFS Active Directory Federated Services.

SEB Sundhedsstyrelsen Elektroniske Brugerstyring. Det er en løsning til centralstyring af rettighe- der for mange applikationer/systemer hos SDS.

SEI1 Sundhedsdatastyrelsens Elektroniske Indberetningssystem version 1. Dette er det allerede ek- sisterende system, som skal fornys til SEI2.

SEI2 Sundhedsdatastyrelsens Elektroniske Indberetningssystem version 2. Dette er det nye system, som dette dokument beskriver.

IVF Dette er en af de skemaer som kan indberettes via SEI2. IVF er fertilitetsbehandling.

NAB Dette er en af de skemaer som kan indberettes via SEI2. NAB står for National Alkohol Be- handling

Dødsattest Dette er en af de skemaer som kan indberettes via SEI2. Dødsattester registreres ifm dødsfald i Danmark.

Tvang Dette er en af de skemaer som kan indberettes via SEI2. Tvang registreres ifm tvangsbehand- linger i psykiatrien.

Injiccerbar heroin/me-

tadon Dette er en af de skemaer som kan indberettes via SEI2. Injicerbar heroin registreres ifm XML XML (eXtensible Markup Language) er et filformat til udveksling af data mellem systemer CSV CSV (comma separated values) er et filformat til udveksling af data mellem systemer.

CPR CPR er forkortelse for Det Centrale Personregister, som er et register over alle danskere, der bl.a. bruges i sundhedsvæsenet til identifikation af individer

SOR SOR er forkortelse for Sundhedsvæsenets Organisationsregister.SOR er et register, der indeholder organisations- og adressedata om sundhedsvæsenet. Registeret anvendes af en række fagsystemer i sundhedsvæsenet, herunder SEI1 og i fremtiden SEI2.

SKS SKS er en forkortelse for Sundhedsvæsenets Klassifikationssystem

FGR FGR er en forkortelse for Fællesgrunddataregister. FGR indeholder forskellige registre inde- holdende koder/stamdata bl.a. til brug for SEI1 og i fremtiden SEI2.

SHAK SHAK er forkortelse for Sygehus-afdelingsklassifikation. Sygehus-afdelingsklassifikationen klassificerer hospitaler og andre sundhedsrelaterede institutioner, samt afdelinger og afsnit i det danske sundhedsvæsen, herunder Grønland og Færøerne. Ligesom SOR anvendes dette i

(4)

4 / 30

en række fagsystemer i sundhedsvæsenet. SHAK vil i fremtiden i stor grad erstattes af SOR, men SEI2 skal i nogen tid understøtte begge.

FDD Funktionel Design Dokument er SCALES standarddokument til brug ved nærmere beskrivelse af konfigurationer og modifikationer identificeret i solution backloggen (SBL).

D365/D365FO Microsoft Dynamics 365 for Finance and Operations er en forretningsapplikation for mellem og store virksomheder. Det er denne applikation som SEI2 bygges på.

Look-up En look-up er en funktion som lister alle relevante stamdata i en lille drop-down liste/pop-up menu, så brugere kan vælge blandt valide værdier/muligheder.

DGWS Den Gode WebService er et udvekslingsformat mellem systemer anvendt i sundhedssektoren og hos SDS mellem SEI1 (Dødsattest side 1 og Børnedatabasen skemaer) og 3. partssystemer.

XMLDSIG XML-syntaks for digital signatur er et udvekslingsformat mellem systemer anvendt i sundhedssektoren og hos SDS mellem SEI1 (alle skemaer) og 3. partssystemer.

IDWS Identity Based Web Services er et udvekslingsformat mellem systemer anvendt i sundhedssektoren. Det er fremtidens webserviceformat i SEI2.

FTT File Transfer Tool er et SCALES product til dataintegrationer til D365.

(5)

5 / 30

2 3. parts integration via webservices

SEI2 er udover en indberetningsløsning med pt 22 skemaer også en opsamling af tilsvarende skemadata registreret i 3. parts systemer fra de store regionale løsninger til de mindre lægepraksisløsninger hos pri- vate.

Således registreres langt størstedelen af data IKKE i SEI2, men i 3. parts systemer i sundhedssektoren i regionale, kommunale og privat regi.

Disse data sendes til SEI2, for fælles opsamling og overlevering til SDS DWH/BI, hvor de modtages som webservices, som skal gennemgå den samme validering/kvalitetssikring, som skemaer indtastet direkte i SEI2.

Dette kapitel beskriver de 3 webservice-formater som SEI2 kan modtage.

2.1 Generelt

For at sikre en glidende/smidig overgang fra SEI1 til SEI2, så er der lavet bagud kompatible webservices i 2 formater:

- XMLDSIG er det format SEI1 generelt anvendte for 3. part og som kommunikation mellem klient og front-end/back-end. Formatet skal udfases i løbet af 2019.

- DGWS er et format, som kun er implementeret i SEI1 på dødsattest side 1 og børnedatabasen.

Formatet skal udfases i løbet af 2019.

Derudover har vi i SEI2 implementeret ”fremtidens” webservice format, IDWS, som er det format som SEI2 vil udstille og som det forventes at alle 3. parts leverandører overgår til i løbet af 2019.

Da de første 2 formater er dikteret af SEI1, så vil det kun i begrænset omfang beskrives i dette dokument, hvad der gøres og ellers henvises til SEI1 dokumentation. De er også ”midlertidige” løsninger, idet de forventes afviklet i løbet af 2019 (sammen med resten af SEI1).

For IDWS tænkes dette dokument at være fyldestgørende således at 3. part kan udvikle mod denne snit- flade.

Bemærk at modsat SEI1, så vil SEI2 altid foretage CPR-opslag og Autorisations-opslag i forbindelse med indberetninger og fejl i disse opslag vil betyde at skemaer afvises med valideringsfejl.

2.2 3. parts løsninger via IDWS

SEI2 introducerer et nyt fremtidens format for webservices til SEI2, som på sigt vil erstatte DGWS og XMLDSIG formaterne, som skal udfases. Dette nye format følger IDWS-standarden (mere præcist IDWS- H).

Der henvises til følgende dokumentation om IDWS-H: https://www.digitaliser.dk/resource/766172 Alle skemaer i SEI2 (undtagen SEI-LPR) vil indberettes via en webservice i IDWS-format.

Der udstilles følgende webservicemetoder:

(6)

6 / 30 - SchemaReport – der laves en metode for hvert skema, hvor body-delen vil være unik for hvert skema. metoden anvendes til at indberette et skema i SEI2. Hvis skemaGUID er udfyldt vil gam- mel indberetning erstattes af den nye og ellers betragtes indberetning som et nyt skema.

- SchemaCancel – der laves en metode for hvert skema, hvor body-delen vil være ens for alle skemaer. Metoden anvendes til at annullere et skema i SEI2.

For MRSA skemaet udstilles endvidere følgende metoder (da dette skema håndteres anderledes end de øvrige):

- SchemaPrefillMRSA – der laves en metode til at præ-udfylde et MRSA skema og indsende det som kladde. Skemaet kræver herefter manuelt behandling i SEI2 for at kunne blive indberettet.

- SchemaGetStatusMRSA() – der laves en metode til at hente status på det tidligere indsendte skema. Denne bruges til at lukke skemaet af i afsender-systemet (eller holde den åben og sende reminder).

Sidst men ikke mindst udstilles følgende ikke skema-relaterede metoder:

- UserGetDetails – der laves en metode til at returnere information til brugeren (indsendte certifikat) om egne brugerdata, brugergrupper samt roller i SEI2. Bemærk denne er IKKE implementeret endnu!

- UserCreate – der laves én metode til at oprette en D365 og SEI bruger, så skema senere kan indberettes på den pågældende bruger. Bemærk denne er IKKE implementeret endnu!

2.2.1 Miljøer

Der er etableret 3 miljøer i SEI2:

1) Testmiljø, der kan anvendes til de første test i forbindelse med udvikling af webservices. Testmil- jøet anvender testdata (fx test CPRnr iht Medcom) og opslag i NSP test-services (read-only) 2) Preprod, der kan anvendes til de sidste test før endelig overgang til produktion. Preprod anven-

der ”produktionslignende” data og opslag i NSP prod-services (read-only) 3) Prod, der er SEI2 produktionsmiljøet.

Man skal tilmeldes alle tre miljøer i processen med at udvikle og teste IDWS webservices og tilslutning til produktionsmiljø.

2.2.1.1 Testmiljø

Der er etableret et testmiljø, hvor IDWS-servicen kan afprøves og hvor man via en brugergrænseflade kan kontrollere sine afsendte data i SEI2.

Testmiljøets brugergrænseflade findes her: https://sei.test.sundhedsdata.dk/namespaces/AXSF/

Testmiljøets webservicegrænseflade findes her: https://seiidws.test.sundhedsdata.dk

SDS er ansvarlig for at lave en vejledning omkring tilslutning samt anvendelse af data på testmiljøet, herunder at:

- Testmiljøet kan anvendes med test CPRnr i henholdt til Medcoms standard.

(7)

7 / 30 - Tilmelding sker ved at kontakte SDS for oprettelse af bruger med FOCES certifikat med informa-

tion om hvilket skema, der ønskes adgang til at indberette samt evt oprettelse af bruger med MOCES certifikat, således at data også kan verificeres i SEI2.

- Til Testmiljøet kan anvendes testcertifikater.

På anmodning kan der udleveres en test-klient til at understøtte udviklingsprocessen på Microsoft plat- formen. Bemærk denne er IKKE supporteret, men er udviklet til SCALES egen test og vil ikke blive vedlige- holdt fremadrettet.

2.2.1.2 Preprod-miljø

Der er etableret et preprod-miljø, hvor IDWS-servicen kan afprøves med ”produktionslignende” data og hvor man via en brugergrænseflade kan kontrollere sine afsendte data i SEI2.

Preprod-miljøets brugergrænseflade findes her: https://sei.preprod.sundhedsdata.dk/namespaces/AXSF/

Preprod-miljøets webservicegrænseflade findes her: https://seiidws.preprod.sundhedsdata.dk

SDS er ansvarlig for at lave en vejledning omkring tilslutning samt anvendelse af data på preprod-miljøet, herunder at:

- Preprod-miljøet kan anvendes med rigtige CPRnr, som testes mod CPR-registret.

- Tilmelding sker ved at kontakte SDS for oprettelse af bruger med FOCES certifikat med information om hvilket skema, der ønskes adgang til at indberette samt evt oprettelse af bruger med MOCES certifikat, således at data også kan verificeres i SEI2.

- Til Preprod-miljøet kan anvendes testcertifikater.

2.2.1.3 Prod-miljø

Produktionsmiljøets brugergrænseflade findes her: https://sei.sundhedsdata.dk/namespaces/AXSF/

Produktionsmiljøets webservicegrænseflade findes her: https://seiidws.sundhedsdata.dk SDS er ansvarlig for at lave en vejledning omkring tilslutning til prod-miljøet, herunder at:

- Tilmelding sker ved at kontakte SDS for oprettelse af bruger med FOCES certifikat med information om hvilket skema, der ønskes adgang til at indberette samt evt oprettelse af bruger med MOCES certifikat, således at data også kan verificeres i SEI2.

- Til Prod-miljøet skal anvendes produktionscertifikater.

2.2.2 WSDL dokumentation

Der er angivet eksempler på webserviceanmodning og retursvar i efterfølgende afsnit, men for den fulde og seneste WSDL henvises til følgende URL: https://seiidws.test.sundhedsdata.dk.

Eksemplet nedenfor er fra en udviklingsboks, men URL kan udskiftes med den viste ovenfor og herfra kan man dykke ned i dokumentationen.

(8)

8 / 30

2.2.3 SchemaReport - SOAP Envelope Request (Webservice Request)

Der indsendes en SOAP envelope bestående af en header og en body. Disse er beskrevet i afsnit nedenfor.

<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"

xmlns:u="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">

<s:Header>

<s:Body u:Id="_1">

</s:Envelope>

Se Header og Body nedenfor.

2.2.3.1 Request Header

SOAP header etableres som anvist nedenfor. Den ”variable” del er vist med gul. For URL, så angives samme URL, dog angives den af de metoder, som beskrevet ovenfor, som ønskes benyttet. Du signerer med eget certifikat. Bemærk at <Removed> er indsat til at erstatte krypteret tekst som ikke giver værdi i denne dokumentation (ud over at gøre eksemplet længere).

(9)

9 / 30

(10)

10 / 30

(11)

11 / 30

2.2.3.2 Request Body

Nedenfor ses et eksempel på en body, med et dødsattest side 1 skema (mortality1). Der kan skiftes mellem de forskellige skema-body ved at angive en anden kontrakt (se WSDL dokumentation). Den gule markering viser det ”variable”.

(12)

12 / 30

<s:Body u:Id="_1">

<contract i:type="b:SEI2SchemaMortality1Contract"

xmlns:b="http://schemas.datacontract.org/2004/07/Dynamics.AX.Application"

xmlns:i="http://www.w3.org/2001/XMLSchema-instance">

<b:schemaCreatedDate>2018-10-04T12:00:00</b:schemaCreatedDate>

<b:schemaGuid>5685656e-4655-493a-ba1c-f4e1157bd8d0</b:schemaGuid>

<b:schemaUserGroupId i:nil="true"></b:schemaUserGroupId>

<b:bornDead>No</b:bornDead>

<b:bornDeadBirthDate>1900-01-01T12:00:00</b:bornDeadBirthDate>

<b:bornDeadGenderChild>NotSelected</b:bornDeadGenderChild>

<b:city>Aarhus C</b:city>

(13)

13 / 30

<b:country></b:country>

<b:deathDate>1900-01-01T12:00:00</b:deathDate>

<b:deathDateTime>1900-01-01T00:00:00Z</b:deathDateTime>

<b:deathPlaceCity></b:deathPlaceCity>

<b:deathPlaceStreetName></b:deathPlaceStreetName>

<b:deathPlaceStreetNum></b:deathPlaceStreetNum>

<b:deathPlaceUnknown></b:deathPlaceUnknown>

<b:deathPlaceZipCode></b:deathPlaceZipCode>

<b:deathResidense>NotSelected</b:deathResidense>

<b:deathSite>NotSelected</b:deathSite>

<b:deathSiteDepartmentCode></b:deathSiteDepartmentCode>

<b:deathSiteHospitalCode></b:deathSiteHospitalCode>

<b:deathSiteSORCode></b:deathSiteSORCode>

<b:deathTime>0</b:deathTime>

<b:electronicImplants>No</b:electronicImplants>

<b:findingCity></b:findingCity>

<b:findingDate>2018-10-04T12:00:00</b:findingDate>

<b:findingDateTime>2018-10-04T11:00:00Z</b:findingDateTime>

<b:findingResidense>NurseryHome</b:findingResidense>

<b:findingSite>Residense</b:findingSite>

<b:findingStreetName></b:findingStreetName>

<b:findingStreetNum></b:findingStreetNum>

<b:findingTime>46800</b:findingTime>

<b:findingUnknown></b:findingUnknown>

<b:findingZipCode></b:findingZipCode>

<b:firstName>Sverre</b:firstName>

<b:gender>Male</b:gender>

<b:mortalityAutopsyDate>2018-10-04T12:00:00</b:mortalityAutopsyDate>

<b:mortalityAutopsyDateTime>2018-10-04T11:10:00Z</b:mortalityAutopsyDateTime>

<b:mortalityAutopsyTime>47400</b:mortalityAutopsyTime>

<b:municipalityCode>219</b:municipalityCode>

<b:otherSubmitterOfPage2>NotSelected</b:otherSubmitterOfPage2>

<b:policeContactedYesNo>No</b:policeContactedYesNo>

<b:policeStation></b:policeStation>

<b:schemaPersonCivilRegistrationIdentifier>010490-9995</b:schemaPersonCivilRegistrationIdentifier>

<b:signCadaveros>No</b:signCadaveros>

<b:signLivores>Yes</b:signLivores>

<b:signMaceratio>No</b:signMaceratio>

<b:signOther>No</b:signOther>

<b:signRigor>No</b:signRigor>

<b:streetName>Testgrusgraven</b:streetName>

<b:streetNum>3</b:streetNum>

<b:submitterCity></b:submitterCity>

<b:submitterName></b:submitterName>

<b:submitterOfPage2>I</b:submitterOfPage2>

<b:submitterStreetName></b:submitterStreetName>

<b:submitterStreetNum></b:submitterStreetNum>

<b:submitterZipCode></b:submitterZipCode>

<b:submittingDoctorFunction>OnCall</b:submittingDoctorFunction>

<b:surName>Test Mosebryggersen</b:surName>

<b:unidentified>No</b:unidentified>

<b:zipCode>3400</b:zipCode>

</contract>

</Report>

</s:Body>

2.2.4 SchemaReport - SOAP Envelope Response (Webservice Retursvar)

Retursvaret konstrueres på samme måde med en header og en body.

(14)

14 / 30 Se Header og Body nedenfor.

2.2.4.1 Response Header

Nedenfor er anvist retursvarets header-format. Dette er ens for alle SchemaReport-retursvar:

(15)

15 / 30

(16)

16 / 30

2.2.4.2 Response Body

Se retursvarets body-format nedenfor (dette er et eksempel på en succesfuld indberetning). Den gule markering viser det ”variable” i retursvaret (dog kun indholdet i tags):

<s:Body u:Id="_1">

<b:errorCode>0</b:errorCode>

<b:errorMessage></b:errorMessage>

<b:schemaGuid>f2750f92-81dc-41a2-a382-8bae529ed860</b:schemaGuid>

<b:success>true</b:success>

</ReportResult>

</ReportResponse>

</s:Body>

2.2.5 SchemaCancel - SOAP Envelope Request (Webservice Request)

Webservicerequest for SchemaCancel-metoden konstrueres med en SOAP header og en body.

2.2.5.1 Request Header

Nedenfor vises en SchemaCancel request header (denne er ens for alle Cancel-metoder). Du signerer med eget certifikat. Bemærk at <Removed> er indsat til at erstatte krypteret tekst som ikke giver værdi i denne dokumentation (ud over at gøre eksemplet længere).

(17)

17 / 30

(18)

18 / 30

2.2.5.2 Request Body

Nedenfor vises et eksempel på en SchemaCancel request body (for et abort-skema). Hver skematype har sin egen schemaType (som kan ses af WSDL dokumentation):

(19)

19 / 30

2.2.6 SchemaCancel - SOAP Envelope Response (Webservice Retursvar)

Retursvaret konstrueres på samme måde med en header og en body.

<s:Header>

<s:Body u:Id="_1">

</s:Envelope>

2.2.6.1 Response Header

Nedenfor vises et eksempel på en SchemaCancel response header (den er ens for alle skemaer):

(20)

20 / 30

2.2.6.2 Response Body

Nedenfor vises et eksempel på en SchemaCancel response body (den er ens for alle skemaer, dog varie- rer indhold af de gule tags):

<s:Body u:Id="_1">

<ResponseContract xmlns="http://schemas.datacontract.org/2004/07/Dynamics.AX.Application"

xmlns:i="http://www.w3.org/2001/XMLSchema-instance">

</ResponseContract>

</s:Body>

2.2.7 SchemaPrefillMRSA - SOAP Envelope Request (Webservice Re-

quest)

(21)

21 / 30 Der indsendes en SOAP envelope bestående af en header og en body. Disse er beskrevet i afsnit nedenfor.

<s:Header>

<s:Body u:Id="_1">

</s:Envelope>

Bemærk at denne metode kun udstilles for MRSA skemaet i SEI2.

2.2.7.1 Request Header

Nedenfor vises en SchemaPrefillMRSA request header. Du signerer med eget certifikat. Bemærk at <Re- moved> er indsat til at erstatte krypteret tekst som ikke giver værdi i denne dokumentation (ud over at gøre eksemplet længere).

(22)

22 / 30

(23)

23 / 30

2.2.7.2 Request Body

(24)

24 / 30 Nedenfor vises et eksempel på en SchemaPrefillMRSA request body:

2.2.8 SchemaPrefillMRSA - SOAP Envelope Response (Webservice Re- tursvar)

Der returneres en SOAP envelope bestående af en header og en body. Disse er beskrevet i afsnit nedenfor.

<s:Header>

<s:Body u:Id="_1">

</s:Envelope>

2.2.8.1 Response Header

Se eksempel på SchemaPrefillMRSA response header nedenfor.

(25)

25 / 30

2.2.8.2 Response Body

Nedenfor vises et eksempel på en SchemaPrefillMRSA response body:

(26)

26 / 30

2.2.9 SchemaGetStatusMRSA - SOAP Envelope Request (Webservice Re- quest)

Der indsendes en SOAP envelope bestående af en header og en body. Disse er beskrevet i afsnit nedenfor.

<s:Header>

<s:Body u:Id="_1">

</s:Envelope>

Bemærk at denne metode kun udstilles for MRSA skemaet i SEI2.

2.2.9.1 Request Header

Nedenfor vises eksempel på SchemaGetStatusMRSA header.

(27)

27 / 30

(28)

28 / 30

2.2.9.2 Request Body

Nedenfor vises et eksempel på en SchemaGetStatusMRSA request body. Man sender bare skemaid på skemaet, man ønsker status på.

<s:Body u:Id="_1">

</SchemaGetStatusMRSA>

</s:Body>

2.2.10 SchemaGetStatusMRSA - SOAP Envelope Response (Webservice Retursvar)

Der returneres en SOAP envelope bestående af en header og en body. Disse er beskrevet i afsnit nedenfor.

<s:Header>

<s:Body u:Id="_1">

</s:Envelope>

2.2.10.1 Response Header

Se eksempel på SchemagetStatusMRSA response header nedenfor.

(29)

29 / 30

(30)

30 / 30

2.2.10.2 Response Body

Nedenfor vises et eksempel på en SchemaGetStatusMRSA response body: