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).
Are you tired of separator sheets? Tired of wasted paper and countless hours of flipping through pages and inserting a barcode sheet at the start of a new document just to take it out after the batch is scanned or leave it in the batch and have more paper to store? Why not have the computer do the work for you? That’s the idea behind the Project Planner module in KTM. There is a standard separation functionality built into KTM that works very well on structured and semi-structured documents but when you have more complex separation rules the Project Planner component of KTM is what you need.
In KTM there is a nifty feature to search the entire document for a date field. It will recognize all dates existing on the form and with some other snazzy logic you can find the date you are looking for. If it is nearby the word “recieved”, then you probably have a recieve date. Easy, right?
Okay, sometimes dates get a little more tricky. “
3-17-20011” and “
MAR 17, 2001” are all valid date strings. Any of those formats could be found on your document. In KTM there is a nifty feature to search for the string “
MAR” and replace it with a “
3” when searching for dates. You use it in your locator’s regular expression. You can setup your own dictionary of months to look for “
March” or “
Mar” (or “
Marzo” if you need internationalization).
Here’s the gotcha. I recently found text in an OCR’d document like this: “
19 NOV2008“. It’s a bit of an odd string. The OCR engine didn’t think there was enough space between the “
NOV” and the “
2008” to put an actual space character in the ORC’d text. So, I can read it, but KTM can’t. The nifty feature to search for the string “
NOV” fails because it is only looking at whole words, those with whitespace on either side. Unfortunately, there is no option in the KTM dictionary setup to change this.
Here’s the fix. Modify the default KTM regular expression from this:
You can now make the space character optional in your regular expression search. You are no longer using the month dictionary, but that’s okay. This logic is only to locate a date, not translate it from a string to a date when found.
I have been working with the Kofax Capture product for over ten years now. To prove that, let me tell you the configuration on one of my first installs. I remember setting up a Bell and Howell 3338 scanner (you know, the one that required a cherry picker to get out of the box and on to the desk) with the Kofax KF board and Kofax Capture version 2.x. Ah yes, I look back fondly on the old days of deploying a scanner with the Kofax card and software. I know it has been out for a while now, but I recently started working with version 9 of Kofax Capture and I am pleased to say that they have finally addressed some of the Kofax gotchas that have been plaguing us for years.
For starters, they made client deployment 100% easier by creating the MSI package. I can’t tell you how many conversation I have had with client admins that go like this:
Me: No we don’t have a SMS or other type deployment package you can use, but you can make your own.
Client Admin: (Furrows brow) Huh?
I will be much happier when those conversations are a little less embarrassing. Now the workstations can be deployed using Microsoft SMS, Group Policy, IBM Tivoli, Symantec Altiris, HP Openview, or whatever deployment suite you use. Kofax has only tested SMS, but Continue reading
I recently was asked to help with a client’s KTM (Kofax Transformation Modules) project, because they were not pleased with the percentages of valid and/or correct extraction fields. My first question was, “Are you using subclasses?” The answer was, “No.” Subclassifying your top forms is an easy way to greatly improve your extraction results.
What I mean by that is instead of trying to use a single locator to find data from all of your documents with a “one size fits all” approach, you can use subclasses to first classify the document and then tune your locators specific to that form to look in a precise location for the information. For example, let’s say you need to find a “Case Number” off of all of your forms. Some forms might have the word “Case Number” above the text you need to extract. Others might have the word “Number” to the left of the data. Another might not have any text around the data to key off of at all. It’s difficult to add enough rules in one locator to catch all the possible scenarios. Furthermore, there are times when adding rules to help find data on one form will actually give you negative results from another. Subclasses can help by allowing you to create a specific locator to zero in on the information that you are looking for. Continue reading
My current project has a requirement to do several Oracle EBS validations and lookups from the Kofax KTM validation window. For example, one requirement is to present the validator with a list of Suppliers. Another is to check for a duplicate invoice number in EBS. I can easily add additional methods as needed.
Kofax KTM provides Win Basic scripting language that can accomplish some of this, but it’s difficult to use compared to modern programming languages. After a little research I discovered it was feasible to create and call methods in a COM object from KTM Win Basic. This meant I could expose a C#.NET dll via COM Interop but have all the power of any version of the .NET framework and Microsoft Visual Studio available to do the heavy lifting.
My C# methods return either arrays or booleans back to KTM where I then use the Win Basic language to present results to the validation user. I can debug my C# code by attaching to the KTM Project Builder exe while running validation tests.
Setting up the C# Class
The first step is to create a project in Visual Studio and set up a class to contain the methods you will call in KTM. The prefered method is to use interfaces in case you need to change the methods without breaking the inferface. Here is an example. Continue reading
Every company no matter how big or small has an Accounts Payable department. It may be as small as one person or it may have ten, fifteen or more people. For medium and large companies there are problems that arise with the data entry of all that invoice data and the tracking of all those invoices through the approval cycle. There have been many different methods that companies have created to try and handle both which still lead to missing/late invoices and mistakes during data entry. Methods such as logging the invoices either in a spreadsheet or manually on paper are just some of the types of methods that companies have tried to keep track of where invoices are and how long they have been waiting to be paid. Maybe there is a better way.
Kofax KTM in conjunction with Oracle I/PM provides a solution to these two issues. Kofax provides two software packages to scan and then process documents like invoices. KTM is the processing part and is able to OCR and identify the key fields on an invoice no matter where on the page the data is located. KTM can also validate some of the data against the ERP system the company is running. Fields like PO Number, PO Release, Vendor Name, Vendor Address, Vendor Pay Site, Vendor Payment Terms and other fields can be read from the ERP system and added to the set of data held by KTM. KTM can then pass this data on to Oracle I/PM.
Oracle I/PM is an imaging and workflow software package. Not only does it store the invoice document with the index data entered through KTM, but it also has a workflow module that can track the invoice through the business process so the users can know where in the process the document is sitting. With I/PM workflow the invoice can be routed electronically to the assigned approver for invoice approval that is done on a Form built for workflow. If there are multiple levels that can be handled within the workflow in one of several ways depending on the information available from other systems such as the company ERP system. In addition, I/PM workflow scripts allow a programmer to write code to transfer the data directly into the ERP system through its data import tables. I/PM has been successfully integrated to pass data to JDE F0411Z1/F0911Z1 tables and Oracle EBS Open Interface tables to name just a few. These code scripts are re-usable so we can quickly get them working in your environment. Have we have found, not every company process their AP Invoices in the same manner, so each implementation we do is slightly different than any other, so we need to discover the differences and then modify the form and script code to match.
We at ImageSource can provide the expertise and experience to quickly get an imaging and workflow process into place in your company. Just contact us at http://www.imagesourceinc.com to find out how.