Further experiments with Mirth
George Lilly
I ran into a problem, however in trying to send a sample CCR xml file through this setup. The error message produced is below and I'm attaching the sample CCR document that I'm using (it is the one supplied by HL7 in the "CCD-Final" delivery and is know to be transformable via XSLT to a CCD).
I went to the mirthproject.org website to see if I could resolve the error, and found no references there to "CCR" or "CCD" (do we know of anyone who has successfully used Mirth for transporting CCRs?). I did find a similar error logged there (details below) and a resolution that suggests using "strict parsing". I am tempted to submit the error we are encountering with our sample CCR as a potential bug in Mirth and see if we can engage that community to help us. I will continue to try and learn how to specify "strict parsing" and see if that clears up the problem I'm having.
I also notice that Mirth includes a built-in XSLT capability that allows one to load a "global variable map" and a template and generate a xml output file (perhaps a CCR). This output file could also be exported with Mirth capabilities to a MySql database. Are these capabilities sufficient for our needs?
I also noticed that Mirth comes with an ant configuration file. The Globas Toolkit also uses ant for configuration management. Would ant ( http://ant.apache.org/ ) be a good choice for us to use? I had some exposure to it when I was learning a bit about Globus, and it is very powerful.
There is lots of capability here given our approach. I will continue to learn about it.
gpl
ERROR-300: Transformer error
ERROR MESSAGE: Error evaluating transformer
com.webreach.mirth.model.converters.SerializerException: java.lang.ArrayIndexOutOfBoundsException: 1
at com.webreach.mirth.model.converters.ER7Serializer.fromXML(ER7Serializer.java:199)
at com.webreach.mirth.model.converters.ER7Serializer.fromXML(ER7Serializer.java:49)
at com.webreach.mirth.server.mule.transformers.JavaScriptTransformer.evaluateScript(JavaScriptTransformer.java:387)
at com.webreach.mirth.server.mule.transformers.JavaScriptTransformer.transform(JavaScriptTransformer.java:307)
at org.mule.transformers.AbstractEventAwareTransformer.doTransform(AbstractEventAwareTransformer.java:48)
at org.mule.transformers.AbstractTransformer.transform(AbstractTransformer.java:197)
at org.mule.transformers.AbstractTransformer.transform(AbstractTransformer.java:200)
at org.mule.transformers.AbstractTransformer.transform(AbstractTransformer.java:200)
at org.mule.impl.MuleEvent.getTransformedMessage(MuleEvent.java:251)
at org.mule.routing.inbound.SelectiveConsumer.isMatch(SelectiveConsumer.java:61)
at org.mule.routing.inbound.InboundMessageRouter.route(InboundMessageRouter.java:79)
at org.mule.providers.AbstractMessageReceiver$DefaultInternalMessageListener.onMessage(AbstractMessageReceiver.java:493)
at org.mule.providers.AbstractMessageReceiver.routeMessage(AbstractMessageReceiver.java:272)
at org.mule.providers.AbstractMessageReceiver.routeMessage(AbstractMessageReceiver.java:231)
at com.webreach.mirth.connectors.file.FileMessageReceiver.processFile(FileMessageReceiver.java:236)
at com.webreach.mirth.connectors.file.FileMessageReceiver.poll(FileMessageReceiver.java:138)
at org.mule.providers.PollingMessageReceiver.run(PollingMessageReceiver.java:118)
at org.mule.impl.work.WorkerContext.run(WorkerContext.java:290)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.ArrayIndexOutOfBoundsException: 1
at com.webreach.mirth.model.converters.ER7XMLHandler.startElement(ER7XMLHandler.java:111)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at com.webreach.mirth.model.converters.ER7Serializer.fromXML(ER7Serializer.java:194)
... 20 more
found on the mirthproject.org website:
| Operating System: | Windows XP, Windows 2000, Linux, Mac OS X |
| Description | « Hide |
|
The 1.7 XML 2 HL7 parser launch an exception for messages which works fine for previous versions
|
| All | Comments | Work Log | Change History |
Sort Order:
|
ERROR-300: Transformer error
ERROR MESSAGE: Error evaluating transformer
com.webreach.mirth.model.converters.SerializerException: java.lang.ArrayIndexOutOfBoundsException: 2
at com.webreach.mirth.model.converters.ER7Serializer.fromXML(ER7Serializer.java:190)
at com.webreach.mirth.model.converters.ER7Serializer.fromXML(ER7Serializer.java:51)
at com.webreach.mirth.server.mule.transformers.JavaScriptTransformer.evaluateScript(JavaScriptTransformer.java:369)
at com.webreach.mirth.server.mule.transformers.JavaScriptTransformer.transform(JavaScriptTransformer.java:289)
at org.mule.transformers.AbstractEventAwareTransformer.doTransform(AbstractEventAwareTransformer.java:48)
at org.mule.transformers.AbstractTransformer.transform(AbstractTransformer.java:197)
at org.mule.impl.MuleEvent.getTransformedMessage(MuleEvent.java:251)
at com.webreach.mirth.server.controllers.MessageObjectController.getMessageObjectFromEvent(MessageObjectController.java:507)
at com.webreach.mirth.connectors.file.FileMessageDispatcher.doDispatch(FileMessageDispatcher.java:74)
at com.webreach.mirth.connectors.file.FileMessageDispatcher.doSend(FileMessageDispatcher.java:208)
at org.mule.providers.AbstractMessageDispatcher.send(AbstractMessageDispatcher.java:166)
at org.mule.impl.MuleSession.sendEvent(MuleSession.java:191)
at org.mule.impl.MuleSession.sendEvent(MuleSession.java:130)
at org.mule.routing.outbound.AbstractOutboundRouter.send(AbstractOutboundRouter.java:85)
at org.mule.routing.outbound.FilteringMulticastingRouter.route(FilteringMulticastingRouter.java:89)
at org.mule.routing.outbound.OutboundMessageRouter$1.doInTransaction(OutboundMessageRouter.java:78)
at org.mule.transaction.TransactionTemplate.execute(TransactionTemplate.java:48)
at org.mule.routing.outbound.OutboundMessageRouter.route(OutboundMessageRouter.java:82)
at org.mule.impl.model.DefaultMuleProxy.onCall(DefaultMuleProxy.java:247)
at org.mule.impl.model.seda.SedaComponent.doSend(SedaComponent.java:209)
at org.mule.impl.model.AbstractComponent.sendEvent(AbstractComponent.java:277)
at org.mule.impl.MuleSession.sendEvent(MuleSession.java:201)
at org.mule.routing.inbound.InboundMessageRouter.send(InboundMessageRouter.java:161)
at org.mule.routing.inbound.InboundMessageRouter.route(InboundMessageRouter.java:128)
at org.mule.providers.AbstractMessageReceiver$DefaultInternalMessageListener.onMessage(AbstractMessageReceiver.java:493)
at org.mule.providers.AbstractMessageReceiver.routeMessage(AbstractMessageReceiver.java:272)
at org.mule.providers.AbstractMessageReceiver.routeMessage(AbstractMessageReceiver.java:231)
at com.webreach.mirth.connectors.file.FileMessageReceiver.processFile(FileMessageReceiver.java:236)
at com.webreach.mirth.connectors.file.FileMessageReceiver.poll(FileMessageReceiver.java:138)
at org.mule.providers.PollingMessageReceiver.run(PollingMessageReceiver.java:118)
at org.mule.impl.work.WorkerContext.run(WorkerContext.java:290)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.ArrayIndexOutOfBoundsException: 2
at com.webreach.mirth.model.converters.ER7XMLHandler.startElement(ER7XMLHandler.java:146)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at com.webreach.mirth.model.converters.ER7Serializer.fromXML(ER7Serializer.java:185)
... 33 more
(Older versions of Mirth used the Strict Parser by default, so this message would work with no change. Imported channels from versions earlier than 1.4 should still be set to use Strict Parser).
pete...@umn.edu
you used the HL7 version final delivery. It is my understanding that HL7
has always placed data into xml tags, which is one of major
incompatabilities between HL7 and ASTM versions of the xml, (and one of the
major disputes in structure of the CCD and CCR). It seems to me that the
HL7 final version continued to do this, which would cause a mess parsing. I
will ask Mark to check, but "strict parsing" may be referring to not
abusing the xml tags. An ASTM CCR might be more straightforward, for
example from CCHIT or Solventus. I would send one, but am on the road and
don't have access. Kevin
> *Operating System:* Windows XP, Windows 2000, Linux, Mac OS X
>
> *Description* « Hide
><http://www.mirthproject.org/jira/browse/MIRTH-721> The
>1.7 XML 2 HL7 parser launch an exception for messages which works fine for
>previous versions
> *Description*
> The 1.7 XML 2 HL7 parser launch an exception for messages which works
>fine for previous versions
>
>Show » <http://www.mirthproject.org/jira/browse/MIRTH-721>
>
> *All <http://www.mirthproject.org/jira/browse/MIRTH-721?page=all>* *
> Comments* *Work
> Log<http://www.mirthproject.org/jira/browse/MIRTH-721?page=worklog> *
> *Change
> History<http://www.mirthproject.org/jira/browse/MIRTH-721?page=history> *
> Sort Order:
> <http://www.mirthproject.org/jira/browse/MIRTH-721?actionOrder=desc> [
> Permlink <http://www.mirthproject.org/jira/browse/MIRTH-721#action_10883>
> | « Hide <http://www.mirthproject.org/jira/browse/MIRTH-721> ] Alberto
> Sáez
> Torres<http://www.mirthproject.org/jira/secure/ViewProfile.jspa?name=albertosaez>
>PollingMessageReceiver.java:118)
> at org.mule.impl.work.WorkerContext.run(WorkerContext.java:290)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask
> (ThreadPoolExecutor.java:650)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run
> [ Show » <http://www.mirthproject.org/jira/browse/MIRTH-721> ] Alberto
> Sáez
> Torres<http://www.mirthproject.org/jira/secure/ViewProfile.jspa?name=albertosaez>
> FileMessageReceiver.java:138) at
> org.mule.providers.PollingMessageReceiver.run(PollingMessageReceiver.java:118)
> at org.mule.impl.work.WorkerContext.run(WorkerContext.java:290)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask
> (ThreadPoolExecutor.java:650) at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run
> (ThreadPoolExecutor.java:675) at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.ArrayIndexOutOfBoundsException: 2
> at
>com.webreach.mirth.model.converters.ER7XMLHandler.startElement(
>ER7XMLHandler.java:146) at
>org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
> at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown
> Source) at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
> Source) at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
> Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at
> org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at
> com.webreach.mirth.model.converters.ER7Serializer.fromXML(ER7Serializer.java:185)
> ... 33 more
>
> [
> Permlink<http://www.mirthproject.org/jira/browse/MIRTH-721#action_10884>|
> « Hide <http://www.mirthproject.org/jira/browse/MIRTH-721> ] Christopher
> Lang<http://www.mirthproject.org/jira/secure/ViewProfile.jspa?name=chrisl>
> [22/Jan/08 11:05 AM] Thanks for finding this!
> [ Show » <http://www.mirthproject.org/jira/browse/MIRTH-721> ]
> Christopher
> Lang<http://www.mirthproject.org/jira/secure/ViewProfile.jspa?name=chrisl>
> [22/Jan/08 11:05 AM] Thanks for finding this!
>
> [
> Permlink<http://www.mirthproject.org/jira/browse/MIRTH-721#action_10885>|
> « Hide <http://www.mirthproject.org/jira/browse/MIRTH-721> ] Christopher
> Lang<http://www.mirthproject.org/jira/secure/ViewProfile.jspa?name=chrisl>
> [22/Jan/08 11:24 AM] The XML file can be successfully processed using the
> "Strict Parser". The non-strict default parser does not recognized
> two-letter segments.
>
>(Older versions of Mirth used the Strict Parser by default, so this message
>would work with no change. Imported channels from versions earlier
>than 1.4should still be set to use Strict Parser).
>
> >
>
George Lilly
It would be great to have several different versions of the CCR to learn from. I read about the controversy of the data-in-XML-tags on the ASTM website, and I was surprised when I found that the problem was still there in the "final CCD" sampleCCDdocument.xml. I hadn't thought they would corrupt the sampleCCRdocument.xml that they send out, but I'll take a look at it. Thanks. George
George Lilly
http://chit.dyndns.org/CCRValidation/
I ran the sampleCCRdocument.xml file from HL7 that I have been using through the validator and it passed. I'm attaching the report.
I am still looking for more sample CCR documents to study and continuing my experiments with Mirth.
gpl