You will need to enabled batching, you can learn how to do it here:
http://www.microsoft.com/technet/prodtechnol/biztalk/2006/library/hipaa/1072c23e-8010-41d2-9a57-56b23bd575ae.mspx?mfr=true
When you use the single schema, it is designed to represent a single
transaction:
http://www.microsoft.com/technet/prodtechnol/biztalk/2006/library/hipaa/2b1e1bf6-e5e1-4a4e-b093-5f29d08db40b.mspx?mfr=true
So your map will need to take 10,000 records and map it to the single
schema, then send it to the accelerator, the next 10,000 records then will
be mapped and then that message is sent to the accelerator.
The accelerator will then batch the messages together.
Hope that this helps,
Eric
http://blog.biztalk-info.com
"Todd G. Hetrick" <ToddGHetrick@[EMAIL PROTECTED]
> wrote in
message
news:10531EDD-88E1-4063-8513-2947137C1291@[EMAIL PROTECTED]
> Hello Everyone,
>
> I am kind of new to this discussion group, so please be patient with me.
> Here is my scenario...
>
> I am currently working on BizTalk Server 2006 solution that utilizes the
> HIPAA Accelerator v3.3 for a client who p***** Benefit Enrollment
> information
> via an 834 to insurance carriers. Sometimes, this information can have
as
> many as 10000+ insured records... The requirement states that for every
> 10000 records, you must create a separate ST SE segment within the GS
> segment. Currently, the internal client XML format uses the following
> structure (obviously, it more complex than this but this is the meat of
> it):
>
> <file>
> <record>...</record>
> :
> :
> <file>
>
> I have created a map that loops the <record> node to the <TS834A1_2000>
> node. I have managed to satisfy all the logic within carrier 834 spec
> except
> for the 10000 record limitation. I am kind of stuck now on how to make
> this
> happen within the map. Also, I cannot break this file up into multiple
> 834
> EDI do***ents. The end result must be one 834 with multiple ST SE
> segments.
>
> Does anyone have any ideas on an approach? It seems to me that other
> folks
> would have come across this since the 10000 record limitation appears to
> be
> relatively standard.
>
> Please let me know if I need to re-articulate this scenario to make it
> clearer. Thanks in advance for your input.
>
> --
> Thanks,
> Todd G. Hetrick
|
