 Figure 1. |
The factors that determine the progress of large information system (IS) projects are often amazingly complex. These projects frequently appear to develop a life of their own. The unforeseen behavior of these projects is not, in fact, unlike certain chemical solutions. Mix up a solution of malonic acid, sodium bromate, sulfuric acid, and the indicator ferroin. In a large glass it behaves very well. It remains uniformly mixed.? Nothing visually observable happens. Pour it into a layer a few millimeters deep. Watch carefully, you may not believe your eyes (see Figures 1-4, page 14).
Add a little ruthenium bipyridyle to the mix. Keep the mixture in the dark and you are safe. Show it the light of day and all kinds of things can happen. Have we created a plant?
Both of these solutions are strongly influenced by the details of their environment.? Large information system projects behave very much the same. Each minor alteration of specifications or resourcing can result in major unforeseen long-term impacts on the overall project.
The solutions discussed here are called dissipative reactions because you must feed them to keep them going. When you do feed them to sustain their life, the food is cheap.
Informatics projects are never cheap to feed and tend to get more expensive as they are influenced by the seemingly minor perturbations in their environment.
ForeWarned Can Be ForeArmed
 Figure 2. |
The devil is in the details. This is the current state of informatics medical imaging in radiology. Seemingly well-defined and well-understood vendors, contracts, products, and interfaces constantly seem to take on a life of their own and demand constant feeding of additional monies and resources. Estimates of the difficulties of implementing large information system projects include: most CIOs lose their jobs in 18 months due to their inability to control large projects; 50% of IS projects will ultimately be abandoned; and the remaining 50% will entail cost and time overruns by a factor of two or more. This is an ominous background in which to approach medical informatics. Health Insurance Portability and Accountability Act (HIPAA) regulations are poised to place further requirements for already strained resources. So why would any sane radiology group even think of? taking on any IS-related projects?
The Next Step
In many institutions, the picture archiving and communications system (PACS) is transitioning from a specialized tool used only by neuroradiologists to a prime-time tool depended on for all routine diagnostic reads performed by all radiologists. This is a difficult transition for both the radiology practice and the PACS vendor community.
Radiology information system/hospital information system (RIS/HIS) vendors have an equal or larger challenge. The transition from the IS environment and its traditional service response needs to the clinical environment may be a large hurdle.
 Figure 3. |
The ideal PACS provides the ability to review electronic images anywhere and anytime. As PACS systems grow, PACS and paper become an increasingly cumbersome and labor-intensive maze for the radiologist and the technologist to negotiate. If the improved efficiencies promised by PACS are to be practically realized, the radiologist must be seamlessly provided with contextual patient and examination information concurrently.
HIS/RIS/PACS integration can provide a unified electronic presentation of pertinent patient contextual information synchronized to the electronic image review process. Integration efforts can provide a single log-on, a single electronic desktop, reduced billing cycles, near-elimination of unread and unreported examinations, and nearly instant referring physician access to signed-off reports.
Over the past 5 years the Cleveland Clinic Foundation has been involved in an ever-expanding quest for improved efficiency and quality of care in the Division of Radiology. This has been driven by many of the same motivations impacting medical practice in general, including reduced payor contracts, improved care requirements, JCAHO, HIPAA, and a variety of local situations such as expansion of emergency facilities and partnering and consolidation of facilities to improve care and buying power and reduce costs in a competitive market. These forces are a common thread in many if not all medical facilities and radiology practices in the United States.
 Figure 4. |
The Cleveland Clinic Foundation has determined that one of the few practical ways to expand coverage and achieve required goals is to begin to use new electronic technologies integrated to its established PACS system. These technologies hold the promise of reduced labor content for diagnosis of remotely performed examinations, increased numbers of examinations read by appropriately subspecialized radiologists, decreased time to diagnosis and report sign-off, greater capture of examination billing on both the technical and professional sides, and reduced billing cycle times. The risks and problems appear to be ever-changing and growing. The potential gains are great. In many institutions, RIS/HIS/PACS integration may be the only path toward meeting requirements mandated by HIPAA, payors, and competitive pressures. Success or failure of these projects may foretell the ultimate fate of the associated enterprise.
Who are the Stakeholders?
Who should control and who should implement RIS/HIS/PACS integration is a subject of constant debate and the source of struggle between many IS departments and radiology groups. There is no perfect answer. The realities are that both must work together to be successful, yet both usually have divergent goals. Radiology in general is interested in improving levels of patient care and efficiency of professional and technical staff. IS groups are commonly more focused on infrastructure control, commonality of tools, management reporting, and billing cash flow. Although these goals may not be completely divergent, the goals will compete for both money and resources on a daily basis in almost all institutions. Who will be the leader and who will be the follower will depend a lot on who has the budget dollars.
Radiology groups, which have traditionally been responsible for only the professional side of the house, may find themselves poorly positioned to take a major role in influencing the future of their practice and personnel work environments.
Experience at the Cleveland Clinic found that a professional staff gain of 30% in efficiency was practical with properly deployed electronic systems. This gain is too great to be ignored by any group or radiologist.
In order for the radiology practice to benefit, it is critical to define key goals. For success, goals must be concise and measurable. Many of the goals will involve process reengineering that will mandate changes in both technologist and physician work flow and practice. Successful measurements will need to be tied to the end-to-end process improvements rather than local practice changes. As an example, consider the traditional report dictation by a radiologist. Most would agree that voice recognition software requires more radiologist time per case with a significant retraining curve to be endured. There are several alternative criteria to evaluate in the global perspective. Are there changes in the percentage of cases billed; are results available for referring physicians and clinicians sooner; does concurrent dictation, proofing, and sign-off reduce unintended transcription errors; and does concurrent dictation, proofing, and sign-off really take more time than the three actions separately or were we just kidding ourselves that we actually proofed our reports?
The technologists in radiology will eat, sleep, and breath every new system change and nuisance. They will, are, and have been the main buffer between the realities of people handling, system utilization, and functionality and what is required by radiologists and other physicians on a daily basis. They are a dual-edged sword. They can make a bad system look great and a great system look bad. We love them/we hate them, but without a doubt we cannot live without them. They must be one of the primary stakeholders in any RIS/HIS/PACS integration project or it will never achieve its full potential.
Primary Goals
One of the overall goals of the integration project should be to assure a single point of entry to the database for all information. Multiple points of entry result in delayed or never reported examinations, resulting in unbillable examinations.
Addressing the Slow Service Issue The PACS vendors have failed historically to treat PACS service and support with the same urgency as acquisition modality issues. Some vendors have had policies that ranked all PACS outages at a lower urgency than a CT or MR failure. For PACS to truly become mainstream, this must change. |
Reduce multiple independent copies of information. For instance, one desk at the Cleveland Clinic produced two copies in different formats of each patient’s scheduling and examination information. All of this was kept very orderly in dual paper card files at the front desk. One set of cards was used by the technologists in performance of the diagnostic examinations on the patients. The other was for synchronization with the electronic HIS and billing systems. This is a classic example of how the technical staff can make the worst system seem to work well. Prior to a RIS/HIS integration project in this department, if the department administrator was asked how many examinations never get billed and how many are uncollectable when billed, she answered that they were all billed and all collected. She assumed this because she never got an exception report from the billing department and she knew she and her staff assured that each examination’s paperwork was sent to billing. The department chair was initially reluctant to get into the major integration effort required. He was shielded from the realities by the double index card system and blissfully believed that all examinations got billed and collected. When the department administrator was asked again in front of the chair what percentage of bills got collected, she had rethought her initial answer and responded that she was not entirely sure because it was an all paper system and she might need some additional resources to analyze the situation on an ongoing basis. The department chair became an instant advocate for the RIS/HIS integration project.
Paper Environment
A typical process flow for a CT examination at the Cleveland Clinic prior to implementation of RIS/HIS integration is shown schematically in Figure 5. Experience has shown that at each step of manual data entry there is an approximate 5% opportunity for data entry error or data to be entered that may be correct but may differ from other entries. Either way, multiple sets of entered data make matching all of the required data through the system to produce a legal bill a never-ending manual process. There are many points at which doctors must manually match several patient demographic parameters in order to assure a valid comparison study or to match signs and symptoms with imaging information.
 Figure 5. A typical end-to-end work flow within radiology. |
The typical billing cycle is a minimum of 5 days and more typically 11. Approximately 5% to 10% of the cases may not ever be billed due to the inability to resolve perceived conflicting patient examination information within the 30-day cutoff of examination billing specified by payors. A typical end-to-end work flow within radiology is shown in Figure 5.
Paperless Environment
A schematic of the patient process flow after RIS/HIS integrations with PACS is shown in Figure 6 (see page 56). Almost all opportunities for redundant entry of patient information have been eliminated. Patient information is available instantly and electronically for each case presented by the PACS review station. The electronic examination reading process is uniform from both the patient and radiologist perspective regardless of the geographical location of the radiologist. In the Cleveland Clinic environment, where most cases are read by a subspecialized radiologist, the patients whose examinations are performed at remote locations such as affiliated hospitals or primary care centers now receive the same quality of care in terms of timeliness and subspecialized reading as patients whose examinations were performed on the main campus. The subspecialty radiologist benefits from reading a greater proportion of cases within his specialty and by being provided much greater uniformity of presentation of patient demographic and physiological data. This reduces fatigue and may lessen the possibility of diagnostic inaccuracies due to nonuniform patient records. Although this system lends itself to automated coding of billing to payors, we have yet to implement such a system. We have benefited greatly from being able to consolidate all coding to a single centralized group that handles all billing for all locations. This improves accuracy and consistency, which results in improved reimbursement levels.
It should be noted that the number of systems in the paperless environment is actually greater than in the paper-heavy situation. This is offset by billing cycle times of typically 5 days being reduced to as little as 2 days for cases dictated and signed with voice recognition software.
Challenges
The deployment of browser-based sys-tems can be made relatively straightforward. Uniformity of browser selection, operating system, computer hardware, and software revision levels are all areas requiring significant diligence. We have been able to support many of our browser-based applications across a variety of platforms, including Windows 95/98, NT, and Windows 2000, and Sun Solaris 5.2 and above. We have been relatively tied to Internet Explorer and have been unable to get some applications to run successfully across different browsers. Early in the process we had significant issues with specific versions of browsers. Care must be taken by developers to write “vanilla” code and resist the temptation to customize to specific browser and operating system configurations. Many of our applications were originally implemented with browser-based JAVA.? Although this provided ease of implementation and some degree of end-user computer platform independence, JAVA also imposed a performance penalty.? JAVA is an interpreted language designed for platform portability.? It places significant demands on end-user client computers and can be significantly slower in some computational, database access and display tasks than other techniques.? To improve performance, many routines were rewritten with Active-X components to use the power of the server.? We have found it easier to buy a few more powerful servers than to update the computing power of many end-user desktop client personnel computers.? Placing applications on the server closer to the source of data they manipulate has provided improvements in the speeds of data and image presentation at the client desktop desired by the doctors.
We are moving forward rapidly to integrate text reports and imaging for efficient access within the electronic medical record.? This will provide a single user log-in? and a more unified user interface for nearly all patient information available electronically.? HIPAA provisions requiring trace ability of the flow on imaging information will be require audit trails on the web servers supplying the images to the medical record.? Many of the requirements of these audit trails can be met by the standard log-files created by the web server.? There are several vendors who are independently investigating this approach. The technology of Web servers allows log files to capture a wide variety of items including, remote user keystrokes, database modifications, pages visited, accessing IP address, Log-on name as well as amount of time a user dwells on any given page.? Big Brother has arrived.? Programs and procedures to routinely assess these files should be straightforward to implement.? The hard part will be deciding what to look for in all the available data.?? HIPAA provides nicely for this by specifically mandating iterative and measurable risk assessments.? This process will allow institutions to implement procedures and then improve on these procedures as required to meet security and data access needs.
Data Duplicity
HIPAA is primarily a security regulation. It requires that appropriate security and traceability be assigned to each duplicate copy of information. HIPAA appears mute on the overall requirements for data duplication for the explicit purpose of assuring availability during disasters. HIPAA specifically addresses disaster recovery by requiring each institution to put in place a set of procedures to enable continuation of service in a timely fashion by requiring each institution to identify critical data.
 Figure 6. Work flow after RIS/HIS integration with PACS |
Independent of HIPAA, the progression of reliance of the medical practice for daily diagnosis and treatment of patients on PACS and integrated RIS/HIS systems will mandate from a practical point of view online near real-time failover systems for major data repositories to assure data availability on a daily basis. These needs will become near requirements first at large institutions with 24×7 practices. Smaller groups treating healthier patients may be able to avoid the additional costs for some time.
A TUNA Fish Story
There are several standards, movements, and crusades that are being developed to facilitate RIS/HIS/PACS integration. These include TUNA-VHE (Top down-Unified-Network enabled-Architecture for Virtual-Health Enterprises), CCOW (Clinical Context Object Workgroup), and CORBA (Common Object Request Broker Architecture). Each has a slightly different approach but all focus on context sharing of patient information between different applications on the desktop. Each may have greater or lessor value to particular integration projects depending on the vendors and systems being integrated. These standards pass messages between applications on the desktop in order to synchronize the presentation of pertinent patient information. Many of the features of these types of approaches can be visualized as an automated cut and paste between two different Microsoft applications. Text from Word can be dropped into Excel. A common log-on or application launch point is provided. There is significant value to the user. The limitations should also be obvious. The user is still left to navigate two or more different operator interfaces, and although the patient context is synchronized, it remains to be seen how specific case and practice and illness management views can be built into essentially disparate systems.
Conclusion
It is time to get started. Get started controlling your destiny now or someone will do it for you. There are many benefits to RIS/HIS/PACS integration that can greatly benefit the radiology practice. Many of these benefits may separate the successful practices from those that eventually can no longer provide timely, expert, and cost-effective services. The benefits of RIS/HIS/PACS integration do not come free and are far from painless. Radiologists have long been the technology and change leaders in many of their institutions. They should not shy away from this next wave of technology innovation, but lead in its planning, implementation, and adoption. Integration is certain to provide radiology practices with the tools and value to continue to contribute medically in their specialty for many years to come.
Robert Cecil, PhD, is network director, Division of Radiology, Cleveland Clinic Foundation, Cleveland.
