Exporting Records Using KTM Medical Claims Add-on & Kofax Export Connector

Kofax provides an add-on pack for their Transformation Modules product to handle CMS-1500 (formerly HCFA) and CMS-1450 (alternatively, UB-04) medical claims forms called the KTM Medical Claims Add-on package. Related to this package is the Kofax Export Connector for Medical Claims. This Export Connector allows for the data captured off of said forms to be formatted in the HIPAA-compliant EDI/ASC X12 837 formats (to be exact, 837 Professional for the CMS1500 and 837 Institutional for the UB04).

While it is a mostly useful tool, Kofax made one assumption with the Export connector that is both extremely puzzling to me and difficult to work around if one needs to: They assumed users of the connector would want to export every document’s EDI data into one file per batch. This creates two problems:

  1. If the KTM Medical Claims add-on project is used to support only one batch class (with the forms existing as Document types), there is potential for both Institutional- and Professional-formatted data to end up in the same file. EDI verifiers and parsers generally don’t accept this, due to the header information for each format being different
  2. Since each document in the batch must be registered by the Export connector, the final output file is not generated until the CloseScript event is fired.

Problem 1 can be somewhat mitigated by creating separate batch classes for the CMS-1500 and UB-04 forms, but that comes at the price of not being able to use KTM’s advanced separation capabilities to cut down on pre-scan manual work. Assuming we don’t want to discard a significant part of what this product does, we need a way to generate separate EDI files, at least to the level of one file per form type.

One way to accomplish this is to leverage the advanced routing capabilities available in Kofax Capture 9 and higher when Kofax Transformation Modules (KTM) is installed. In KTM’s scripting interface, the Project-level script allows us to handle the Batch_Close event. Here, we can set the KTM_DOCUMENTROUTING XValue for each of the documents in the batch. Using the naming functionality along with the document type name (found in the XDocument.ExtractionClass variable), we could dynamically group all CMS-1500s and UB-04s into their own separate batch classes.

Alternatively and if more granular error handling is desired, each document could be separated into its own batch. Kofax Capture provides the ability to process documents as individual batch instances natively, but if you don’t want to be dealing with each document individually until you need to Export them, using scripting to route each document individually post-Validation should be the preferred direction to follow:

One possible way to separate a batch instance with many documents into many batch instances with one document each

Since we have separated the original batch into individual batch instances, we have mitigated Problem 1 and achieved our goal of releasing individual EDI documents. This leaves us with one last problem, though – what do we do with the released data?

We could build a sweeper application to pick up the file and send it to whatever destination system it needs to reach (WebSphere or another EDI validation tool/parser are most common), but how do you recover if the document’s image releases successfully but your EDI file fails Validation within the destination system? Ideally, what we’d like to do is keep both data and image release processes contained within Kofax Capture, so if we need to push something back to a previous step, we don’t have to go through the entire (and possibly expensive) process of cleaning up the released image/data and re-processing of the form in question to do it.

The best thing to do here, assuming the data release is a repeatable call that cannot be easily repealed, is release the data as a prerequisite to the image’s release in a custom Export connector. Keep Problem 2 in mind at this point, though – the EDI file is not generated until CloseScript is called for the Export Connector for Medical Claims, meaning we cannot actually release the data or image until we hit CloseScript in our custom Export connector. At that point, it is possible to pick up the text file, read its contents, and send them on their way to the destination system, after which the image can be sent to its respective repository as well.

To put it bluntly, this is not how Kofax Export connectors usually work, in reference to either the custom Export connector proposed above or the Kofax Export Connector for Medical Claims itself. The good news is we have the tools and ingenuity necessary to work around the problems this presents, in order to deliver a solution that gets the job done both correctly and in the most supportable fashion possible.

Jesse Kinney
Support Engineer
ImageSource, Inc.