On the provider side of healthcare integration, HL7 (particularly v2) is a critical message type to understand. While it is standardized and heavily used by various EHRs/EMRs, it’s used in slightly different ways. There are efforts to further standardize and normalize its use across the board (such as with v3/FHIR), many EHRs and EMRs continue to use 2.x messages. Common HL7 messages include admissions/transfer/discharge (ADT), scheduling (SIU), lab orders and results (ORU, ORM), and medical reports (MDM). Choosing the right HL7 or EDI Software platform can be challenging.
Some of the challenges of HL7 2.x messages include:
The ability to add non-standard custom segments or additional data anywhere in the message (whether they are completely custom “Z Segments” or other segments that aren’t typically part of the message, such as IN1 segments in an ADT message to include additional insurance information).
A myriad of…
We heavily use the BizTalk Deployment Framework to aid in the deployment of simple to complex BizTalk solutions. One of the greatest benefits is the ability to run custom deployment tasks and scripts. In previous blogs we have shown how to run a custom post deployment scripts in BTDF, today, we will show how custom scripts can be used to conditionally import a binding file during BTDF deployment.
Recently while working on a Biztalk project there was a number of suspended instances that were appearing in the Biztalk Admin Console, after some investigation in to the cause of these suspended instances it was determined that the orchestrations were failing because of uncaught exceptions being thrown from within the orchestration’s exception handlers.
The cause of these uncaught exceptions was eventually tracked down to the following line of code inside of a message construction shape.
To give a little bit of context to the code snippet above, the xmlExceptionMsg object is an orchestration variable of type System.Xml.XmlDocument which is being used to construct a BizTalk message and the LoadXml method is meant to take a string of text which is valid Xml from which that message will be built.
However, it was this method call that was raising the exception that subsequently caused…
I have often run into the same errors in my time developing BizTalk HL7 applications to interface with various HL7 EHR systems. These errors stem from using out of the box BizTalk maps to transform HL7 messages using the Microsoft BizTalk Accelerator for HL7. Here are two of the errors that I have come across that others might have too…
On one of our Dell Boomi projects we had a simple task which was to create an XML profile by importing an XSD file that was generated using BizTalk‘s schema generator. While this task seemed trivial at the time, when importing the file that was provided the following error was generated: “Error Occurred: Error on line 1: Content is not allowed in prolog.”
Tom Babiec wrote a great blog a few months back on inserting multiple parent child tables in a single stored procedure. We use this technique a lot in our data integration work, and it’s proven to be very robust in many contexts. The SQL procedure outlined in that blog is useful not just for BizTalk, but generally speaking for ADO.NET and other applications trying to load multiple rows into SQL Server for multiple parent child tables. However, when dealing with larger datasets (and as the table grows), we’ve noticed some degradation in performance. In some cases, we were seeing variances of 30 seconds to 10+ minutes for loading the same exact data set on the same database. We tried a few different options, including forcing a recompile of the stored procedure between each load
, but this did not solve…
This error is typically harmless, but can result when the XML Disassembler encounters an empty Envelope message instance that’s formatted like this:
instead of this:
BizTalk chooses to make a semantic difference between these two instances, and process the second one fine (publishing no messages), but raising an exception like this for the first:
There was a failure executing the response(receive) pipeline: “…” Source: “XML disassembler” Send Port: “…” URI: “…” Reason: Unexpected event (“eos”) in state “processing_header”.
This can happen particularly when using an XmlProcedure or XmlPolling from SQL – if the resultset is empty, the adapter will publish this message. While this behavior may be desirable (and can frequently be avoided by ensuring you have good Data Available statements on your polling ports, and only call XmlProcedures with valid parameters/at valid times), it can also generate a lot of alarming errors….
Dell Boomi’s AtomSphere integration platform provides a simple, yet very powerful feature – the ability to utilize temporary, and semi-temporary files system folders. Coming from a Microsoft BizTalk integration background, the ability to store documents to a temporary directory is a huge advantage over storing into a database such as the BizTalk MessageBox, especially with larger files. While BizTalk does provide the necessary mechanism to save files to a local folder through the use of the file adapter, Boomi provides an easier way of achieving this.
The Tallan Integration Practice heavily utilizes Azure Infrastructure as a Service (IaaS) virtual machines for quickly setting up isolated environments for prototypes and BizTalk development environments. However, with so many virtual machines it is often difficult to remember to shut them off when not needed. With Azure’s Automation features, we can setup a scheduled job to shut down non mission critical VM’s, saving on hosting costs.
MSDN provides an example of INSERTing large data into SQL Server, leveraging the WCF-SQL adapter’s built in FILESTREAM capabilities. However, it’s also possible to leverage the transaction enlisted by the WCF adapter in a custom pipeline to pull FILESTREAM data out of SQL Server more efficiently than the more common SELECT … FOR XML query which simply grabs the FILESTREAM content and stuffs it into an XML node in the resulting document.
Imagine, for example, you had a large document of some sort (XML, Flat File, etc.) to store in SQL Server that BizTalk would need to process from a FILESTREAM table defined like so:
The tradeoff here is losing the typed XML data in favor of more efficient storage and access to larger file objects (especially when the data will, on average, be large). This can make a vast difference if you have…