Now that COVID-19 has completely derailed any strategy and subsequent plan to achieve Q1 goals and we are all continuing to adjust to the ‘new normal,’ we’re thrilled to present our curated list of Tallan’s top viewed blog posts of 2019.
It’s no surprise that the top two posts are both about developing in an Azure environment. Microsoft Azure was awarded a highly sought after contract from the U.S. Department of Defense (DOD) in October of last year. You can read the statement published by the DOD here.
Importantly noted in the statement, is that the DOD has not aligned with any one vendor or provider for their cloud strategy efforts, “Today the Department of Defense has taken another step forward in the implementation of our Cloud Strategy with the award of an enterprise general-purpose cloud contract to Microsoft. This continues our…
BizTalk has long been one of the most complex and powerful integration platforms out there. With BizTalk, developers and business users alike have been able to create powerful inter-organizational integrations to automate complex business processes. While most BizTalk developers should be familiar with the basic features of the core BizTalk components such as schemas, maps, orchestrations, pipelines, and receive/send ports the same cannot be said for some of the more hidden and/or complex features. If used properly these features can greatly reduce the amount of development overhead for more complex integrations. One of these features is the XmlPolling option in the WCF-SQL receive configurations.
Over the past several years, there has been a lack of clarity about Microsoft’s integration roadmap. Various integration tools have been offered, rebranded and renamed, and ultimately retired. With a lack of a published roadmap, it is hard to make an informed investment into an integration platform that needs to meet today’s needs and still be relevant into the future.
Since 2000, BizTalk has been around to meet critical on-premises integration needs. Many customers have implemented complex business-critical solutions based upon BizTalk. With the migration to the cloud and the advent of Integration Platforms as a Service (iPaaS) offerings, there have been concerns about the future of BizTalk and its role in Microsoft’s integration strategy.
A recent announcement by Microsoft’s Jon Fancey, the Azure Integration Services PM Lead, attempts to clear up some concerns about Microsoft’s integration roadmap and lays the foundation for what…
Need a way to test your systems without compromising patient data? Creating Electronic Data Interchange (EDI) test files from scratch can be an extremely time-consuming option. This leaves many searching for downloadable sample files that often contain only the mandatory loops and hinder the scope of your HIPAA EDI testing.
Fortunately, today’s Healthcare EDI professionals can find an EDI Management Platform to help alleviate their HIPAA compliance headaches.
X12 Studio EDI Toolbox is an EDI development toolkit (available as a free trial download) with a wide range of features that are essential to simplifying the EDI development process. There you’ll find the HIPAA Test File Generator which can generate various sample EDI files, for any healthcare EDI transaction type, in the blink of an eye.
This post will demonstrate how to generate EDI test files in X12 Studio EDI Toolbox
1. The process for utilizing the HIPAA Test File Generator is straightforward. To start, click on the “HIPAA Test File Generator”…
The Electronic Data Interchange (EDI) consists of a file in a specific format that represents data exchanged in a transaction from supply chain to healthcare. EDI 835 Claim Payment transaction provides payments information in reference to claims in EDI 837 Healthcare Claim format. The details include transactions such as charges, deductible, copay, payers, payee, etc. The information is stored a hierarchical structure. The standard of EDI format is well defined and the complexity can be very overwhelming. Additionally, we do not want this high degree of detail slowing our processing time.
One of the problems that enterprise systems face with EDI is file size. A single EDI 835 may contain multiple claim records and the quantity of claims in a single file can make it very difficult to process the file. Systems are often bogged down when dealing with a very…
The X12 HIPAA transaction set is used across the healthcare industry to transmit claim, enrollment and payment information. Given the importance and ubiquity of these EDI files, you might assume that translating them from ANSI to a relational database format would be well-supported with a range of options.
In practice, a task as common as parsing a claim or encounter and storing it in a database can quickly escalate into a significant problem.
One solution we’ve seen involves archiving a snapshot of the EDI file using filestream storage. This can satisfy some retention requirements, but provides little in terms of fine-grained tracking or analytic capabilities.
A more complete approach is to parse the X12 file into its discrete elements and store them in a relational database. The ideal solution captures the full extent of the EDI transactions while also applying a reasonable leveling of flattening to keep in the number of table joins under control.
BizTalk360 is a browser-based monitoring application for Microsoft’s BizTalk integration platform. The out-of-the-box monitoring functionality can be difficult to navigate both for new users and experienced admins, and is complex and time consuming to set up for multiple users with varying access rights. BizTalk360 combines the Admin Console and Event Log, with some added analytical and notification functionality, to create an easy to navigate operational tool.
In this overview of basic BizTalk360 setup, I will assume you have a BizTalk application already deployed that contains at least one receive port and send port. Although there is a huge amount of configuration and monitoring that can be done through BizTalk360, this article will focus on initial configuration and simple environment health monitoring.
One of the great new additions of the recently released Feature Pack 1 for Microsoft BizTalk 2016 is a REST API, which can be used to administer BizTalk Server. Longtime users of BizTalk may have experience with using ExplorerOM.dll or WMI based scripts to manage their BizTalk environment. The REST API introduced in Feature Pack 1 provides a more flexible alternative, including a Swagger definition providing rapid implementation of an application to consume the API. In this post, I will walk through the process of installing the API as well as using Swagger to generate a C# client and demonstrating a simple command.
There are many situations where we need to deploy WCF Services that we can use to interact with BizTalk, but if you’re constantly deploying to new systems, the process of manually creating and configuring them can become very time consuming and tedious. Leveraging the abilities of the BizTalk Deployment Framework (BTDF) we can automate this process along with your typical BTDF deployment.
In this guide we’ll step through how to configure BTDF to build the deployment of our existing WCF Services into the installer which BTDF creates for deployments.
In order to follow this guide it’s assumed that you have the following prerequisites:
A BizTalk solution and environment with BTDF installed
Already deployed WCF Services which you wish to replicate via deployment on the same machine
A basic knowledge of BizTalk, WCF, and IIS
First up we need to move our services into our solution folder. Simply…
Microsoft has provided us a lot of nifty new features with BizTalk 2016, and among them are a few different ways to control the various application settings while importing and exporting applications. We’ve discussed some of these new additions in a previous post, but today we’ll talk about a new checkbox which allows us to control whether or not the tracking settings will be imported.