Designing a Remote Coding Program: Seven Steps to Success, Part II

Vol. 12 •Issue 23 • Page 10
Hands-on Help

Designing a Remote Coding Program: Seven Steps to Success, Part II

Leslie: In “Designing a Remote Coding Program: Seven Steps to Success, Part I,” published in ADVANCE, Oct. 14, 2002, we covered steps one through three: obtain executive sponsorship, create a remote coding project team, and create and communicate a remote coding vision. In this column we will discuss step four, select remote coding technology. So let’s go shopping!

Patty: Not so fast, Leslie. The process for selecting the best technology solution for a remote coding program is the same deliberate process one uses for any new technology you might be choosing for the health information management (HIM) department. The project team needs to gather information, define remote coding functionality requirements, meet with technology vendors and select the remote coding technology that best fits their needs and circumstances.

Leslie: You are right, of course. We have seen times when a hastily selected solution turns out not to be the best solution, resulting in unanticipated costs, disruptive work flows, additional support staff and a disappointing first experience with remote coding.

Patty: Remote coding technology meets two important needs for a remote coding program. First, it provides a means for coders to access patient medical records electronically, and second it supports the workflow necessary for an efficient coding process.

Leslie: Let’s discuss electronic access to patient information first. The project team needs to understand their organization’s information technology (IT) strategic plan for an electronic medical record (EMR) and how far along the path their organization is toward an EMR.

Patty: Knowing the planned path toward an EMR is critical because it identifies the immediately available access options and projects a timeline for when the options will change. For example, if a hospital already has a complete EMR, the technology discussions will center on how coders may directly access the EMR system, how work would be electronically routed to coders and supervisors, and reporting capabilities. Will coding staff access the EMR through dial-up or the Internet? For coders working onsite, will there be any problems accessing the EMR from hospitals in the system? Does the hospital have a virtual private network (VPN)? Will the coders working from home have to install a firewall on their desktops? Are there special requirements for coders’ workstations (monitor size, RAM, hard disk, software, etc.)

Leslie: If an organization does have a complete EMR, the project team will also want to learn about the workflow support. Does the system have a remote coding module for managing the coding function? Is workflow built into the existing system that enables electronic distribution of records, and does it support the real time tracking of coding production? Does it allow coders to refer coding questions to supervisors? Does the system have reports that a supervisor can reference to know the status of coding, turnaround times and productivity?

Patty: Some organizations may have an EMR for some record types but not for others. Or the current EMR includes a scanning platform but does not have coding workflow. That information alone may determine the best place to start the remote coding program for the most rapid and cost-effective start-up. In most circumstances, in the first phase of the remote coding program, coders would remotely access the EMR. The second phase of the program would address records not yet in an electronic form or records in electronic format that are not accessible remotely.

Leslie: If EMRs are in a very preliminary stage or not in the IT plan yet, the technology discussion must address how paper documents will be put into an electronic format, and how discrete patient databases, such as radiology or laboratory results, may be accessed if needed during the coding process.

Patty: Several companies offer remote coding technology that provides for scanning paper documents, encrypting the data and transmitting scanned documents via the Internet to host servers. These solutions include the workflow software that enables coders to code remotely and supervisors to manage the coding process.

Leslie: The team still has more information to gather. They need to understand the internal capabilities available to remotely access HIM and clinical applications. They must determine how remote coders will access the encoder/grouper for performing the coding process and how they will enter data into the clinical information system. The most efficient remote coding process replicates the in-house process in which coders access the encoder to code and then abstract information directly into the clinical information system.

Patty: We have seen many remote coding programs in which remote coders must fax or e-mail the codes back to the hospital site for other staff in the HIM department to do the record abstracting and data entry. While that scenario may be helpful in cases of extreme coder shortages, it is a costly solution and far from the most efficient way to perform remote coding.

Leslie: Good point Patty. It is one of the reasons representatives from IT need to be on the project team. They must understand the needs of the entire coding process so they can plan to implement remote access technology to HIM applications, clinical databases and other systems necessary to support the coding function.

Patty: If remote coding is to be accomplished using the Internet, as it is in many situations, the project team also needs to know what type of access to the Internet is available in their area. If coders will be working from home, the team needs to poll each coder to determine if they have broadband (cable modem or DSL) access to the Internet in their community. Broadband access is highly recommended for remote coding. Dial-up access to the Internet impedes productivity and phone charges can mount up.

Leslie: Patty, your last point suggests we need to talk more about differences in remote coding functionality.

Patty: Functionality requirements vary from hospital to hospital, and remote coding products differ in several ways. The project team needs to understand the differences and have discussions regarding the priority needs of their organization. First, it is very important to understand the difference between products that are Web-based and those that are Web-enabled. Web-based products require only a Web browser and are written in the latest languages, i.e., XML, HTML, Java, etc. Web-based products can work in a thin client environment, which means that software is not needed on the users desktop, moving away from client/server technology where software resides on a PC and on the server. This also means it can be deployed to more people at once because many of the barriers to access are removed and the cost per user is lower than client/server technology. Web-enabled products use older programming code with a Web viewer as its front end. They are client/server based, which is becoming an outdated approach to deploying software. Web-enabled products do not have the same degree of flexibility when it comes to customizing views, reports, etc. And Web-enabled products cannot take full advantage of Internet technologies and are more costly to implement.

Leslie: In many ways, the transition to Web-centric systems is as significant as moving from DOS to Windows or as the introduction of PCs into a mainframe environment.

Patty: I agree Leslie. It’s a huge paradigm shift, enabling greater security, access to data and functionality that never existed before.

Leslie:.Other functionality requirements that may vary are workflow, security, reporting tools, data entry, batch scanning and auto indexing, storage and technology infrastructure.

Patty:.All of these are important requirements for the project team to discuss and to understand how they impact the coding management process and the quality of data. Some have more impact on costs and timeliness than others. For example, batch scanning and auto-indexing is a big time saver for the HIM department’s scanning staff. Scanning that requires manual indexing takes more time, limits the number of fields included in the remote coding database for reporting and requires a quality control process to be performed by HIM staff. Manual indexing not only requires more scanning resources but the time to complete scanning delays coding.

Leslie:.When the team has completed their functionality requirements, they will want to see demonstrations of various systems to compare against the functionality requirements. A checklist with functionality requirements used by each member of the project team can capture the critical information for discussions following the demonstrations. (See sample on our Web site at

Patty: As with all major technology purchases, it is also a good idea to speak with clients of the systems you consider. They can give you a heads up on potential problem areas in a product, as well as letting you know how implementation went and how service is delivered on a long-term basis.

Leslie: In the final analysis, the team should make its selection based on the best fit for their remote coding vision, current and planned infrastructure, and functionality requirements. Peer recommendations should also be carefully considered.

Patty: When the project team has reached a decision about the technology they will use, the team can move on to the last three “steps for success”: performing a remote coding readiness assessment, developing a work plan and implementing the work plan. We will address those steps in next month’s article.

Leslie Ann Fox is president and chief executive office and Patty Thierry is vice president and chief information officer, Care Communications Inc., Chicago. They invite readers to send their thoughts and opinions on this column to [email protected] and [email protected].