1. Introduction

1.1. Purpose

The purpose of this document is to specify the web service interface provided by the national document sharing service (DDS) for data retrieval.

1.2. Reading Guide

In the document the concepts of authorization and authorized are used primarily in a security context, that is, in the understanding that a person or a system is authorized to use a given resource. If the concepts concern health professionals with Danish authorization listed in Danish Health Authority’s authorization register, it will be stated explicitly.
A system that uses the web service(s) described in this document is referred to as a user system. Note that there are particular responsibilities that the user system must fulfil, as described in section 1.5.
It is assumed that the reader understands the general use of SOAP-based Web services, why technical terms such as SOAP, WSDL etc. is not clarified. Knowing Den Gode Webservice (DGWS) 1.0.1 described in [DGWS 1.0] and [DGWS 1.0.1] will facilitate comprehension considerably.
It is also assumed that the reader understands the use of IHE XDS.

1.3. Document History

1.4. Definitions and References

The purpose of this section is to provide an overview of the definitions and document references used in this document.

1.5. Responsibilities of the User System

The web service that is the subject of this document performs checks on consent as required by Health Act §42a, paragraph 6 and 7, unless consent override is applied (§42a, paragraph 5).
In addition, concerning the user's access to data, there may be aspects of complying with Health Act §42a that the web service does not have the ability to control, including the necessity of access to the information and the hospital management's authorization of non-authorized healthcare professionals. Consequently, agreements must be made between the data controller for document sharing service and the user system to establish the user system's responsibility in regard to compliance of Health Act §42a and additional IT security laws and regulations.

2. Usage Scenarios for DDS Repository

DDS Registry performs the role of Document Registry [ITI TF-1] and keeps and maintains metadata for registered documents [ITI TF-1]. DDS Registry does not perform the role of a Document Repository [ITI TF-1]. This role is performed by the source systems that register documents in DDS Registry.
A user system appears in the role of Document Source Actor [ITI TF-1] and can perform queries in the DDS Registry and find document metadata registered for patients. This scenario corresponds to ITI-18 [ITI TF-2b]. Subsequently, the user system is able to extract, i.e. retrieve, documents by means of the found metadata. This corresponds to IHE’s ITI-43 [ITI TF-2b].
For the usage scenarios described in the following, it is the responsibility of the user system to verify the information given as input. This includes information on the user context, and, for instance, any relation between a citizen user and the patient.

2.1. User System Retrieves Document(s) About a Citizen

A user system performs retrieve of one or more documents by using the web service DDSRepository and operation DocumentRepository_RetrieveDocumentSet.
As input to this operation, the document id and other attributes found in document metadata returned upon querying the DDS Registry is used.
What is returned from the DDSRepository when retrieving documents depends on the user type.
If the user is the citizen him or herself, all documents are returned. A citizen user is also able to query another citizen's documents if the user has a relation to the citizen in question.
If the user is a health professional, consent checking influence what is returned as follows: when identified as a health professional for which patient consent blocks access, documents and document parts, respectively, covered by the consent, are filtered out of the reply and a mark is added indicating that filtering has occurred due to consent-related restrictions.
Note that general consents towards a health professional are always verified, while verification of data-specific consents would have to occur in the underlying document source. To which extent and how data-specific consents are verified depends on the specific document source and should be found in its documentation.
In addition, verification of the current treatment relationship between the health professional and citizen is initiated.

2.2. User System Forces Retrieve of Document(s) About a Citizen

Forced extraction of documents is extractions that are performed using the consent override rule in the Health Acts §42a paragraph 5.
A user system performs forced extraction of documents registered in DDS Registry concerning a citizen by using the Web service DDSRepository and the operation RegistryStoredQuery where, as described in section 4.1.2, the use of consent override is indicated.
It is the responsibility of the user system to verify that the user is a health professional authorized to perform consent overriding.

3. DDS Repository Web Services

3.1. Reading Guide

Every third DDS Repository Web service is described in a separate section. The following template is used to document the exposed operations

3.2. Web Service – DDSRepository

Web service that expose operations for retrieval of documents based on metadata information concerning citizen in DDS Registry.

3.2.1. Operation – DocumentRepository_RetrieveDocumentSet

4. DDS Repository Web Services Semantics

4.1. Message Format

The Web service expects SOAP messages, where the SOAP header contains security header and MEDCOM header as required by DGWS 1.0.1, in addition to a Healthcare Service User Identification (HSUID) header.

Figure 1 SOAP message containing security header, MEDCOM header and HSUID header is used as message format.

The format of Security- MEDCOM and header are described in [DGWS 1.0] and [DGWS 1.0.1], while the format of the header HSUID described in [HSUID-header].

SOAP body contains IHE Retrieve Document Set RetrieveDocumentSetRequestType and RetrieveDocumentSetResponseType in request and response respectively. IHE Retrieve Document Set is described in [ITI TF-2b] section 3.43.

Borgere kan forespørge på egne eller anden borgers dokumenter ved at medsende OIO IDWS token. I dette tilfælde ser en request således ud:

4.1.1. Attributes in HSUID header applied for user who is a citizen

When the user of the service is a citizen, attributes in Table 1 are applied in the HSUID-header.

Table 1 Attributes in HSUID-header applied for user who is a citizen.
Note that it is the user system's responsibility to ensure that the social security number given in nsi:CitizenCivilRegistrationNumber is identical to the one used when querying for document metadata.

4.1.2. Attributes in HSUID header applied for user who is a health professional

When the user of the service is a health professional, attributes in Table 2 are applied in the HSUID-header.

Table 2 Attributes in the HSUID-header applied for user who is health professional.

The identification of the organization of which the user is associated, may be given by a single value and a single format, such as SHAK-code:
<hsuid:Attribute Name="nsi:OrgUsingID" NameFormat="nsi:skskode">
<hsuid:AttributeValue>6620151</hsuid:AttributeValue>
</hsuid:Attribute>

The organization of which the user is associated, can alternatively be specified by two values, e.g. as both SOR- and SHAK-code:

<hsuid:Attribute Name="nsi:OrgUsingID" NameFormat="nsi:sor">
<hsuid:AttributeValue>440081000016006</hsuid:AttributeValue>
</hsuid:Attribute>
<hsuid:Attribute Name="nsi:OrgUsingID" NameFormat="nsi:skskode">
<hsuid:AttributeValue>6620151</hsuid:AttributeValue>
</hsuid:Attribute>

Note that it is the user systems responsibility to ensure:

1. consistency between the given id across classification systems (such as SOR, SHAK, and Healthcare Provider Number (Danish: ydernummer)).
2. that the patient id reflects the patient id used for querying for document metadata

4.2. Web Service Security

The security of this Web service is based on the SOSI integration pattern in Den Gode Webservice (DGWS). Authentication is carried out by a trusted third party component on NSP (Security Token Service) and based on OCES digital certificates.
As a rule, the service requires authentication with the STS component based on employee signature (MOCES) corresponding to authentication level 4 for use by health professional users.
Highly trusted systems - initially the Health journal only - can during a transitional period gain access with level 3 based on company signature (VOCES).
The service enforces authentication level 3 for use by either user types.
Additional security aspects, including authorization, integrity, confidentiality, availability and privacy considerations are enforced to some extent by the technical service. The aspects that are not currently handled by the technical service will be handled in the service agreement, as specified by the data responsible authority (NSI), which users of the service must agree to.

Som en alternativ snitflade udbydes en OIO IDWS baseret snitflade for borgerforespørgler. Det medsendte OIO IDWS token validers af servicen.

4.2.1. Authentication and authorization

4.2.1.1. Authentication and authorization of user system

When STS' signature of the ID card or OIO IDWS token is validated successfully, the user has been authenticated.
Authorization of user system is performed using a whitelist in the Web service based on information in the system-part of the ID card.

4.2.1.2. Authentication of user

When the user system is authenticated and authorized, the user is authenticated by the HSUID header attribute nsi:ActingUserCivilRegistrationNumber.

4.2.1.2.1. Authentication of health professional user

For user of type health professional, it is verified that the authentication level of the ID card is equal or above 3, corresponding to consumer's use of a company certificate (Danish: Virksomhedscertifikat, VOCES) or a functional certificate (Danish: Funktionscertifikat, FOCES). When an ID card of level 4 is used, corresponding to an employee certificate, it is verified that the acting user ID provided in the HSUID header is identical to the user identified in the ID card.

4.2.1.3. Authorization of citizen

Whether user is a health professional or citizen is determined from the HSUID-header-attribute nsi:UserType.

4.2.1.3.1. Web service-operation(s), where the user is health professional

The Web service authorizes all users who are health professionals to use its operations.

4.2.1.3.2. Web service-operation(s), where the user is citizen

A citizen is authorized when he/she performs queries for own documents. Therefore it is verified that the HSUID header describes the user as the same person as the one indicated as patient in the HSUID-header.
A citizen is, however, authorized to perform queries for another citizen's documents provided that the user citizen has a relation to the citizen being queried. As previously noted, it is the responsibility of the user system invoking the web service operation, to ascertain that such relation exists and that the user is indeed allowed to perform the operation.

4.2.2. Timeout on ID card

A request with ID card is rejected when it has been more than 24 hours since the start of the ID card validity period.

4.3. Status Code and Flow Status

As required by DGWS 1.0.1, only HTTP-status codes 200 and 500 are used.
On HTTP-status code 200, FlowStatus is always flow_finalized_succesfully.

4.4. Timeout on Web Service Operation

Timeout on Web service operations is the same as default timeout on the NSP platform.

4.5. Session

Each request is handled in its own session.
No check is performed whether MessageID in request has been received previously and no answer is guaranteed if a request with the same MessageID is received.
This deviates from DGWS 1.0.1 in regard to handling of retransmission.

4.5.1. Assignment and reuse respectively of flow ID

If the request contains a flow ID, it is reused in the reply and calls to other services. If no flow id is provided, a unique flow ID will be created.
Handling of flow ID complies with DGWS 1.0.1.

4.6. Processing of Request for Non-Repudiation

Digital signing of replies is not supported. On request for non-repudiation, a fault-error message is returned as described in [DGWS 1.0].

4.7. Error Handling

Errors are handled in two ways, depending on their relation to the IHE standard. For errors related to processing of document ID and other things in from extraction input, errors are embedded in the response as described in section 4.7.2. For errors in general, such as errors related to security, SOAP errors are returned as described in section 4.7.1.  Excluded from this distinction is, however, the warnings that are embedded in the response due to the withheld information caused by consents. These are described in section 4.7.2.

4.7.1. SOAP errors

SOAP errors are returned with the components as described hereinafter.  A structure has been chosen wherein both standard error codes as described in [DGWS 1.0] and Web service specific error codes can be returned.

<soap:Body>
	<soap:Fault>
	  <soap:Code>
		<soap:Value>soap:Sender</soap:Value>
	  </soap:Code>
	  <soap:Reason>
		<soap:Text xml:lang="en">SAML Assertion has expired</soap:Text>
	  </soap:Reason>
	  <soap:Detail>
		<FaultCode xmlns="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd">expired_idcard</FaultCode>
	  </soap:Detail>
	</soap:Fault> 
</soap:Body>

Code listing 1 Structure of SOAP faults returned from Web service operation. The example shows FaultCode used when the ID card has expired.

4.7.1.1. SOAP Fault Status Codes

For all Web service operations described in section 3 will be used SOAP Fault with FaultCode-values as listed in Table 3, originating from DGWS 1.0.1.

Table 3 Applied FaultCode-values originating from DGWS 1.0.1
Additionally, Web service specific FaultCode-values as listed in Table 4 are used.

Table 4 Applied Web service specific FaultCode-values
In WSDL, which describes the Web service(s) described in this document, these SOAP Fault status codes are not specified for every service (or operation).

4.7.2. Error codes and warnings embedded in the reply

See [ITI TF-2b] section 3.43.4.2 and 3.43.5 for description of embedding of errors in reply in addition to [ITI TF-3] section 4.1.13 for specific errors.

The following subsections describe the error codes and warnings embedded in the reply that are not defined in the IHE.

4.7.2.1. Error on detained document or document parts

For a user who is a health professional, there may be registered consents for a citizen which prevents the user from accessing complete documents or parts thereof concerning the citizen (without consent overriding).
If complete documents or parts thereof are detained in the reply to a DDS Repository extraction due to consent towards the user, it is indicated in the reply by the following RegistryError element in the reply's RegistryErrorList element:

<rs:RegistryError
codeContext="urn:dk:nsi:ConsentFilterApplied"
errorCode="XDSRegistryError"
severity="urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error"/> 

The namespace-prefix for "urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0", in this case rs, may have another value.

4.7.2.2. Errors on non-responding service endpoints

The Service endpoint, from which the document is extracted, is resolved based on HomeCommunityId or RepositoryUniqueId [ITI TF-2b]. If this endpoint does not return a useful reply or does not reply at all, it is indicated in the reply by the following RegistryError element in the reply’s RegistryErrorList element:

<rs:RegistryError
 codeContext="Responding gateway identified by Home Community Id: 
              1.2.3.4.5.6.8.10 and Repository Unique Id: 1.2.3.4.5.6.8.10             
              could not be contacted."
 errorCode="XDSUnavailableCommunity" 
 severity="urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error"
 location="DOCUMENT_UNIQUE_ID" />

The namespace-prefix for “urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0”, in this case rs, may have another value.

4.7.2.3. Errors on service endpoints not found

The Service endpoint from which the document is extracted is resolved based on HomeCommunityId or RepositoryUniqueId [ITI TF-2b]. If this endpoint is not registered, it is indicated in the reply by the following RegistryError element in the reply’s RegistryErrorList element:

<rs:RegistryError
 codeContext="Responding gateway identified by Repository Unique Id: 
              1.2.3.4.5.6.8.10 could not be found."
 errorCode="XDSUnavailableCommunity" 
 severity="urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error"
 location="DOCUMENT_UNIQUE_ID" />

The namespace-prefix for “urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0”, in this case rs, may have another value.

4.7.2.4. Error on extraction failure

For a user who is a health professional, there may be registered consents for a citizen which prevents the user from accessing complete documents or parts thereof concerning the citizen (without consent overriding).
If errors occur while detaining complete documents or parts thereof from a DDS Repository extraction due to consent towards the user, the document or document parts are withheld. This is indicated in the reply by the following RegistryError element in the reply's RegistryErrorList element:

<rs:RepositoryError
codeContext="urn:dk:nsi:Information Withheld due to Extraction Error"
errorCode="XDSRepositoryError"
severity="urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error"/> 

The namespace-prefix for "urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0", in this case rs, may have another value.

4.8. Web Service Input Validation

For DGWS It is validated that:

• Properly formatted HSUID header is included in the SOAP header, including the attributes that respectively may and must be present for a given user type as described in section 4.1.1 and 4.1.2. Furthermore, it is validated that attribute values ​​belong to established sample spaces and are not null or just whitespaces
• ID card in security header is valid and signed by STS and that the additional conditions described in section 4.2 are met
• Times of headers are given in Zulu time, as required by DGWS 1.0.1
• Given authorization numbers are valid and exist in an authorization register corresponding to the Board of Health authorization register

For OIO IDWS valideres det:

• Det medsendte OIO IDWS Token er validt og udstedt af STS.

There will be performed:

• No XML Schema validation
• No validation that given Social Security numbers are valid
• No validation that a given ID for health professional organization is valid in given classification system, nor that there is consistency between the ID when multiple ID and classification systems are provided
• No validation that a health care professional is affiliated with a given organization
• No validation that the user is acting under responsibility of given health professional

4.9. Standards

DDS Repository Web service interface is based on the following standards

1. SOAP version 1.1
2. Soap Fault version 1.1
3. WS-I Basic Profile 1.1
4. DGWS 1.0.1, with the exception of requirements regarding retransmission and control of reuse of message-ID as described in section 4.5, in addition to exception of structure used on errors as described in section 4.7.1.
5. IHE ITI-43, see [ITI TF-2b]
6. OIO IDWS

For the sake of compliance with IHE standard, the following is not met:

• OIO NDR [OIO-NDR]
• OIO WSDL [OIO-WSDL]

5. DDS Repository Web Services Schemas

This section aims to provide a general description of the most important elements in those XML-schemas that together with WSDL-files, define the Web service operations described in section 3.

5.1. RetrieveDocumentSetRequestType

See description of contents of RetrieveDocumentSetRequestType in [ITI TF-2b].

5.2. RetrieveDocumentSetResponseType

See description of contents of RetrieveDocumentSetResponseType in [ITI TF-2b].

6. Governance

6.1. Documentation

In the DDS Repository-solution, the interface between the actor-systems and the DDS Repository is versioned.
The interface specification constitutes the contract that defines how the systems involved must act.
The Interface specification consists of:

• the technical specification of schemas (documented by XSD files) and
• service descriptions (documented as WSDL files) and
• documentation of the semantic and functional importance of the exchanged data (documented in this document).

6.2. Time-based Versioning

Versioning of resources takes place where it is not already defined by DGWS, the IHE standard or another Web service standard, by stating the release date in the form year/month as part of the URL that identifies the resource:
http://host/YYYY/MM/resource

7. WSDL, Schemas, and Examples

WSDL file and XSD files are available in source code structure subfolder ddsservices\client-types\src\main\resources. These can also be downloaded from the following URL:
https://wsdl.nspop.dk/

7.1. DocumentRepositoryRetrieveDocumentSet

7.1.1. Request

---[HTTP request - http://localhost:9090/ddsrepository]---
Accept: text/xml, multipart/related, text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Content-type: multipart/related;start="<rootpart*5c8caa90-b074-4ed1-b609-2d4c13b37815@example.jaxws.sun.com>";type="application/xop+xml";boundary="uuid:5c8caa90-b074-4ed1-b609-2d4c13b37815";start-info="text/xml"
Soapaction: "urn:ihe:iti:2007:RetrieveDocumentSet"
--uuid:5c8caa90-b074-4ed1-b609-2d4c13b37815
Content-Id: <rootpart*5c8caa90-b074-4ed1-b609-2d4c13b37815@example.jaxws.sun.com>
Content-Type: application/xop+xml;charset=utf-8;type="text/xml"
Content-Transfer-Encoding: binary

<?xml version="1.0" ?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
 <S:Header>
  <ns10:Security xmlns:ns13="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns12="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:ns11="http://www.nsi.dk/hsuid/2016/08/hsuid-1.1.xsd" xmlns:ns10="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns9="http://www.w3.org/2000/09/xmldsig#" xmlns:ns8="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns7="urn:oasis:names:tc:ebxml-regrep:xsd:cms:3.0" xmlns:ns6="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:ns5="urn:ihe:iti:xds-b:2007" xmlns:ns4="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0" xmlns:ns3="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0">
   <ns13:Timestamp>
    <ns13:Created>2016-12-17T14:43:10Z</ns13:Created>
   </ns13:Timestamp>
   <ns8:Assertion IssueInstant="2016-12-17T14:38:10Z" Version="2.0" id="IDCard">
    <ns8:Issuer>TEST1-NSP-STS</ns8:Issuer>
    <ns8:Subject>
     <ns8:NameID Format="medcom:other">SubjectDN={SERIALNUMBER=CVR:30808460-UID:25351738 + CN=NETS DANID A/S - TU VOCES gyldig, O=NETS DANID A/S // CVR:30808460, C=DK},IssuerDN={CN=TRUST2408 Systemtest VIII CA, O=TRUST2408, C=DK},CertSerial={1276276200}</ns8:NameID>
     <ns8:SubjectConfirmation>
      <ns8:ConfirmationMethod>urn:oasis:names:tc:SAML:2.0:cm:holder-of-key</ns8:ConfirmationMethod>
      <ns8:SubjectConfirmationData>
       <ns9:KeyInfo>
        <ns9:KeyName>OCESSignature</ns9:KeyName>
       </ns9:KeyInfo>
      </ns8:SubjectConfirmationData>
     </ns8:SubjectConfirmation>
    </ns8:Subject>
    <ns8:Conditions NotBefore="2016-12-17T14:38:10Z" NotOnOrAfter="2016-12-18T14:38:10Z"/>
    <ns8:AttributeStatement id="IDCardData">
     <ns8:Attribute Name="sosi:IDCardID">
      <ns8:AttributeValue>U8Isxqp4txtGmVsfSzfgxw==</ns8:AttributeValue>
     </ns8:Attribute>
     <ns8:Attribute Name="sosi:IDCardVersion">
      <ns8:AttributeValue>1.0.1</ns8:AttributeValue>
     </ns8:Attribute>
     <ns8:Attribute Name="sosi:IDCardType">
      <ns8:AttributeValue>system</ns8:AttributeValue>
     </ns8:Attribute>
     <ns8:Attribute Name="sosi:AuthenticationLevel">
      <ns8:AttributeValue>3</ns8:AttributeValue>
     </ns8:Attribute>
     <ns8:Attribute Name="sosi:OCESCertHash">
      <ns8:AttributeValue>RngjckX+3IBZ0RNnWVXfuHDTa/Q=</ns8:AttributeValue>
     </ns8:Attribute>
    </ns8:AttributeStatement>
    <ns8:AttributeStatement id="SystemLog">
     <ns8:Attribute Name="medcom:ITSystemName">
      <ns8:AttributeValue>DDS - VOCES</ns8:AttributeValue>
     </ns8:Attribute>
     <ns8:Attribute Name="medcom:CareProviderID" NameFormat="medcom:cvrnumber">
      <ns8:AttributeValue>30808460</ns8:AttributeValue>
     </ns8:Attribute>
     <ns8:Attribute Name="medcom:CareProviderName">
      <ns8:AttributeValue>NETS DANID A/S - TU VOCES gyldig</ns8:AttributeValue>
     </ns8:Attribute>
    </ns8:AttributeStatement>
    <ns9:Signature id="OCESSignature">
     <ns9:SignedInfo>
      <ns9:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
      <ns9:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
      <ns9:Reference URI="#IDCard">
       <ns9:Transforms>
        <ns9:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
        <ns9:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
       </ns9:Transforms>
       <ns9:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
       <ns9:DigestValue>
        <Include xmlns="http://www.w3.org/2004/08/xop/include" href="cid:253e1019-bd61-4c44-8d07-8dd62f246a15@example.jaxws.sun.com"/>
       </ns9:DigestValue>
      </ns9:Reference>
     </ns9:SignedInfo>
     <ns9:SignatureValue>
      <Include xmlns="http://www.w3.org/2004/08/xop/include" href="cid:b34faefa-3d17-4dd9-a2c8-54644ad4b58e@example.jaxws.sun.com"/>
     </ns9:SignatureValue>
     <ns9:KeyInfo>
      <ns9:X509Data>
       <ns9:X509Certificate>
        <Include xmlns="http://www.w3.org/2004/08/xop/include" href="cid:223986ce-7f5a-4bc5-9bbc-8fe0f7e8cb0b@example.jaxws.sun.com"/>
       </ns9:X509Certificate>
      </ns9:X509Data>
     </ns9:KeyInfo>
    </ns9:Signature>
   </ns8:Assertion>
  </ns10:Security>
  <ns12:Header xmlns:ns13="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns12="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:ns11="http://www.nsi.dk/hsuid/2016/08/hsuid-1.1.xsd" xmlns:ns10="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns9="http://www.w3.org/2000/09/xmldsig#" xmlns:ns8="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns7="urn:oasis:names:tc:ebxml-regrep:xsd:cms:3.0" xmlns:ns6="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:ns5="urn:ihe:iti:xds-b:2007" xmlns:ns4="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0" xmlns:ns3="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0">
   <ns12:SecurityLevel>3</ns12:SecurityLevel>
   <ns12:Linking>
    <ns12:FlowID>urn:uuid:95427a32-cea8-4dd3-bfa8-7d6a7fc3e05c</ns12:FlowID>
    <ns12:MessageID>AAABWQ08kTMpuqZH/DCvw1NPU0k=</ns12:MessageID>
   </ns12:Linking>
   <ns12:RequireNonRepudiationReceipt>no</ns12:RequireNonRepudiationReceipt>
  </ns12:Header>
  <ns11:HsuidHeader xmlns:ns13="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns12="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:ns11="http://www.nsi.dk/hsuid/2016/08/hsuid-1.1.xsd" xmlns:ns10="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns9="http://www.w3.org/2000/09/xmldsig#" xmlns:ns8="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns7="urn:oasis:names:tc:ebxml-regrep:xsd:cms:3.0" xmlns:ns6="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:ns5="urn:ihe:iti:xds-b:2007" xmlns:ns4="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0" xmlns:ns3="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0">
   <ns11:Assertion IssueInstant="2016-12-17T14:43:10.191Z" Version="2.0" id="HSUID">
    <ns11:Issuer>DDSRegistry Test</ns11:Issuer>
    <ns11:AttributeStatement id="HSUIDdata">
     <ns11:Attribute Name="nsi:UserType">
      <ns11:AttributeValue>nsi:Citizen</ns11:AttributeValue>
     </ns11:Attribute>
     <ns11:Attribute Name="nsi:ActingUserCivilRegistrationNumber">
      <ns11:AttributeValue>100000001</ns11:AttributeValue>
     </ns11:Attribute>
     <ns11:Attribute Name="nsi:SystemOwnerName">
      <ns11:AttributeValue>System owner</ns11:AttributeValue>
     </ns11:Attribute>
     <ns11:Attribute Name="nsi:SystemName">
      <ns11:AttributeValue>System name</ns11:AttributeValue>
     </ns11:Attribute>
     <ns11:Attribute Name="nsi:SystemVersion">
      <ns11:AttributeValue>1.0</ns11:AttributeValue>
     </ns11:Attribute>
     <ns11:Attribute Name="nsi:OrgResponsibleName">
      <ns11:AttributeValue>Org responsible for consuming service</ns11:AttributeValue>
     </ns11:Attribute>
     <ns11:Attribute Name="nsi:CitizenCivilRegistrationNumber">
      <ns11:AttributeValue>100000001</ns11:AttributeValue>
     </ns11:Attribute>
    </ns11:AttributeStatement>
   </ns11:Assertion>
  </ns11:HsuidHeader>
 </S:Header>
 <S:Body>
  <ns5:RetrieveDocumentSetRequest xmlns:ns13="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns12="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:ns11="http://www.nsi.dk/hsuid/2016/08/hsuid-1.1.xsd" xmlns:ns10="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns9="http://www.w3.org/2000/09/xmldsig#" xmlns:ns8="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns7="urn:oasis:names:tc:ebxml-regrep:xsd:cms:3.0" xmlns:ns6="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:ns5="urn:ihe:iti:xds-b:2007" xmlns:ns4="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0" xmlns:ns3="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0">
   <ns5:DocumentRequest>
    <ns5:RepositoryUniqueId>1.2.3.4.5.6.7.8.11</ns5:RepositoryUniqueId>
    <ns5:DocumentUniqueId>pdf</ns5:DocumentUniqueId>
   </ns5:DocumentRequest>
   <ns5:DocumentRequest>
    <ns5:RepositoryUniqueId>1.2.3.4.5.6.7.8.11</ns5:RepositoryUniqueId>
    <ns5:DocumentUniqueId>image</ns5:DocumentUniqueId>
   </ns5:DocumentRequest>
   <ns5:DocumentRequest>
    <ns5:RepositoryUniqueId>1.2.3.4.5.6.7.8.11</ns5:RepositoryUniqueId>
    <ns5:DocumentUniqueId>Doc6.1</ns5:DocumentUniqueId>
   </ns5:DocumentRequest>
  </ns5:RetrieveDocumentSetRequest>
 </S:Body>
</S:Envelope>
--uuid:5c8caa90-b074-4ed1-b609-2d4c13b37815
Content-Id: <253e1019-bd61-4c44-8d07-8dd62f246a15@example.jaxws.sun.com>
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary

I̮V࠴󫀊-Zۆy60
--uuid:5c8caa90-b074-4ed1-b609-2d4c13b37815
Content-Id: <b34faefa-3d17-4dd9-a2c8-54644ad4b58e@example.jaxws.sun.com>
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary

[Contents removed here]

--uuid:5c8caa90-b074-4ed1-b609-2d4c13b37815----------------------

7.1.2. Response

Some contents of response have been replaced with [Contents removed here] to improve readability.

---[HTTP response - http://localhost:9090/ddsrepository - 200]---
null: HTTP/1.1 200 OK
Server: WildFly/8
Connection: keep-alive
X-powered-by: Undertow/1
Date: Sat, 17 Dec 2016 14:43:10 GMT
Transfer-encoding: chunked
Content-type: multipart/related; type="application/xop+xml"; boundary="uuid:ed6c9e16-af67-4c91-aef3-7dc6a7bf00e9"; start="<root.message@cxf.apache.org>"; start-info="text/xml"
--uuid:ed6c9e16-af67-4c91-aef3-7dc6a7bf00e9
Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
Content-Transfer-Encoding: binary
Content-ID: <root.message@cxf.apache.org>

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Header>
        <ns7:Header xmlns:ns14="urn:dk.nsi.service" xmlns:ns13="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0" xmlns:ns12="urn:oasis:names:tc:ebxml-regrep:xsd:cms:3.0" xmlns:ns11="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:ns10="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns:ns9="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns:ns8="http://www.nsi.dk/hsuid/2016/08/hsuid-1.1.xsd" xmlns:ns7="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:ns6="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns5="http://www.w3.org/2000/09/xmldsig#" xmlns:ns4="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns3="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns2="urn:ihe:iti:xds-b:2007" ns14:maxAge="24">
            <ns7:Linking>
                <ns7:FlowID>urn:uuid:95427a32-cea8-4dd3-bfa8-7d6a7fc3e05c</ns7:FlowID>
                <ns7:MessageID>9c6353fa-0a89-4f54-ba66-47bba7d58e1d</ns7:MessageID>
                <ns7:InResponseToMessageID>AAABWQ08kTMpuqZH/DCvw1NPU0k=</ns7:InResponseToMessageID>
            </ns7:Linking>
            <ns7:FlowStatus>flow_finalized_succesfully</ns7:FlowStatus>
        </ns7:Header>
    </soap:Header>
    <soap:Body>
        <RetrieveDocumentSetResponse xmlns="urn:ihe:iti:xds-b:2007" xmlns:ns2="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns3="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns4="http://www.w3.org/2000/09/xmldsig#" xmlns:ns5="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns6="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:ns7="http://www.nsi.dk/hsuid/2016/08/hsuid-1.1.xsd" xmlns:ns8="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns:ns9="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns:ns10="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:ns11="urn:oasis:names:tc:ebxml-regrep:xsd:cms:3.0" xmlns:ns12="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0">
            <ns9:RegistryResponse status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"/>
            <DocumentResponse>
                <RepositoryUniqueId>1.2.3.4.5.6.7.8.11</RepositoryUniqueId>
                <DocumentUniqueId>pdf</DocumentUniqueId>
                <mimeType>application/pdf</mimeType>
                <Document>
                    <xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:b32c28c3-6cc7-4c53-bc94-c6bb10508c59-35037@urn%3Aihe%3Aiti%3Axds-b%3A2007"/>
                </Document>
            </DocumentResponse>
            <DocumentResponse>
                <RepositoryUniqueId>1.2.3.4.5.6.7.8.11</RepositoryUniqueId>
                <DocumentUniqueId>image</DocumentUniqueId>
                <mimeType>image/jpeg</mimeType>
                <Document>
                    <xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:b32c28c3-6cc7-4c53-bc94-c6bb10508c59-35038@urn%3Aihe%3Aiti%3Axds-b%3A2007"/>
                </Document>
            </DocumentResponse>
            <DocumentResponse>
                <RepositoryUniqueId>1.2.3.4.5.6.7.8.11</RepositoryUniqueId>
                <DocumentUniqueId>Doc6.1</DocumentUniqueId>
                <mimeType>text/xml</mimeType>
                <Document>
                    <xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:b32c28c3-6cc7-4c53-bc94-c6bb10508c59-35039@urn%3Aihe%3Aiti%3Axds-b%3A2007"/>
                </Document>
            </DocumentResponse>
        </RetrieveDocumentSetResponse>
    </soap:Body>
</soap:Envelope>
--uuid:ed6c9e16-af67-4c91-aef3-7dc6a7bf00e9
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
Content-ID: <b32c28c3-6cc7-4c53-bc94-c6bb10508c59-35037@urn:ihe:iti:xds-b:2007>

[Contents removed here]

--uuid:ed6c9e16-af67-4c91-aef3-7dc6a7bf00e9----------------------