Gradually Changing the Capture Process

Our client is currently scanning lab test requests at their California office. These are prepared by having a PDF417 barcode label affixed to the document, which contains the main metadata value, called the Accession Number. Accessions (i.e., lab tests) are scanned, processed by the PaperVision Capture software to recognize the Accession Number, full-text processing is performed, and then the processed data is uploaded to ImageSilo for access from any office. They would like to begin processing their EOBs and other backup documents as well, so they are included on ImageSilo.

These supporting documents physically arrive at the office at a later date than the lab results, of course. The objective is that a single search of an Accession Number on ImageSilo brings back the lab results and any relevant backup documents, if available. It is important to note that some supporting documents, notably EOBs, contain information about multiple Accessions, and therefore must be duplicated so they appear in more than one Accession search. Ideally, this duplication process will not take additional space on ImageSilo.

Currently backup documents are sent for manual scanning and indexing before processing. Hard copies are then sent for manual hand-key entry into the billing-management system. This hand-key process consists of entering at least one unique reference then hand-keying individual line-item details.

Now, you can see the duplication and labour-intensive issues here, and, as a technologist, it’s easy to make the jump straight to sophisticated forms-recognition functions auto-populating the practice management system in the background, thereby eliminating errors, reducing labour requirements and making everyone’s life a lot easier. But it’s often not so clear cut. The user is already expending the labour, and even when you can show a clear ROI, they may not be ready to make the capital investment in forms recognition software, or they may not think their staff are ready to support the new process, or there may be concern about third-party vendor cooperation or even whether the third-party applications have the capability to back-end volume data imports, and the potential cost implications of those applications, et cetera, et cetera. So we go down a different road, the available road, and we begin to gently transition the process to better, at least, if not best.

Step 1: Immediate Changes to Capture All Supporting Documentation

The first step does not significantly reduce the amount of effort currently being expended, however remember that this wasn’t the primary objective. The main goal is to bring all supporting documents onto ImageSilo, so that lab results and supporting documents can be located with a single search.

In PaperVision Capture we create a new capture Job for scanning supporting documents. This new job has similar index fields as the primary lab results scanning job, with whatever additions are required, if any. The output data will load to the same project as current lab results so all documents are in the same place. (We considered different projects and global search methods, but it’s not really practical on this job, especially with the existing search integration from the web-based practice management application.) The scanning process will differ from the current barcode-breaking mechanism to include manual document breaking (we are investigating other methods, and whether barcodes could be made efficiently at this stage; I don’t think so, but possibly). We also add the document “duplication” process during indexing using PaperVision Capture Detail Sets functionality.

PaperVision Capture Detail Sets define a collection of indexes that allow multiple sets of field data to reference a single document. This will allow the user to create X number of “duplicate” database entries (where X is based on the number of accession references required per supporting document), and where the duplicates are only database entries pointing to the same image file(s) and not physical copies of the image. With the appropriate number of duplicate entries, the user can then begin manually indexing the various accession references that are present on the scanned document. The unique reference field (EOB reference or similar) automatically carries across all documents and is not indexed manually more than once (but will need to be indexed manually each time the detail set changes). Indexed documents are submitted and uploaded to ImageSilo automatically.

And our first objective – getting all the data online and accessible – is met.

Step 2: Automating the Indexing and Merge Process

At this point we will seek to change the process so that keying of data into the practice management system occurs before scanning. In this way, all the data entry has been completed and the indexing data is available for us to run database updates.

In short, this process would allow users to scan each supporting document, index only the unique reference number, and then use database update functionality native to PaperVision Capture to create the appropriate number of items in each detail set, and populate Accession references across all of those items with the data that has already been hand-keyed once.

So, we start getting more efficient on the data-entry at this point – instead of keying into the imaging system and then re-keying into the practice management application, we’re going to hand-key from hard-copy into the practice management and reverse the population of data into the imaging system (whereas normally we would seek for an imaging system to populate the accounting system. Remember, baby steps.).

We have a few questions on this part, of course, mainly around the best point of entry for accessing the hand-keyed data. Does the commit on the data entry process immediately generate a transmission into a reference database? Or are we waiting until the actual data merge takes place to pull data from the web-based application? We’re looking at methods now and our decision will, as ever, be based on the most efficient method for users.

But we also open up a couple of other areas of potential efficiency gains. Particularly we’d like to eliminate the hand-keying in the imaging system altogether, as well as improving the document break method. So at the data entry point, can we generate a unique 2D barcode reference that applies to the supporting document and kills two birds with one stone: the barcode becomes the automatic document break and populates our unique reference field, enabling automated details sets and bulk updates of accession references. That’s the question we’ll be asking ourselves in weeks to come.

One step at a time. But the sooner we can get to at least this step, the better for the client. At which point they will be a lot more open to re-visiting the ROI on a proper forms-recognition module that eliminates all hand-keying from the process entirely. Especially considering that they are seeing those volumes rise on a weekly basis already.

Read more...

PaperVision Forms Magic

As per the previous post, I had a chance to see Digitech unveil the latest addition to PaperVision Capture (more later) and the long awaited forms processing solution we’ve all been hoping they’d write: Forms Magic. It seems some of their developers have been challenged and inspired, internally and externally, to release a next-generation forms processing and data extraction application, and from the look of it they’ve succeeded. Forms Magic processes scanned images and various other file types and extracts everything from heading detail to line items, and it’s especially good at recognition and classification of different form types.

As alluded to, PaperVision Forms Magic is intended to build on to the PaperVision Capture suite. At this stage, though, it remains a separate system and is handled by Digitech’s own professional services team (an industry rarity: they mean it when they say ‘professional’). But Digitech’s CTO made it clear that integrating into PV Capture is a priority for the company, and he’s not lead us wrong in the past so I look forward to the announcement. Even as a stand-alone product, it shows a lot of promise – I have two invoice processing projects on the burner that need exactly this product, and I’m looking forward to getting my hands on the data and working with Digitech to get it in front of the client. If it can do for these customers (a private college and a retail group recovering from our latest recessions) what they demonstrated on site, then I think we’ll be able to secure some good business and give the client a powerful, cost-saving solution. Can’t wait to get it out to the railways.

Forms Magic is competitively priced and the margin for the reseller, while less percentage-wise than a typical PaperVision or PaperVision Capture module, is both attractive and fair to the end-user and partner. One gets the feeling they might publish MSRP to remain attractive on the street. In fairness it has to be done – you can’t continue to lose business due to an overzealous partner pricing a product out of range. Digitech have stuck true to their channel and they deserve a lot of respect for that, but it’s good to see them exert a little more influence on how their product is represented and sold. Again, that’s all conjecture – I have no idea what their plans are for pricing once it’s all integrated or whether it will stay in PS or whether they’ll publish pricing. I just think they should, and this seems like the product to do it.

It’s all a part of a palpable vibe of change at the company – again, nothing they publicly announced, but I get the feeling they had an interesting 12 months previous. To start off with – now it’s DSU, it’s midweek, no heavy marketing push – let’s get to the products, end of. And there’s a lot of good in that, although I think they could have struck a better balance between the old and new. They just seemed to have an open, corner-turning feel about them, like they’d re-discovered what was fun about being a software company – coming out with new product and turning other people on to it. It seemed a really healthy vibe and I’m happy for them, the individuals who make up that company and the group as a whole.

Got a little tear-jerky there, didn’t I? Never mind, back again in a few days with an update: I had started down an OpenERP road sometime back and I enjoyed learning about it. I’ll take this company into those areas in years to come – I’d envision a hosted OpenERP environment in an Azure patch at a low monthly rate, with predefined configurations for retail, logisitics, etc. But that might change by the time I get around to it – it was a pleasant distraction but the business of getting down to business has taken 100% of my energy and I had to back off; ultimately I just needed the CRM portion and I kept getting too deep into the rest of the product. So I’ve wiped it out and switched over to the Community Edition of SugarCRM, all running locally. It’s definitely doing the trick and I’m just using it for what I really need, so no more distractions (don’t count on it).

Read more...