Computing Rounds
 

accepted for publication in Medical Computing Today August 1997
(updated) December 1997, May 1998, January 1999


Sections (Case Presentations)
Importing Clinical Reports - Solo Practice's Progress - Making the Computer Useful - Search for the Magic Vendor

Physicians master clinical medicine by learning from their peers and predecessors, so why not use the same teaching/learning style to master medical computing? We all have had professional encounters with computers that would be interesting and informative to others, that were or became a learning experience. When presented as cases they showcase successful computerizations, Monday morning quarterbacking, a "here's how I/we solved it" -- and so illustrate by example what to seek out or avoid.
 
Every practice has faced, is facing, or will face computerization. How do the authors' experiences compare with the introduction of computers into your practice, group, hospital, or health care organization? Have you had more success or hit deeper pitfalls?
 
E-mail your experiences, comments and questions. We can post short replies directly on this page, but we also welcome more lengthy contributions as described under Information For Authors.

Sections CASE 4: Importing Clinical Reports
In 1999, I ran across an advertisement for a free electronic medical record program called PowerMed. I couldn't believe that any program offered for free could be any good but, since I had started two new practices in the past five years, money was tight and I was willing to give it a try. Surprisingly, the program turned out to be reasonably good and I have used it in the office since. Written in Windows, it employsFileMaker Pro to manage the database.
 
One of the problems in using any such program is entering data from outside the office -- laboratory and imaging reports, for example. PowerMed does contain a facility for importing images. Importing, however, takes much too long, the images are often too dark and difficult to read, and they take up a great deal of disk space. And, although PowerMed has its own laboratory record format that enables its users to graph lab data, the numbers must be entered by hand and the process is quite cumbersome.
 
Fortunately, most of the data in these forms are textual and the pictures are not necessarily important to the clinical record. Therefore, I have arrived at a simple method for entering these external data into the PowerMed SOAP notes using a scanner to read the documents and convert them into electronic form. I had been using a Paper Port scanner and OCR software to put articles into my database for clinical reference. This has worked well; even though the indexing for Paper Port is rather slow, I can find data on pretty much all the articles I have entered relatively quickly. Using Paper Port for clinical data, even though PowerMed cannot read Paper Port's special file format, I can scan and copy the text of any document onto the Windows clipboard. From that point it is very easy to paste it into PowerMed's clinical note. This method is so simple and fast that it becomes practical to put imaging and laboratory reports into the clinical data stream for later retrieval.
 
--contributed January 1999 by Matthew Cushing, MD, Internal Medicine, Greenbrae, California
 
 
Sections CASE 3: Solo Practice's Progress
When I moved to rural Ohio in 1981 to enter a solo family practice, our practice used manual billing based on superbills. In 1982 we began switching to a computer-based accounting system for billing. Even though our first system used a generic "medical" receivables accounting software package running on a dual floppy drive Victor computer, we could see the improvement when we generated the daily income reports. Since this first program did not handle CPT codes very well, we could not automatically generate reports regarding specific CPT utilization. On the positive side, after we entered all the patient ledgers into the computer system we realized that the manual system had left a lot of accounts unbilled, which meant increased revenue for the same amount of work.
 
About three years later, we installed an online billing system offered by a Blue Cross/Blue Shield subsidiary in Ohio. The hardware included an IBM PC-AT with an "unfillable" 20 Mb hard drive; we filled it in five months. This system permitted us to transmit claims directly to Community Mutual Insurance (BC/BS) along with Medicare and Ohio Medicaid claims. That carrier then routed the Medicare/Medicaid claims to the appropriate federal and state carriers. Claims that had been taking Medicare three to six months to process now took only 30 to 45 days. Claims that took the Medicaid agency nine months to a year to handle (if they were ever returned) took slightly longer than the Medicare claims. Miraculous! Many physicians in Ohio at that time did not even try to bill Medicaid due to delays and problems with clean claims that could cost more money than they yielded.
 
This system's other good points included improved tracking of receivables to the carriers; fewer claim fields to complete; less worry about clean claims, as the software would report errors prior to and during transmission; relatively quick return on claims reimbursement, and a generic, but useful, confirmation report upon completion of claims transmission.
 
Not everything was rosy; there were bad points. Payments sometimes went to the patients, further delaying payment to the office; individual patient demographics had to be entered each time a claim was built for transmission; this system was still not integrated with the remainder of the office accounting (automated for the receivables and manually handled for the payables), and scheduling was manual.
 
I n 1985/86 we upgraded again, purchasing through Community Mutual a minicomputer with several Altos workstations. The operating system -- Xenix, a version of Unix -- on this 80286 machine also ran on the next upgrade, a blazingly fast 80386. The software, from a BC/BS system in Florida, included accounts receivable and patient scheduling modules. In addition to the Altos units, we used our older, original ATs to give us more workstations without much additional cost. The upgraded software was an improvement. The receivables and scheduling modules were integrated and used the same patient demographic database stored on the hard drive (letting us do our online claims transmission without having to reenter the basic demographics each time a claim was generated), and the software was designed with the use of ICD-9 and CPT codes in mind. Now, four years after starting computerization, we could generate automatic monthly and yearly reports.
 
When our vendor suddenly announced it would no longer support our system, but would happily sell us a new one, we decided to shift accounting over to a module that would extend our Practice Partner medical records system (from Physician Micro Systems, Inc) and to move that system from DOS to Windows. We had to stay with DOS for the billing and scheduling modules, though, since the Windows versions have not yet been released. Our goal in switching was to have a completely integrated system that shared all patient demographics, eliminating duplicate entry of patient data. On the downside, I purchased a single-user license, meaning that only I can do the data entry; I cannot allow any office staff to enter the data for me or use the system. Within the office, each of the integrated modules for which I have a single-user license is assigned to one staff member. However, as the only practitioner in the office I pay the entire overhead, so the single-user license ends up saving the cost of multiuser licenses for each module.
 
I also use a medical history taking package called The Windows Historian. This standalone program, installed on our Windows for Workgroups network, generates reports accessible as ASCII files over the network. Unfortunately, the medical records program cannot integrate this output into the record.
 
We recently purchased new hardware, including 300 MHz Pentium II Compaq Presario towers that will anchor our network when we switch from Windows for Workgroups to Windows 95 to Windows NT. They have DVD and video camera capabilities that we hope to exploit later. I hope to set up a dedicated office Web site for staff and patient use, and a telemedicine operation allowing us additional access to our homebound and nursing home patients.
 
--contributed May 1998 by Thomas C Thornton, MD, Family Practice, Upper Sandusky, Ohio
 
 
Sections CASE 2: Making the Computer Useful
Seventeen years ago I bought my first computer, an off-the-shelf Radio Shack, and took it to the office to see how my solo practice might use it. It took six months, but the staff finally learned they could use this newfangled gadget for keeping essential patient data and for billing, and told me, quite kindly, that if I wanted one to use myself, I had best go buy another. Ever since then I have been searching for ways that computers can help me practice medicine.
 
Better machines came along and were incorporated into the practice. Based on a published algorithm, I wrote a program that helped prevent taking short cuts in the ECG interpretation procedure. Our next step was making and keeping patient notes, which I typed myself, maintaining information on floppy disks until increased storage allowed keeping all these records in one place on the hard drive. We then added spreadsheets for lab results.
 
As we added to and updated our system along the way, we had to convert our old data to various new formats. Most were fairly simple and straightforward but we had a big problem converting text material to something the newer software and hardware could handle. Then, last year, our systems engineer suggested we could use a server running Linux and let it interpret all the material we had stored. This worked, and now we can move material back and forth with little effort or risk of losing information.
 
The next innovation we are considering is speech recognition. Right now I dictate my records, notes, and letters into a small handheld recorder at the time I see the patient. These are transcribed by one of my office staff, usually the same day, into a word processor for a permanent record. At this time these are also printed as a paper record to satisfy legal requirements. With dependable speech recognition we would hope to get the dictation into the permanent computer record immediately. The leading candidate right now is Dragon's Naturally Speaking, but I expect to evaluate other systems as they become available; 95% accuracy in medical text is not good enough.
 
--contributed December 1997 by William H Burch, MD, Family Practice, Lake Lure, North Carolina
 
 
Sections CASE 1: Search for the Magic Vendor
I joined Welborn Clinic in 1982 after duty in the U.S. Public Health Service. I came with an interest in microcomputers and some introductory experience in computer use in high school and college. My limited exposure and knowledge of computers put me ahead of most, if not all, the doctors already here. The Clinic already led most practices in the use of computers for the most fundamental medical office function -- billing. Their Perkin-Elmer minicomputer ran an obscure computer language (GISER), but reliably sent out the bills.
 
In 1983, we recognized that our system had reached its limits and switched. We chose to use software from a company which up to that time had used a time sharing system to do physician billing work. Their system, which we picked in preference over an IBM mainframe system, already had most of the features IBM promised would be available "real soon now." Our upgrade, state-of-art computing for the day, brought us dumb terminals connected to a Burroughs (now Unisys) mainframe programmed in Cobol. It wasn't any time at all until we were submitting our Medicare billing on tape, improving the collection time.
 
Over the years, as Experior (our software vendor) made additions and modifications, it grew into an enterprise computing system. What started as an accounting program now includes multiple sub-systems: accounts payable, accounts receivable, inventory, general ledger, vendor lists, material management, time and attendance, HMO management, pharmacy system, and medical records. Medical records expanded out of our transcription system and includes chart tracking with bar codes. Our system vendor worked with another vendor to integrate a laboratory system with its clinical and financial parts; now it runs on our mainframe to collect and distribute lab information. Lab, x-ray, and dictation are visible on the computer for authorized users anywhere on our system.
 
As microprocessors developed and personal computers (PCs) got faster, we added a Novell network to our system. Personal computers replaced many of the mainframe dumb terminals. While some PCs run applications locally, most use terminal emulation to access the Unisys/mainframe programs. For a more detailed look at our network, check the Network Computing Magazine's June centerfold article.
 
As our system grew, we learned several practical lessons about computer systems. For example, if we wanted added features in the system, there were two ways to get them. We could pay for custom programming, either by in-house programmers or by Experior. Or, we could encourage Experior to develop the features for their system. Doing the latter through the Experior User's Group saved money and easily justified the cost of the annual User's Group meeting. Usually what we wanted was something other clinics using the system wanted, too. The cost of software improvement was therefore less if those costs were spread across all the other clinics.
 
Another thing we learned was that having only one software vendor to deal with is simpler. Since at one point we had all but one of 13 different functions integrated into the Experior package, if things went wrong, we had only two places to look: the one software vendor or the Unisys hardware vendor. This eliminated some of the finger pointing we used to get when we had multiple software vendors.
 
Unfortunately, the medical business environment has gotten almost as complex as clinical practice. Between government regulations, pharmacy needs, changes in the HMO business, and private insurance payment concerns, the demands on our enterprise software grew. Even the hardware, which we thought was so fast we would probably never exceed its capacity became limiting. We have learned that our one vendor can not provide for us the breadth and depth of expertise and knowledge we need in every area. Specialization, dividing knowledge into ever smaller, more understandable chunks, has come to enterprise computing, just like it came to medicine. For example, the Experior software does not have every feature that a dedicated HMO package offers for contract management or reporting. The standalone pharmacy packages, built very specifically to follow the usual pharmacy work flow, are easier to use. Therefore, for two years we have been looking outside our single provider system for ways of improving our information infrastructure.
 
The process we use for evaluating alternative vendors has involved computer system users from every area of the Clinic, not just the Information Systems area. We convened Clinic user meetings to develop our request for proposal (RFP). Each clinic area helped develop lists of features important to their business function, including both "must have" features and features we want, but could live without. Other mechanisms for gathering information about vendors has included our Information Systems (IS) department members quizzing friends at other clinics, and studying vendor presentations at meetings such as Medical Group Management Association. Thick RFP packages go out to various vendors we hear about if we think they may have software that does what we want.
 
Cranking the handle on this process last year popped out the names of four vendors with system software that appeared to do what we needed. Vendors' demonstrations quickly showed up shortcomings and eliminated two of the four. The final two systems, on paper at least, appeared to have enough of what we thought we needed to justify taking the next step. We sent our personnel to tour working installations at sites the vendor chose. That step proved to be the key in our decision. One might think that a vendor would suggest outstanding or superior implementations to demonstrate its product. In these cases, neither site had working software that matched what had been demonstrated in the controlled environment of "The Demo." In actual day-to-day operation, neither system had the integrated functionality of our existing system. And, as if that hadn't been disappointing enough, the initial system cost quotes from the vendor whose system looked most promising early on, rocketed upward. As we demanded ever more from their system in order to get the functionality we were used to, the price, which had started temptingly below that of our current system, climbed until the quote stood at twice our present cost!
 
We were disappointed to find the marketplace for complex, integrated packages to be so barren. So we are changing course, intending to tweak functionality by acquiring separate subsystems while we wait for the market to bring new systems on line. We have added a separate, dedicated pharmacy system, the integration of which is proceeding nicely. We are still considering whether or not to get a separate HMO package.
 
Meanwhile, we have met with our one vendor, and upgraded to its latest release to make sure that the Millennium bug doesn't bite us. We keep reevaluating complex packages, and see much innovation and improvement. And we wait, hoping that the vendor with that magic combination of the right features and price shows up.
 
--contributed August 1997 by Lawrence Judy, MD, Department of Internal Medicine, Welborn Clinic, Evansville, Indiana
 

 
Comments or questions for posting?
 
Archives of other articles