SEI2 snitfladebeskrivelse (IDWS) SEI2 (Sundhedsdatastyrelsens Elektroniske Indberetning 2) 1 / 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 2 / 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 eksisterende værktøjer/frameworks som er tilgængelige i D365. I dette dokument kan der derfor være henvisninger 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 SDS ADFS SEB SEI1 SEI2 IVF NAB Dødsattest Tvang Injiccerbar heroin/metadon XML CSV CPR SOR SKS FGR SHAK Beskrivelse Sundhedsdatastyrelsen, som har bestilt og skal anvende løsningen Active Directory Federated Services. Sundhedsstyrelsen Elektroniske Brugerstyring. Det er en løsning til centralstyring af rettigheder for mange applikationer/systemer hos SDS. Sundhedsdatastyrelsens Elektroniske Indberetningssystem version 1. Dette er det allerede eksisterende system, som skal fornys til SEI2. Sundhedsdatastyrelsens Elektroniske Indberetningssystem version 2. Dette er det nye system, som dette dokument beskriver. Dette er en af de skemaer som kan indberettes via SEI2. IVF er fertilitetsbehandling. Dette er en af de skemaer som kan indberettes via SEI2. NAB står for National Alkohol Behandling Dette er en af de skemaer som kan indberettes via SEI2. Dødsattester registreres ifm dødsfald i Danmark. Dette er en af de skemaer som kan indberettes via SEI2. Tvang registreres ifm tvangsbehandlinger i psykiatrien. Dette er en af de skemaer som kan indberettes via SEI2. Injicerbar heroin registreres ifm XML (extensible Markup Language) er et filformat til udveksling af data mellem systemer CSV (comma separated values) er et filformat til udveksling af data mellem systemer. 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 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 er en forkortelse for Sundhedsvæsenets Klassifikationssystem FGR er en forkortelse for Fællesgrunddataregister. FGR indeholder forskellige registre indeholdende koder/stamdata bl.a. til brug for SEI1 og i fremtiden SEI2. 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 3 / 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. 4 / 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 private. 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 snitflade. 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: 5 / 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 gammel 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. Testmiljø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 anvender 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. 6 / 30
- 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 Testmiljøet kan anvendes testcertifikater. På anmodning kan der udleveres en test-klient til at understøtte udviklingsprocessen på Microsoft platformen. Bemærk denne er IKKE supporteret, men er udviklet til SCALES egen test og vil ikke blive vedligeholdt 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. 7 / 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). 8 / 30
9 / 30
10 / 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. 11 / 30
<s:body u:id="_1"> <Report xmlns="https://seiidws.test.sundhedsdata.dk/ "> <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> 12 / 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. 13 / 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: 14 / 30
15 / 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"> <ReportResponse xmlns="http://sundhedsdatastyrelsen.dk/sei2"> <ReportResult xmlns:i="http://www.w3.org/2001/xmlschema-instance" xmlns:b="http://schemas.datacontract.org/2004/07/dynamics.ax.application"> <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. Se Header og Body nedenfor. 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). 16 / 30
17 / 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): 18 / 30
2.2.6 SchemaCancel - SOAP Envelope Response (Webservice Retursvar) Retursvaret konstrueres på samme måde med en header og en body. <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.6.1 Response Header Nedenfor vises et eksempel på en SchemaCancel response header (den er ens for alle skemaer): 19 / 30
2.2.6.2 Response Body Nedenfor vises et eksempel på en SchemaCancel response body (den er ens for alle skemaer, dog varierer 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"> <errorcode>0</errorcode> <errormessage /> <schemaguid>1069f250-09c0-4a42-9042-ea456a08b72b</schemaguid> <success>true</success> </ResponseContract> </s:body> 2.2.7 SchemaPrefillMRSA - SOAP Envelope Request (Webservice Request) 20 / 30
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. 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 <Removed> er indsat til at erstatte krypteret tekst som ikke giver værdi i denne dokumentation (ud over at gøre eksemplet længere). 21 / 30
22 / 30
2.2.7.2 Request Body 23 / 30
Nedenfor vises et eksempel på en SchemaPrefillMRSA request body: 2.2.8 SchemaPrefillMRSA - 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: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.8.1 Response Header Se eksempel på SchemaPrefillMRSA response header nedenfor. 24 / 30
2.2.8.2 Response Body Nedenfor vises et eksempel på en SchemaPrefillMRSA response body: 25 / 30
2.2.9 SchemaGetStatusMRSA - 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. Bemærk at denne metode kun udstilles for MRSA skemaet i SEI2. 2.2.9.1 Request Header Nedenfor vises eksempel på SchemaGetStatusMRSA header. 26 / 30
27 / 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"> </s:body> <SchemaGetStatusMRSA xmlns="http://sundhedsdatastyrelsen.dk/sei2"> <schemaid>f26e9b60-6770-44c3-947c-db368a363b9b</schemaid> </SchemaGetStatusMRSA> 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: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.10.1 Response Header Se eksempel på SchemagetStatusMRSA response header nedenfor. 28 / 30
29 / 30
2.2.10.2 Response Body Nedenfor vises et eksempel på en SchemaGetStatusMRSA response body: 30 / 30