System Imaging

MedSuite's Imaging Workflow module supports two major features. The first feature is, as its name implies, to create a "workflow" so that scanned documents can be routed to various stations based on the type of document scanned so that data input may occur directly from the scanned documents. The second major feature is to provide ability to "index" a scanned document to some data whether that data represents a Patient, an Account, a Visit, a Payment, or some other data entity such as a Plan, a Fee Schedule, or a Staff Member.

Any scanner designed to support a sheet feeder that rapidly scans multiple documents (and many that scan only one image at a time) assigns some unique identifier to an image as its file name or Document ID. This identifier is often in the format of DOC99999.TIF or IM999999.GIF where 99999 and 999999 represent some sequential number assigned to the image.

"Indexing" generally refers to linking either specific documents (by Document ID) or batches of documents (by some other criteria) to some recognizable search data in an automated manner. The whole purpose behind scanning documents is to make retrieval both possible and easier than searching for the paper document in a storage facility. If a practice or billing company would like to retrieve a scanned document at some point in the future, then Indexing the document to some recognizable search data is crucial.

Batch Indexing assigns "some recognizable search data" to a group or batch of documents. For example, a batch of Hospital Faces Sheets can be indexed by the hospital admit date or the patient's surgery date. With Batch Indexing, retrieval is basically a manual process. The user typically has to find the batch of images (by date in our example) and then display each image to determine if the displayed image is the image the user is searching for. If the images were not alphabetized before scanning, then on the average, the user will have to review one-half of the images before he finds the image that he wants. If the images are alphabetized prior to scanning, then the search process will be somewhat faster.

If Batch Indexing can be thought of as indexing a group or batch of documents to some recognizable search data, then Document Indexing can be thought of as indexing specific documents to some recognizable search data. Whereas Batch Indexing functions at the batch "level", Document Indexing functions at the document "level".

What we are really talking about when we refer to Document Indexing is having the "recognizable search data" that is tied to a document specific enough so that a single document or just a handful of documents can be retrieved. Let's look at an example:

Let's assume that a patient had surgery on Jan 1, 2005. There are three paper documents associated with the service that the practice or billing wants to scan; a Hospital Face Sheet, an Anesthesia Record, and a Charge Ticket. Furthermore, let's also assume that we had enough detail on each document so that a specific document or a handful of documents could be retrieved by a search. Let's look at an example:

We now have a database table called the Document Index Table. Each row of the table stores data such as the Patient Name, Medical Record Number, Social Security Number, Date of Service, Document ID, Document Type, and Document Date Scanned. After several months we have thousands of documents and thousands of corresponding rows in the Document Index Table. Let's assume we have also written a program that will take input like a Patient's Name, or Medical Record Number and retrieve the matching rows from the Document Index Table and the documents corresponding to those rows.

Our document retrieval process has been drastically changed for the better. Rather than having to view tens or even a hundred documents or more to find the one or two that we need, we can now retrieve exactly those documents that are for a specific patient. Let's further assume that the search program was sophisticated enough to allow the user to search on multiple criteria such as Patient Name, Date of Service, and Document Type. Now the search result will be only the one or two documents meeting the search criteria.

That was the easy part. Creating the rows in the Document Index Table is the hard part. There are a number of ways to create these rows and most of them are dependent upon how much access and control the people implementing the imaging system have over the billing software. In cases where there is no control whatsoever, Document Indexing may be a separate stand-alone data input process. This is time-consuming and prone to data input errors. Where there is some control of the billing software, Document Indexing is often a "screen-scraping" process in which a program "reads" the data input screen and inserts specific data from the screen into the Document Index Table. While this often works, it has its flaws. If patient's name was originally misspelled and later corrected after the image was indexed, will the change be populated to the Document Index Table? Unfortunately, the answer to this question is frequently "No".

We now usually get into a cost-justification discussion over Batch Indexing vs. Document Indexing. Batch Indexed documents are easier, faster, and cheaper to Index, but require more effort and are by far more expensive to retrieve. One the other hand, Document Indexed documents require more work and are more expensive to Index, but require little effort and expense to retrieve. Often, Batch Indexing is selected because it is less onerous to Index and the hope is that the practice or billing company won't have to retrieve too many documents.

What if Indexing could occur as quickly and easily as Batch Indexing and document retrieval could occur as quickly and easily as Document Indexing? Image Workflow makes both of these possible. The idea behind Image Workflow is that, in many applications, a document isn't just scanned, indexed, and stored. In some applications, like auto insurance claims, there are many types of documents such as accident reports, photos of the car, claim adjuster's worksheets, body shop estimates, etc. Some of these are just supporting documentation while others are the documents that drive the process. At various points during the claims process, different people need access to these documents; some for review and approval, others to actually enter, adjudicate, and pay the claims. This is probably an extreme example, but it illustrates the point that in a workflow setting, documents need to be sent from one step in a process to the next. As the documents move from step-to-step, more and more data is captured along with the scanned documents until, eventually, the process is "completed" and the "case" is closed.

In an anesthesia billing office, some documents like a Hospital Face Sheet are data input, indexed, and closed in a single step for while others such as a Charge Ticket can go to coding, data input, batch verification and balancing, and then are closed. In MedSuite's Image Workflow, a specific document can be displayed on the screen while the data is input. The action of saving the data that has been input has been modified to save the data (Patient, Visit, etc.), index the document to the data, and pass the document on to the next step in the process.

Anytime the volume of work to be input in an office exceeds the ability of one person to enter all of that work, the work must then be divided among multiple users for data input. Of course, there are many ways to divide the work for data input. Due to Concurrency issues, all of the anesthesia charges for a date of service for a physician need to be entered at the same time. If an anesthesia group works out of multiple facilities, the paper documents often arrive in the central billing office facility-by-facility, so some offices will divide the work by facility. Under the same scenario, others offices will accumulate all of the work for all facilities by date of service and then divide the work evenly among the available data entry staff.

Since the work to be entered is organized into multiple "batches", most billing systems, including MedSuite, allow the user to create a "logical batch" of charges or payments that represents the physical batch of work. These logical batches can capture information that allows the user to "balance" their batch of work. This generally involves making sure that all of the documents in the physical batch have been entered and entered correctly. Typically, the user will run an adding machine tape of the count of documents and a "hash total" of the CPT Codes to be entered. For a batch of payments, an adding machine tape of total payments and total adjustments will be run and compared to the total payments and total adjustments entered into the computer.

Obviously, office policies and procedures dictate how the total volume of work in the office is divided into physical and therefore logical batches. Someone in the office actually divides the work. We at MedSuite needed to make sure that we were not going to force a client into dividing the work before scanning just to accommodate the Image Workflow.

Prior to scanning, the user must separate documents by Document Type (Charges, EOBs, Face Sheets, etc). The documents can be further subdivided into smaller batches by criteria that make sense to the user. For example, charge tickets could be divided by facility and service date. EOBs could be divided by remittance date and insurance or self. Insurance EOBs could be further divided by bulk and non-bulk EOBs. What we do not want to do is to force a client into organizing their physical batches in a specific way. If a day's work is roughly divided into equal shares, then the same division of work can take place prior to scanning. If an anesthesia group works out of multiple facilities, and the paper documents arrive in the central billing office facility-by-facility, then the documents can be scanned by facility.

MedSuite accommodates these requirements by allowing the user to define "image types" and "image stations". When documents are scanned, the user assigns a specific image type and a station name, which is nothing more than a user-defined name for the first (or only) location to which the "batch" of documents will be sent. A batch of documents could be scanned into a station that several people use for source documents.

Among other things, the image type controls the level at which documents of that type will be indexed. For example, one office may want to index charge tickets by visit while another office wants to index by batch. One office may want to index hospital face sheets by patient while another office wants to index by batch (service date).There is no reason why MedSuite should not be capable of permitting these options.

What does change is that if indexing by patient or by visit is selected, then the user will key from the image. MedSuite will allow both the image and a data entry window (demographics, visits, payments) to be open simultaneously which facilitates data entry directly from the image. Demographic face sheets and anesthesia records/face sheets should be separated so that Demographics are keyed first, then visits are keyed separately.

If an office is indexing by batch, then the user will typically key from paper and scan the documents after-the-fact. Documents can be scanned into an already open station. For example, in a setting where several users are "sharing" a station, it is expected that new documents will be scanned into that station.

Based on the previous discussion of Image Workflow and Office Policy and Procedures, it is clear that certain capabilities needed to be implemented in MedSuite in order to accommodate Image Workflow:

•	Documents must be scanned to a "first" station, which may be the only station in the "workflow" for that image type. For example, charge documents may be scanned to "Coding".

•	Multiple users should be able to pull documents from a single station. If two users attempt to pull the same image from a station at the same time, an error will be generated for the second user and optionally allow them to choose another image.

•	The user must be able to transfer Images from one station to another. Charge documents should be capable of being transferred from "Coding" to "Visit Entry".

•	An image type must be capable of "knowing" the level at which indexing will be performed for that image. For example, a charge document should be indexed at the Visit level, while a Demographic document should be indexed at the Patient level.

•	An imaging station's "action" must be capable of invoking a specific MedSuite function:

For example, a charge document should invoke the New Visit function, while a demographic document should invoke the Patient (Patient Search) function.

•

Image Workflow must be capable of capturing and holding "data" for an image. For example, in a Coding Department, the codes are written on the Charge Documents. Since we are going "paperless", the codes need to be saved as data fields on the image itself. Since this data has already been keyed and saved on the image, it can be imported to the Visit or Payment screen at the time the Visit or Payment is keyed.

•	An Electronic Remittance Advice (ERA) file should be processed so that an "image" is created for each claim in the file and indexed to the claim. Secondary claims will need this "image" as their EOB.

•	Users are able to cut sections of a scanned EOB and attach them to individual insurance payments.