printer friendly version

Liability of Hospitals and Their Officials When Technology Projects Fail

By Randy Gainer and Scott Coplan
[November 2003]

Reproduced with permission from BNA’s Health Law Reporter Vol. 12, No. 39, pp. 1528-1535 (Oct. 2, 2003) © 2003 by The Bureau of National Affairs, Inc. (800-372-1033) http://www.bna.com

Hospitals and other health care providers are likely to spend more than $100 billion over the next decade to convert paper records to Electronic Medical Records ("EMRs"), to enable doctors and staff to use wireless handheld devices, to implement Computerized Physician Order Entry ("CPOE") systems,¹ and to comply with the Health Insurance Portability and Accountability Act ("HIPAA").² Many hospitals that have tried to implement information technology ("IT") projects have learned the hard way that such projects are difficult to complete successfully.³ When hospitals attempt to deploy IT projects and fail, they will not only incur operational costs. They and their officers and directors may also face claims from investors or the state attorney general, and from patients and vendors. This article explains how hospitals and their officials may be liable when IT projects fail and describes steps they can take to minimize their exposure to lawsuits.

Hospital IT Systems Are Mission Critical

Doctors must have timely and accurate information to treat their patients.⁴ Fragmented and inaccessible information threatens patients' lives.⁵ Technologies that improve the way doctors and other health care providers' use information can reduce medical errors and improve patient safety.⁶ Although the failures of IT projects at Cigna, Cedars-Sinai Medical Center, Beth Israel-Deaconess Medical Center⁷ and Oxford Health Plans⁸ show that hospital IT projects can be unsuccessful, U.S. hospitals nevertheless must improve their IT systems. Such improvements are required by statutes,⁹ rules,¹⁰ and clinical practice guidelines.¹¹ If hospitals fail to adopt technologies that have been shown to be effective, they increase the risk that a judge or jury will find that they committed medical malpractice.¹²

The Pace of Hospital IT Projects Is Increasing

United States hospitals lag behind those of Great Britain, Australia, New Zealand and Sweden¹³ in adopting computerized clinical systems.¹⁴ As of 2001, less than ten percent of U.S. hospitals had adopted EMR systems and less than five percent used CPOE systems.¹⁵

Proponents of health care IT reform have proposed that the federal government establish a $5 billion loan fund to help defray the cost of health care IT projects.¹⁶ The Patient Safety and Quality Improvement Act passed in 2003 by the House of Representatives would authorize $25 million in each of fiscal years 2004 and 2005 to permit the Secretary of the Department of Health and Human Services to make matching grants to deploy and evaluate CPOE systems and other health care technologies.¹⁷ The Senate is considering similar legislation.¹⁸

While it may cost several million dollars to convert to a CPOE system and may take up to three years to implement such a system,¹⁹ one hospital that installed a CPOE system estimated that the hospital saves between $5 million and $10 million annually by using the system.²⁰ Some experts estimate that complying with HIPAA regulations will cost health care providers more than $5 billion,²¹ but the cost of failing to comply with HIPAA requirements may result in statutory penalties and exposure to class action lawsuits filed by patients claiming multi-million dollar damages.²² To take advantage of the benefits of new information technologies, to comply with HIPAA, and to avoid the risks caused by falling behind as technology develops, many hospitals are deploying new IT systems.²³

How a Hospital IT Project Can Fail

Successfully deploying a hospital IT project is challenging. The following example, based on an actual project, describes how a hospital IT project can fail.

A large, multi-facility health care provider ("the hospital") hired an IT vendor to replace the health information system at its multiple in-patient and ambulatory care facilities in response to a request for proposals from the hospital. The proposed system included several subsystems provided by subcontracting vendors, interfaced with existing Commercial-Off-The-Shelf ("COTS") systems from other vendors that were previously installed at the hospital or operated through an application service provider, and interfaced with other systems that were custom-developed and maintained by the hospital.

The vendor was chosen from among candidates that had proposed various products. The hospital's project team conducted an evaluation, selected the vendor, negotiated an agreement, and the implementation started. Problems were discovered after the new system went "live." The system failed to meet users' needs and the vendor was unable to correct deficiencies. The agreement between the hospital and the vendor did not include sufficient protections for the hospital in the event of such disputes. The IT project, budgeted at over $140 million, ground to a standstill, while participants engaged in finger pointing. Meanwhile, users, third party payers, and patients were exposed to faulty information, incorrect billings, and service delays.

The hospital hired a consultant team to assess the situation, to prepare a recovery plan, and to identify measures to reduce the risk that subsequent IT projects would fail. The hospital's board wanted to resolve the issues that had derailed the project as quickly as possible.

To diagnose the problems that had caused the project to fail, the consultants identified key project representatives and interviewed them. They also reviewed project documentation, including the project contract, the work plan, examples of software application code, trouble reports and correspondence.

The problems that prevented the project from being successfully completed included the following:

• Project requirements were not adequately defined.
  
  
• The hospital did not prepare risk and quality management plans.
  
  
• The hospital's attorney, who prepared the contract for the project, had no experience with IT acquisition and implementation contracts.
  
  
• Essential vendor staff did not have adequate training or previous implementation experience with the system being provided.
  
  
• Although the hospital was contractually able to request removal of key vendor personnel, it did not do so.
  
  
• The vendor did not adequately understand the software modifications that were required to support the hospital's unique business environment.
  
  
• The implementation schedule did not take into account the operational impact on the hospital's facilities, which led to pressure to convert, implement and accept the new system too quickly.
  
  
• The vendor's software quality assurance program was inadequate.
  
  
• The project plan was not divided into specific measurable deliverables, depriving the hospital of one key way of controlling (i.e., monitoring, detecting and preventing) problems that could prohibit the project from achieving its intended objectives.
  
  
• The vendor did not fulfill the many requirements defined in the RFP (e.g., delivery of required software functionality).
  
  
• The vendor did not follow standardized procedures for writing code. Consequently, an essential portion of the project could not be easily maintained.
  
  
• Many production problems were found in the billing software and were never resolved.
  
  
• The vendor's standards and controls for maintaining the new system were inadequate and did not meet industry standards.
  
  
• As a result of defects in the application software, unverified bills were sent to third party payers.
  
  
• The acceptance test period was too short to determine whether many of the application functions operated properly (e.g., closings for accounting periods, building census information, etc.).
  
  
• The impact of the data conversion strategy and data conversion software—both on the hospital's accounts receivable from its patients and the workload that the data conversion effort generated for hospital staff—was not properly defined.
  
  
• The timing of the conversion to the new system required that the old system be abandoned rather then permitting the old and new systems to run in parallel during the first few months of the new system's operation. This requirement prevented the hospital from returning to the old system when the new system proved unstable.
  
  
• The procedure for the hospital to report trouble with the new system was cumbersome and complicated, requiring several levels of approval before the vendor was notified of an issue. This process made it difficult for the vendor to respond in a timely manner, and in some cases, made it impossible to re-create and resolve problems.
  
  
• The vendor did not properly control the versions of its software, sometimes mistakenly installing earlier, uncorrected versions instead of updated, tested and corrected versions.
  
  
• The hospital did not use a valid test methodology. In addition, the vendor did not have sufficient staff to support the software testing that was attempted.

The hospital staff who were responsible for managing the project could have prevented most of these problems if they had followed standard IT project management principles. Any vendor can misrepresent itself and its products and can fail to deliver as promised. If, however, a hospital's project management team adheres to project management standards, has cohesive requirements against which to validate the vendor's products and services, and has comprehensive and workable standards for controlling and measuring compliance, the possibility that the vendor can "work around" or "misunderstand" the hospital's specifications will be greatly reduced.

Potential Liability for Failed Hospital IT Projects

If hospital officials mismanage an IT project, they and the hospital may face several types of legal claims. The ownership of the hospital affects the parties who may bring claims.

Claims Against Hospitals Owned by Publicly Traded Corporations

Publicly traded corporations, including those that own hospitals, must comply with the Securities Exchange Act of 1934 ("the 1934 Act") and with rules adopted by the Securities Exchange Commission ("SEC") to enforce the 1934 Act and its amendments. The Sarbanes-Oxley Act of 2002 ("Sarbanes-Oxley")²⁴ added new reporting requirements to the 1934 Act. The SEC adopted rules in 2002 and 2003 to enforce Sarbanes-Oxley requirements.

Before Sarbanes-Oxley

Even before Sarbanes-Oxley was enacted, hospitals owned by publicly traded corporations, as well as the officials, directors and auditors of the hospitals, faced huge potential damages if they tried but failed to implement a hospital IT project unless they disclosed the risks associated with the project to investors. The court decisions in the Oxford Health Plan Security Litigation²⁵ provide a textbook case of the legal liabilities that may arise if publicly traded corporations that provide health care unsuccessfully attempt a major IT project without publicly disclosing the risks.

Oxford is a managed care company that provides health care services on a prepaid basis through a network of medical service providers to members in four northeastern states.²⁶ In 1996, Oxford attempted to upgrade its computer system, including its billing and claims processing services.²⁷ According to the plaintiffs, the computer conversion was "a disaster."²⁸ Consultants from Oracle Corporation determined that Oxford's computer system was so deficient that Oxford should stop adding functions and data to it.²⁹ The computer problems caused Oxford's financial reporting systems to be in disarray, caused them to produce inherently unreliable data, and made them incapable of providing accurate financial statements.³⁰

In May 1997, the New York State Insurance Department determined that Oxford's internal controls were severely deficient and fined Oxford $3 million, directed Oxford to increase its reserves by millions of dollars, and ordered Oxford to terminate management personnel, including the CFO, and to replace two leaders of the KPMG auditing team that had audited Oxford's financial statements.³¹ In 1997, Oxford had to take charges on its books for more than $500 million when more than 57 lawsuits were brought against Oxford related to the mismanagement of the computer conversion project.³² In October 1997, shortly after the New York State Insurance Department demanded a meeting with Oxford's Board of Directors, Oxford announced that it would report a loss of between 83 and 88 cents per share for the third quarter of 1997, rather than the previously estimated profit of 47 cents per share.³³ After that announcement, the value of Oxford's common stock dropped 62%.³⁴ A month and a half later, when Oxford officials announced that the company would be forced to increase its claims reserve by $164 million and reported an expected net loss of $120 million for the quarter ending in December 1997, the stock dropped another 15%.³⁵ The court to which the numerous cases were transferred refused to dismiss the claims by investors in Oxford stock,³⁶ then certified the investor lawsuit as a class action.³⁷ The investors' lawsuit was consolidated for trial with a shareholders' derivative lawsuit against corporate executives.³⁸

Under the 1934 Act, when a company such as Oxford registers stock for sale in the public market, it is required to file annual reports on SEC Form 10-K, quarterly reports on Form 10-Q, and reports of certain material events on Form 8-K.³⁹ Many of the claims in the Oxford cases were based on statements in and omissions from disclosure statements filed by Oxford officials.

The plaintiffs claim in the Oxford Health Plans Securities Litigation that the corporation and its officers violated the disclosure requirements of the federal securities law in effect before Sarbanes- Oxley was enacted. The plaintiffs also claim that the corporate officials and directors violated their duty to supervise and monitor the conduct of the corporation as required under the corporation laws of the state of Delaware, where Oxford is incorporated.⁴⁰ The Oxford Health Plans cases demonstrate that, even under pre-Sarbanes-Oxley laws, corporate officials must report the risks of IT failures to the public if they know about those risks, so that potential investors can make investment choices based on all pertinent facts. The cases also demonstrate that, again even under pre-Sarbanes-Oxley laws, directors have an obligation to assure that a corporation has adequate recordkeeping and that managers adequately supervise the company's operations.

The cases also illustrate that shareholder derivative claims against corporate directors for nonfeasance and acquiescence to management misrepresentations will not be dismissed on the basis of the "business judgment rule" "where directors have either abdicated their functions, or absent a conscious decision, failed to act."⁴¹ The business judgment rule is "a standard of judicial review for director conduct."⁴² In refusing to dismiss the nonfeasance claims against the Oxford directors, the court relied in part on an earlier Delaware case, In re Caremark International, Inc.,⁴³ which held that, even though directors and officers may not be liable for wrongdoing that they have no reason to suspect, they have an affirmative duty to establish a corporate compliance system. Caremark also held that a lack of good faith by directors can be established by showing "a sustained or systematic failure to exercise oversight and assure adequate recordkeeping."⁴⁴

After Sarbanes-Oxley

Sarbanes-Oxley and the SEC rules implementing that act require principal executive officers of publicly traded companies and their chief financial officers to certify that each quarterly and annual report contains no untrue statement and omits no material fact that would make the report misleading.⁴⁵ CEOs and CFOs must also certify in the quarterly and annual reports that the companies have "internal controls" and "disclosure controls and procedures" that ensure that company executive and financial officials are timely receiving the information that they must, in turn, disclose under the 1934 Act.⁴⁶ Because the failure of a major IT project could materially affect the company's operations and finances, which the officials would be required to disclose,⁴⁷ internal controls and disclosure controls and procedures must alert corporate officials to the status of such projects.

Sarbanes-Oxley therefore requires that CEOs and CFOs of hospitals owned by publicly traded corporations be kept informed of the status of major IT projects and the risks that may cause the projects to fail. Unless internal controls and disclosure controls and procedures would make them aware of such risks, CEOs and CFOs should not sign the quarterly and annual certifications required by Sarbanes-Oxley. If the controls and procedures are working and the officials are aware of IT project risks, they must disclose the risks in the reports. Failure to do so could cause the officials to be personally liable if the IT projects fail and the hospital suffers losses.

The procedural mechanisms for lawsuits such as those against Oxford are provided by federal and state statutes and by federal and state court rules. Investors who are damaged by corporate disclosures that are misleading or omit material facts have the right to bring claims under the 1934 Act.⁴⁸ Shareholders of a corporation may bring derivative lawsuits against corporate directors and officers on behalf of the corporation for the officers' and directors' breach of their duties of care. The right of shareholders to bring such derivative actions is stated in the Model Business Corporations Act⁴⁹ and in the procedural rules of both the federal courts and most state courts.⁵⁰

These procedural mechanisms for investor and shareholder lawsuits are complemented by the efforts of stock analysts who monitor the performance of most publicly traded stocks. Stock analysts track the performance of such corporations and, when the analysts report corporate mismanagement, the price of a stock falls. Falling stock prices, in turn, provide incentive to investors and shareholders to bring lawsuits against the corporations and their officials. Entrepreneurial attorneys of the plaintiffs' class action bar "are eager to help them do so because of the possibility of attorney fee recovery."⁵¹

The combination of strict corporate disclosure rules, Sarbanes-Oxley annual and quarterly certification rules, the duty of care imposed on corporate officials and directors, and statutory causes of action empowering investors and shareholders to sue publicly traded corporations and their officials and directors make IT projects dangerous. Corporate officials and directors can reduce the legal risks inherent in major IT projects if they publicly disclose the risks that the project might fail and if they ensure that the project is carefully managed.

Claims By Patients

Investors are not the only potential plaintiffs who could sue publicly traded hospitals and their officials for mismanaging IT projects. If a patient is harmed because a hospital did not have an EMR, CPOE, or other IT system in place and, under the applicable standard of care, the hospital should have had such a system,⁵² or if a patient is harmed because a deployed IT system generated inaccurate data, the patient or his or her family could bring a claim for medical malpractice.

Claims Against Non-Government, Nonprofit Hospitals

Nonprofit institutions owned 61% of the hospitals in the United States in 2000.⁵³ In the late 1990s, nonprofit hospitals provided 56% of all hospital beds and accounted for 70% of all hospital expenditures.⁵⁴ While nonprofit hospitals have been subject to substantial financial pressures in the last few years,⁵⁵ many have invested in IT projects. At least 27 of the 100 "most wired hospitals" appear to be owned by nonprofits.⁵⁶

When the officers and directors of nonprofit hospitals undertake IT projects, they must perform their duties with at least the care that an ordinarily prudent person would use under similar circumstances, including the duty to exercise reasonable inquiry.⁵⁷ In a few states, nonprofit directors are held to an even higher standard of care. In those states, they must act with the skill and care of persons of ordinary prudence in dealing with their own property.⁵⁸

Courts and legal commentators do not agree whether the business judgment rule should apply to the actions of nonprofit corporation officers and directors.⁵⁹ If the business judgment rule is used to review nonprofit officers and directors' actions, they will be shielded from liability for affirmative decisions unless they were grossly negligent. The officers' and directors' duty of care, however, contains two constituent duties: the duty of attention and the duty to obey the law and the purposes of the nonprofit corporation as expressed in its articles and bylaws.⁶⁰ The duty of attention, as its name suggests, requires officers and directors to be attentive to their responsibilities.⁶¹ As the court held in the Oxford Health Plan Securities Litigation, where directors abdicate their responsibilities or fail to act, the business judgment rule does not apply.⁶² Accordingly, if a nonprofit hospital's IT project fails because the nonprofit's officers and directors fail to monitor and supervise the project, the business judgment rule will not protect them even in those states that apply the rule to gauge nonprofits' officers and directors' conduct.

More important regarding the potential liability of nonprofit hospitals and their officials for failing to competently manage IT projects is the lack of standing of parties who may sue such hospitals and their officials. State attorneys general are the main enforcers of the public's rights regarding nonprofit corporations and are the primary source of litigation against nonprofits.⁶³ Donors and beneficiaries of nonprofits must have a "special interest" in the nonprofit that goes beyond the benefit conferred on the public to be granted standing to sue a nonprofit.⁶⁴ The offices of state attorneys general are overburdened, short of funds and lack manpower to devote much effort to policing nonprofits.⁶⁵ On the other hand, recent scandals involving nonprofit organizations have caused an increase in investigations into decision-making by nonprofit health care organizations.⁶⁶ Thus, while there are fewer potential litigants against nonprofits than against hospitals owned by publicly traded corporations, nonprofit hospitals, their officers and directors face potential claims from state attorneys general if they fail to adequately manage IT projects.

Additionally, as with hospitals owned by publicly traded corporations, the patient or his or her family could sue a nonprofit hospital for malpractice if the patient shows that he or she was harmed because the hospital did not have an IT system that the hospital should have had to meet the applicable standard of care, or if a system caused harm to a patient by generating inaccurate
data.⁶⁷

Claims Against State and Local Government Owned Hospitals

If a state or local government owned hospital attempts to implement a major IT project and fails to complete it due to mismanagement, lawsuits against the hospital and its officials are possible in at least 17 states. In those states, state legislatures have waived sovereign immunity in a manner that permits lawsuits against publicly owned hospitals.⁶⁸ In 14 other states, however, state legislatures have retained sovereign immunity for claims the state, state employees, or public hospitals and their employees based on the exercise of a discretionary function against, whether or not the discretion has been abused.⁶⁹ The management of a hospital IT project requires the exercise of discretion. Accordingly, claims against public hospitals and their officials for failure to manage hospital IT projects would be barred in those states that bar claims based on discretionary acts.

In those states that permit claims against public hospitals based on discretionary acts, concerned taxpayers and other members of the public at large do not have standing to sue the hospitals or their officials for mishandling IT projects.⁷⁰ It appears, therefore, that the only groups of potential plaintiffs who could sue a public hospital and its officials for mismanaging an IT project (other than the vendors of the IT system⁷¹ ) would be patients harmed because the hospital did not have an IT system that it should have had and patients harmed because an improperly deployed system provided flawed data.⁷²

Claims by Vendors

Regardless of whether a hospital is owned by a publicly traded corporation, by a nonprofit, or by a state or local government, if a large IT project fails, the hospital may claim the project failed because the vendor breached its contract. If vendor staff are forced to defend their performance, they will not hesitate to point out any instances where hospital officials failed to perform their duties under the IT contract.

Litigation between IT system buyers and vendors often centers on a debate about who caused the project to fail.⁷³ Hospital officials should ensure that any hospital staff involved in the project perform all of their contractual duties and document that they have done so. If hospital staff fail to perform their contractual implementation duties or if they cannot prove that they performed those duties in the face of vendor claims that hospital staff caused the project to fail, the hospital may be unable to recover damages from the vendor even if the vendor caused the project to fail. Worse, if hospital personnel fail to perform contract-mandated tasks or fail to document their performance, a vendor may win substantial damages against the hospital even if the vendor was at fault.

Managing Hospital IT Projects to Minimize Legal Risks

Recommended Contract Terms

Hospital IT project contracts should be carefully negotiated and drafted to make sure that both the hospitals and the vendor's interests are addressed.⁷⁴ Although IT vendors often present hospitals with "standard contracts," hospitals should never accept such contracts without requiring that they be changed because they favor the vendor. If possible, the contract should be prepared by an attorney representing the hospital who is skilled in negotiating IT contracts. While most vendors may be ethical and have their clients' interests at heart, frequent acquisitions of technology companies and turnover in vendor personnel can cause even the best-intentioned agreement to be inadequate. Given that it takes months for hospital staff to identify a technological solution, it may cost hundreds of thousands of dollars, if not more, to implement that solution, and the hospital may incur substantial liability if the project fails, hospital officials should spend the time and money it takes to have the proposed contract reviewed by an experienced attorney.

IT project contracts should cover many important issues. Not all of them are addressed here, but those most important to assure that such projects are successfully implemented include the following:

• Specifications - Detailed specifications should be completed before implementation begins. The vendor should understand that it will not be paid if the delivered system does not comply with the specifications. Hospital IT staff, on the other hand, should understand that if the hospital receives what is specified, it will have no right to complain even if it turns out that what the hospital specified was not what it needed.⁷⁵
  
  
• Payment Schedule - Payments to the vendor should be tied to project completion milestones. A substantial portion of the total purchase price should be held back until final acceptance criteria are met.⁷⁶ The contract should provide that the vendor will be paid only after the hospital has received and tested each phased deliverable. Acceptance testing should test software and all other system components to requirements stated in the contract.⁷⁷ Final acceptance testing should be done with actual data under "real world" conditions after the system "goes live."⁷⁸
  
  
• Performance Criteria - Acceptance criteria should include throughput measurements. The system should perform so that screens are refreshed and data are transmitted within specified (millisecond) time periods. It should not be sufficient that the system "works" if it takes seconds or minutes for users to complete multi-step functions using the system.
  
  
• Vendor Personnel - The contract should require the vendor to assign an adequate number of qualified personnel to complete the project successfully, on time, within budget, and with required functionality. If possible, key vendor staff who have a history with the project should be identified by name and the vendor should be precluded from reassigning those personnel without the hospital's consent.⁷⁹
  
  
• Delay Damages - The contract should state that the vendor will pay liquidated (i.e., predetermined) damages if it fails to meet milestone target dates or if it exceeds cost levels in the absence of written change orders approved by both parties. Early completion bonuses may be useful in encouraging the vendor to beat milestone targets.
  
  
• Warranties and Remedy Limitations - Any warranty disclaimers, remedy limitations, or liability limits should be carefully reviewed⁸⁰ and should be as protective of the hospital as possible. For example, any damages limitations that the vendor wants for itself should also apply to the hospital. Responsible vendors should be willing to warrant that the system will comply with agreed specifications.⁸¹ The contract should include a warranty that the deployed system will interoperate with all customer-specified software and hardware, including future versions of listed third-party software.⁸² The vendor should be required to promptly cure all breaches of these warranties.
  
  
• Post-Implementation Support - The contract should require the vendor to correct postimplementation design and programming defects within specified time periods. Tiered response levels should require prompt attention (typically within an hour) to critical defects while allowing longer time periods to correct less critical defects.⁸³
  
  
• Patient Data Safeguards - Vendor personnel will have to use patient data in deploying and testing the new system. The vendor and any subcontractors should sign HIPAA business associate agreements that require them to keep such patient data confidential. Other terms that should be included in IT system contracts include: source-code escrow provisions; sections that state clearly who owns the software that is part of the system, including any modifications to the software made by the vendor or by hospital staff; and sections that prevent exorbitant licensing fees from being extracted from the hospital if additional hardware, different database software or a different operating system is needed or if the hospital needs to migrate the software due to an acquisition or merger.

Project Management Steps

Hospital IT staff should ensure that proven project management standards are applied in the process of planning, analyzing, designing, acquiring and implementing IT systems. Such standards include performance reporting and the development of, and compliance with, a Software Project Management Plan. The Plan should describe system implementation steps in compliance with the Institute of Electrical and Electronics Engineers Standard 10581998 and Project Management Institute methodologies.

Project planning that follows these standards may require a significant investment in time and resources, but the investment should produce clearly defined and easily understood objectives, tasks, responsibilities, and a basis for acceptance testing, which will cost much less than trying to recover from a failed implementation. Additionally, proper planning from project inception reduces the risk that business issues arising during contract negotiations will be misunderstood, which will strengthen the hospital's bargaining position during the negotiations. If the hospital can clearly identify what it needs, and the mechanisms are in place to ensure that those needs are met, the vendor will be less likely to find a "loophole" that will allow it to deliver inappropriate products or services.

Regular performance reporting is essential to successfully manage an IT project. Depending on the project schedule, monthly or more frequent reporting should address:

• Status Reporting - where the project is in terms of budget and schedule;
  
  
• Progress Reporting - what the project team has accomplished; and
  
  
• Forecasting - anticipated status.

The Software Project Management Plan and Project Management Institute processes should include the following additional components, all of which help reduce the risk that the project will fail.

• Project Overview - An overview of the purpose, scope, and objectives of the project, the project assumptions and constraints, a list of project deliverables, and a summary of the project schedule and budget.
  
  
• Project Organization - The communications and reporting relationships to organizational entities external to the project, describing the project's internal organization structure, and a definition of roles and responsibilities for the project.
  
  
• Managerial Process Plans - The project management processes for the project. This includes the start-up plan, risk management plan, work plan, control plan, issue resolution process, and closeout plan.
  
  
• Technical Process Plans - The development process model, the technical methods, tools, and techniques to be used to develop the various work products, plans for establishing and maintaining the project infrastructure, and the product acceptance plan.
  
  
• Supporting Process Plans - The supporting processes that span the duration of the software project. These plans include configuration management, verification and validation, software documentation, quality assurance, testing, reviews and audits, and subcontractor management. In particular, the roles, responsibilities, authorities, schedule, budgets, resource requirements, risk factors, and work products for each supporting process are specified.
  
  
• Additional Plans - Additional plans required to satisfy product requirements and contractual terms with the vendor. Additional plans include: a Security Plan for the safety, privacy, and security requirements; an Installation Plan that includes special facilities or equipment; a System Design Report Plan (i.e., a description of customizations to Commercial-Off-The-Shelf software); a User Training Plan, an Integration Plan; a Data Conversion Plan; a System Transition Plan; a Product Maintenance Plan with the vendor; and a product Support Plan with the hospital's IT staff, if any. These plans are developed to support completion of deliverables by the vendor.
  
  
• Annexes and Indexes - Definitions, indexes, and reference documents such as the Project Team Directory, Plan Index, Lists of Tables and Figures, Definition of Terms, Reference Documents, and Change History.

Conclusion

U.S. hospitals will spend billions of dollars in the next decade to improve their IT systems. Unfortunately, many hospital IT projects will fail. Hospitals and their officials may be liable to investors, patients, vendors, and, if they are owned by non-profit corporations, the state, if hospital officials do not monitor the progress of the projects, assure that they are effectively managed, and disclose the risk that the projects may fail. Hospital officials can increase the likelihood that the projects will succeed by ensuring that IT system contracts include appropriate terms and by ensuring that the projects are managed in accordance with accepted software project management standards.

FOOTNOTES

1 CPOE systems allow doctors to order medications by typing orders into handheld devices or personal computers.
2 HIPAA is codified at 42 U.S.C. §1320d. Hospital spending on information technology projects is projected in Jeff Goldsmith, David Blumenthal, and Wes Rishel, Federal Health Information Policy: A Case of Arrested Development, Health Affairs, 3, 6, July/August 2003, available at http://www.healthaffairs.org/freecontent/v22n4/s13.htm.
3 See Scott Berinato, A Rash of IT Failures, CIO Magazine, June 15, 2003, available at Http://www.cio.com/archive/061503/tl_health.html (describing Cigna's $1 billion false start overhauling its IT system, which caused the health insurer to acknowledge customer defections; describing Cedars-Sinai Medical Center's suspension of a CPOE in January 2003 after doctors objected to the system; and describing the overload of a new laboratory computer system at Los Angeles County-USC Medical Center, which prompted the emergency room to turn away ambulances in April 2003). IT projects of all kinds are difficult to complete successfully, not just those attempted by hospitals. Matthew Furton, Discovering the True Cause of Failure in Software Development Projects, 20 Computer and Internet Law 1 (2003) (stating that more than 80% of IT projects fail); J.T. Westermeier, Software Services and Maintenance Contract Fundamentals, 734 PLI/Pat 645, 649 (2003) (stating that software projects are typically 100% over budget and a year behind schedule).
4 William Hersh, M.D., Medical Informatics, 228 JAMA, 1 (October 23, 2002), available at http://www.JAMA.amaassn.org/cgi/content/full/288/16/1955.
5 Jeff Goldsmith, et al., supra note 2 at 2, citing L.T. Kohn, J.N. Corrigan, and M.S. Donaldson, eds., To Err Is Human - Building a Safer Health System (National Academies Press 2000). More than 98,000 people die each year from preventable medical errors. Amy Sokol and Christopher Molzen, The Changing Standard of Care in Medicine, 23 Journal of Legal Medicine 449, 456 (2002), citing Kohn, et al., at 26.
6 Studies have demonstrated that CPOE systems and other new health information technologies can reduce medication-related errors by as much as 56%. Amy Sokol, supra note 5 at 457-62. See also, William Hersh, M.D., supra note 4 at 1, citing Kohn, et al., supra note 5; R.S. Dick, E.B. Sten, and D.E. Detmer, eds., The Computer-Based Patient Record: An Essential Technology for Health Care, National Academy Press (Rev. Ed. 1997), and For the Record: Protecting Electronic Health Information (National Academy Press 1997).
7 See Scott Berinato, All Systems Down, CIO Magazine, February 15, 2003 (describing the effect of a network crash at Beth Israel-Deaconess Medical Center in November 2002, which caused the hospital to close its emergency room for four hours and to operate without access to computerized data for several days).
8 See text accompanying notes 25-44 infra.
9 In addition to complying with HIPAA requirements, hospitals in California must implement technology such as CPOE systems by January 1, 2005, to eliminate or substantially reduce medication-related errors. See Ca. Health & Safety Code §1339.63.
10 See, e.g., federal Department of Health and Human Services Centers for Medicare and Medicaid Services' Quality Assessment and Performance Improvement rules, effective March 25, 2003. 45 C.F.R. §482.21.
11 Amy Sokol, supra note 5 at 483-84.
12 Id. at 483-86. See also Monique Leahy, Negligence Liability for Non-Use of Computer, 31 AmJur Proof of Facts 3d 1, §§1, 11 (2002).
13 Thomas Bodenheimer, M.D., and Kevin Gurmbach, M.D., Electronic Technology - A Spark to Revitalize Primary Care?, 290 JAMA 3 (July 9, 2003) (stating that only 17% of U.S. primary care physicians used electronic medical records systems compared with 58% in the United Kingdom and 90% in Sweden), available at http://jama.ama-assn.org/cgi/content/full/290/2/259.
14 Jeff Goldsmith, et al., supra note 2 at 2.
15 Id. at 1; Amy Sokol, supra note 5 at 467. Although U.S. health care providers invested more than $20 billion in 2001 for IT projects, the majority was spent for financial systems and only $6.5 billion was spent for clinical systems. Jeff Goldsmith, et al., supra note 2 at 1, 2.
16 Molly Coye and William Bernstein, Improving America's Health Care System by Investing In Information Technology, Health Affairs, July/August 2003, available at http://www.healthaffairs.org/freecontent/v22n4/s14.htm.
17 H.R. 663, 108th Cong., 1st Sess. (2003), §§104-106.
18 S. 720, 108th Cong., 1st Sess. (2003).
19 Goldsmith, et al., supra note 2 at 3.
20 Amy Sokol, supra note 5 at 467-68, citing David Bates, et al., Effect of Computerized Physician Order Entry System and a Team Intervention on Prevention of Serious Medication Errors, 280 JAMA 1311, 1311-16 (1998) (describing CPOE system at Boston's Brigham and Women's Hospital).
21 Jeff Goldsmith, et al., supra note 2 at 6.
22 See Randy Gainer, et al., WiFi Devices in Hospitals Pose Major HIPAA Challenges, 12 Health Law Reporter 852, (BNA, May 29, 2003) (describing potential claims if health care providers fail to secure wireless networks used to transmit health data).
23 Laura Landro, "Most Wired" Hospitals Enhance Patient Care Through Technology, Wall Street Journal Online, July 11, 2003.
24 116 Stat. 745 (2002), codified at various sections of 15 U.S.C.
25 In re Oxford Health Plans, Inc. Securities Litigation, 244 F. Supp.2d 247 (S.D.N.Y. 2003); 199 F.R.D. 119 (S.D.N.Y. 2001); 191 F.R.D. 369 (S.D.N.Y. 2000); 192 F.R.D. 111 (S.D.N.Y. 2000); 187 F.R.D. 133 (S.D.N.Y. 1999); and 51 F. Supp.2d 290 (S.D.N.Y. 1999) (describing securities fraud and shareholder derivative actions brought against managed care company, its outside auditors, its corporate officials and its directors based on the defendants' failure to disclose the effects of a failure to convert the managed care company's computer system) (collectively referred to as "The Oxford Health Plans Securities Litigation"). The consolidated cases have not yet been tried. The various pretrial decisions denied motions to dismiss and certified some of the lawsuits as class actions, among other things. The court's description of the facts reflects the plaintiffs' claims, which is appropriate on motions to dismiss. The claims must be proven at trial.
26 51 F. Supp.2d 290, 292.
27 Id.
28 Id. at 293.
29 Id.
30 Id.
31 Id.
32 Id. at 292 n.1 and 293.
33 187 F.R.D. 133, 138.
34 Id.
35 Id.
36 187 F.R.D. 133 (S.D.N.Y. 1999).
37 191 F.R.D. 369 (S.D.N.Y. 2000).
38 See 244 F. Supp.2d 247 (S.D.N.Y. 2003).
39 15 U.S.C. §78m, 17 C.F.R. §§240.13a-1 through 240.13a-17.
40 192 F.R.D. 111, 115.
41 192 F.R.D. at 117, quoting Aronson v. Lewis, 473 A.2d 805, 813 (Del. 1984).
42 Denise Lee, The Business Judgment Rule: Should It Protect Nonprofit Directors?, 103 Colum. L. Rev. 925, 939 (2003), quoting Dennis Block, et al., The Business Judgment Rule: Fiduciary Duties of Corporate Directors, 4 (5th ed. 1998).
43 698 A.2d 959, 972 (Del. Ch. 1996).
44 192 F.R.D. at 117, quoting Caremark, 698 A.2d at 972.
45 15 U.S.C. §7241.
46 Id. See also the SEC's June 6, 2003 announcement regarding amendments to 17 C.F.R. §§240.13a14 and 240.15d14 and other rules, clarifying the certifications required by 15 U.S.C. §7241 (§302 of Sarbanes-Oxley), available at http://www.sec.gov/rules/final/33-8238.htm, at sections II.D.-F.
47 See, e.g., 15 U.S.C. §78m(l), which requires publicly traded corporations to "disclose to the public on a rapid and current basis such additional information concerning material changes in the financial condition or operations of the issuer, in plain English … as the Commission determines, by rule, is necessary or useful for the protection of investors and in the public interest." SEC rules effective August 13, 2003 define "internal control over financial reporting" as including, among other things, policies and procedures that "[p]rovide reasonable assurance regarding prevention or timely detection of unauthorized acquisition, use or disposition of the issuer's assets that could have a material effect on the financial statements." 17 C.F.R. §240.13a-15(f)(3), available at http://www.sec.gov/rules/final/33-8238.htm.
48 15 U.S.C. § 78; (b) and 17 C.F.R. § 240.106-5.
49 See §§7.40, 7.41of the Model Business Corporations Act.
50 See Fed. R. Civ. Proc. 23.1 and counterpart state rules.
51 Denise Lee, supra note 42 at 957.
52 The standard of care for health care providers traditionally has not required the use of the newest procedures or state-of-the art technology unless it can be shown that the procedures and technology have gained general acceptance in the medical community. Amy Sokol, supra note 5 at 470-71. A growing number of courts, however, have refused to defer to medical custom to set the standard of care. Id. at 482-83; Phillip Peters, Jr., The Quiet Demise of the Custom: Malpractice at the Millennium, 57 Wash. & Lee L. Rev. 163, 172-85 (2000). See, e.g., Darling v. Charleston Comm. Mem. Hosp., 211 N.E.2d 253, 257 (Ill. 1965) (custom should never be conclusive because physicians could adopt unreasonable habits); and Helling v. Carey, 83 Wn.2d 514, 519, 519 P.2d 981, 983 (1974) (pressure test for glaucoma should have been performed on patient under 40 despite that established medical practice was not to perform such tests). If CPOE systems or other hospital IT systems are either generally accepted by the medical community as standard practice or if a court holds that such systems should be used regardless of whether their use is customary, failure to use such a system could provide a basis for a malpractice claim. Malpractice suits could be successful both when no attempt is made to deploy a system deemed mandatory under a state's medical standard of care and when an attempted deployment fails.
53 Hospital Statistics, at 6, American Hospital Association (2002) (non-governmental not-for-profit registered hospitals were 3,003 of 4,915 registered U.S. hospitals in 2000).
54 Dana Reiser, Decision-makers Without Duties: Defending the Duties of Parent Corporations Acting As Sole Corporate Members In Nonprofit Health Care Systems, 53 Rutgers L. Rev. 979, 981 (Summer 2001), citing Lester Salamon, America's Nonprofit Sector: A Primer, 95-99 (Second Ed. 1999).
55 The changes in reimbursement methods under Medicare, Medicaid and other health care problems drastically decreased payments to hospitals in general and teaching hospital in particular. Dana Reiser, supra note 54 at 985. The shift in health insurance from indemnity insurance (in which patients chose their own health care providers) to managed care organization contracts (in which employers contract with managed care providers) also hurt nonprofit hospitals that could not offer as attractive rates as larger, affiliated hospitals. Id. at 986-87.
56 Laura Landro, supra note 23. Nonprofit hospitals have obviously managed to invest in information technology despite economic pressures and must comply with HIPAA-mandated requirements, just as all other hospitals must.
57 American Bar Association, Revised Model Nonprofit Corporations Act, § 8.30(a) (directors); id. § 8.42 (officers).
58 This "trustee" standard applies, among other states, in Wisconsin. See, e.g., Old Settlers Clubs v. Haun, 113 N.W.2d 913 (Wis. 1944). See generally Pat Chew, Directors' and Officers' Liability, § 7:2 Nonprofit Corporations (Practicing Law Institute 2001), available on Westlaw at PLIREFDIRLIB 7:2.5.
59 See, e.g., Denise Lee, supra note 42 at 926-27; Pat Chew, supra note 58 at § 7:2.7; and William Fletcher, 19 Fletcher Cyclopedia of Private Corp., § 3:18 (2003), available on Westlaw at FLETCHER-CYC 3:18.
60 Dana Reiser, supra note 54 at 999-1000.
61 Id.
62 192 F.R.D. 11, 116-17. See also In re Caremark International, Inc., supra note 43, 698 A.2d at 972 (systematic failure to exercise oversight and to assure adequate recordkeeping not protected by business judgment rule).
63 Denise Lee, supra note 42 at 955; Victor Futter, ed., Nonprofit Governance and Management, 393-94 (ABA 2000). See, e.g., Revised Model Nonprofit Corporation Act §§ 1.60, 3.04 (giving state attorney general the right to sue nonprofits in various circumstances).
64 Denise Lee, supra note 42 at fn. 177.
65 Dana Riser, supra note 54 at 1020.
66 Id. and fn. 178 citing investigations in Michigan, California, and Ohio. See also New York Attorney General Eliott Spitzer's announcement that he will propose legislation requiring CEOs of nonprofits with annual revenues of more than $250,000 to certify financial reports and to certify the adequacies of the internal controls of the organizations, as corporate counterparts are required to do under Sarbanes-Oxley. The Nonprofit Times (March 1, 2003), available at http://www.nptimes.com/Mar03/npt2.html.
67 See note 52. See also, Burton v. Brooklyn Doctor's Hospital, 452 N.Y.S.2d 875 (N.Y. App. Div. 1982); Darling v. Charleston Comm. Mem. Hosp., 211 N.E.2d 253 (Ill. 1965).
68 See Deborah Taylor, Liability for Public Hospitals Under the Texas Tort Claims Act, 2 Tex. Wesleyan L. Rev. 629, 644-46 and fns.143-145 (Spring 1996). The states that have waived sovereign immunity as to public hospitals include Alabama, Arizona, Colorado, Connecticut, Illinois, Michigan, Montana, New Hampshire, North Carolina, North Dakota, Ohio, Pennsylvania, Virginia, Washington, and Wyoming. Id. at fn. 143. Additionally, Arkansas and Maryland have waived sovereign immunity to the extent that damages may be covered by liability insurance. Id. at fn. 144.
69 See Deborah Taylor, supra note 68 at 644-45 and fn. 145. The states that have retained sovereign immunity for claims based on the exercise of a discretionary function include Alaska, California, Delaware, Indiana, Kansas, Kentucky, Maine, Minnesota, Nebraska, Nevada, New Jersey, New York, Oklahoma, Oregon, South Carolina, Tennessee, Utah, and Vermont. Additionally, West Virginia does not permit claims against the state, and its tort claims act expressly excludes the application of that act to hospitals of a public subdivision. Id.
70 See, e.g., County of Alameda v. State Board of Control, 4 Cal. App. 4th 1096, 1103, 18 Cal. Rptr. 2d 487, 490-91 (Div. 1 1993).
71 See text accompanying note 73.
72 See note 52. Some commentators advocate lawsuits as one way that poor and minority patients served by public hospitals can attempt to improve the quality of the medical that they receive. See, e.g, Marianne Lado, Breaking the Barriers of Access to Health Care, 60 Brook. L. Rev. 239 (1994).
73 See, e.g., State of California v. Lockheed Martin IMS, 2002 WL 99554 (Cal. Ct. App. 3rd Dist. 2002) at *3-10.
74 See Richard Wyde, ed., The Entrepreneur's Guide to Technology and Internet Law, Ch. 1, "Licensing Guidelines" (Davis Wright Tremaine LLP, 2003)
75 See Diana Richard and Michael Murphy, Frequently Litigated Software Contract Clauses, 700 PLI/Pat 33, 42-50 (2002); and Steven Davidson, Avoiding Pitfalls and Allocating Risk in Major Software Development and Acquisition Contracts, 14 Computer Law. 12, 15 (1997).
76 Steven Davidson and Gabriel Holloway, Software Services and Maintenance Agreements, 734 PLI/Pat 611, 623 (2003).
77 Raymond Nimmer, Law of Computer Technology, §6:21 (2003), available on Westlaw at LCOMTECH §6:21.
78 Davidson, supra note 76 at 623, 625.
79 Id. at 624.
80 Diana Richard, supra note 75 at 61-88.
81 Davidson, supra note 75 at 13.
82 Davidson, supra note 76 at 627.
83 Id. at 636-641.

FOR FURTHER INFORMATION, PLEASE CONTACT:

Randy Gainer, Seattle, (206) 628-7660, randygainer@dwt.com

Scott Coplan is the president of President of Coplan and Company, which provides project management services for health, financial and justice information technology system projects. He can be reached at (206) 287-1703 or scoplan@coplan.com.

This Health Law Advisory is a publication of the Health Law Group of Davis Wright Tremaine LLP. Our purpose in publishing this Advisory is to inform our clients and friends of developments in health care law. It is not intended, nor should it be used, as a substitute for specific legal advice as legal counsel may only be given in response to inquiries regarding particular situations.

return to Advisory Bulletins main page