scandihealth / lpr3-docs

https://scandihealth.github.io/lpr3-docs/
MIT License
11 stars 7 forks source link

Error deleting an episode of care #150

Open CgiMofr opened 6 years ago

CgiMofr commented 6 years ago

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 commented 6 years ago

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[bot] commented 5 years ago

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.

KirstenLHSDS commented 5 years ago

This has been transfered to the LPR backlog.