Jan 262007

After recieving a few requests from a few people from this post I finally got time to create the proptotype.

I first started by creating a property schema and internal schema to use as an initilization correlation set.

I also created a flat file schema that would start the process of extracting the information. 

The next part is to have a map that takes the base schema and extracts the isa id, click qualifier, look gs id and the control number. The below picture has all of the functiods and their subequent arguments.

So lets take a look at the orchestration that does all of this work:

The first thing that happens is that the EDI document gets parsed against the flat file, pilule I have receive pipeline that parses the file for this orchestration to pick up.

It then creates the Who Is message, which is the sender id (ISA qualifier, ISA Sender Id, Control Number, GS Id) is the first thing that I extract, also, I store the filename in the crossreference table for use in the flat file message later on. The following code stores the data.


Then the message is sent to the HIPAA accelerator, while the accelerator is starting to parse the file, I initialize the correllation set by sending the whoIsMsg to the message box and immediately pick it up again.

Now the orchestration is waiting to pick up the subsequent HIPAA messages (well, for at least for 10 minutes), it then picks up the XML version of the HIPAA document. It then creates the flat file and assigns the filename from the original message using the following code:


Through my contact page you can get a copy of the code. Please follow the instructions in the readme.txt so that you can implement the Cross Referencing funtionality along with importing the 837 schema, as the code needs to have those pieces imported.

Jan 232007

Drafting from Tom’s explaination on Cross Referencing, I wanted to step you through how I was able to use the functionality that is built into BizTalk and save myself a lot of coding.

Scenario: Take original filename of an 837 transaction, look up the actual pickup date based on the filename from a table and place it in the encounter staging table for every row that represented a claim.

Issues: HIPAA accelerator does not retain file name

There is no place in the data that I can use to pull the recieved date from within the data content. Only context data, and even at that I have to refer to issue point 1.

Oh, ya, these 837s were all custom 837 messages coming in.

I created a process that picks up the EDI file and starts an orchestration where it extracts the ISA05, ISA06, ISA13, and GS02 using a flat file pipeline (I will explain how I do that sometime) so I can retrieve the filename from the context of the message. Having that, I call a seperate orchestration that takes the enveloping information and filename and looks up the file recieved date. Once I had that file received date, I really did not need to know the filename anymore, I had the enveloping information in the file, I had the received date, now all I needed to do was store it and retrieve it.

The first thing I did was set up the necessary XML documents to setup the XRef tabes in the BizTalkMgmtDb. They are as follows:





Since I am not going to ‘preload’ the data into the database, it is going to be built on the fly, I did not create the ListOfIDXRefData.xml.

Now to the exciting part. In order to insert this information into the tables, we need somehow to actually load it. Oddly enough there is a executable in the BizTalk folder that will do just that: BTSXRefImport.exe

Tom has this really nifty (is that a kosher word?) batch file that will load the data, but I need to learn to crawl before I start running with this.

So how does the BTSXRefImport.exe import the data and set up the relationships between these three (four in Toms case) xml files? There needs to be a setup file that is called as an argument. Here is the setup xml file I used and in the comments, you can see how it is supposed to be invoked c:\>btsxrefimport -file=setupfile.xml

Now I need to write the data to the XRef table in an orchestration, right after I get the response from the stored procedure. The first thing I need to do is in this orchestration, I need to add a reference to the Microsoft.BizTalk.CrossReferencing.dll (located in the BizTalk install folder). I need to create my unique key, I do that by concatonating the ISA05,06,13, and GS02 together and then putting the string version of the date as the second argument. My logic is as follows:

So now I have the data in the XRef table, now all I need to do is extract it in the map.

And the arguments to the Get Common ID functoid are as follows:

So to resolve the issues, when the file is originally picked up, I go and extract the envloping information, look up the recieved date and store those two bits (enveloping information and file pickup date) of information and then send it to the HIPAA accelerator.

Once the HIPAA accelerator deserilizes it to its custom 837 schema, I have seperate maps for each provider that maps it into the standard schema, and then there is the final 837 to encounter map that I then use the Get Common ID value and by concatonating the envelope fields together, I can get the recieved date and put it in the staging table directly.

Jan 172007

Unlike BizTalk, the HIPAA EDI Subsystem group needs to be set up as a domain group when setting up a distributed system. Local groups will give this error about invalid characters, and all places that log the data, event log, log file, do not explain any further the issue when going thru the configuration of the HIPAA EDI accelerator.


Update: Don’t bother trying to install a distributed enviornment when running under a NT4 Domain group, yes you can get BizTalk to communicate successfully with a remote SQL Server, but the HIPAA Confuration Framework will not validate it against an NT4 Domain.

Jan 152007

I am sure some of you who happen onto this blog have worked with the old Mercator or WebSphere TX product.

I just spent the last few days working on upgrading a 6.7 solution to 8.1. I was amazed how I was still able to remember all of the command line switches/card overrides after a few years of not dealing with it.

I just want to tip my hat to all you who are still working with that product. I wish that the mapping capacities that are in the mapper would be present in the BizTalk mapper.

Anyway, just wanted to put a note out there that I was surprised that either the product must be near perfection because there were not many new features from two versions ago, except a debugging utility in the mapper, and it deals with XML a little differently.

Update: I just wanted to put a comment on this entry about the relationship between BizTalk and Mercator. I have been in some meetings with the product team regarding a conversion tool between Mercator and BizTalk. I am not sure that there were any developments by Microsoft towards that. There were a hurdles that largely prevented this from happening. I will list a few that I thought of (maybe not to Microsoft, but ones on my own):

  1. Run Maps: there is no functionality that could be replicated in a BizTalk environment.
  2. Mapping: Custom functions in Mercator have no direct correlation to XSLT that BizTalk uses.
  3. Orchestrations: The integration flow designer and Orchestrations don’t have common conversion features.
  4. Databases: Mercator creates in the adapter an insert statement, BizTalk uses SQLXML

A friend of mine has created a type tree to schema conversion tool that can be accessed here:


I like it, but with BTS 2006, it is almost as easy to create a new schema using the flat file wizard, and I would not use it for XML documents.

Jan 032007

A recent question was asked me  as follows:

How to change the Segment Terminator in the HIPAA 837 schema to ‘~’ (tilt)? I think in my schema currently I have CF/LF. I need to change that to ‘~’. Currently my output comes like this.

ISA*00*          *00*          *ZZ*1234567        *ZZ*7654321        *070129*1247*U*00401*000010247*0*P*>


I need the output like the following

ISA*00*          *00*          *ZZ*1234567        *ZZ*7654321        *070129*1247*U*00401*000010247*0*P*:~GS*HC*1234567*7654321*20070129*124745*10247*X*004010X098A1

This is actually not set in the schema, cialis but in the port configuration, discount when you set up the send port you specify a wrap segments, patient along  with the original segment terminator

In this case you want to have Wrap Segments set to No, which will not put a CR/LF after the segment terminator.

After you make the change the setting here, you need to restart either the HIPAA service or the EDI service.