Support Custom Segment Headers #13
Conversation
270/271 messages use numbers (20,21,22) for their HL03 values. segPathMatch would get bad results if numbers were used. Fixed segPathMatch to work with numbers.
Generation only validated the ISA,GS, and ST segments. Extended this to be configurable via the serialization options so that users can pass in their own specific segment validators.
|
Kudos, SonarCloud Quality Gate passed!
|
|
At quick glance, I like what I see. Thanks for chipping in with these changes! I'm super-swamped but should be able to make time to review within the next two weeks and cut a release then, if that works for you. |
|
Sounds great, I am not in any rush. I am using my forked branch for my app now. If I do anything else that my be useful to others I will push back again. Thank you so much for the excellent library! I am using it in our new medical billing app and it is wonderful not having to use our old C++ lib that was such a pain to work with! |
|
So I am not sure if you want it but I have another branch in my fork that extends this one some more where I tried to implement loops. I got it working pretty much for what I need. Here is a link to my POC where you can see it action. Just paste this sample edi in the EDI Data Section and click either of the Save Icon Buttons. The left side will show the parse results. |
That's cool. I must confess, staring at the 271 I don't quite understand what's happening with FORSEGLOOP. Your POC kicks butt. I'm doing docs in ecommerce, and I FEEL like most ecom docs I've been provided with so far haven't required this use case, but clearly you'e got one. I would welcome that change as well. Did you happen to write an explanation of the FORSEGLOOP with an example in the docs? Looks like you wrote some tests, which is fantastic. Just not sure I can do justice to FORSEGLOOP if I were to add documentation for it. |
|
Sure, I can document the stuff I added. I am by no means an expert on EDI but the FORSEGLOOP is a way to filter segments based on loops. EDI has a concept of bounded and unbounded loops. A bounded loop has a trailing segment just like XML open and close tags. Unbounded loops do not, they start when you first encounter a segment and then end when you encounter the next same segment or another starting segment or the ending of a previous bound segment. It is very confusing. To keep track of loops I updated the parsing code to add extra properties to the X12Segment class. The main one is loopPath which is a string that contains where in the looping the segment falls. Given the following EDI:
The parse code will now figure out the loops and record them like this
You already had support to pull out the different HL segments with your HL query but what I needed to do was also get the NM1 and EB unbounded loops. Line 7 above starts the first and only unbound NM1 loop. Within that loop there are multiple EB loops. The first one starts and stops at line 12. The second one starts at line 13 and stops at line 14. Line 13 is an EB and line 14 is a DTP, which is included in the preceding EB loop. Until another EB or other loop start or end segment is encountered, all segments are part of the loop. To make it more complicated, line 30 starts a bounded loop within an unbounded loop.
This is the ninth EB segment and it contains all the lines from 27 to 35. Lines 30 to 35 are a sub loop and are required because they contain segment tags NM1 which normally should cause a new loop but in this case because they are a child of the LS/LE bounded loop, they are treated as regular segments and assigned to the current loop. Since each segment now has a loopPath string property it can be used by the QueryEngine to apply extra filters. This is the purpose of the FORSEGLOOP marco. I wanted to add a way to apply a filter against the loopPath property while still keeping all your current query syntax. It's technically not a macro but it seems to be the least destructive way to add the feature. The FORSEGLOOP works like your other macros where it is split on '=>'. Everything to the left is the macro, everything to the right is query. The left part is parsed for the value between the parentheses. This value can be plain text or regex and is used to apply a pre-filter match against the loopPath property for the segments. The right side is then applied as usual and the same result type is returned. My POC is just using vm2 to run the code in the script window on the backend. I attached my own query functions to the script context that wrap your query functions but that take an extra parameter to further massage the results. Give me about a week or so to move this code into our main app so I can make sure it works and then I will update documentation MD files and refresh this branch. |
|
Clearly it has taken a LOT longer than two weeks. I'm working on this today. |
|
This is now in, and will be published later today. I like the re-organization of the segment header/trailer defaults and layout. Makes much more sense. |
|
No worries, I am behind as well and have not had a chance to work on the next stage I am planning. I should have time soon. I am planning to build out a UI for your library based on my POC test. I want it to be able to create build and parse script packages that can be saved, then use those saved packages as API's that can be called from other apps via HTTP like a micro-service. |
I needed to support this for my use so I though I would push it back. I am processing 270/271 patient eligibility stuff and found that the ST segment was not working right. According to the spec I have the segment has 3 elements but in the code it is hard coded to only allow 2. Instead of changing that I reworked things to allow users to pass in overrides. This also allows another thing I needed which is to valid other segments. I added tests and got all of them to pass expect for some compare ones which I have a feeling the issue is that fact I am on windows.
I also fixed a small bug in the HL query. All the medical messages are using numbers for the HL03 value. This was causing an issue and returning no results.