Considerations in Contracting to Purchase or License an Electronic Health Records System
July 1, 2011
By: James B. Wieland and Joshua J. Freemire
Health Law Resource Center Reproduced with permission from the Health Law Resource Center, Copyright 2011 The Bureau of National Affairs, Inc. (800-372-1033) www.bna.com. The following checklist provides guidance for medical providers regarding contracts to purchase or license an Electronic Health Records system and provides specific considerations for an Electronic Health Record that is intended to qualify for the incentives provided for in the Health Information Technology for Economic and Clinical Health (HITECH) Act for "meaningful use" of Electronic Health Records. [See final rule on meaningful use of EHRs, 75 Fed. Reg. 44313 (July 28, 2010).] An Electronic Health Record ("EHR") is a software program that can make a patient’s health information available when and where it is needed. It has the capability to bring a patient’s total health information together in one place, and always be current – clinicians need not worry about not knowing the drugs or treatments prescribed by another provider, so care is better coordinated. EHRs don’t just "contain" or transmit information, they also compute with it – for example, a qualified EHR (an EHR which may be used to qualify for provider incentives) will not merely contain a record of a patient’s medications or allergies; it will also automatically check for problems whenever a new medication is prescribed and alert the clinician to potential conflicts. EHRs can improve safety through their capacity to instantly analyze all of a patient’s information and automatically identify potential safety issues—providing "clinical decision support" capability to assist clinicians. An EHR can also serve as a patient’s and a provider’s "legal" medical record – the official documentation of the patient’s medical care. In short, EHRs offer medical providers and their patients substantial benefits, but also pose unique questions with regard to purchase or licensing agreements. Medical Provider’s Checklist Medical providers who are considering an arrangement to purchase or license Electronic Health Records software should engage in the following analysis before executing an agreement to purchase or license a vendor’s product. - Consider HIPAA implications of the various EHR contract models. In general, any vendor of any type of EHR will be a business associate of the covered entity that purchases or licenses the EHR. The only exception would be an EHR license in which the software was housed on the servers of the covered entity that purchased or licensed it and is never accessed by the vendor for maintenance or upgrades. Such arrangements are virtually nonexistent in today’s world.
At its most basic, EHR software is housed on the servers of the covered entity, but the vendor will have access (usually through protected network access) for maintenance or upgrading of the software. In this situation, the vendor will have sufficient access to the Protected Health Information (PHI) stored in the software (the actual electronic medical records) to make it necessary that the vendor execute a business associate agreement (BAA) with the covered entity. More commonly, the EHR and the electronic medical records it contains are remotely hosted, in an arrangement traditionally referred to as an Application Service Provider (ASP) model. Here the vendor houses the software and maintains the electronic medical records on its own servers and the licensee accesses the software and the records it contains securely through the internet or another form of connectivity. Increasingly, under so-called Software as a Service and Cloud Computing Arrangements, variations on the longstanding ASP model, the vendor offers lower pricing to the licensee by making the EHR available "on demand" and the actual information constituting the electronic medical record is stored on a "space as needed" basis across a variety of servers owned or controlled by the vendor. - Analyze the degree of risk. While all of the arrangements discussed above require a BAA between the EHR vendor and the medical provider, BAAs should be negotiated with regard to the degree of risk to the provider in the arrangement, with the self-hosted arrangement being the least risky and the cloud computing being the riskiest. In short, the greater control the vendor has (rather than the covered entity provider), the greater the risk that actions or inaction on the part of the vendor could result in HIPAA compliance problems for which the provider would be ultimately responsible. The greater the risk that vendor action or inaction could result in a HIPAA violation, the more closely the provider needs to consider the following:
- How robust are the vendor’s security measures?
Comment: HIPAA requires business associates to maintain the same physical, administrative, and electronic security measures to protect PHI in the business associate’s possession as a covered entity. However, if the vendor has actual custody of the electronic health records, as in an Application Service Provider model, the provider must exercise greater due diligence than would be required if the vendor simply accessed the medical provider’s servers periodically for maintenance and upgrading. - Are there detailed procedures in place in the event there is a breach of the security of unsecured PHI in the hands of the vendor?
Comment: A provider should not enter into an arrangement with a vendor that does not encrypt PHI in the vendor’s custody, particularly with a vendor who actually stores the PHI on the its own servers. However, breaches of unsecured PHI can still occur, as with unsecured PHI stored in a laptop or portable media of a member of the vendor’s workforce or through negligent or intentional conduct of a member of the vendor’s workforce. While a HIPAA compliant BAA need only provide that the vendor will notify the provider within 60 days of when the vendor knew or should have known of the breach (unless the vendor is deemed to be an agent of the provider under federal common law, in which case the vendor’s knowledge is imputed to the medical provider), notice should be provided at the earliest opportunity, in order to allow ample time to investigate the breach and make required determinations as to notice to individuals whose PHI was subject to the breach. - Beyond providing the basic "who, what and where" required by HIPAA, the vendor should be required to cooperate with the medical provider’s due diligence investigation. The provider should consider who will be responsible for the costs of providing notice to individuals and agencies, which can be quite expensive in the case of a breach involving a large number of individuals’ PHI. Ultimately, the provider should be concerned with the insurance and the underlying financial resources of the vendor, in the event an indemnification clause provides for the vendor to assume responsibility for financial damage to the medical provider caused by a breach.
- Most EHR license agreements contain clauses limiting the vendor’s financial responsibilities for breach of the agreement. The provider should consider exempting violations of the HIPAA business associate agreement from these limitations, especially if the violations are the result of negligence or willful misconduct by the vendor.
- Establish responsibility for EHR regulatory compliance. EHRs are subject to the same laws that govern paper patient records in most states, as well as the federal requirements of HIPAA. Providers should consider who will be responsible for monitoring changes in these laws and for the costs of providing changes to the EHRs necessary for providers to maintain compliance with the laws.
- Provide for orderly transfer of information upon termination. Most EHR contracts, unless title to the software is conveyed to the licensee, require the licensee to discontinue use of the EHR and, if applicable, return or destroy all but an archive copy upon, or shortly after, termination of the agreement. In the case of an EHR contract, such a clause could seriously impair medical care by the licensee medical provider by, at the very least, impairing access to medical records stored on the EHR. A contract for EHR should contain provisions that reflect this.
- The vendor should be required to cooperate with an orderly transfer of all information, in an industry standard or other agreed format, to the provider’s system or to the system of a successor vendor.
Comment: The baseline industry standard is "ASCII, comma delimited," which is basically the electronic equivalent of a paper document and is thus readily exportable to other systems. - To the extent that such cooperation requires more than nominal effort on the vendor’s behalf, such as development of custom interfaces or translation programs, the provider should expect to pay the vendor’s fees, usually charges on the basis of the vendor’s published fee schedule. These fees should be negotiated and agreed in advance.
- The provider should be able to continue to use the EHR, while continuing to pay appropriate fees, until such a transfer is complete and the successor system is up and running.
Comment: Many vendors will impose some absolute time limit on this, such as a twelve month period after termination, and will not agree to provide upgrades (as opposed to maintenance required to keep the EHR functional) during the transition period. - Under no circumstances should the vendor be permitted to insert disabling code or otherwise turn off the EHR without the provider’s consent.
- Decide upon uptime guarantees and disaster recovery. Depending on the data hosting arrangement and the agreed responsibility for EHR maintenance, the vendor will have a greater or lesser degree of responsibility for guaranteeing that the EHR will function, subject to downtime for scheduled maintenance. In addition, in most arrangements, the vendor will have obligations as to some minimum period of time to respond to reports of problems or malfunctions of the EHR, including complete unavailability of the EHR due to a natural or man made disaster.
- The provider should recognize that the greater the uptime commitment and the shorter the time to restore the EHR following a problem, including complete unavailability due to a natural or man-caused disaster, the higher the fees the medical provider will have to pay.
Comment: The mechanics vary, depending on whether the EHR is hosted on the medical provider’s server or hosted remotely by the vendor. In either event, however, given the importance of uninterrupted access to the EHR for purposes of patient care, careful balancing of cost versus availability is needed. The best, and most expensive, solution to a serious incident is to have duplicate servers running at two geographically separate locations. If one server goes down, the EHR system can immediately and seamlessly switch to the second, "mirror" server. - If the vendor provides help desk support for the medical provider, the provider should also negotiate guaranteed response times to reports of problems, should also be negotiated with keeping in mind the importance of access to medical records in mind. There should be a procedure for classifying the nature of a reported problem, from a minor issue up to unavailability of the EHR, with vendor response times specified for each and with procedures to escalate vendor resources in the event a problem is not remedied in a timely fashion.
- Consider vendor recommendations for hardware configuration. Vendors of EHR will often have requirements and recommendations for hardware to be acquired by the medical provider. The provider should ensure that the license agreement contains a vendor warranty that such requirements and recommendations are appropriate for implementation and will allow the EHR to perform properly.
Comment: This is particularly important with EHR, given the need to interface with multiple sources of input and multiple users. - Ensure compliance with the provider’s security and access policies. To the extent the EHR is hosted by the medical provider, the vendor will require remote access to the EHR and possibly physical access. The contract should provide that the vendor:
- agrees to comply with the provider’s security and access procedures, and
- will provide the provider with advance notice of any such access, even if it is remote.
- Negotiate licensed volume. Some EHR licenses are priced based on the number of authorized users. Providers should consider and, if possible, pre-negotiate rate changes in the event the number of authorized users increases or decreases.
Comment: Measurement of the number of authorized users should be an average over time, in order to avoid triggering an increase in fees for a short-term increase in the number of authorized users. - Designate vendor’s implementation team. Implementation of an EHR is a sensitive process that involves dealing with various levels of medical provider personnel over time. The best EHR system may not be successfully implemented if there is no user "buy-in." For this reason the provider should be sure the vendor designates at least one high level contact who is reasonably acceptable to the provider as the project leader and point of contact, and commit to using best efforts to keep the same person in place throughout the implementation process and, if necessary, to provide an equally acceptable successor.
- Provide for training of medical provider’s team. Given the number of users of a typical EHR system, the provider should make certain that the vendor commits to appropriate obligations to train the provider’s project team and end users. The agreement should give the provider a clear understanding of:
- the costs of training;
- whether end user training will be for all end users of the system or will be a "train the trainer" approach; and
- in the event training is at the vendor’s site, the costs and time commitments involved.
- Consider appropriate warranties. In addition to usual warranties, such as performance in accordance with specifications discussed in the general technology contracting checklist, providers should consider additional warranties, such as:
- A warranty that the EHR will support the medical provider’s qualification for Meaningful Use (see next section).
- A warranty that the EHR will support compliance by the provider with HIPAA and state confidentiality of medical records laws.
Comment: Vendors cannot guarantee such compliance, of course, since that depends on how the EHR is used by the medical provider. However, the EHR should have the various functionalities that are consistent with compliance by the provider. - Especially for those providers that file cost reports for federal programs, consider the need for a warranty that the vendor and the vendor’s personnel are not debarred/excluded from federal programs.
- Avoid change orders. Because acquisition and implementation of an EHR is a complicated process, providers should make every effort to assess their immediate and anticipated needs prior to entering into negotiations. Once the ink is dry on the contract, any modifications will require a "change order," typically an expensive way to correct for a lack of proper planning.
Establishing Meaningful Use The Medicare and Medicaid Electronic Health Record (EHR) Incentive Program offers eligible hospitals (EHs) and eligible professionals (EPs) substantial incentive payments for the Meaningful Use of certified EHR technology. A failure to meet the program’s detailed requirements, however, through the use of EHR technology that has received proper certification, may mean that an EP or EH has made a substantial investment in technology that will fail to qualify for incentive payments. EPs and EHs can substantially limit their investment risk by ensuring that the agreements that they execute with EHR vendors provide proper assurances of certification, continuation of necessary upgrades or patches, any required modifications, support and training, and a warranty that the purchased EHR system, when properly configured and implemented, will support the EH’s or EP’s attestation of Meaningful Use and application for incentive funds.
|
