17
Special-Purpose Software
James M. Walker and Michael J. Komar
The rationale for special-purpose software to supplement the core EHR is compelling:
There are many critical clinical processes that no general EHR software is (or soon will be) able to support effectively. (One example is integrated sub-systems for simul- taneously documenting and coding procedures while capturing and labelling the asso- ciated images.) Unfortunately, most special-purpose software ends up costing an organization far more than is ever realized in benefits—financial or clinical. This chapter discusses methods for integrating special-purpose software with your core EHR in ways that will increase your odds of completing successful individual projects and of constructing an integrated, cost-effective EHR.
The Setting
Requests for special-purpose software almost invariably arise out of user dissatisfac- tion with the existing EHR. Frequently this dissatisfaction is the result of a “plain vanilla” implementation of the EHR that does not take adequate account of the work- flows and information needs of specific user groups. Dissatisfaction may also stem from user ignorance of the functions available in the organization’s currently implemented EHR. So requests for special-purpose software offer your team an opportunity to check the adequacy of your implementation and your training efforts—and to refine them both.
Another frequent cause of dissatisfaction with the EHR is the fact that many clini- cal information management needs go beyond the current (and sometimes develop- mental) scope of the EHR. This is an area where an effective partnership with your EHR vendor is critical. You need them to be organized enough to know what func- tions they plan to deliver and when—and honest enough to tell you. And you need them to deliver on schedule. Having a clear sense of whether and when new functions will be available is critical to making the business case for special-purpose software. If the new function will be available in six months, special-purpose software could not be selected and implemented in a shorter time frame. If the vendor has no plans to develop the function, it is a simple matter of estimating benefits and costs.
Another source of dissatisfaction arises out of EHRs’ remarkable effectiveness at what they do well. Because of their high performance, users (as well as informaticians) may have trouble distinguishing between what is feasible (given inevitable resource constraints and organizational priorities), what is possible (in the absence of con- straints), and what can as yet only be imagined.
134
Finally, special-purpose software may appear to be a better bargain than it is because many of the costs of a successful implementation are hidden from the customers. It is a rare sales presentation that includes any mention of the need for (or cost of) such critical project components as the needs assessment, process re-design, building and maintaining multiple electronic interfaces to other information systems, and plan- ning for data security and confidentiality. Educating your internal customers regarding these considerations is a difficult, but critical, element of managing special-purpose software effectively. A written policy ratified and consistently enforced by senior clinical and operational leadership is a critical first step in the educational process. (See Appendix 12 for an example.)
Avoiding Chaos
It should be no surprise that special-purpose software strikes many clinicians and even some managers as a panacea. As opposed to the usual compromises among different stakeholders and the wait for implementation (or enhancement) of the core EHR, special-purpose software promises a rapid, focused solution to the needs of a specific set of users. But, while this narrow focus is the reason that special-purpose software exists, it has the potential to create chaos. This is because connectivity is critical to infor- mation system effectiveness. In the same way that a personally optimized telephone would be useless if it did not connect to the standard telephone system, special-purpose software—however perfectly designed for its users—must connect seamlessly to other information systems (e.g., EHR, laboratory, image management, scheduling, registra- tion) to be usable. This is the main reason that most special-purpose software does not end up being used—even by the individuals who select it.
Understandably, connectivity seems relatively unimportant to users who request special-purpose software. They feel their own immediate needs vividly. They are unlikely to understand the importance of connectivity until, for example, multiple data- bases make creating a report difficult and expensive. In fact, it is often their customers (particularly other clinicians) who find the lack of connectivity between the special- purpose software and the core EHR unacceptable. For example, they may be mystified and impatient when echocardiography reports are not available in the EHR.
Lack of connectivity has multiple implications. The first is fragmentation of the EHR.
For example, if colonoscopy results are not transmitted to the EHR, clinical-decision support to remind clinicians of a patient’s need for colon cancer screening will be unworkable. Producing reports on the organization’s performance on colon cancer screening will require accessing multiple databases, increasing the cost (or decreasing the quality and number) of reports that can be produced.
An obvious way to increase connectivity is to build electronic interfaces among infor-
mation systems. Unfortunately, interfaces are unpredictably difficult and expensive to
build and to maintain. As Clem McDonald, a leading EHR designer, implementer, and
researcher observes, “These many different and cubby-holed systems present an enor-
mous entropy barrier to the joining of patient data from many source systems in a
single EHR. The work required in overcoming this entropy by interfacing to the many
different islands and regularizing the data they contain has been more than most can
afford. Medical data does not generate spontaneously within the medical record. It all
comes from sources elsewhere in the world, and all of the obstacles and most of the
work of creating an EHR relate to these external data sources and the transfer of their
data into the EHR.”
1Figure 17.1 illustrates the way that non-interfaced, multiple clinical information systems require repeated performance of the same task, for example, entry of the patient registration.
Another hidden cost of special-purpose software is associated with “bullet-proofing”
the system. Reducing downtime to an acceptable minimum, creating and testing a dis- aster recovery plan, and providing adequate information security are expensive of money and human resources. External regulations are not negotiable, but CDOs often make an implicit decision to operate such systems without effective fault tolerance and disaster recovery plans—a fact that users are typically unaware of until disaster strikes.
Reg Reg Reg
Reg
Reg Reg
Reg Reg
Reg Reg
Reg
Reg
DB DB DB
DB DB
DB
DB DB
DB
DB
DB
Billing Billing Billing
Billing Billing
Billing Billing
Billing
Billing Billing