ADT^A31 v2.5 message gets parsed as ADT^A05 v2.5 #597
Description
Activity
I've downloaded the sources to investigate this, and it's the NameValueCollection.Get() method that returns ADT_A05 even though ADT_A31 is in that collection of keys:
- added a commit that references this issue
on Oct 7, 2024 I've created a fork to investigate this issue: https://github.com/eloekset/nHapi/tree/feature/issue-597-investigate-parsing
I had to upgrade .NET and various packages to be able to run tests in VS2022, so I did that in a separate commit before adding the unit test used to debug as shown in the screenshot above.
For some reason the NHapi.Model.V25 assembly has a mapping from ADT_A31 to ADT_A05.
@eloekset hello, thanks for raising an issue, have you read the wiki page about event mapping?
https://github.com/nHapiNET/nHapi/wiki/Decoding-a-message#event-map-to-code-structure-mappings
I think what you might be describing is "a feature" or querk 🙂 rather than a bug.The reason why is because this is how the Java hapi library works of which this is a port, they have a Faq with a question covering this here.
the event mapping for 2.5 maps A31 to A05 accoring to the map
Please let me know if I have missunderstood.
also you fork seems to be 135 commits behind the current nhapi master branch
Thanks! I've found this part of the documentation. I've been trying to make the PipeParser parse ADT^A31 messages as my custom message defined in my application's Core assembly, however I've still not succeeded despite several attempts at debugging the PackageManager and EventMapper code.
There's a comment in the DefaultModelClassFactory describing how to define custom messages in the original Java project, but that doesn't match the nHapi port:
I'm trying to define a v2.5 message with a few custom segments:
there is a section in the wiki which explains how this can be done
https://github.com/nHapiNET/nHapi/wiki/Configuration-Options#custom-hl7-object-modelsThere is also a unit test showing this in action:
https://github.com/nHapiNET/nHapi/blob/master/tests/NHapi.NUnit/CustomZSegmentTest.cs
corresponding app.config
https://github.com/nHapiNET/nHapi/blob/master/tests/NHapi.NUnit/App.configThanks! Those are the items I've found, and I'm trying to figure out how to override the default mapping from ADT_A31 to ADT_A05 for v2.5. Since I've created a file called EventMap.properties in a folder EventMapping and set its Build Action to Embedded resource, I would expect the dynamic resolving code in the EventMapper class to load the message structure that I've specified for v2.5:
However that doesn't happen, because the inResource variable resolved to null:
Since the CustomZSegmentTest doesn't originally define custom messages like I do, this feature isn't demonstrated.
I can try to rebase my feature branch and push the latest changes as far as I've come now.
- added a commit that references this issue
on Oct 8, 2024 I created a new branch instead of rebasing, since the NUnit stuff was already updated for VS2022. I've pushed my latest attempt here: https://github.com/eloekset/nHapi/tree/feature/issue-597-investigate-parsing-2
However, I now got the idea that maybe it's easier to create a custom model factory that derives from(It doesn't even get into the constructor of the ADT_A31 message, so the custom model factory won't ever be used.)DefaultModelClassFactoryinstead of relying on that dynamic loading of message structures.the
CustomZSegmentTestdoes use a custom message
https://github.com/nHapiNET/nHapi/blob/master/src/NHapi.Model.V22_ZSegments/Message/ADT_A08.cs
you shouldnt need to attempt to override the event mapping.did you see this bit in the wiki when parsing?
var parser = new PipeParser(); var parsed = parser.Parse(message, "2.2.CustomZ");
Notice the second argument, it tells the parser to use the custom version when parsing.
Thanks for the help @milkshakeuk!
This finally did the trick:
Reacted by Jake Aitchison- locked and limited conversation to collaborators
on Oct 9, 2024
Describe the bug
new PipeParser().Parse(hl7Content)parses an ADT^A31 message as ADT^A05.To Reproduce
Parse the sample message content.
Expected behaviour
This should be recognized as an ADT^A31 v2.5 message.
Screenshots
Sample HL7
Environmental Details (please complete the following information):
Additional context
Works fine for ADT^A01 sample message and several other similar sample messages: