PdqResponseToPdqmResponseTranslator issue

[Seunghun Jun]

Hello,

I am currently working on PDQm profile by using 3.2-rc1 version which I believe the most recent version.

When I send a pdqm query, I can see the message goes through from iti-78 endpoint -> translator(PdqmRequestToPdqQueryTranslator) -> itivalidator -> iti21endpoint -> itiValidator. 

However, when it reach to translateHL7v2ToFhir(PdqResponseToPdqmResponseTranslator) and while the message is translating from HL7v2 to fhir in thePdqResponseToPdqmResponseTranslator, it is converting pid[19] to cx type. 

However, I think pid19 supposed to be st type.

I believe that gives me nullpointexception when I debug at the end of the stage of translating message from HL7v2 to Fhir...

Could you double check on this?

Thank you

Sincerely, 

Sean Jun

[Christian Ohr]

That's right.

See https://github.com/oehf/ipf/issues/139. Fixed with https://github.com/oehf/ipf/commit/b5b3565241e096cd68bdb9e555a3f5660a44aebd.

The translator now has an additional nationalIdentifierUri that is used as identifier system for PID-19.

Thanks for reporting!

cheers

Christian

[Seunghun Jun]

I just checked, and it works good~!

Thank you for your help as always!

Seunghun Jun

[Seunghun Jun]

One another question with my curiosity. 

When I sent a ITI-83 message, I get a response with value of targetIdentifier. However, it doesn't seems like contain value for targetId.  When I checked PixQueryResponseToPixmResponseTranslator, I can see it sets Name for targetIdentifier and values, but no targetId. 

According to PIXm IHE document (3.83.4.2.2 Message Semantics), it says,

"For each matching identifier, the parameters Resource shall include one parameter  element with name="targetIdentifier". For each matching Patient Resource, the parameters resource shall include one parameter element with name="targetId". The values may be returned in any order.

Am I missing something?? 

On Friday, January 20, 2017 at 4:26:11 PM UTC+9, Christian Ohr wrote:

[Christian Ohr]

The semantics in this specification is not entirely clear to me... I know that there has been discussions about the wording of the previous version of the spec, but the result is not really an improvement :-)

As both PIX Query and PIXm are intended to return patient identifiers rather than Patient resources, the PixQueryResponseToPixmResponseTranslator translates these identifiers exclusively into valueIdentifiers rather than valueReferences. You still can overwrite the handleRegularResponse method if you want to return valueReferences as well.

cheers

Christian

--
You received this message because you are subscribed to the Google Groups "ipf-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ipf-user+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Christian Ohr]

FYI: 

I posted this to the ITI mailing list a while ago (https://groups.google.com/forum/#!topic/ititech/ebyemiRNhrU).

From the response I conclude that there is no enforcement to return valueReferences.

Christian

[Seunghun Jun]

Thank you so much for this info. Helped me so much. Thanks~! 

I have another question regarding to EU connectathon. I am almost done with PDQm and PIXm. But, when I am looking through test cases under gazelle, I am little bit confused.

When it is talking about test for PDQm Supplier and Patient Identifier Cross-reference Manager, is this referring to eMPI? Then, do I suppose to test both consumers and eMPI?

I though those Supplier and Manager just act as translator for request and response message, not actually providing patient's info. 

Not sure If you know what I am talking about. Any ideas?

--
You received this message because you are subscribed to a topic in the Google Groups "ipf-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ipf-user/PNaYdNKAN1U/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ipf-user+unsubscribe@googlegroups.com.

[Christian Ohr]

PDQm Supplier and Patient Identifier Cross-reference Manager can very well natively respond with FHIR Patient or Parameter resources without the help of any translation. 

Noone enforces a translation to/from legacy PIX or PDQ transactions. It's just an implementation option for which IPF offers some support by means of the respective translators.

Christian

  

To unsubscribe from this group and all its topics, send an email to ipf-user+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "ipf-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ipf-user+u...@googlegroups.com.

[Christian Ohr]

Please provide the complete stacktrace - and run without any debugger.

Thanks

Christian

Seunghun Jun <seung...@gmail.com> schrieb am Fr., 24. Feb. 2017 um 06:29 Uhr:

i got an another issue with ITI-83 PIXm. 

I get a right response, but it comes with an error....from enrichAuditDatasetFromResponse method in Iti9AuditStrategyUtils. 

the error is 

org.openehealth.ipf.modules.hl7.dsl.HL7DslException: Cannot obtain the value of a segment

groovy.lang.MissingPropertyException: No such property: QUERY_RESPONSE for class: DUMMY

groovy.lang.MissingPropertyException: No such property: PID for class: DUMMY

so, it gives me 

ERROR AuditInterceptorUtils          - Exception when enriching audit dataset from response

It sounds like problem with a PID. 

But I think I am getting a right response from my eMPI

as 

MSH|^~\&|TPLUS-EMPI|TPLUS-COM|TPLUS-MOBILE|TPLUS|20170224141101.31+0900||RSP^K23^RSP_K23|4502|P^T|2.5

MSA|AA|27783eae-7446-404a-a91d-152ccb6cf1a0

QAK|9010435b-7012-44af-926f-21434931891e|OK

QPD|IHE PIX Query|9010435b-7012-44af-926f-21434931891e|566253be-9bf4-47af-ae52-041f00895814^^^&1.3.6.1.4.1.21367.2011.2.5.5435&ISO

PID|||12312^^^TPLUS&1.3.6.1.4.1.21367.2011.2.1.226&ISO||~^^^^^^S

is this my problem or ipf??? Not really sure....

[Seunghun Jun]

Here it is~

Thank !

org.openehealth.ipf.modules.hl7.dsl.HL7DslException: Cannot obtain the value of a segment

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)

at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)

at java.lang.reflect.Constructor.newInstance(Constructor.java:423)

at org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:83)

at org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:105)

at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:60)

at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:235)

at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:247)

at org.openehealth.ipf.modules.hl7.extend.Hl7Dsl2ExtensionModule.getValue(Hl7Dsl2ExtensionModule.groovy:400)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:498)

at org.codehaus.groovy.runtime.metaclass.ReflectionMetaMethod.invoke(ReflectionMetaMethod.java:54)

at org.codehaus.groovy.runtime.metaclass.NewInstanceMetaMethod.invoke(NewInstanceMetaMethod.java:56)

at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)

at org.codehaus.groovy.runtime.metaclass.MethodMetaProperty$GetBeanMethodMetaProperty.getProperty(MethodMetaProperty.java:76)

at org.codehaus.groovy.runtime.callsite.GetEffectivePojoPropertySite.getProperty(GetEffectivePojoPropertySite.java:64)

at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:296)

at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetPropertySafe(AbstractCallSite.java:410)

at org.openehealth.ipf.commons.ihe.hl7v2.atna.iti9.Iti9AuditStrategyUtils.enrichAuditDatasetFromResponse(Iti9AuditStrategyUtils.groovy:43)

at org.openehealth.ipf.commons.ihe.hl7v2.atna.iti9.Iti9AuditStrategy.enrichAuditDatasetFromResponse(Iti9AuditStrategy.java:45)

at org.openehealth.ipf.commons.ihe.hl7v2.atna.iti9.Iti9AuditStrategy.enrichAuditDatasetFromResponse(Iti9AuditStrategy.java:1)

at org.openehealth.ipf.platform.camel.ihe.mllp.core.intercept.AuditInterceptorUtils.enrichAuditDatasetFromResponse(AuditInterceptorUtils.java:137)

at org.openehealth.ipf.platform.camel.ihe.mllp.core.intercept.AuditInterceptorUtils.doProcess(AuditInterceptorUtils.java:75)

at org.openehealth.ipf.platform.camel.ihe.mllp.core.intercept.producer.ProducerAuditInterceptor.process(ProducerAuditInterceptor.java:39)

at org.openehealth.ipf.platform.camel.ihe.hl7v2.intercept.AcceptanceInterceptorUtils.processRequest(AcceptanceInterceptorUtils.java:49)

at org.openehealth.ipf.platform.camel.ihe.hl7v2.intercept.producer.ProducerRequestAcceptanceInterceptor.process(ProducerRequestAcceptanceInterceptor.java:32)

at org.openehealth.ipf.platform.camel.ihe.hl7v2.intercept.producer.ProducerAdaptingInterceptor.process(ProducerAdaptingInterceptor.java:86)

at org.openehealth.ipf.platform.camel.ihe.core.Interceptor2ProducerAdapter.process(Interceptor2ProducerAdapter.java:43)

at org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)

at org.apache.camel.processor.SendProcessor$2.doInAsyncProducer(SendProcessor.java:169)

at org.apache.camel.impl.ProducerCache.doInAsyncProducer(ProducerCache.java:341)

at org.apache.camel.processor.SendProcessor.process(SendProcessor.java:164)

at org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:460)

at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:190)

at org.apache.camel.processor.Pipeline.process(Pipeline.java:121)

at org.apache.camel.processor.Pipeline.process(Pipeline.java:83)

at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:190)

at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:109)

at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:87)

at org.openehealth.ipf.platform.camel.ihe.fhir.core.intercept.consumer.ConsumerAuditInterceptor.process(ConsumerAuditInterceptor.java:55)

at org.openehealth.ipf.platform.camel.ihe.fhir.core.FhirConsumer.runRoute(FhirConsumer.java:185)

at org.openehealth.ipf.platform.camel.ihe.fhir.core.FhirConsumer.handleInRoute(FhirConsumer.java:161)

at org.openehealth.ipf.platform.camel.ihe.fhir.core.FhirConsumer.handleResourceRequest(FhirConsumer.java:100)

at org.openehealth.ipf.commons.ihe.fhir.AbstractPlainProvider.requestResource(AbstractPlainProvider.java:96)

at org.openehealth.ipf.commons.ihe.fhir.AbstractPlainProvider.requestResource(AbstractPlainProvider.java:75)

at org.openehealth.ipf.commons.ihe.fhir.iti83.Iti83ResourceProvider.pixmQuery(Iti83ResourceProvider.java:72)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:498)

at ca.uhn.fhir.rest.method.BaseMethodBinding.invokeServerMethod(BaseMethodBinding.java:258)

at ca.uhn.fhir.rest.method.OperationMethodBinding.invokeServer(OperationMethodBinding.java:294)

at ca.uhn.fhir.rest.method.BaseResourceReturningMethodBinding.doInvokeServer(BaseResourceReturningMethodBinding.java:306)

at ca.uhn.fhir.rest.method.BaseResourceReturningMethodBinding.invokeServer(BaseResourceReturningMethodBinding.java:257)

at ca.uhn.fhir.rest.method.OperationMethodBinding.invokeServer(OperationMethodBinding.java:268)

at ca.uhn.fhir.rest.server.RestfulServer.handleRequest(RestfulServer.java:665)

at ca.uhn.fhir.rest.server.RestfulServer.doGet(RestfulServer.java:1215)

at ca.uhn.fhir.rest.server.RestfulServer.service(RestfulServer.java:1191)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)

at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)

at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:121)

at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:198)

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:108)

at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:522)

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)

at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)

at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:620)

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:349)

at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:1110)

at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)

at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:785)

at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1425)

at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

at java.lang.Thread.run(Thread.java:745)

2017-02-24 17:40:17,795 [nio-8080-exec-1] DEBUG UDPSyslogSenderImpl            - Auditing to 188.165.194.55:10009

[Christian Ohr]

In fact, this was a problem with client side auditing of PIX Query. I fixed it (see https://github.com/oehf/ipf/issues/144).

Probably you don't need client-side auditing in a PIXm to PIX Query translator anyway, as the PIXm consumer already writes an ATNA audit (and your EMPI probably as well). 

IMO the translation logic does not need to be audited (at least I don't do this) as it is an implementation detail. Just add a ?audit=false parameter to your ITI-9 producer.

cheers

Christian

Seunghun Jun <seung...@gmail.com> schrieb am Fr., 24. Feb. 2017 um 09:23 Uhr:

Here it is~

Thanks

[Seunghun Jun]

That sounds right...thank you for checking 

Seunghun Jun

--
You received this message because you are subscribed to a topic in the Google Groups "ipf-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ipf-user/PNaYdNKAN1U/unsubscribe.

To unsubscribe from this group and all its topics, send an email to ipf-user+unsubscribe@googlegroups.com.

[Seunghun Jun]

Hello, 

I just figured there is an another error with PDQm.

All the other query parameters are working fine except birthdate.

It works fine with one parameter, but IHE says this:

8.4.1.2 Message Semantics

"The Patient Demographics Consumer shall use the date and interval mechanism described in HL7 FHIR (http://hl7.org/fhir/DSTU2/search.html#date) to indicate a specific date of birth or a date that lies within the range specified by the parameter."

So, I checked Fhir search for date and it is saying this:

To search for all the procedures in a patient compartment that occurred over a 2 year period:

 GET [base]/Patient/23/Procedure?date=ge2010-01-01&date=le2011-12-31

Therefore, I made query like this:

http://localhost:8080/mobile/fhir/Patient?&birthdate=gt1986-01-01&birthdate=eq1986-08-08&_format=application/json+fhir

And the error says:

2017-03-10 16:12:31,167 [nio-8080-exec-5] INFO  IpfFhirServlet                 - ERROR - search-type - Patient
2017-03-10 16:18:46,051 [nio-8080-exec-6] WARN  ExceptionHandlingInterceptor   - Failure during REST processing: ca.uhn.fhir.rest.server.exceptions.InvalidRequestException: Multiple values detected for non-repeatable parameter 'birthdate'. This server is not configured to allow multiple (AND/OR) values for this param.

Could you check on this please?

Thanks

Seunghun Jun

[Christian Ohr]

I corrected the parameter signature for PDQm so that your birthdate range request will be accepted.

However, for the time being, the translation from PDQm to PDQ will just respect the first birthdate parameter and treat it as exact search, because PDQ does not support anything else by default.

cheers

Christian

[Seunghun Jun]

Thank you,

I should have checked pdq.... Thank you for checking 

Sean