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's 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.

DDS Registry performs the role of Document Registry \[ITI TF-1\] where document metadata registered about documents are stored in an XDS Registry associated with DDS Registry. 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 Consumer Actor \[ITI TF-1\] and can perform queries in the DDS Registry and find metadata registered for patients. This scenario is corresponds to ITI-18 \[ITI TF-2a\].
The DDS Registry is used in an XDS community, that is, by a set of actors agreeing to certain common rules. The document metadata handled by DDS Registry must adhere to a certain _metadata definition{_}, that is, be based on defined value sets, formats, encoding systems and so forth. The DDS Registry may be used with one of many metadata definitions, but currently, it is used in an XDS community that adheres to metadata definitions defined in \[Metadata Profile\].
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. 

A user system may have retrieved one or more documents, for instance through the web service described in \[DDS Repository\]. In a retrieved document — depending on its type — there can be references to other documents. In cases where the reference contains the referenced document's document id and when the referenced document is (or may be) registered in the registry, the user system can query for document metadata given the document id.
A user system performs querying for metadata in DDS Registry for a given document id by using the GetDocuments variant of the Web service {_}DDSRegistry{_} and the operation {_}DocumentRegistry_RegistryStoredQuery_ of the web service {_}DDSRegistry{_}.
If the user is a health professional, consent checking influences what is returned as follows: when identified as a health professional for which patient consent blocks access, document metadata 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. This marking can be interpreted as an indication that further document metadata than returned exists.
In addition, verification of the current treatment relationship between the health professional and citizen is initiated.
If the user is the citizen him or herself, all metadata is returned. A citizen user is also able to query another citizen's metadata if the user has a relation to the citizen in question.
It is the responsibility of the user system to provide the id of the patient for which the document id pertains.

The format of Security and Medcom-header are described in \[DGWS 1.0\] and \[DGWS 1.0.1\], while the format of the HSUID-header is described in \[HSUID-header\].
SOAP body contains IHE XDS Registry Stored Query AdhocQueryRequest and AdhocQueryResponse in request and response respectively.  IHE XDS Registry Stored Query is described in \[ITI TF-2a\] section 3.18.

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

See \[ITI TF-3\] section 4.2.4 for a description of how errors are embedded in a query response.
The following subsections describe the error codes and warnings embedded in the reply that are not defined in the IHE.

See description of content in AdhocQuery \[ITI TF-2a\].
The table below contains selected parts of AdhocQuery shown with emphasis on conceptual content. See \[ITI TF-2a\] section 3.18 for additional content, format etc.

See description of content in AdhocQuery \[ITI TF-2a\].
The table below contains selected parts of AdhocQuery shown with emphasis on conceptual content. See \[ITI TF-2a\] section 3.18 for additional content, format etc.
Either $XDSDocumentEntryEntryUUID or $XDSDocumentEntryUniqueId shall be specified. This transaction shall return an error if both parameters are specified.

See also \[Metadata\].

See description of content in AdhocQueryResponse \[ITI TF-2a\].
AdhocQueryResponse is a collection of metadata that for each contains conceptual content as described below.

See also \[Metadata Profile\].