PRODUCTION: Der er sket ukendt en fejl. Kontakt venligst REGIS administration.

[Remcovanderwerf]

Hi,

in production (sending to PatientHealthcareReportingService) we got the following situation:

On: Mar 06, 2019 12:09:04 PM we send the following CDA: errorCDA.txt and got the response:

Mar 06, 2019 12:09:08 PM
Response-Code: 500
Encoding: UTF-8
Content-Type: text/xml; charset=UTF-8

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <soapenv:Header/>
    <soapenv:Body>
        <soapenv:Fault>
            <faultcode>soapenv:66</faultcode>
            <faultstring>Der er sket ukendt en fejl. Kontakt venligst REGIS administration.</faultstring>
        </soapenv:Fault>
    </soapenv:Body>
</soapenv:Envelope>

2 minutes later we resend the same message and got the following response back from LPR3: "INTEGRITY_CHECK|||Set with id 9fe67bda-917a-5785-b4a2-7285290537b1 already exists in the registry, and ClinicalDocument does not contain a relatedDocument|||SET_ALREADY_EXISTS_AND_NO_RELATED_DOCUMENT|||9fe67bda-917a-5785-b4a2-7285290537b1"

It looks like the first submission was correctly handled but did give back an soapFault.

This is very inconsistent in our response handling in our sending application.

Please investigate.

Kind regards,

Remco van der Werf Enovation, the Netherlands Contractor: Region Syddanmark

[TueCN]

Hi <faultstring>Der er sket ukendt en fejl. Kontakt venligst REGIS administration.</faultstring> is not a fault string that LPR produces.

I suspect LPR handled your request correctly and then some fault happened in a middleware layer somewhere. I have no idea who or what REGIS administration is :)

[Remcovanderwerf]

Hi @TueCN ,

thank you for the quick response. I will ask the region for this matter.

[ThorkildFriis]

@TueCN : It is correct that the error message is not generated by DXC. It is generated in our proxy because we never receive an ack. So the interesting thing is to find out if the ack is missing because the server did not send it or because somebody pulled out a cable from a switch or rebooted a firewall.

[TueCN]

From @Remcovanderwerf first post it looks like the SOAP fault happened 4 seconds after the connection was opened so it does not seem like this could be a timeout issue.

My best guess is a network error as @ThorkildFriis suggests. Is this a one time incident or has it happened on multiple occasions?

[Remcovanderwerf]

It happens occasionally and results in resending a document from our application. The response from LPR3 after the second attempt gives us the Set with id 9fe67bda-917a-5785-b4a2-7285290537b1 already exists in the registry.

[TueCN]

Ok. I do not have enough information to assist with the continued investigation into this issue. There are no errors in our logs around Mar 06, 2019 12:09:04 PM (CET) and we do not log TCP level messages AFAIK (we only have HTTP level request/response logs, and only in test). I suspect the issue lies in the middleware that generates the SOAP fault.

@ThorkildFriis can you investigate the exact conditions that causes the SOAP fault to be generated and check if there is a bug or network issue on your side? We have not had reports from any other reporting authorities regarding issues related to lacking acknowledgement messages.

[ThorkildFriis]

@TueCN currently we do not have logging at TCP/IP level either. All we can see for now is that we never receive the ack. Investigation further would require a new build of the proxy. And we will not implement any changes before issue #322 is solved. So I don't suppose that we will have any progress on this issue today.

[stale[bot]]

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.