Thanks to all the media attention the “Y2K bug” has received, nearly everyone in the world has heard of it, and most people have formed an opinion about its potential impact. While some of the information has been accurate in describing the problem, most reports seem to focus only on the technical issues.
The majority of people polled in two recent surveys said they believed the Y2K problem was technical in nature and they also said it was up to technical professionals to fix it. While significant technical issues are involved, the real problem for most medical practices is operational integrity.
If your computer systems stop working or malfunction, the technical solution is pretty straightforward: Get the problem fixed or get a new system. The business end, however, becomes far more complicated. What happens to the computerized chiropractic practice if the system, software or network fail? What if it takes a day to get the systems fixed? How about a week? How about a month? How will the business operate without computers?
Without some sort of a contingency plan, many practices could face serious financial problems. Fortunately, there are some steps you can take to make your office Y2K compliant before the end of the year.
The Business of Business
The media have responded to the Y2K issue by focusing on the huge amount of time and resources required by big business to respond appropriately. Those types of reports would have you believe that if you didn’t begin your efforts three years ago with $100 million dedicated to the problem, you don’t stand a chance. While this may be true for the Fortune 100 companies, it is totally misleading with respect to small businesses, including medical practices. The majority of chiropractic practices can be adequately prepared for Y2K within 30 to 90 days, depending on your level of commitment.
Setting the Stage
Following are specific recommendations for the chiropractic practice that will help you meet the minimum requirements for reasonable Y2K preparation.
- Documentation: Begin by documenting, for each department, the business processes involved, the steps required to achieve each process, and the equipment, devices, software, services and other items needed to carry out the process. For example, for the finance department, billing is one process. For billing, the steps may involve getting patient records, coding the visit and procedure, accessing the fee schedule, completing a form, and electronically submitting the claim. Dependencies may include computer hardware, networks, software, phone systems, modems, electricity, etc.
- Inventory: Develop a complete inventory of hardware, software, equipment, imbedded systems and supplies. This means compiling serial numbers, version numbers, manufacturers, vendor information, support agreements, warranties and anything else that can be used to identify the specific item.
- Making Contact: Contact manufacturers, vendors, suppliers and others involved in the supply chain. Ask them about their Y2K compliance programs. Find out from them what tests should be performed, if any, and how to do it. Get letters of compliance from them and be sure to record names, dates, comments and specific information discussed either on the phone or in writing.
- Testing: After you have obtained testing information from your vendors, you should begin the process of testing all of your devices and software that may be date-dependent. Remember, this does not mean testing every aspect of your hardware and software. You only need to test the date-dependent areas. If you are not confident or qualified to perform tests, then hire someone who is. Also, make sure to verify all claims of compliance.
- Risk Analysis: The next step is to develop a risk analysis assessment. For each of the processes you documented, determine the primary dependency. This is the dependency that, should it fail, would take the process down with it. For example, in the billing process, if the computer failed, another computer could be substituted. If the phone system failed, calls could be made from another location. But if the software failed, the process would fail. Therefore, the billing software would be the primary dependency.
Next, consider a list of possible scenarios and determine the risk potential, such as: limited disruption (i.e., an hour or a day); partial disruption (i.e., a week); long-term disruption (i.e. several weeks or months); or total failure.
The combination of a process, primary dependency and the risk potential create a unique risk paradigm. It is this paradigm that you will use to create your contingency plan.
The Contingency Plan
A contingency plan is really nothing more than an altenative process in casse of a disruptionor failure of an existing process in the practice. There are several consecutive steps you will need to take to outline the process, thereby increasing the efficiency and decreasing the amount of work that needs to be done.
- Identify the potential solutions. For every paradigm, there may be several different possible contingencies. Ask yourself, for each possible scenario, which option is: the most practical, the most cost-effective and the least disruptive.
- Document the plan. Take a look at the possible scenarios for each contingency, such as: the short-term quick fix or a way to work around the problem; partial replacement; full replacement; retirement (meaning eliminating the process or the dependency); outsourcing.
- Assign responsibility. If you really expect the contingency to work, someone is going to have to be responsible to see that it gets implemented when it should be, the way it should be, for no longer than it should be. Each contingency must be tracked properly for evaluation and review.
- Assign a cost. Make sure to assign a cost estimate to the contingency. For example, if you need to hire clerical staff to take care of an otherwise automated process, how long will you need the additional employees and how much will they have to be paid? This is an important step in preparing the budget.
- Identify the “Start Trigger.” Define, within the plan, what triggers the implementation of the contingency. For example, if the power goes out for an hour, there is not much you need to do. If it goes out for a day, it may trigger some contingencies and not others. You need to know when to get going on your plan.
- Identify the “Stop Trigger.” Remember that the purpose of the plan is to get you through a stalled or failed process, not to put in place a new process (unless, of course, that is part of the contingency itself). You need to know what situation will trigger an end to the plan.
- Develop a resumption plan. Sometimes, resuming business as usual is not as easy at it seems. For example, if you contracted with an agency or temporary employees for a certain time period, you may be liable to pay them even after you have fixed the problem that caused the contingency.
- Preparing a budget. Now that you have the contingencies put together and documented, add the costs up and figure out what resources may be needed and what you can realistically afford. In some cases, the difference may be great. In those situations, it becomes necessary to triage by highlighting those contingencies you can afford and trying to rework those that you can’t.
- Training your staff for the contingency. The next step is to begin training for the contingency. This means the people involved in each contingency should be trained to handle the exceptions. For example, if you have manual billing as a contingency for a failed electronic billing situation, someone has to be trained to manually complete a HCFA 1500 form. If the payroll system fails, someone has to be trained to manually calculate hours, wages, write the checks, compute the taxes, pay the payroll taxes, fill out a 940 and 941, etc. To be safe, you should be able to perform any automated process manually if the need arises. You also must test your contingency plan, following the steps outlined on the previous page.
- Reporting and tracking events. Finally, but no less important, is to track everything that happens and document, document, document. You will need this information not just for critical analysis, but also for liability issues. Some of the things you may want to track are: What triggered the problem?; When did it start?; How is it working now?; How long did it last?; What did it cost?; What really triggered the end?; What problems were encountered? This type of information is important for future analysis and to show a sense of reasonableness and responsibility. You should develop a simple form to make the documentation process easier and to make recall more efficient.
So What Do I Do Now?
So what do I do now, you ask? First of all, don’t just sit there, do something. Tell others in your office about your ideas. Talk it up. Give them this article to read. If the first person you talk to doesn’t respond, go to someone else. The practice, the patients’ welfare, even your job stability, could be at stake.
Having said that, remember to stay calm. We have weathered many other crises in the medical profession, some so serious that doctors lost their practices. Some so complex that it required millions of dollars to achieve regulatory compliance. The Y2K bug is not the worst thing that will ever happen or has ever happened. This is, in essence, a speed bump. Being prepared will prevent the majority of catastrophic occurrences. Hunker down and do what you have to do to prepare your contingency plan, and then sit back and relax.