One of the tricks to getting custom file names out of the HIPAA Accelerator is to add an extra component in the orchestration.

These are the steps I took to get a custom filename generated from the HIPAA_EDI adapter.

1. Created a property schema with a element defined as a string and have it be a context property
2. Create an schema with the delimiters that will be defined in the HIPAA_EDI send port with an element that repeats 30 times
3. Create both a flat file send pipeline and receive pipeline using the schema defined in step 2
4. Create a single element and associate this element with the element defined in step 1
5. In the orchestration, assign a variable a time
6. From that assigned time do three things in a message assignment
1. Assign the BHT_05 from the variable 
2. Assign a string variable the date as a string in HHMMSSDD format
3. Assign the message with the context property created in the property schema
7. Create a Correllation Type set to the context property
8. Create a Correllation Set defined from Step 7
9. Initialize the Correlation Set in the send shape
10. Have a recieve shape using the message created in step 2 and have a following correlation set
11. Assign the recieved message to a new message and assign the FILE.ReceivedFileName to whatever you want the filename to be
12. Send the newly created message out
13. Deploy
14. Create a temporary folder that you assign the HIPAA_EDI adapter to write to
15. Assign a recieve location to the the folder created in step 14
16. Use the recieve pipeline created in step 3
17. Create a send port using the pipeline created in step 3
18. In the file name use %SourceFileName%
19. Set the directory to the real directory where the HIPAA file is to be placed
20. Bind the logical ports to their respective physical ports

A client I have been working at has a very large message (150 mb message) that needs to be passed through BizTalk from the results of a stored procedure.

I was continually getting System.OutofMemoryException in the event log.

I read through this article and also this one both sites options did not appeal to me.

Another option is to use custom XSLT instead of the code inside of the map (which seems to stream the entire message into memory).

The solution is actually very easy:

1. Create your map
2. Inside of the mapper, create all of your links, functiods and everything
3. Validate the map
4. Take the XSLT that is generated and add it to your project
5. In the mapper grid, point to the xslt (by following these instructions)
6. Deploy it

It does not process the file very quickly, but it does not error, and I get the output.

I just attended the first (of I am sure) many HiMSS conferences. I am kicking myself for not going to them sooner. I got to meet a few friends that I have been in contact with, and other fellow bloggers, well I wouldn’t call him just a blogger, but that is another discussion. I also met with some guru’s that offered a lot of insight!

There were great sessions for a whole spectrum of Health Care Professionals, from developers to IT Pros, to management for both the partners and more importantly customers. There were a lot of great things that partners had presented and even more cool things that Microsoft has in store. I did enjoy the other perks that were offered to the attendees, especially the sessionitis I seemed to come down with!

I was very interested in the Connected Health Framework (CHF) and will be blogging about my experiences with my take on best ways to implement the CHF to add additional value to the development life cycle. I don’t think that the CHF is readily available (at least I could not find it), however, as soon as it is published, I will be adding a few entries to my blog.

There are great things going on, and I am glad that I got to be an attendee there. Hopefully I can meet up with you again next time.

I am heading up to Redmond for a couple of conferences:

and

Let me know if you are going, it would be great to meet you! 

Back in the day (BizTalk 2002) the incremental numbers in the HL Segments were something that an average developer did not need to worry about.

However, with newer versions comes enhancements, built in tools that make it easier and quicker to develop the same solution. HL Numbering however is actually harder. Microsoft has decided that it is not going to modify any of the data inside of the Transaction using the HIPAA adapter. I had to create a process that would do the numbering.

The trick was to get the numbers to increment regardless of where in the transaction the work was being done. I used some simple C# code to create a constant variable and increment the number.

I created a self contained orchestration that would accept a Claim (institutional or professional) re number it and then send it back. I did this so I can do my mapping logic and then finally plug this in.

The example here has the professional and institutional schemas included, but you would most likely have it in a seperate project that would contain the actual schemas, but I thought that it would be easiest to have it so that you could at least see the map in action.

You will have to add the projects as references to your professional and institutional projects, and then use a call orchestration shape and send the correct claim, and you will be ready to go.

Here is a list of the behaviors that I have found when using the custom pipeline component vs the adapter for receiving and sending data:

Pipeline

• Allows multiple recieve ‘locations’ for a single party, where you define a receive location that has the configuration information and then multiple pick ups and drop offs, where they can be any adapter (file, ftp, http, MQ Series, etc.) can be used
• Ability to use Send Port Groups (archiving is an example of this usage)
• Does not check the interchange control number for duplication per party
• Data that is recieved or sent, is not archived in the location defined in the documentshome location in the parame table
• No information is logged to the audin and audout tables, so the HIPAA_EDI reports in HAT is not available
• Promoted properties in the WPC schemas are not invoked

Adapter

• Only a single port can be defined for receiving and sending
• Copies of both edi and xml data is stored in the documentshome location
• Interchange control number checking is done
• Information is stored in the audin and audout tables, so the HIPAA_EDI reports are accessable
• Using the DefaultXML pipelines; promoted properties can be used for correllation/filtering/orchestration usage

I have put together a really simple example of both usages, so differences can be seen.

Instructions:

1. Deploy the Solution
2. Using the Deployment wizard, import the Binding.xml file
3. In the Management Console, in the HIPAA_EDI adapter, in the properties of the Send Handler, set the the Party to Us
   
   
4. Restart the HIPAA service
5. Enable the Receive Locations
6. Start the Send Port
7. Drop the file into the ..\input directory and see if the file is produced in the ..\output directory
8. Notice the following information in HAT - HIPAA_EDI Reports
   

Here is the list of changes that need to take place if you are having issues either in validating or deploying the WPC schemas.
Click below…

1. Stop the HIPAA Service
2. Delete all files (normally the .wrk and .eif files) in this directory C:\Documents and Settings\All Users\Application Data\Microsoft\BizTalk Server 2004\HIPAA_EDI\Subsystem\EIF
3. Start the HIPAA Service
4. in the {Program Files}\Microsoft BizTalk Accelerator for HIPAA 3.0\HIPAA_EDI\Subsystem double click on the compeif.exe and wait for it to complete
5. Open up the parame table in the BizTalkHIPAA_EDIDb and change the column repolock to NULL by pressing CTRL+0

You now should be able to re-validate or re-deploy the schemas that were causing the issue.

Many a client has requested to have custom filenames using the HIPAA_EDI adapter.

I originally planned on using a custom ASM pipeline component and setting the ghost port to batching, and within the orchestration setting the RecievedFileName.

Found out that when that happens, no file is created, also, no errors are created! This really smells like a bug, as there is no documentation on this!

After contacting Microsoft, and submitting a ticket, this is the response I got back:

The HIPAA pipeline is not architected to support batching. It simply does a one-on-one translation from XML to EDI and that’s it.
The batching mechanism is depending on the data in the audout table and the HIPAA pipeline does not persist any data.
The only way you can create outbound EDI batches is via the HIPAA EDI adapter.

I ended up having to re-engineer the process so that (written about here), by single threading the entire process, files do not get batched together and files can be accounted for.

For those of you who got used to the Covast bells and whistles that come with the Covast EDI adapter, and then come to another EDI tool interfacing with BizTalk, namely the HIPAA accelerator, made for Microsoft by ?????, there are quite a few nice things missing. One of those things being the ability to clear the report so you are not flooded with ’stuff’

Another BIG issue is that while testing, it would be REALLY nice to be able to send the file through a few times to make sure that the file works correctly. There is NO way to disable the duplicate interchange control checking.

Here is the sql code (run against the BizTalkHIPAA_EDIdb database) to clear out the report, and also allows you to run the same file through the HIPAA accellerator again:

delete from audin
delete from audout

Bye the way, you will want to go into the %documentshome% directory and delete/archive the files that are there, as the temporary files will prevent the adapter from writing new ones.

Another option is to use the custom HIPAA DASM that does not check for duplicate control numbers, namely because it does not check the audin and audout tables.