“Indexing? What indexing?”
You’ve decided to peek at the grim underbelly of the document management world, where brave souls venture forth … and occasionally don’t return. But where do these explorers go, and what are they looking for?
The elusive perfect indexing specification!
Indexing can be pretty confusing. It seems so easy at first, just naming files as they should be named. If you have folders, name (index) them by what’s on the folder. If you have stapled or paper-clipped files, name them by whatever’s on the first page of the file! If you have microfiche sheets, name them by the microfiche title strip!!
What’s so hard about that, BMI??
I’m glad you asked.
1. Native Knowledge
You have “native knowledge” of your files, and the content (actual data) of those files. What seems an obvious way to name a document to you could be extremely difficult for someone that doesn’t have a solid understanding of your records. Imagine that you have a bunch of patient charts, and you decided to name a file by Patient Name and Date of Birth (DOB). And those two index points (or “fields”) should be on the first page of every patient chart. Easy enough, right?
Ok, so we scan the patient chart into a digital format and are about to index the file. We’re looking at the first page within the chart.
Patient Name: check. (Easy peasy)
Date of Birth: check!
But wait!! Is that another date on the first page? Which one is Date of Birth?
Can you hear the sounds of something grinding to a halt?
What happens next is a string of emails and/or phone calls to ask what you want to do, and you don’t know because you can’t see the file, and so on and so forth. This back and forth to solve an indexing question may only take a couple of minutes, or a string of ten emails. Even when this one instance is resolved, it’s really only the first glimpse into the world of exceptions.
2. Exceptions
Exceptions are relatively common. Pretty ironic, right? An exception is an instance of an index point that doesn’t match the criteria that’s been described by the owner of the files. Or in English:
What we see doesn’t match what you told us we’d see.
Scenario:
- You have student transcripts on microfilm rolls and want the Student Name, Date of Birth, Social Security Number, and Student ID of each student captured.
- You’ve told us that all four fields are on the first page of a student’s file.
- A student file is identified by a big red “S” stamped on its first page.
As we go through the first roll of microfilm, we see the “S” stamped on images, and we start keying the fields you’ve requested. All’s well, but as we move through the roll, about 50 student files in, we stop. We’ve found the big “S” stamp, easy enough. There’s a Student Name, Date of Birth, and Social Security Number, but no Student ID. EXCEPTION!
Further along, we find another file that has Date of Birth, Social Security Number, Student ID, but two Student Names!! It looks like the person changed their name senior year. Which name should we use? EXCEPTION!
At the end of the roll, we find the big “S” stamp, but the first page is some kind of cover letter. Should we move on? Should we consider these images as part of the previous file? EXCEPTION!
In each of the above three examples, an exception occurred that would cause us to pause and clarify with you about how you’d like the exceptions resolved. This is time-consuming, costly, and throws the project into stall mode.
But how’s this problem solved? Contingency plans, my friend. In the student transcript example, a contingency to alleviate the exceptions would be: “if one of the four fields is not found, replace that field with an ‘NA.’” You may not be able to plan a contingency for every exception, but as many as can be identified and resolved prior to the project starting saves loads of time later on.
Solved. Done. Success.
3. Do You Really Want That?
This is a bit more philosophical than the other two reasons that indexing can be difficult, but important anyway. What it comes down to is knowing what will be considered useful and complete once the project is done.
If you work at a building department with thousands of permits on microfiche, a microfiche title might have a Permit Number, Street Number, Street Name, Project Name, Notes, Year, and more. If you ask to just “index the Permit Number,” it could be useful, but all that other information wouldn’t be captured. Once all of your microfiche are in digital form, like a PDF file or in a content database, is the Permit Number all you need? Will it be the single field you’ll use to find these records later on? If not, you may need to dig a little deeper and identify other fields that need to be captured.
On the flip side, if you wanted to capture all the information on the microfiche title, you could be creating an overload of information. Sure, it’s on the title currently, but that doesn’t mean it’s necessarily useful. We’ve seen many a case where title fields were added over the years and the current staff doesn’t know what half of the information means. If you don’t slice off some fat from the title info, you could be creating a mess that doesn’t help anybody.
So, what will be useful? That’s what you have to answer.
Final Thoughts
Getting your indexing right can be tough, we won’t sugarcoat it. But you want to do as much as possible to nail it down right so that you have an effective way of finding your records once they’re digitized. There’s not much that’s more demoralizing than wrapping up a digital conversion project, only to realize that you can’t even find your records and you’d be better off having not done the project at all. This is the exact opposite of how we’d want you to feel.
So, before leaping off the digital conversion cliff, take some time to really figure out the most effective and efficient way to access your records once they’re digitized, utilizing the ideas we’ve presented in this article.
Next Steps
Reach out to us today! Click the “Get Your Quote” button below, fill out the form, and we’ll quickly reply to you to discuss your project.
Further Reading
To learn more about digital conversion projects, take a look at these three articles below:
“Legacy Data Migration” covers the topic of transferring (or migrating) data and images from one system to another.
“Creating A Conversion Process Flow” describes how, if you decide to work with us, we create a unique project workflow to match up with your specific requirements.
“Document Scanning & Redaction” presents ideas about redacting information to prevent it from being seeing by the wrong people. Sometimes you have information that needs to be removed, and this article presents some options for you.