Validation error of AssignedCustodian

[ScaAnders]

I am trying to submit a ClinicalDocument with the following 'assignedCustodian' element:

I get the following errors from LPR3:

ErrorCode: InvalidDocumentContent Location: a737f970-f084-5a72-84b5-5039a6a4767d^3bea95a1-e269-4de0-84f7-7e0c6c1d9243|||/:ClinicalDocument[namespace-uri()='urn:hl7-org:v3'][1]/:custodian[namespace-uri()='urn:hl7-org:v3'][1]/:assignedCustodian[namespace-uri()='urn:hl7-org:v3'][1]/:representedCustodianOrganization[namespace-uri()='urn:hl7-org:v3'][1]/*:id[namespace-uri()='urn:hl7-org:v3'][1] CodeContext: SCHEMATRON|||(DKCustodian): The value of the @extension SHALL be a valid Danish Business Identification number (cvr-nummer)

ErrorCode: InvalidDocumentContent Location: a737f970-f084-5a72-84b5-5039a6a4767d^3bea95a1-e269-4de0-84f7-7e0c6c1d9243|||/:ClinicalDocument[namespace-uri()='urn:hl7-org:v3'][1]/:custodian[namespace-uri()='urn:hl7-org:v3'][1]/:assignedCustodian[namespace-uri()='urn:hl7-org:v3'][1]/:representedCustodianOrganization[namespace-uri()='urn:hl7-org:v3'][1]/*:id[namespace-uri()='urn:hl7-org:v3'][1] CodeContext: SCHEMATRON|||(DKCustodian): The value for @assigningAuthorityName SHALL be 'Erhvervs- og Selskabsstyrelsen'.

Can you explain why I get these errors? The assigningAuthorityName is set to 'Erhvervs- og Selskabsstyrelsen' and the extension is a valid CVR number (8 digits).

[ScaAnders]

Missing XML: `

</assignedCustodian>`

[TueCN]

Hi @ScaAnders The XML you pasted looks valid to me. Could you please attach the full ClinicalDocument that reproduces the error?

[ScaAnders]

LPR3.txt

[TueCN]

@ScaAnders thanks, but the provided document does not for me produce the errors you listed in the issue. Can you please verify you get the errors when using LPR3.txt?

• (DKCustodian): The value of the @extension SHALL be a valid Danish Business Identification number (cvr-nummer)
• (DKCustodian): The value for @assigningAuthorityName SHALL be 'Erhvervs- og Selskabsstyrelsen'

[ScaAnders]

I do get the errors using the attached document. What is the url for the test system you are using? Maybe we are not testing against the same instance...

[TueCN]

I use https://lprws-test.sds.dsdn.dk/cda-ws/DocumentRepository_Service/PatientHealthcareValidateReportingService

I suspect it might be encoding related. Can you provide the full HTTP request (including http headers) or can you give me an exact timestamp (down to the second) of a request that gives the error (so I can find it in the log)?

[ScaAnders]

LPR3-Raw.txt ok, so we are using the same service :) Please see the atachment for the raw request.

[TueCN]

When comparing your request to my request I notice a difference in the SOAP attachment's Content-Transfer-Encoding: You use 8bit while I use binary. Could you try and use binary transfer encoding instead and see if it helps?

From https://www.w3.org/Protocols/rfc1341/5_Content-Transfer-Encoding.html

The values "8bit", "7bit", and "binary" all imply that NO encoding has been performed. However, they are potentially useful as indications of the kind of data contained in the object, and therefore of the kind of encoding that might need to be performed for transmission in a given transport system. "8bit" means that the lines are short, but there may be non-ASCII characters (octets with the high-order bit set). "Binary" means that not only may non-ASCII characters be present, but also that the lines are not necessarily short enough for SMTP transport.

The difference between "8bit" (or any other conceivable bit-width token) and the "binary" token is that "binary" does not require adherence to any limits on line length or to the SMTP CRLF semantics, while the bit-width tokens do require such adherence. If the body contains data in any bit-width other than 7-bit, the appropriate bit-width Content-Transfer-Encoding token must be used (e.g., "8bit" for unencoded 8 bit wide data). If the body contains binary data, the "binary" Content-Transfer-Encoding token must be used.

[TueCN]

Hmm, I also noticed that your http Headers field contains MIME-Version=[1.0].

I just stumbled across this (see bold part): https://www.w3.org/TR/SOAP-attachments#HTTPBinding

1. The Content-Type: Multipart/Related MIME header must appear as an HTTP header. The rules for parameters of this header specified in section 2 apply here as well.
2. No other headers with semantics defined by MIME specifications (such as Content-Transfer-Encoding) are permitted to appear as HTTP headers. Specifically, the "MIME-Version: 1.0" header must not appear as an HTTP header. Note that HTTP itself uses many MIME-like headers with semantics defined by HTTP 1.1. These may, of course, appear freely.

[ScaAnders]

I find it very surprising that I receive a business-rule-error instead of a deserialization or encoding error if your assumption about the headers are correct. Its a big thing to start looking into the communication stack that we are using, in order to change the values that you suggest. So before I start to do that I would like to be certain that it will solve the problem. Is it possible that you can investigate your log file around this point in time: 11/14/2018 12:08:37 PM (I just tried to submit it again to log the time stamp)?

[TueCN]

The reason I suspect encoding errors is because we have previously experienced a similar thing: Deserialization happens fine, but SCHEMATRON validation errors appear due to not using UTF-8 encoding.

Now, I can see you use UTF-8 encoding in the attachment so that is not the problem here.

My suspicion is that since you use 8bit Content-Transfer-Encoding that maybe the encoding or decoding inserts newlines (CRLF) because it is a fixed-width encoding and the Schematron rules do not allow linebreaks in strings like 'Erhvervs- og Selskabsstyrelsen'.

The difference between "8bit" (or any other conceivable bit-width token) and the "binary" token is that "binary" does not require adherence to any limits on line length or to the SMTP CRLF semantics, while the bit-width tokens do require such adherence.

I don't really have other suggestions right now as to what your problem is :(

[TueCN]

@ScaAnders I see nothing different in your request 12:08:39 than the raw http request you already attached here.

I can post LPR's log of your full request + LPR's response, but this is a public forum so I just want to make sure that your SAML token has expired before doing so.

[ScaAnders]

Do you have any documentation on this in relation to LPR3? The reason I ask is because we have been using a standard Microsoft implementation of the MTOM protocol and since this need to be changed it will be nice to know that this is a requirement in order to make a successful WS call to LPR3. If possible and to minimize the time we use writing in this thread we could consider arranging af phone call :)

[TueCN]

No, this is purely speculation on my part (that the 8bit encoding is the problem).

Before you start a huge undertaking let me try and run this issue by a few other people. If you can wait until next week I can run this issue by @jonigkeit (he's on vacation) and see if he has any other suggestions as to what might be wrong.

[ScaAnders]

Unfortunately we are starting the official integration test to LPR3 within 3 weeks and we still have not been able to submit a single ClinicalDocument. We are a bit pressed for time :) Is there any other way we can continue the investigation this week?

[jonigkeit]

If @TueCN is right about the encoding issue causing a problem with Erhvervs- og Selskabsstyrelsen try to remove the XML attribute @assigningAuthorityName from the CDA document.

[TueCN]

@ScaAnders I had a chance to run your issue by @jkiddo and he spotted another difference between yours and ours request: Your request is not MTOM/XOP optimized. Although the service might initially accept unoptimized content, processing could result in strange behavior like we see here and the documentation actually requires request to be MTOM/XOP optimized.

Only SOAP with MTOM/XOP optimized content will be processed

https://wiki.ihe.net/index.php/XDS.b_Implementation#More_on_MTOM_vs_MTOM.2FXOP explains what MTOM/XOP optimization is:

it is generally a good idea to push the document contents out of the XML document and place it in its own part of a MIME Multipart. Then it is not part of the XML stream so the XML parsing is easier/faster and as its own part, binary encoding can be done. Binary coding means that it is not base64 coded. This pushing of the document contents into a multipart part, is called optimization.

Your request has the <ClinicalDocument> base64 encoded and embedded in the SOAP <Envelope> part.

Here is an example of a MTOM/XOP optimized request: https://scandihealth.github.io/lpr3-docs/examples/index.html#sample-request-using-mtomxop As you can see the SOAP <Envelope> is in one part and the <ClinicalDocument> is in another cart (and not base64 encoded)

Please do not base64 encode the document as it requires unnecessary computation for both client and server.

[jonigkeit]

I have proposed a new error code in #227.

[jonigkeit]

@ScaAnders please retry your request employing XOP/MTOM encoding.

[ScaAnders]

I'm looking into it ASAP.

[ScaAnders]

We can see that Microsoft has some internal problems regarding the MTOM protocol. Do you know of any other clients that have successfully used Microsoft as a client for the LPR3 service? If so is it possible that you can find a contact person (of course with their blessing) so that we can reach out in order to get some input?

[jonigkeit]

Not to our knowledge. Try contacting the Danish National Patient Register project group at the Danish National Health Data Agency.

Please close this issue if you have no further comments.