10. Obstacles to Automation of
the Patient Medical Record

10.1 Project Context: Obstacles to the Success of a Project

Obstacles to the success of the project influence business decisions to continue or change the project and often provide additional business requirements for the project. See figure 10.1.

Obstacles to the project might be so overwhelming that management might determine that the project is not possible or is too costly to continue. Some obstacles may have to be taken care of immediately, while other obstacles with no certainty of occurring might require a contingency plan to take specific actions if the obstacle does occur during the project.

Obstacles often result in additional business requirements or changes to previously determined business requirements. Technical obstacles, such as computer system capacity and performance constraints, are determined by specialized technical staff rather than business people; these technical obstacles should be included in a Performance and Scalability Plan document.

Development, or even installation, of an automated patient chart system in a healthcare organization is a project of major proportions. There are many obstacles to doing so. This chapter explores these obstacles and how to overcome them. Contingency plans and additional business requirements that might result from the obstacles are listed in the last section of this chapter. Goals that could be used to measure the business requirements are also listed.

10.2 Physician Acceptance of the Automated Patient Medical Record System

Automation of the patient medical record will not be successful unless physicians and other caregivers use the system. Physician usage is particularly important.

Physician decisions in the care of their patients account for more than three-quarters of all health care costs [1]. Therefore, it is extremely important to accurately and thoroughly record and later retrieve for analysis these decisions by physicians. This can only be done if physicians, or less ideally, caregivers working for the physicians, use the automated patient medical record system.

Studies have shown that physicians, even more so than other caregivers, are reluctant to use clinical information systems [1]. A major effort must be made by HMO management to convince physicians, and other caregivers, to use the automated patient medical record system.

The experience of one facility of an HMO in the Northwest in this regard was that approximately half the physicians refused to use their facility’s automated patient medical record system and simply left the organization. These physicians were replaced with computer-literate physicians who did use the system. Physicians left even though the HMO facility chose the least automated input method: keeping point of care documentation on paper within the exam room while providing a computer system in the physician’s office. Did the facility make mistakes in implementation of their system, or will it always be the case that a large number of physicians will not want to use an automated patient medical record system?

For a caregiver to use the automated patient medical record system, the system must fit into a workflow that the caregiver is comfortable with. This is why workflow analysis before implementation of an automated patient medical record system is so very important (see chapter 11).

Of particular importance is to have quick log-on and sign-off of the system(s) the caregiver uses; otherwise, the caregiver is spending significant time logging on and off the computer. A goal should be that, with the automated system, care processes should not take longer than without the system.

Some people also contend that a caregiver will only use the automated patient medical record system if he also benefits from the system. For example, it must supply the caregiver with more useful information than without the system.

A caregiver must not only use the system, but must use the system well [2], so there is complete, accurate and organized information in the patient medical record. The accurate recording of chart information could be a particular problem if the caregiver does not directly input chart information himself during the patient interview, and either relies on others to input the information or inputs the information much later himself.

10.3 Many Paper Charts at Many Locations

Another obstacle to automation of the patient medical record in an HMO is the situation that there may currently be many paper charts in many different facilities in the HMO for a patient, as well as in many different locations outside the HMO.

Consider figure 4.8 identifying a possible set of charts that could exist for a patient in an HMO. For each facility in the HMO where the patient was seen as an outpatient, there could be a different outpatient chart. For each facility in the HMO where the patient had a hospital stay, the patient could have an inpatient chart. Psychiatry and genetic departments keep their own charts in the HMO. With alliances with hospitals and clinics outside the HMO, further charts could exist in these alliance organizations. With “point of service” agreements, allowing patients to also be seen outside the HMO, still other charts could exist.

Thus, for a single patient, there is likely to be many charts at many locations. Even after automation of the chart, this is likely to remain true, as the HMO is unlikely to have control over charts outside the HMO; this complicates the process of automating the chart, especially if the intent of automation is to produce a single complete patient medical record for a patient (sometimes referred to as a “longitudinal” or “lifetime” patient record).

There will be many different types of documents in a chart, each with a different format. Even if the documents from different organizations are of the same type, they are also likely to use different formats and have different formats for the same field (e.g., names, dates, etc.). The identifier for the patient is likely to be different [3], and other identifiers are also likely to be different (e.g., perhaps one location would use a numeric identifier for a physician, while the other might use an alphabetic mnemonic). Terminology used in each chart is also likely to differ, by organization, location or even caregiver [4].

Retrieving chart information pre-existent to the automated patient medical record is a challenge. Building an automated patient medical record system that combines patient medical record information in charts is a challenge.

10.4 Lack of Agreed Upon Standards or Inadequacy of Standards

Another obstacle to automation of the patient medical record is sometimes the lack of standards for the patient medical record and clinical information, and sometimes, the multiplicity of different, competing, standards. See the appendix.

Presumably, one of the reasons an HMO would want to implement an automated patient medical record system is to get a competitive advantage over its competitors. However, for the automated patient medical record system to evolve into the longitudinal patient record and to thus work in the long run, there must be agreement on standards for the automated patient medical record information between the HMO and its alliance hospitals and also eventually among other healthcare organizations. At first glance, agreement with other healthcare organizations on standards seems contradictory to the HMO trying to get a competitive advantage. However, assume, that the HMO goes it alone and develops its own proprietary system for storage of the patient chart, which the HMO demands that alliance hospitals also follow. If eventually, other outside organizations agree upon non-proprietary standards, then the HMO is suddenly at a competitive disadvantage. The HMO is thus best off if it works with other healthcare organizations in developing standards for the patient medical record information prior to implementing the system, even though this approach may appear to cause the HMO to lose its competitive advantage in the short run.

Further, a large HMO that first develops an automated patient medical record system using standards can have a large influence on the direction of standards and thus can insure that the standards entirely fit the needs of the HMO. This could provide a significant competitive advantage to the HMO.

The standards that are required are those for storing the detailed patient medical record information and the indexing necessary to retrieve this information; also, there must be some standard for recording patient encounters. With such standards, the HMO could also have a competitive advantage based upon additional summary information, compatible with the standard clinical information, that the HMO could keep in its own computers and upon the methods it uses to tie together the different parts of the patient chart.

Agreeing upon standards on storage of patient medical record information and indexing to retrieve it has the additional advantage that the principal information in the patient chart could be stored in a remote location, say Pacific Bell, instead of the HMO’s chart rooms and would be readily available to other health care organizations, including alliance hospitals given agreed upon security standards.

My prediction of the future, as discussed in chapters 6, is that there will be a computer-based patient record (CPR) that will be stored in a repository outside the healthcare organization. The CPR will be a standardized longitudinal (i.e., lifetime) patient record from many healthcare organizations that summarizes clinical information from each of the organizations’ patient records. See figure 10.2.

Each healthcare organization may have its own patient information in its own format in terms of “source documents” (e.g., progress notes, incident reports). A healthcare organization may opt to save its source documents off site, replacing its chart rooms. These source document depositories may be in the healthcare organization or perhaps in telecommunication or computer companies—Pacific Bell has such a source document depository for diagnostic images [5].

Ideally, the CPR repository would identify the locations of all source documents for each healthcare encounter, whether these documents are on paper in the healthcare organization or electronically stored in source document repositories. In order to locate the CPR repository for any patient, a patient registry might also be set up. The CPR might also reference clinical practice guidelines; repositories for these clinical practice guidelines might exist within healthcare organizations or nationally (e.g., the AHCPR National Guideline Database [6]).

When transmitting information over a network from one computer to another, sets of header and trailer data are tacked on to the data transmitted; this is called a layer of information. These layers are used by hardware or software to route, interpret or verify the transmitted information. After the layer is used by the hardware or software, it is stripped off. An existing network protocol standard at the applications level for healthcare is Health Level 7, HL7 [7]; this is the innermost layer used by healthcare software to interpret healthcare information. Using this protocol within the HMO is highly beneficial to the HMO, as almost all commercial clinical systems use this protocol for interfacing between their system and others. One standards organization, the ASTM (the American Society for Testing and Materials) has defined a standard for the CPR that also uses HL7 to communicate CPR information to a CPR repository [8]--this standard, the ASTM E1384 standard for a CPR, is referred to throughout this book.

The HMO must join standards organizations and have an influence over these standards.

10.5 Existing Clinical Systems

Another obstacle to automation of the patient medical record is that the HMO automated patient medical record system must be integrated with existing HMO clinical systems.

In a highly automated HMO, there is likely to be a large number of existing clinical systems prior to creation of an automated patient medical record system. See figure 10.3. The creation of the automated patient medical record system would require an interface with these clinical systems to insure the consistency of clinical information.

The information in the existing clinical systems is likely to be redundant and possibly contradictory, with the likelihood that the same information was being re-entered in multiple systems. It is also very likely that the information in these systems is not organized to support an automated patient medical record. Thus the creation of the automated patient medical record system might involve (1) interfacing with these other systems, making sure information is no longer redundantly entered, (2) changing or replacing these other systems so they supply information organized according to the requirements of the automated patient medical record system, or (3) conversion in format of information or restructuring of databases to match the needs of the automate chart system.

During the development of an automated patient medical record system, the paper chart will be phased out and existing clinic systems will be changed or phased out. There thus will be many intermediate steps in development of the automated patient medical record as the automated patient medical record system evolves. I think that the proper development process should be to first attempt to design the complete final future data base for the automated patient medical record system, and then develop an approach that evolves toward use of this final data base, incorporating changing requirements as they occur (e.g., changing standards for storage of the patient chart).

As stated in the previous section, a standard for interfacing clinical systems is HL7 application network protocol. Assume a clinical system uses this protocol. An upgraded version of the clinical system also using HL7 protocol could then replace the existing one, with minimal change to the previous interface.

Although redundancy and inconsistency in data and lack of communication between clinical systems is a potential obstacle in implementing the automated patient medical record system, correcting such problems could provide a significant benefit to the healthcare organization above and beyond the benefits gained from the automated patient medical record system. Creating a common, although perhaps distributed, data base that would result from synchronizing clinical data and getting rid of redundancies would result in a database with much greater integrity of data—data that is more likely to be correct. In this process, synchronization of data could go beyond clinical databases, into financial, personnel and other databases.

As we will see later, besides removing the possibility of redundant information, interfacing these systems with the automated patient medical record is also necessary to enable ordering through the clinical systems (e.g., the pharmacy and clinical laboratory systems) and for the automated patient medical record system to know about encounters (outpatient visits from the appointment and registration systems, inpatient stays from the ADT system, etc.) which could be used to organize the patient medical record.

10.6 Required Reengineering of the Organization

In order for the automated patient medical record system to be successful, the entire HMO care process must be reengineered, as such a system will change the way caregivers work, but, at the same time, the system must fit into the operations of the HMO, be comfortable for caregivers to use and provide more productivity in the care process. See chapter 11 for a discussion of reengineering.

This reengineering must be planned along with planning the development of the system. Because the automated system will evolve over time, incorporating more and more of the paper patient medical record into the automated one, needed reengineering will also evolve over time as the system evolves over time.

10.7 Maintenance of the Paper Chart Must be Continued

Another obstacle in automation of the patient medical record is that the paper patient charts can not be gotten rid of, at least for a long time to come.

Until the patient chart is completely automated in the HMO and all previous paper versions of the chart can be retired, the paper versions of the chart must continue to be maintained. During interim stages in the development of the automated patient record and universal patient record, a patient chart may consist of separate charts at various institutions together with automated patient medical record information from various institutions. Scanning paper charts to produce digitized image copies is a possibility, though perhaps somewhat costly, requires a lot of storage space and does not allow one institution to translate data from another like defined format or character information would. The ability to order paper charts or scanned versions of them must be maintained in the automated patient medical record system.

10.8 Emerging Technology

Another obstacle in the automation of the patient medical record is that it likely requires new technology that hasn’t yet matured, or perhaps does not even yet exist. An automated patient medical record system may require distributed technology and perhaps Internet type technology, i.e., distributed but independently controlled systems. In order to make this feasible, very high-speed networks will be required.

Multiple caregivers may be viewing or updating the patient chart at the same time. This requires “group communication” capabilities [9,10] that enable control over view of the patient chart information by multiple caregivers at the same time with possible updating at the same time.

Use of a computer during examining and interviewing the patient, could potentially detract from patient care. Use of a pen computer during the examination of the patient, where the pen computer has the appearance of the paper chart, can create greater personalization of care. Pen computers fall into two categories: a “handheld” computer (a pen computer that can be held in one hand) and a “tablet” (sometimes also called a “slate”) computer (a pen computer about the width and length of a standard, 8 ½” x 11”, sheet of paper); the one appropriate for medical care is the tablet computer [11]. Pen computers have various methods of conveying information between the pen computer and the automated patient chart system; wireless communication, if it had no complications, would provide for the most personalization of care. Further research is required to determine if wireless communications, whether infrared or spread-spectrum, is without complications; some reports of conflicts of cellular phones with defibrillators have been reported, which indicate that there may be problems with spread-spectrum, but, on the other hand, infrared has its limitations also-- infrared is point of light communication and thus cannot go through walls or turn corners.

Both where the patient medical record will be stored and the standards to be used for the format of the stored patient medical record need to be determined. Storage and quick retrieval of the large volume of information in the patient medical records for an HMO may require super high speed networks [12,13] and archival storage media capable of storing huge amounts of information cost effectively, perhaps tape cartridges or optical disk, and SANs (Storage Area Networks). Automation of the patient medical record involves distributed client-server technology, where computers of different types and manufacturers, and having differing operating systems, can be connected, whether through an Intranet or other connections.

Much of the above is, at the very least, emerging technology. Research dealing with such technology is discussed more in sections 17.2 and 17.3.

10.9 Technical Obsolescence and Obsolescence Due to Changing Standards

Because technology needed for automation of the patient medical record is changing so rapidly and because standards for a national or international patient health record have not be agreed upon as of yet, any system to automate the patient medical record has the potential of becoming quickly obsolete with upcoming technical changes and changes in standards. This is another potential obstacle to the automation of the patient medical record.

In order to develop a completely automated patient medical record, the HMO must move from relatively independent automated clinical systems, possibly using proprietary interfaces between them, to a fully integrated automated patient charting system as illustrated in figure 5.6, most likely using the HL7 standard for healthcare networking.H Because of the emerging technology required for implementation of the automated patient medical record (see section 10.8) and because of yet-to-emerge standards (see section 10.4), it may, or may not, be too early to fully implement such an automated patient medical record system and any system developed would become immediately obsolete. What I think can be done now is development of the software infrastructure for future development of this system.

Organizing the software infrastructure for a future automated patient medical record system includes organizing existing clinical systems so they provide the information needed by the future system (1) through a common database with data organized according to the future requirements of the automated patient chart system (rather than the data base being solely organized for existing clinical systems) and (2) through implementation of industry standard HL7 interfaces to transfer information from clinical systems to this database, so replacement of existing clinical systems with newer ones will be made easier.

Further plans for the automated patient medical record should be based upon the assumption that patient medical record information will be stored in the future at a site outside the health care organization along with patient medical record information from other health care organizations. The HMO should be active in developing standards for such off site storage of clinical information.

Also, because personal computers, networks, distributed systems and operating system software are changing so rapidly, any hardware or operating system that is bought now will become virtually obsolete in about two or three years. However, this is simply a fact of life about current personal computer and distributed system technology. Early large-scale investments in a hardware or distributed system infrastructure may thus not be cost effective; one approach might be to delay implementation at a location until just before the hardware is needed at the location so as to maximum the life of the hardware.

10.10 Security and Confidentiality

Another obstacle to the automation of the patient medical record is that patient medical record information would potentially become available to more people, and thus there is greater potential of problems with the security and confidentiality of patient medical information.

Laws and standards must be set for patient medical record information electronically transmitted outside the HMO. Where HMOs have direct alliances and “point of service” agreements direct agreements between the HMO and the outside organizations might also apply. Where HMOs are dealing with patient medical record information in non-affiliated healthcare organizations, laws and standards only must suffice. Healthcare organizations should also have confidentiality agreements with its employees.

Together, these laws, standards, direct agreements, and confidentialty agreements would determine

· who is allowed to view the patient medical record information

· who is able to update it

· at what points the patient medical record for a particular encounter can no longer be changed

· the legality of electronic signatures

· who may do ordering

· who may order narcotics

· etc.

Laws and organizational standards may exist for certain categories of information in the chart, including HIV and genetic test results, psychiatric care, abortions, etc. There may also be standards across healthcare organizations.

Patients are entitled to confidentiality of their own health care information. Claims for invasion of privacy might be made against a health organization that allows release of patient medical record information to an unauthorized person. For example, the patient must be protected against the fear of being discriminated against because he is tested HIV positive, the fear of being harassed due to having an abortion, or the fear that an insurance company might drop her due to having a gene that predisposes her to breast cancer or colon cancer (e.g., women with the mutated BRCA 1 gene have up to an 85% chance of developing breast cancer and up to a 60 percent chance of developing ovarian cancer sometime in their lives).

In some healthcare organizations there may be department specific security rules that were developed and agreed upon at a facility or healthcare organization level, but getting an agreement to extend such security rules beyond the single healthcare organization level may be very difficult or impossible. For example, at one healthcare organization, the genetics department wanted its charts viewable only by personnel in the genetics departments; on the other hand, oncologists would want to know if a woman had the BRCA 1 gene. The psychiatry department wanted its charts viewable only by personnel in the psychiatry departments; on the other hand, ED physicians wanted the whole patient’s medical record available to them. This agreement in one healthcare organization might be difficult to extend beyond the healthcare organization.

Laws on security and confidentiality of patient charts may differ from state to state and thus complicate creating a national, or international, patient record.

Access to patient medical record information without identification of the patient might be provided to research institutions. This allows for large-scale studies of a drug, procedure or treatment plan and allows for picking of ideal target patient populations for clinical research (although the researcher might have to be restricted from knowing the identities of the patients).

Methods of legally identifying caregivers, e.g., by user log-ons and passwords, and methods of auditing chart information access (keeping an “audit trail”), must be established. There must be methods of controlling what information a user is allowed to access or change, of insuring that information is not sabotaged or accidentally destroyed, of insuring that information is not made inconsistent with other information, and of insuring that medical information that is signed off and part of the patient’s permanent record will be preserved, yet can be corrected.

A report on electronic medical records systems privacy was done by a committee of the National Research Council in 1997 and commissioned by the National Library of Medicine, an agency within the U.S. Public Health Service’s National Institute of Health. The committee’s recommendations on improving electronic medical record security included the following [14]:

· Every employee with a legitimate need to know about information in a record should have a unique identifier or password, and anyone who shares a password or leaves records unattended at computers should be punished.

· Organizations should use additional access controls to restrict employees from getting information not necessary for their jobs. Electronic audits should be conducted routinely to track all access to clinical data.

· Points in a system that are vulnerable or set up for remote access should be strongly protected through special software, encrypted passwords or “dedicated” modem lines that carry no other electronic traffic.

· Organizations should encrypt all patient-identifiable information before transmitting it over public networks such as the Internet. That includes e-mail and messages between caregivers.

· HHS and the U.S. Office of Computer Affairs should develop a visible, central point of contact about privacy issues—a privacy ombudsman. The government ombudsman could field complaints from patients about privacy breaches.

Also JCAHO, a healthcare accreditation agency, established a set of standards for information management systems, which included security, confidentiality and integrity requirements [15].

An approach for caregiver security developed in Europe for the European Commission is to provide personal smart cards (computer chips imbedded in credit cards) to caregivers to gain access to healthcare systems, using RSA encryption algorithms [16]. The project’s name is Trustworthy Health Telematics (TrustHealth).

Encryption is the transformation of confidential plain text into a cipher text in order to protect it from being read by a third party. Encryption may have its own problems, including slowing performance, making it more difficult to detect computer viruses, and making it harder to detect when someone outside your system is maliciously accessing your patient or other information.

Perhaps smart cards could also be used for patient access to their own records through the automated system. A patient could also carry the equivalent of the CPR with him/her on a smart card. This is an approach fraught with large potential security problems such as unauthorized use and possible legal problems due to the data not being up-to-date. However, accurate information would be extremely beneficial, especially in emergency care situations. In 1987, Mark Landis started a company, Health Information Technologies, to store a patient’s medical history and to store patient insurance information, supplying healthcare organizations with card readers. The liability of inaccurate information and patient unwillingness to pay for such cards limited the success of this endeavor [17].

The Health Insurance Portability and Accountability Act (HIPAA) of 1996 for Medicare and Medicaid programs includes standards for security and electronic signatures (as well as standards for provider identifiers and taxonomy, electronic transfers, and employer identifiers) [18].

10.11 Unavailability of the System

The automated patient medical record system may become unavailable at any time, requiring caregivers to go back to a paper system or some lesser automated system. This might even occur in the middle of a visit.

With the system down, automated clinical practice guidelines and physician and nurse protocols would also be unavailable. They would now have to be on paper.

Unavailability of the automated patient medical record in the outpatient clinic and Emergency Department (ED) is no different than situations that commonly occur now: the chart can be found, the chart has not arrived, the patient has not been seen before.

There are no similar situations where the chart is unavailable in the inpatient setting. Unavailability of patient information in the inpatient setting could be a big problem.

If the automated patient medical record system came down in the hospital, then suddenly all the patient information that the clinical staff was using, and relied upon for communication between them and for patient care, might suddenly disappear.

One possible solution to this is to periodically print the automated patient medical record information at the unit. Such printed information, though not necessarily up-to-date, would most likely provide enough information to smoothly continue taking care of the patients in the unit.

Another possible solution is to save the current inpatient chart information at the unit for all patients in the unit on storage media that could later be available to the local computers. When other parts of the automated patient medical record system went down, the local computer could use this stored information. This works as long as the local computers don’t go down also.

Thus, in summary, if the automated patient medical record system came down, then two ways of continuing are the following: (1) Run from local computers from previous patient information stored locally. (2) Continue care from paper, possible using patient information printed periodically.

Once the failed component(s) come back up, patient medical record information recorded when the system was down must be sent to the automated patient medical record system. If the information was recorded in a local computer, it must be uploaded. If the information was recorded on paper, it must first be entered into the system.

It is absolutely essential that patient medical record information not be permanently lost because of a disk failure. A number of ways exist to protect against such disk failures, referred to as “fault tolerance”. Methods of fault tolerance include disk mirroring, writing the same information on two different disks with two different controllers, and striping using three or more disks and controllers and keeping the data on one disk and parity data on another disk; if data is lost, it can be reconstructed from data on the other disks. A method of using standard, lower cost, disks to do this is called RAID technology with RAID-1 being disk mirroring and RAID-5 involving striping [19].

Other forms of fault tolerance handle abnormal termination of programs due to software errors via “checkpoint/rollback”, rolling back database updates occurring during the program so the database(s) are not inconsistent or otherwise corrupted.

Methods of assuring the parts of the automated system do not go down for very long after a power failure are to provide emergency power in servers via generators and UPSs (uninterruptible power supplies) for workstations.

Excluding these short unplanned outages every now and then (and recovery procedures), the automated patient medical record system must be available 24 hours a day, seven days a week, every day of the year.

10.12 Reliability and Performance Requirements

Reliability is the measure of how well a software system provides the services expected of it by its users, including up time, accuracy of information, and speed in operation. (Up time was discussed somewhat in the last section, specifically, what to do when the system is not up.)

Reliability is an intertwined web. Unless caregivers use the automated patient medical record system for input of virtually all patient clinical information, then this information will not be easily accessible, as much of the information will still be stored on paper in chart rooms--which would defeat the whole purpose of an automated patient medical record system. If the system is down quite often, slow in operation, or does not provide significant benefits to the users, the users will not use the system unless perhaps coerced. Coercion, in turn, makes for a high turnover of users, which also decreases the reliability of the system.

Part of reliability is accuracy of patient clinical information. If a caregiver questions the data, then it is much less useful, as any time savings that would be accrued from immediacy of information through an automated system, would be eaten up by the caregiver having to extensively reverify significant portions of the patient clinical information. An important aspect of accuracy of information is real-time communication between clinical systems, as data which must be entered many different times in many different systems without immediate synchronization, has a high probability of being inconsistent.

When a computer system is not powerful enough to handle all the users, then the users may have to wait an unduly long period of time to receive back responses to what they have entered; such lack of system performance could cause a user to lose his or her train of thought. Performance monitoring, measuring the performance of an automated system while it is in operation, to monitor response time as well as other performance characteristics is important in a system as large and complicated as the automated patient medical record system with its many computers, networks and users. Highly loaded parts of the system, and bottlenecks in the system, should be identified as soon as possible so that these parts of the system could be enhanced ahead of time. In computer terms, a bottleneck is a system component that limits the performance of the system [20]

Performance testing is a carefully designed, repeatable experiment used to evaluate the performance characteristics of an automated system, hardware or application [20]. Performance testing should first be done immediately before the automated system is implemented in the Implementation step. Performance monitoring could be based upon scripts mimicking user input developed in the Business Reengineering step; see section 11.7.

10.13 Capacity and Performance: Technical Considerations

Capacity and performance requirements are such common obstacles to large-scale complex systems that they are singled out here. This section looks at capacity and performance from a technical point of view.

Automated systems must handle the current and future projected number of users, database requests, and network traffic; otherwise, the response time of users will become very large.

Business planners and capacity planners should be significantly involved in the Evaluation step, advising the organization about the feasibility of planned hardware, including networks, and planned system software to handle the current capacity and performance required and advising the organization about the future scalability of the system to take care of anticipated increases in capacity. Capacity and performance evaluations are difficult at this stage because (1) during the project, the system is likely to be used at more and more locations with increases in capacity required; (2) the requirements for the system are likely to change over the lifetime of the system with resultant increase in the demands of the system; but (3) technology to handle the capacity is likely to change, allowing for increased capacity.

The business planner would anticipate future changes in business requirements for the system over time. The capacity planner would determine if there were indeed capacity and performance concerns.

In the Evaluation step, a Performance and Scalability Plan document should be started to record anticipated capacity requirements for automated systems, anticipated needs for upgrading the system, and to identify how and when capacity and performance measurements should be done to evaluate the system.

10.14 Overwhelming Size of Project

A major obstacle to automation of the patient medical record is the huge size and cost of such a project.

The amount of work in completely automating the patient chart is overwhelming. Because it is so large, the project must be an iterative, evolutionary, one. But to make this iterative development possible, the entire project must be extensively pre-planned.

For example, an HMO may be composed of a number of regions (e.g., the East, the Midwest, the West and the South) with many facilities in each region. Each region may have alliances with other health care organizations where their patients may also be seen. Because an automated patient medical record system works well when implemented for a single facility does not necessarily mean that it can be upgraded to work well for multiple facilities or regions. If the system is not pre-planned to be designed for multiple facilities, regions and organizations, then it is very unlikely that the system would be able to smoothly evolve into a system that could be expanded to completely automate the patient medical record, creating a longitudinal patient record.

As part of implementation of any part of the automated system, criteria for the success of that part of the system should be established with criteria that can be measured. This criteria for success may be improved service for patients, timesaving, improved accuracy of information, or greater monetary reimbursements. Measurements should compensate for a temporary overhead of having both a non-automated and partially automated patient medical record.

Redesign might be required where the success criteria are not realized, with a reconsideration of the effects of the redesign on the entire system. The success criteria of certain parts of the system might simply be that these parts of the system have been completed, as they might not provide any measurable benefit other than being absolutely required to create a useful automated patient medical record system (e.g., establishment of a network, hardware and system software infrastructure, and of other infrastructure items).

10.15 Costs

The costs of an automated patient medical record system could be enormous. Costs are at least in four areas:

· infrastructure costs: the costs of virtually everything that is hidden that is connected with the automated patient medical record system. This includes the costs of user, technical and other meetings to design the system, the “blueprints” for the system, the costs of planning for, and making changes, to buildings, including new wiring for the system, logical database design, etc. (These costs are usually substantial and all occur without any visible payoff.)

· development and implementation costs: the costs of developing, installing, and implementing the automated patient medical record software system. This includes the physical database design and the programming, and this includes putting the computers in the pre-planned places in the medical centers.

· training and personnel costs: the costs of training; of lost personnel time due to learning and training, and not doing their normal jobs; and the costs of resistance to the system.

· maintenance costs: the costs of preserving the system so it is not deteriorated and so necessary changes are made to it. The costs include the substantial costs for maintenance staff to service installed hardware and software, support the controlled documentation and identify, prioritize and quickly make maintenance fixes to any parts of the system that may be used by users, with the feedback of these fixes to development staff. (This is a huge cost mainly due to the long time frame that the system undergoes maintenance.)

This section will discuss the minimization of these costs based upon the following ideas:

1. Build the automated patient medical record system correctly

2. Standardize to control scope

3. Build the organizational infrastructure first

4. Measure feasibility before implementing

5. Build iteratively, if possible, identifying and initiating subprojects with early payback

6. For infrastructure outside the organization, use someone else’s infrastructure.

7. Encourage component adaptability in the healthcare industry for systems with interface with the automated patient medical record system (e.g., clinical laboratory systems, ADT systems, etc.)

10.15.1 Build the System Correctly

According to reference [21], costs of any computer system can be minimized via the following means:

· Design the system right to begin with: develop requirements for the automated patient medical record system that fit the needs of both the HMO and the general health care community

· Develop the system right: make sure that these requirements are built into the system when the system is being developed

· Build for the next: build for expandability for the future and anticipated future changes in requirements.

I would also add the following to the list because an automated patient medical record system is such a large project and thus must be developed incrementally:

· Build for the current and previous: because the automated patient medical record system must be done gradually, enable current systems, for example, the paper chart system, to function also. (Building the automated patient medical record system is sort of like building a superhighway in the right of way of an old highway: you want old highway to be useable while you build the new one, and thus have to do additional engineering work to do so.)

An additional reason for building for the current and previous is that it is desirable to also include patient clinical information for HMO patients from outside health care organizations that the HMO may have little control over (e.g., hospitals who have alliances with the HMO).

To design the system right to begin with and to do it economically, I think you have to treat such a system, which is largely untried, like other such projects that were new and untried: NASA and the space program, or the building of the Panama Canal. Put together a nucleus of people that have a strong academic interest in the area and are willing to reason out the best ways of doing things, based upon their intellectual interests in the area. Consider the project to be consisting of a number of research areas to be studied (e.g., a CPR repository, searching through the automated patient medical record, distributed systems and network technology, etc.) See Chapter 17 for a discussion of many of these research areas.

Developing the system right is a matter of creating good design requirements, hiring good computer software and hardware people, and executing a lot of discipline in following the requirements. Further, the overall design must be validated first before deploying it in possibly many thousands of computers.

For the concept of “build for the next”, I will use the term “flexible”. For the concept of “build for the current and previous” as well as build for the initial version of the automated patient medical record system, I will use the term “broad”. Costs for development and infrastructure can be minimized by creating a system that is broad and flexible. “Broad” means that it can handle current non-sophisticated solutions for the patient chart (e.g., paper patient charts and e-mail) as well as initial automation of the patient medical record. “Flexible” means that the automated system can be upgraded in capabilities without having to be extensively changed (e.g., the initial automation of the patient medical record can be extended to include a national Patient Health Record with clinical information from other healthcare organizations; business policies can be changed without large changes to the automated patient medical record system).

Examples of “broadness” are the following:

· The automated system can order paper charts, for later manual transport, as well as gather automated patient medical record information transferring the information over computer networks

· Small facilities can send e-mails/messages summarizing patient encounters to the automated system and repositories, while large facilities could send complete patient clinical information

· Besides providing direct input of clinical information through specially formatted GUI (graphical user interface) screens, or through pen input, while interviewing the patient, the system gives the user the option of inputting documents through automated forms that duplicate the paper form so information from paper forms can still be used.

Examples of “flexibility” are the following:

· Interfacing clinical systems are set up to communicate with the automated patient medical record system via established standards (principally via HL7 [7]--see section 12.11.6) so they can be more easily replaced when other improved clinical systems become available

· The automated patient medical record system supports the ability to integrate products from multiple vendors (such as by use of Cooperative Business Objects—see section 11.2.2). (The system must follow “open standards”.)

· Future technology, such as gigabit ATM (Asynchronous Transfer Mode) WAN networks and gigabit Ethernet LAN’s for transferring diagnostic images and multi-media information or voice technology transcription, can be implemented as needed without large changes to the system. (The future technology must be compatible with open standards.)

· If necessary, systems are developed or purchased that are “portable”, i.e., a system is able to run on the different computer system architectures that will be used

· An important part of flexibility is “scalability”, those characteristics of system structure that allow it to grow gracefully: the number of users or distributed computers or the data volume can be increased and the system still works and still works efficiently.

· Changed health organization business policies can be implemented quickly without significant changes to the system (see section 7.6).

“Broadness” and “flexibility” decrease costs in that the system does not have to be implemented all at once, but can be implemented incrementally. New health care institutions can be quickly made part of the system, even when they currently use unsophisticated technology. The infrastructure required for the automated system (e.g., high-speed networks) can be incorporated as it is needed, not before it is needed.

10.15.2 Standardize to Control Scope

Some CIO’s of large corporations (Hewlett-Packard and 3M Corporation) have stated in computer conferences that the way to minimize costs of a new large system is to use only standard, already matured, systems. This means that where more expensive technology is needed in the automated system (e.g., PACS systems), systems should have been around a number of years rather than being state of the art, and, in all other cases, well established standard, preferably identical, computer, server and workstation systems should be implemented throughout the healthcare organization. There are a number of reasons this philosophy could minimize overall costs:

1. Standardizing on systems greatly decreases maintenance costs, as there can then be company-wide standard procedures for fixing systems and for providing help to users.

2. Standardization of systems opens up the possibility of remote distribution of new software; otherwise, personnel would have to load the new software individually on each machine.

3. Implementing systems that follow open standards offers greater future flexibility in replacing and matching up systems that make up the automated patient medical record system.

4. Systems would be able to communicate with each other when necessary (e.g., one PACS system could transfer medical images to another system, whereas incompatible systems may not be able to do so).

5. Unique new non-established technology is likely to become obsolete very quickly, as the technology industry either tries to sell a better product or more of an established product in quantity.

6. The cost of brand new technology decreases in price as it matures; delaying its implementation usually greatly decreases costs.

10.15.3 Build the Organizational Infrastructure (Correctly) First

The infrastructure is virtually everything that is hidden that is connected with the automated patient medical record system. This includes the costs of user, technical and other meetings to design the system, the “blueprints” for the system, the costs of planning for, and making changes, to buildings, including new wiring for the system, logical database design, etc.

The infrastructure of a computer system is analygous to the foundation, structural components, plumbing, electrical works, etc. of a house. If the infrastructure of the house is not done right then something is going go seriously wrong with the house later on, even to the extend that the occupant might get killed by house falling down.

Likewise, many, many future costs of the automated patient medical record system could be saved by doing its infrastructure first and doing it correctly.

10.15.4 Measure Feasibility Before Implementing

Despite any standardization approaches chosen, the automated patient medical record system involves new technology and ideas. Any implementation may involve thousands of workstations and many other computers. Any implementation involves implementing many ideas over and over again. In order to minimize the risks of accidentally implementing a very costly idea, the following should first be done:

· create a “testbed” system where new ideas can be tested and validated

· implement and evaluate the system in a pilot site first

· build the system iteratively, continually evaluating the system, especially early on before too much money is spent.

· do a complete overall design of the system first so every part you build will fit together.