Skip to content
This repository has been archived by the owner on Dec 19, 2023. It is now read-only.

Error deleting an episode of care #150

Open
CgiMofr opened this issue Jul 19, 2018 · 3 comments
Open

Error deleting an episode of care #150

CgiMofr opened this issue Jul 19, 2018 · 3 comments

Comments

@CgiMofr
Copy link

CgiMofr commented Jul 19, 2018

Hi,

document.txt
soap-response.txt

We try to delete an episodeofcare but get a soap response with responsestatustype=failure.
But no indication of the type of error.
Attached is the document we send, and the soap response.

is it possible in any way to see what the error is ?

@TueCN TueCN self-assigned this Jul 23, 2018
@TueCN
Copy link
Contributor

TueCN commented Jul 23, 2018

Hi,

I assume you are calling the validate endpoint?

In that case, this is not an error since the service always returns a RegistryResponse element with attribute status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure", even when there are no validation errors.

This is because of the way IHE ITI TF-3 section 4.2.4.2: Error responses is specified:

The following tables explain the meaning of the status attribute in RegistryResponse

Table 4.2.4.2-1: [ITI-41]:

RegistryResponse status RegistryErrorList element Result
urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success May be present. If present will contain one or more RegistryError elements with warning severity, none with error severity All metadata defined in this volume, and documents were successfully registered. Extra metadata may or may not be saved, based on the presence of the XDSExtraMetadataNotSaved warning
urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure Present, contains one or more RegistryError elements. At least one has error severity others may have warning severity Metadata and documents not stored

Since the validate endpoint does not register the documents, it cannot return Success according to the definition of success in the table 4.2.4.2-1: [ITI-41].

Therefore, if you wish to save the registration of a deletion of an episode of care, you should use one of the other endpoints.


There is another issue with the validate endpoint it seems: The validate endpoint does not fully comply to the Failure definition, as there are no RegistryErrorList with at least one RegistryError element, as is required.

Here is the response from the validate endpoint:

    <soap:Body>
        <ns2:RegistryResponse xmlns:ns10="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:ns12="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns:ns13="urn:lpr" xmlns:ns2="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
                              xmlns:ns3="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0" xmlns:ns4="urn:ihe:iti:xds-b:2007" xmlns:ns5="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
                              xmlns:ns6="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns7="urn:oasis:names:tc:SAML:2.0:assertion"
                              xmlns:ns8="http://www.w3.org/2000/09/xmldsig#" xmlns:ns9="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
                              status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure"></ns2:RegistryResponse>
    </soap:Body>

The response should have included at least one RegistryError element that explains that the document has not been saved because you called the validate endpoint.

However, I would think adding this "false-positive" error will complicate client implementations since you have to detect and specifically ignore this non-error.

Suggestion:
Maybe we should instead deviate a bit from the spec and change the validate endpoint to return Success status when there are no validation errors (even though the documents are not saved). This would make the response more intuitive and ease implementation for everybody (both sender and receiver).

This is something that has to be decided in a broader forum. I will escalate the issue and get back to you when we have a resolution.

@stale
Copy link

stale bot commented Jan 24, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Jan 24, 2019
@TueCN TueCN removed the stale label Jan 25, 2019
@KirstenLHSDS
Copy link

This has been transfered to the LPR backlog.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants