In this economic climate, veterinary clinics -- and small businesses in general -- are looking for ways to cut costs, and create more value for their customers. Here at Chester County Cat Hospital, we believe we've been able to leverage open source technologies to modernize the way we work, effectively providing better record keeping and organized workflow.

These benefits aren't directly visible to our customers, but provide value to them indirectly. For instance, mistakes due to hand-writing legibility vanish. Throughput increases because, these days, most doctors can type faster than they can write -- yielding more complete records in the same amount of time. We've become more aware of what patients are present, what their needs are, and what their status is. These benefits ultimately provide what we're really after: better care at a lower cost (be it time or money).

Open vs. Closed Source

For all of the software discussed below, there exist open and closed source solutions. So why not use the closed source solutions? Well, honestly, you may very well want to use them.

It's clear that the opensource route isn't for every one. There are several concerns why you might want to stay away from opensource. The difference can be characterized in the following way:

Closed Source

  • Support: Generally good, but requires support contracts.
  • Capabilities: Fully featured
  • Ease-of-Use: Very good.
  • Price: Can range from $1000 to $100,000 for an installation, support contracts generally $1000 to $5000 per year. Cloud based solutions have similar pricing with lower upfront costs.
  • Stability: Generally excellent.

Open Source

  • Support: Community based, mixed bag regarding how much attention can be had.
  • Capabilities: Basic capabilities all present, more advanced capabilities lacking.
  • Ease-of-Use: Very good.
  • Price: Excellent -- free or very low cost, except time.
  • Stability: Excellent.

The largest difference we've experience between the two types is availability of support. To a large extent, we support our own network, servers, and software. In order to be successful with the opensource solutions it's imperative that the practice has a technical resource at its disposal. There is generally a cost associated with this that is not accounted for above. It's difficult to quantify because that very same cost gets blended with the general cost you'll have to support your computers, network, printers, etc. There are several companies that provide consulting services, but the real win is if you have someone on staff that's technical, or can get easy cheap access to such a resource.

Practice Management Software

Possible the most important piece of software that a veterinay practice runs is the the practice management software. This software tracks patient records, client accounts, invoicing, inventory, reminders, etc. There are many proprietary solutions available with varying degrees of sophistication. We have first hand experience with CornerStone and Avimark... both of which are good systems.

The first reason we've chosen to use opensource has to do with data portability. These systems tend to use closed format data storage. That means that if you ever want to move your data in the future, you'll have to jump through hoops to do it. The last data migration we performed required jumping through hoops, a lot of them. The good news is that the existing system was only half used (primary for invoicing) and so a digital record push felt like the right time to move everything.

The system we've chosen to implement here is OpenVPMS. We considered several other systems before chosing this one such as radvet and Evette. None of these seemed to be as feature rich as OpenVPMS. OpenVPMS also offered a preferrable architecture. OpenVPMS runs on tomcat (in a web browser) with a MySQL backend. Leveraging web style technologies means I would be free to use any platform I choose for the rest of the computers in the clinic. We presently are running systems with Windows XP, Linux, and Android, all connecting through to OpenVPMS.

There are several features missing from OpenVPMS that stand out including DICOM work lists, in-house diagnostic tool connection protocols, boarding schedules, and several other things, but what it does, it does quite well. And, by the way, anyone is welcome to fund projects if they have a particular need in the community. These types of features we group into the "advanced" category, and have decided not to worry about now. The initial thrust was simply to get us up and running digitally. We've succeeded in that and are very happy with this software.

Digital Radiography (PACS)

Where to start with this one? Well, if you're not familiar with PACS, it is a mechanism by which you can archive images. It deals with a special protocol (and format) called DICOM which is specially designed to house medical imaging. We had initially thought that we could just attach radiographs to the patient records in OpenVPMS. However, it turns out that having a PACS server is a good thing. It means that all of the imaging software has a place to look, speaking its own language. That is, most imaging software expects, or at least wants, to have a PACS server up and running.

After scouring all of the available PACS servers, and client utilities, we decided on dcm4che. This software is not well documented, but at least there was some setup information. Since this type of software runs in the background more than anything else, we won't spend as much time on it. It simply needs to archive our images. It does, and we're happy. There are some advanced features that we could talk about (compression, etc.) but they're not necessary, or crucial to business operation.

Our Fuji CR connects with the dcm4che server (called a modality in DICOM speak) as it reads an exposure. These images then become accessible from the server through some DICOM client software.

Many options exist for the image viewing software as well. Some of these run as stand-alone applications, and some run in web browsers. We needed to ensure that it would run on any and all computers we would deploy in the future. In order to accomplish that goal, two options exist: web technologies, or Java. It just so happens that the same folks producing dcm4che also endorse projects that do both of these things: Oviyam and Mayam. We went with Mayam simply because it was easier to deploy.

This software works very well, even though it's not at version 1.0 yet. It allows reading of CDs that we receive from other clinics, as well as viewing all our inhouse imaging. The only challenge we've had with it is exporting to JPEG. This has to do with the fact that our terminals are all running on 64-bit linux, which doesn't appear to support the JPEG encoding libraries properly. We found a work-around for this, but an easier solution might be just to use 32-bit linux, or possibly Windows. (Note: We're not discussing operating systems here because that's all very well covered elsewhere.)

Our Experience: Training and Acceptance

We were prepared for a bit of a journey in training and understanding how to use these new systems. We started with the practice management system first.

There was an immense amount of work that went into the configuration and preparation of the system (as would be needed by any system). I wrote several scripts that help move data out of the old system and into the new one. This took approximately a week (not full time). Once that was completed, we took the plunge and "turned it on" for the rest of the staff.

The first time the staff used it, there was much confusion. In the rush of patients and owners coming in and out, it was difficult to spend time to learn the system. We had held an information session about it, but there was a majority of people who said they needed to "use it to learn it". Hence a more on-the-fly learning approach was adopted. We stood over and helped everyone through the first week or so, until there was some self-sufficiency.

It's been steady progress since then, but honestly, we're still learning new things about the system as of this publishing, and continue to do so. The OpenVPMS community is continually improving and adding features. We'll keep pace as this happens.

Training and acceptance of the digital X-Ray system was very simple in comparison to the VPMS. The number of steps required to successfully operate the system is exponentially less than the VPMS. We were pleasantly surprised by the relative simplicity of this transition.

Where We Are Now

Things are running smoothly now. Everyone is past any hurdles regarding usage of the system. Any glitch that appears is usually due to trying to attempt something new, or use a new feature in some software that we hadn't before. A lot of it is user error.

While not a panacea, opensource technologies provide a way for smaller clinics to manage their costs while retaining some of the benefits had by the larger, more expensive software solutions.

The author is available for consulting on this topic, as well as other business topics. Please contact him at Chester County Cat Hospital.