HTTP Listener: transformer not reading CDA XML correctly if the root element has xmlns="urn:hl7-org:v3"

[rbeckman-nextgen]

I have a channel with an HTTP Listener that receives XML (all datatypes are set to XML).

I'm testing this channel with HL7 CDA documents that have this form (valid against the CDA XSD):

<?xml version="1.0" encoding="UTF-8"?>

Pablo Federico Pazos Gutiérrez Dr. Christine Curie AESP World University Hospital e1xydGY...

Since the CDA appears base64 encoded on the HTTP request, I use this to get the XML message:

var base64 = msg['Content'].toString(); var decoded = FileUtil.decode(base64); var decodedAsString = Packages.java.lang.String(decoded); var mensajeXML = new XML(decodedAsString);

That works OK, already tested in other channels.

The problem I see is that when I do mensajeXML['recordTarget'] to get the patient data, it is empty.

After several tries, modifying the CDA and the channel I found that if the xmlns="urn:hl7-org:v3" attribute is removed from the ClinicalDocument element (root), mensajeXML['recordTarget'] retrieves the patient data.

So this might be a Mirth issue with that namespace declaration. And that declaration exists in almost all CDA examples you can find on the web. Few examples: https://github.com/chb/sample_ccdas/tree/master/HL7%20Samples

Imported Issue. Original Details: Reporter: ppazos Created: 2016-07-24T21:25:53.000-0700

[rbeckman-nextgen]

BTW, this was working on v3.0.3

Imported Comment. Original Details: Author: ppazos Created: 2016-07-24T21:27:13.000-0700

[rbeckman-nextgen]

Just tested and appears to work perfectly for me in the latest version. If the inbound data type is XML then the default namespace will be set to the namespace of the root node, if present. Sounds like this is a channel implementation error; you probably need to set the default namespace, or create one and reference it explicitly when referencing nodes in your manually-created E4X XML object.

Also note that for an HTTP Listener, the Binary MIME Types field determines what MIME types cause the receiver to Base64-encode incoming data. By default it's a regular expression that matches application/*, image/*, etc., but excludes application/xml and application/json. However if you've upgraded that channel from an earlier version it's possible that the Binary MIME Types field is still set to something that doesn't capture the xml/json cases. In any case, if you don't want that field to be Base64-encoded, check that HTTP Listener setting.

Let us know if there's still an issue and we can certainly reopen the issue. Thanks!

Imported Comment. Original Details: Author: narupley Created: 2016-07-24T22:10:48.000-0700

[rbeckman-nextgen]

Hi Nick, thanks for the feedback.

How can I attach my channel to this discussion? Can you please publish your test?

With encoding, my channel works OK just by removing xmlns="urn:hl7-org:v3" from the ClinicalDocument of the incoming CDA, and none of my channel logic depends on that. I'm trying to access the XML in the way Mirth processes it.

Yeah, I removed application/ from the binary MIME Types and I saw the XML in the request without encoding. Also, on this case (no encoding) I saw that Mirth is removing all the namespaces from the ClinicalDocument element, I get just (I saw the white spaces after the name, where the namespaces were, it seems a string replace is done there). Because of that I think the processing doesn't have trouble with the xmlns="urn:hl7-org:v3" attribute.

Imported Comment. Original Details: Author: ppazos Created: 2016-07-24T22:39:10.000-0700

[rbeckman-nextgen]

Attaching working test channel for 3.4.1.

Imported Comment. Original Details: Author: narupley Created: 2016-07-25T13:53:07.000-0700