While I firmly believe backfile scanning is a necessary step in any successful EHR implementation, I recognize that doing it all at once can be a daunting proposition, both in scope and investment.

Fortunately, there are options for facilities for which a full, up-front backfile conversion is not a possibility. At my company, we refer to them as “scan on-demand” and “just-in-time scanning.”

Both make sense in certain cases. Document management studies have shown that, once a file is pulled, the likelihood it will be accessed again in the near future increases exponentially. Thus, it can make sense to focus backfile conversion investment on files most likely to be used – and re-used.

Scan on-demand: A scan on-demand project is exactly what it sounds like: Patient records are digitized one at a time, based on individual need. In a medical setting, this would likely mean scanning records for each patient the day of or the day after an appointment. The work can be done on-site at the hospital or practice, or all records can be shipped to an off-site scanning facility after the visit and scanned on an as-needed basis.

This solution can be cost-effective compared to an “all at once” backfile conversion, as it minimizes the amount of unnecessary digitization work actually performed. But it’s less proactive than its cousin …

Just-in-time scanning: At its core, just-in-time scanning is a hybrid approach between a full backfile conversion and scan on-demand. Rather than digitizing everything at the beginning of the project or waiting until the day it’s needed, records and charts are scanned a week ahead of time, based on the facility’s upcoming appointment calendar.

The result, on a day-to-day basis, is similar to that of a full backfile conversion, but with a substantially reduced initial investment.

With potentially reduced costs, of course, comes a tradeoff. Scan on-demand and just-in-time scanning each require an ongoing commitment of manpower, on both the coordination and imaging ends. Still, both remain valuable options in the quiver of facilities hoping to fully leverage a new EHR implementation.

Bob: Hello, I want to thank you for allowing me to interview you and for the record, can you provide my readers with some insight as to who you work for and with a description of your role?

John: I'm currently a first line manager at Fujitsu Enterprise Business Services. I manage a large team (25+) of senior DBAs and application engineers who support all the relational databases for Blue Cross Blue Shield of North Carolina, as well as the team that supports BCBSNC's major document, content and imaging systems like Mobius, Filenet and Thunderhead.

Bob: When did you get the idea to make AIIM Education part of your training focus and what were the drivers for the decision?

John: I've relied on AIIM information, white-papers, etc. for a long time in the content management space. As my involvement in enterprise content management increased, both in terms of setting strategy, defining policies, and executing operationally, I wanted to take the next step and get some quality formal training. AIIM was my first choice.

Bob: What do you see as a benefit for you and future attendees of these programs?

John: Well, program curriculum is great but the benefits extend far beyond the classroom. Whether in class or as an AIIM member you get to be a part of a large network of folks who are not just thinking about but doing and going through the same things you are, and that's immensely valuable.

Bob: For the future, how do you see the role of AIIM education evolving in relation to you and/or your customers?

John: From e-discovery to social media, I think AIIM's done a great job of keeping up with changes in the marketplace.  I also appreciate the technology-agnostic approach. Whether it's imaging, content management, or social media, AIIM gets that success is never about the tool or the brand, but the deliberate and thoughtful approach you take in how you establish a program that values and accounts for people and process.

Bob: Is there anything else you might want to share with our readers related to AIIM Training and how it has been of benefit to you and may be of benefit to them?

John: I think I'd like to see more un-conferences, un-meetups, tweetups, etc., greater use of social media, and would like to see AIIM grow its community.  There's a lot of expertise out there, let's look for different ways to share that.

Bob: I want to thank you, for taking time to talk with me and for sharing your valuable insights and perspectives with our readers.

What say you? Do you have a story to tell? What are your thoughts on this topic? Do you have a topic of interest you would like discussed in this forum? Let me know.

Bob Larrivee, Director and Industry Advisor – AIIM

Email me: blarrivee@aiim.org   

Follow me on Twitter – BobLarrivee

www.aiim.org/training     

Last month, Emory Healthcare in Atlanta announced that 10 discs containing electronic records on 315,000 patients had gone missing. That’s sensitive information on every patient who had surgery at three hospitals over a 17-year period.

Naturally, such a security breach is unacceptable under any circumstances. But it’s less important here to indict Emory than to consider how EHR can be made even more secure going forward.

Our business specializes in outsourced scanning and backfile conversion projects and considers three levels of safety and security when it comes to sensitive records like EHR.

First, there’s physical security. This is exactly what it sounds like – literally securing documents. The key here is an auditable chain of custody. Take a backfile scanning project involving tens of thousands of paper patient charts. Whether the job is performed on-site or at a dedicated scanning facility, you must be able to tell where any document is, and be able to access it immediately.

The most effective way to accomplish this is to implement a file tracking system designed to account for all actions: folder pull, delivery, folder check-in, document preparation, scanning, quality assurance testing, re-processing, indexing/exporting/OCR, auditing, folder check-out and in-process check-out.

Card Key access to documents and CCTV are also used to control and monitor the physical plant and equipment.

Part and parcel with physical security is electronic security. This is simply securing electronic information (whether on servers, physical media or stored remotely), and limiting who has access to it. An acceptable level of scrutiny here alone would have prevented the situation in Atlanta. I’ll never understand how 10 critical discs could be allowed to leave the facility. The fact they got out is mind-boggling.

The most important level of security, perhaps, is process security. This is about effective control of the scanning, indexing and archiving process, based on the detection of variances from the project plan in time for the project team to apply corrective measures.

What individuals have access to given documents at any point in time, and for how long? What logging is done of the time spent with the documents? How many people touched the documents? Are documents being scanned as efficiently as planned? All this information is essential to proper security procedures, and can be used to head off potential breaches long before they become a problem.

Then, I decided to make a PDF document of an Internet displayed page, and the Adobe PDF printer driver failed – again. Instead of a nice PDF copy of a bill payment receipt, I got some “gibberish” looking characters that made the PDF document largely unreadable. This had occurred last year, before a hard disk crash, and most technical advice found on the Adobe and Microsoft sites was not very helpful. Some blog advice had been to reinstall the Adobe Acrobat software.  Then the disk drive crashed, and on the new drive I installed a newer version of Adobe Acrobat and the problem went away. Or so I thought.

Then, yesterday, it came back. So I researched it again. This time, the answer was to be found at “Adobe Acrobat 10 Displays/Prints Gibberish” - http://helpspot.business.uconn.edu/index.php?pg=kb.page&id=344. The problem has to do with the option of the Adobe software to “Rely on system fonts only, do not use document fonts” when the PDF file is generated. Checking or not checking this box changes the PDF creation approach. The example of character gibberish provided was exactly what my documents had been looking like. In some cases this document creation failure was not apparent in the first few lines of the documents generated. It would only be apparent if one looked at the entire document.

 This could cause real problems with automatically rendered PDFs to be used as official records unless human eyeballs caught the anomaly. Possibly, an automated OCR check of the PDF might catch the problem, but this would need to be executed on all rendered PDFs to identify specific document creation failures, thus taking up more CPU cycles during the document conversion process. Obviously, finding these PDF garbage files that must be deleted retrospectively after many had been stored in an ECM system would be costly for a system owner/operator.  Imagine the reaction of Corporate Legal counsel if this is all they could produce during discovery proceedings to attest to the innocence of their client. And, if the fonts are altered from the original document, do you really have an archival quality rendition?

So, despite our reliance on automated solutions to ECM and ERM to get our daily work accomplished, it is still important to not completely turn our futures over to computer based robots or automated systems. All of the technical wizardry in the world during systems design will not assure we have records of evidentiary value and archival quality if the systems do not perform exactly as expected. Human review of the performance of software must be factored into every automated system or our futures may depend on archival records of questionable quality due to the unexpected generation of gibberish.