HIPAA EDI Document Splitting - 837D
Hey everybody,
We are encountering a problem with BizTalk Server 2006 R2 with regards to document splitting in the 837D EDI schema. In our current environment, we are running BizTalk Server 2006 and are attempting to move to BizTalk Server 2006 R2 for a new project we have underway.
The problem we are seeing is in how the EDI Engine in R2 is splitting up our EDI 837D files when they are picked up by BizTalk through a Receive Location that utilizes the EdiReceive Pipeline. In 2006, once an 837D EDI file was received, the HIPAA Accelerator would split the file into messages where each Claim (2300 Loop) was its own Message. I looked at the 837D schema (multiple) that came with 2006, and it appears this document splitting was based on the attribute subdocument_creation_break="yes" being speficied in the 2300 Loop XML node.
The 837D multiple schema that came with R2 also has subdocument_creation_break="yes" specified at the 2300 Loop, but it generates drastically different results than what we are seeing in 2006. In 2006, the 837D file, once translated to XML and split, would give us one Message per Claim where the information in the XML Message included only that information that pertained to the Claim. This would include information from the ISA segment, GS segment, ST segment, 2000A Loop, 2000B Loop, 2300 Loop, etc., all the way down to the most granular level of detail that pertained to the Claim, but would not include any information that did not pertain to the Claim.
Now, in R2, if this document splitting attribute is specified in the 2300 Loop, in each Message we still get only that information from the 2300 Loop on down that pertains to the Claim. However, we get all of the information from the higher levels in every Message generated by the EDI Engine. For example, if we have an 837D EDI file that has 3 Claims in it (3 2300 Loops), and each 2300 Loop has its own 2000B Loop as a parent (3 2000B Loops), each Message generated by the EDI Engine will contain only one 2300 Loop, but it was also contain all 3 2000B Loops. We have tried moving the attribute subdocument_creation_break="yes" to other higher levels in the 837D schema, but that can result in more than one 2300 Loop being included in each Message.
Basically, I'm trying to duplicate the processing output we are seeing in 2006, but I can't make it work in R2. We either get lots of unnecessary data in each Message, or we get multiple 2300 Loops in each Message.
Have any of you seen or experienced this same problem, and can help us achieve the desired result? Even if it is not possible in R2, that would be good to know. Every post I've read about the subdocument_creation_break="yes" attribute makes it sound like it works great, but it is not giving us the results we are looking for.
Thank you.
All Replies
Hi Jeff,
sorry for delayed response. It is known issue that subdocument_creation_break="yes" doesn't effectively work when it is promoted at higher levels. For other issue about inclusion of extra information( 3 2000B loops) our team is looking into it. we will come back to you soon.
Thanks,
Bhola
- Proposed As Answer byLeonid GanelineMVPMonday, February 16, 2009 4:59 PM
Hi Bhola,
Thank you for the response and for looking into this issue. I am obviously very eager to hear what your team discovers.
Jeff
Hi Jeff,
In the schema if there is a subdocument_creation_break="yes" at a node then the siblings of the parent node are kept intact. This is the issue that you are facing. So a mapper or orchestration can be used that strips out the additional siblings after EDI DASM for this. This has been noted as an issue and will be addressed in future release.
Thanks,
Kowshik Palivela
Hi Kowshik,
As Jeff previously noted, this is a really big problem for us. This issue while can be worked around will simply cause us additional unnecessary work until it is fixed. What does "future release" mean? If we have to wait until BizTalk 2009 comes out then we will have to seriously consider not implementing 2006 R2 at all. Can we escalate this with a support request and get a hot fix created?
Thanks,
Joel
Hi Joel,
If this is urgent, you could raise a support request and it shall be considered for HotFix based on the current priority list and business impact.
regds
Ravi
Hi,
Is there a fix available for the issue reported by the Joel? I was going to start a new thread to report a similar issue with the 837P claims and came across this thread when I did a search. So just wanted to bring to your attention.
thanks.
Not that we have been made aware of. We have opened a support request with Microsoft and hope that a fix is created quickly as this problem causes our file sizes to grow enourmous.
Joel
My team has not been looped in yet on the support request. Is it closed or is it in progress?
- Ravi, Jeff from the original posting has opened a support request and the request is in progress. We are hoping for a hotfix to be created as we can't go to production with this issue. Thanks, Joel.
- kowshik - MSFT said:
Hi Jeff,
In the schema if there is a subdocument_creation_break="yes" at a node then the siblings of the parent node are kept intact. This is the issue that you are facing. So a mapper or orchestration can be used that strips out the additional siblings after EDI DASM for this. This has been noted as an issue and will be addressed in future release.
Thanks,
Kowshik Palivela
Dear MSFTs,
Sorry to resurrect this old thread, but this is going to be a major issue for us as well. In production we process 100,000 to 120,000 claims between 6 AM and 1 PM using BizTalk 2002. This is just the claims portion. We also process several other transactions like 834s, 835s, 270/271s, 278s, 820s and so on between 1 PM and 6 AM. So pretty much BizTalk is on 24 x 7 schedule. We have several Trading Partners that send 837 claims in all different formats. Some with 10,000 to 15,000 claims within a single ST. Some uses multiple STs etc. etc. In production we have one server dedicated for parsing and two servers dedicated for processing. The processing servers process the claims at the rate of 10 -12 claims/sec. Our goal is to make this number at least 15 - 20 claims/sec with better hardware and software (R2).
The work around you mentioned to handle the splitting issue won't work well for us as it will severely affect the performance. Imagine the outcome if we process a claim file with 15,000 claims in a single ST. I have been playing with R2 for sometime now and there are lot of nice fatures in R2 that were not available in 2002 and I am really impressed. This splitting issue is a major thing that needs to be addressed by the R2 development team. The million nice features in the EDI portion of the R2 won't do any good until this is resolved. Since this is a relatively new product, there may not be that many people out there who use R2 for processing inbound HIPAA docs. From the forums I could see that lot of people are in the process of migrating. So no matter what, at some point they all are going to hit this bottleneck. So I kindly request to the MSFTs to do whatever it takes to resolve this issue. This is a biggy in the real world situation. Once again, thanks a lot for helping people like me in the forums.
thanks. - Hello Everyone,
I just wanted to give you all an update on where I have gotten with regards to this issue, even though I ultimately do not have any further information to share on how this issue can be addressed, or whether or not it will be addressed.
I have been working with a BizTalk Escalation Support Professional for the last few weeks trying to get a resolution, or hotfix, to address this issue. To date, all I know is that the BizTalk Development Team has been assessing the issue and has not as of yet determined whether or not to address it. There might be some sort of hotfix or workaround to address this problem. It might be something that is addressed in BizTalk Server 2009. I simply do not have any more information about how Microsoft plans to deal with this problem.
I will submit another posting to this thread once I finally do have more information regarding this issue. I wanted to make sure, though, that this didn't simply turn into another thread that goes stale because the resolution was so long in coming that no updates were ever posted.
It is too bad, though, that I do not have more to share up to this point.
Jeff - Just a quick status update here... Microsoft has been working on a hotfix for this "bloated xml" issue and is close to finalizing it.
It'll be available for public download soon.
Gerard - A fix has been released for this Bloated XML issue. It als results in good performance of the splitting.
Please contact Microsoft support for the Hotfix. We can dig up the KB article for the same if Support team cannot locate it
regds
Ravi - Hi,
Could you post the KB article for this particular Hotfix?
Thanks,
Mark - I have written a simple Orchestration for the 3 Types of 837's to split claims dependent and subscriber level into individual xml's and then I preserve all the header and other information as is. Then I have a helper map that fixes the HL numbering. This approach has taken the dependency on Microsoft to release a patch for this very small issue.
Let me know if anyone needs ideas on the ODX to fit their split requirements @ technoamit@gmail.com
-amit
amit kumar - Kb article for this Hotfix is 967945.
Thanks
Gyan
- Proposed As Answer byGyan Prakash[MSFT] Friday, March 27, 2009 8:31 AM
- Is there a similar hotfix available for BTS2009? We are urgently trying to upgrade to BTS2009, but the bloated XML generated by the EDI Engine out-of-the-box is hindering us. We would like to start preparing for v5010 of the HIPAA schemas, whether they are currently available or not. However, because of the excessive XML generated during the translation of EDI documents in BTS2009 as compared to BTS2006R2, the severe loss in performance we experience cannot be justified. Please let me know if there is a similar hotfix for BTS2009, if one is on the way, or if there are no current plans for such a BTS2009 hotfix.
Thank you,
Jeff- Edited byJeff Erickson Thursday, November 05, 2009 6:49 PMAdded more information
- Hi,
In BTS2009 there is fix for Hipaa5010 that includes this fix as well. It's in Beta stage right now. you can download it from here:
http://blogs.msdn.com/biztalkb2b/archive/2009/07/10/hipaa-5010-public-beta-available.aspx
Thanks
Gyan
If this answers your question, please mark it as "Answered".
