Guide to Critical Issues in Health Care Technology Contracting

Today's health care providers operate in a constantly changing environment shaped by increased regulation and competition. In an effort to meet these challenges, health care providers increasingly are embracing the latest in technological advances. Many health care technology vendors lure providers with a siren song of lowered costs, increased efficiencies, access to more and better data, and improved patient care. Given the substantial cost of these technologies, their "mission-critical" nature, and the myriad of legal and operational issues related to their acquisition, implementation, and use, these solutions also present substantial risk to providers who follow the lure of these promises without careful planning and implementation.

This Guide to Critical Issues in Health Care Technology Contracting addresses some of the critical legal issues presented in a typical acquisition of health care technology. Due to our extensive experience in health care technology we recognize that each transaction presents unique legal and operational issues, and that the particular method(s) of addressing these issues will change substantially with each transaction and each particular vendor. Although this guide does not attempt to identify all of the potentially important issues that your organization will face, we hope it will be a useful resource as your organization navigates through the quagmire of health care technology acquisitions.

Most, if not all, health care entities have experienced technology acquisition projects that significantly exceeded budgets and/or project timelines. In today's competitive environment, budget overruns and endless implementation projects are more unacceptable than ever. Although these problems are all too common, there are a number of contractual tools available to ensure that your project is completed on time and under budget.

Most standard vendor agreements do not contain enforceable project timelines. When pressed, most vendors seek to avoid the development of a detailed work plan until after the agreement is executed by the parties. Even when a detailed work plan is attached, vendors will usually attempt to use a "level of effort" (e.g., "commercially reasonable" efforts) standard to describe their contractual obligations. (See Sample One below.)

In addition to a lack of enforceable project timelines as exemplified in the language above, most vendor agreements contain an unlimited "time and materials" approach to project implementation services, with fees paid on a recurring (e.g., monthly) basis. Under this framework, if the actual work effort required is double the originally projected work effort, the vendor's implementation fees are doubled. In addition, the vendor receives regular payments regardless of its progress (or lack thereof) and regardless of whether the system and/or system components are working. Payment structures such as these invite budget overruns.

Although implementation costs and timelines are the most obvious risks to your organization, there are a number of other areas where a failure to adequately address payment issues could result in hidden costs to your organization. For example, many agreements contain unclear licensing metrics (e.g., vaguely worded descriptions of how the vendor counts concurrent users) that can result in substantial unanticipated license fees. In addition, most vendors offer no protection that agreed-upon third-party software and hardware will be adequate to operate the vendor's software. As a result, if additional third-party technology is required, it is most likely your organization's financial responsibility (despite the fact that your organization may have purchased the exact third-party software and hardware configuration that was specified by the vendor).

If these and other problems remain unaddressed in the agreement, project budgets and timelines amount to nothing more than your current "best guess," and are oftentimes based substantially upon oral conversations and vendor promises that are not included in the agreement. Using the tools described below, your organization can help ensure that the vendor appropriately shares the risk that the project will meet timelines and/or budget requirements.

• Develop a project plan and timeline before the execution of the agreement with the vendor, and attach it to the agreement as an exhibit. Obligate the vendor to meet the milestones described in the exhibit on or before the prescribed dates. Ensure that the vendor's obligations in this regard are clearly described, and avoid "level of effort" language that merely obligates the vendor to using "commercially reasonable efforts" (or some other level of effort) to meet project timelines.

• Consider alternative payment methodologies for the vendor's implementation fees. These include "fixed fee" projects, "not-to-exceed" projects, or a "hybrid" structure whereby cost overruns progressively reduce the vendor's hourly or daily rate to the point where the vendor is providing services without charge.

• Regardless of the chosen methodology, payments should be milestone driven. Payments should be released to the vendor based upon actual results (e.g., the acceptance of a particular deliverable), not the passage of time.

• Ensure that the agreement clearly and unambiguously describes the applicable licensing metric(s). If necessary, include examples to ensure that both parties are in agreement regarding when additional licensing fees will be paid.

• Include appropriate configuration warranties to ensure that the vendor will bear any costs of unexpected additional third-party technology that may be necessary to support your use of the vendor's system.

• Include an "All Fees Stated" limitation that requires the vendor to specifically and succinctly describe any and all costs payable to the vendor under the agreement.

Almost all vendors use their standard agreements as a vehicle for limiting their liability in the event of a problem during the implementation or use of the vendor's product. Although these liability limitations take a variety of forms, they all share the fundamental purpose of shifting the risk of the vendor's nonperformance to your organization.

The most common such clause is usually labeled as a "Limitation of Liability" and, for legal reasons, it is oftentimes drafted in capitalized or bold text. These clauses typically: prohibit the customer from recovering certain types of damages (usually indirect, consequential, incidental, special, and punitive damages); and limit the amount of recovery for other types of damages, even if the customer is able to prove that the vendor breached its obligations and that the breach caused the damages. (See Sample Two (A) below.) In a sense, this clause is the most important part of your organization's agreement with the vendor. If you successfully negotiate an agreement that contains very specific implementation timelines, functionality commitments and other vendor promises, these commitments are only as good as your organization's ability to enforce the agreement in the event of a vendor breach. If the limitation of liability protects the vendor from incurring any meaningful damages if it breaches the agreement, the value of these commitments is substantially reduced or eliminated.

Many vendors also attempt to shift risk to the customer using a number of less obvious methods. For example, vendors will often include a "blanket disclaimer" of responsibility for certain risks. Although these disclaimers may sound reasonable on the surface, they are almost always overly broad and include risks that are appropriately the vendor's responsibility. (See Sample Two (B) below.) (Note that additional, health care-specific disclaimers are discussed in connection with Issue Three on following pages.)

Another common form of liability limitation is the use of "sole and exclusive remedy" clauses. (See Sample Two (C) below.) Pursuant to these clauses, the vendor usually commits to use a "commercially reasonable" level of effort to either fix or replace a defective product or to re-perform defective services and asks the customer to waive all other rights and remedies resulting from such defect. Although a fixed product is an appropriate remedy, it oftentimes should not be the only remedy. For example, if a patient is harmed by a defective product, the vendor's obligations should extend beyond a commitment to repair or replace the product. Similarly, if a product failure causes your organization to incur substantial damages (e.g., an inability to perform procedures) an obligation to fix or replace the product is an incomplete remedy, at best.

Finally, many vendors seek to limit their potential liability by limiting the customer's right to bring a claim after a certain period of time. (See Sample Two (D) below.) These "artificial" statutes of limitations are almost always shorter than the statute of limitations offered under state law. In addition, these clauses are oftentimes drafted in a one-sided manner such that the customer must bring any claims within a shortened time period, while the vendor reserves the luxury of filing claims within the longer statute of limitations offered by applicable state law.

Limitations of liability are a critical aspect of health care technology transactions. In a health care environment, a product failure could cause an inability to treat patients or bill for services rendered. In the worst case scenario, a defective product could harm a patient. As a result, limitations of liability should receive careful scrutiny. Remember, just because limitations of liability are extremely common in the technology industry, this does not mean that they are always fair or reasonable to the customer. In most cases, they are neither. It is critical that your organization evaluate the risks posed by these limitations, and determine in each case whether it is acceptable for the vendor to shift the risk of its non-performance to your organization.

• Remember that the commitments found elsewhere in the agreement are only as good as the limitation of liability. If the vendor provides "iron-clad" commitments elsewhere in the agreement, those commitments are worthless if the customer does not have the ability to enforce them.

• Do not assume that all agreements must contain a prohibition on the recovery of consequential, indirect, incidental, punitive, and other similar damages. This issue, like all others, will be dictated by the course of the negotiation and the parties' respective bargaining positions.

• If the vendor insists on an overall cap on liability, ensure that the cap amount is sufficient to permit the recovery of your organization's potential damages. This will, of course, vary greatly depending on the type of product being acquired and the size of the transaction.

• All liability limitations and exclusions of damages should apply equally to both parties.

• Include "carve-outs" from any liability limitations to protect your organization from certain "worst case scenarios," or to address those situations where a limitation of liability cannot be justified under any circumstances. Consider the following carve-outs (in addition to any others that are relevant to the particular transaction):

1. Damages caused by a breach of confidentiality obligations
2. Damages covered by insurance, up to the amount of such insurance
3. Damages caused by the intentional breach of the agreement
4. Damages caused by the violation of applicable law
5. Damages resulting from any third-party claims (including, without limitation, any contractual obligations to defend, indemnify, or hold the other party harmless from any third-party claim(s) and any damages caused by a breach of those obligations)

If a problem arises during the implementation or use of any technology, that problem may cause your organization to incur damages, but it also may harm third parties. In the context of health care transactions, these third-party risks can be more central than in other technology projects. Many health care technology products will serve as a repository for highly confidential patient data, while other products are used directly or indirectly in the treatment of patients. For these reasons, it is particularly important in the context of health care technology transactions to ensure that the relevant agreement fairly allocates the risk of these third-party claims. As you might expect, most vendor agreements attempt to shift the risk of third-party harm to the customer.

For example, many vendors obligate their customers to defend and indemnify the vendor and hold the vendor completely harmless from a broad range of third-party claims. (See Sample Three (A) below.)

Although in certain circumstances it may be appropriate for the customer to indemnify the vendor for certain third-party claims, most vendor-requested indemnification clauses are overly broad, and in many cases require the customer to indemnify the vendor for claims that were caused by the vendor itself (or the vendor's products). As noted in Sample Three (A), the customer is obligated to defend, indemnify, and hold the vendor harmless from any claim "related to the use of the Product or any other act or omissions of Customer." This overly broad obligation would actually require the customer to defend the vendor in a lawsuit resulting from a patient being harmed by a defective product, merely because the customer "used" the product!

In addition to the use of overly broad indemnification clauses, many vendors also seek to limit their responsibility by including a variety of "practice of medicine" disclaimers. (See Sample Three (B) on following page.) These disclaimers are similar to those discussed in the "Limitation of Liability" section above, but are particularly tailored to the health care setting and are intended to shift certain risks (usually the risk of patient harm) to the customer. Although these disclaimers may sound accurate at first (e.g., both parties can agree that the vendor does not practice medicine) they have the effect of simplifying a complex issue at the customer's expense.

The reality is that in many cases, practitioners will rely on the data received from a clinical system or product. If a defective system (e.g., laboratory equipment) provides inaccurate information (a "false positive" blood test) which in turn leads to a misdiagnosis, the responsibility for any resulting patient harm should not be dictated by these simplistic and overly broad risk-shifting provisions.

Finally, almost all vendor agreements contain some form of indemnification for intellectual property claims. Although these clauses are commonly found in vendor agreements, they are oftentimes drafted in a manner that significantly limits the vendor's obligations to your organization for these claims. (See Sample Three (C) below.) These clauses should be reviewed carefully to ensure that your organization accepts no risk associated with a vendor's misappropriation of a third party's intellectual property.

• Do not agree to overly broad indemnification obligations that extend to your organization's use of a product or its acts or omissions. These indemnification obligations could result in a duty to indemnify the vendor for claims that are properly the vendor's responsibility.

• Do not agree to broad "practice of medicine" disclaimers. These clauses attempt to shift the risk of patient harm to the customer in all cases, even when the harm was primarily caused by the vendor.

• As discussed under "Limitations of Liability" above, it is critical that you ensure that thirdparty claims and damages are expressly carved out of all limitations or exclusions of liability.

• With respect to intellectual property indemnification clauses:

1. Ensure that the clause covers infringement/misappropriation of "patents, copyrights, trademarks, trade secrets, and other propriety rights."
2. Include obligations to defend, indemnify, and hold harmless your organization, its affiliates, and its and their respective employees, officers, directors, agents, and predecessors and successors-in-interest.
3. Ensure that any exclusions from the vendor's obligations are appropriate and narrowly drafted.

Most vendor agreements tie all warranties and representations, and the performance of the product, to the vendor's standard "documentation." (See Sample Four (A) below.)

This approach has several significant pitfalls. First, it is unlikely that the relevant vendor documentation will be delivered or carefully reviewed prior to the execution of the agreement. If the vendor documentation serves as the standard for the performance of the product, any failure to carefully review this documentation is tantamount to permitting the vendor to define your organization's requirements. All too often, clients spend significant amounts of time analyzing competing products, defining requirements, drafting request for proposals (RFPs), and selecting vendors/products, only to ignore all of this hard work when it matters most — when the vendor is actually being asked to commit to meet these standards and requirements.

Second, the vendor's documentation is usually subject to change at any time by the vendor, and usually without notice to its customers. As a result, if the vendor experiences a particular problem, it can effectively remove its contractual obligation to fix the problem by deleting the particular description of that functionality from its documentation. Finally, the documentation will not include any reference to specific representations made by its sales representatives and technical staff regarding the performance of the products in your environment. If your organization bases its vendor or product choice upon these representations, it is important to include them as vendor commitments in the agreement.

To address these issues, we strongly recommend supplementing the vendor's documentation with other standards and requirements. These other materials will almost always include an exhibit or schedule to the agreement that describes your organization's key requirements for the acquired product. If your organization used an RFP, the RFP documents also should be considered for inclusion. Together with the vendor documentation, these additional materials should be defined collectively as the "Specifications" and used consistently throughout the agreement. The agreement also should clarify that in the event of any inconsistency between the vendor documentation and your defined requirements, your defined requirements should prevail.

Finally, most vendor agreements do not refer to the concept of "acceptance." If a vendor-drafted agreement does include an "acceptance" provision, it is likely to state that acceptance shall be deemed to occur upon a certain event and/or the expiration of a certain period of time. Invariably, these "deemed acceptance" clauses are triggered so early in the acquisition process that they effectively prevent any meaningful acceptance testing rights. (See Sample Four(B) below)

The agreement should be revised to include specific acceptance testing rights, processes to follow if the product fails to pass these tests, and the ultimate consequences of failed acceptance testing. If the vendor is unable to fix reported problems after a reasonable number of attempts, the customer should retain the option to terminate the agreement and receive a full refund of all amounts paid (including, without limitation, product costs and service fees) as well as reimbursement for other out-of-pocket expenses incurred as part of the failed project (e.g., the costs of obtaining third-party hardware in reliance upon an expectation that the vendor's software would function properly).

• All warranties and other performance representations that originally required compliance with the vendor's "documentation" should be revised to require compliance with the newly defined "Specifications."

• Prepare a "Product Requirements" exhibit that defines your organization's key requirements (e.g., functionality, interoperability) for the acquired product.

• The definition of "Specifications" should include all functionality, interoperability, and other requirements or commitments that are included in (i) the agreement (including without limitation, the "Product Requirements" exhibit and any attached RFP documents); or (ii) any vendor documentation (but only to the extent consistent with (i) above).

• Use "Specifications" as the standard for the product not only in product warranties, but also as part of acceptance testing and maintenance and support.

• Include a specific "Acceptance Testing" provision in your agreement that authorizes your organization to perform those acceptance tests deemed necessary to confirm that the product complies with its "Specifications."

• In the "Acceptance Testing" clause, include: (i) a pre-defined process to follow if the product fails acceptance testing; and (ii) a clear description of the consequences of failed acceptance tests. These consequences should include the right to terminate the agreement and receive a refund of any amounts paid to the vendor as well as reimbursement of other costs and expenses incurred in connection with the failed project.

• Do not agree to automatic "deemed" acceptance after an arbitrary period of time. Acceptance should only occur when your organization has certified that the product complies with the Specifications.

• Withhold a meaningful portion of the payment until acceptance.

Most purchasers of health care technology base their purchasing decisions upon assumptions that go beyond product functionality. Despite this, many vendors offer few, if any, warranties beyond a very limited product performance warranty. (See Sample Five below.)

It is important for purchasers of health care technology to ensure that the agreement contains comprehensive warranties covering the full range of assumptions that are being made about the vendor and its product as part of the customer's purchase decision. Consider not only your business and technical assumptions, but also the many requirements that are unique to the health care industry.

Consider obtaining warranties that address the following topics:

• The vendor should warrant that the product will contain all functionality necessary to comply with all standards, guidelines, and recommendations of the Joint Commission on the Accreditation of Healthcare Organizations (JCAHO) and the National Committee for Quality Assurance (NCQA), and any other applicable independent accrediting or standard-setting organizations.

• The vendor should warrant that the product will comply, and will contain all functionality necessary for your organization to comply, with all applicable federal, state, and local laws, rules, and regulations (including, without limitation, those regarding Medicare or Medicaid, state and federal health care fraud and abuse laws, confidentiality laws, and the Health Insurance Portability and Accountability Act (HIPAA) of 1996 and its implementing regulations, and all regulations of the Centers for Medicare & Medicaid Services (CMS)).

• The vendor should warrant that it has obtained and will maintain all required approvals of and/or certifications by the U.S. Food and Drug Administration (FDA).

• The vendor should warrant that it (including its employees and subcontractors) is not listed by any governmental agency as excluded, debarred, or otherwise ineligible for participation in any governmental health care program, and that it will not contract with any individual or subcontractor who has been convicted of a criminal offense related to health care or has been excluded from participation in any governmental health care program. The vendor also should agree to screen potential employees andsubcontractors with the General Services Administration's (GSA) List of Parties Excluded from Federal Programs and the U.S. Department of Health and Human Services/Office of Inspector General (HHS/OIG) Cumulative Sanction Report.

• Depending on the payment structure in the agreement, if your organization's compliance with the Stark and Anti-Kickback laws is based upon an assumption that the vendor has no financial relationship with referring physicians, the agreement should contain a warranty that no such relationship exists and a commitment that the vendor will not create any such relationship with referring physicians in the future.

• The vendor should warrant that all services will be provided in a timely, workmanlike manner, and in compliance with the industry best practices.

• The vendor should warrant that the product will not infringe the intellectual property rights of any third party.

• The vendor should warrant that the product will be free from viruses, other destructive programs, and disabling devices.

• The vendor should warrant that there is no pending litigation that may impair or interfere with its performance of the agreement or the customer's right to use the product.

• In the case of software systems, the vendor should warrant that the recommended configuration is adequate to operate the software in the customer's environment.

• The vendor should provide appropriate warranties regarding the ability of its product to integrate and interface with other systems and products.

• The vendor should warrant that it will continue to offer maintenance and support on the product for a pre-defined period of time (minimum of five years) in the future, and that it will continue to provide updates, releases, and new versions of the product for a pre-defined period of time (minimum of five years).

• The vendor should warrant that it will not withhold services for any reason.

Most health care information technology vendors offer surprisingly few commitments with respect to maintaining and supporting their products in the future. In many cases, vendors will only obligate themselves to provide services consistent with their "then-current support policies." The vendor will then usually either provide a copy of the current support policies, or provide a reference to the internet Web site where the policies are available. Of course, this approach is problematic from a number of perspectives. First, most vendors draft these policies carefully to avoid "iron-clad" commitments and obligations. Instead, many of these documents focus more on the customer's obligations and responsibilities than on those of the vendor. Second, these policies and procedures are subject to change without the purchaser's approval. Unfortunately, vendor agreements will not offer the ability to terminate support or adjust the amount being paid for maintenance based on such unfavorable, unapproved changes.

In addition, despite the substantial costs associated with many health care IT initiatives, many vendors make no commitments regarding their obligation to offer future support beyond the initial term of any support contracts. When asked for such commitments, most vendors will initially respond that they will commit to provide support for only as long as the acquiring entity is willing to commit to purchase support. In other words, vendors are usually willing to extend the initial term of support, but are reluctant to make additional commitments. This result is unacceptable. Clients cannot, and should not, be forced to sign support contracts that mirror the expected useful life of the acquired technology asset (e.g., usually eight years or more). In most cases, the initial support term should be much shorter, with the acquiring entity having unilateral options to renew support. Finally, any maintenance and support fees should be fixed for a defined period of time (e.g., two to three years). After such time, any increases in maintenance and support fees should be capped at a fixed percentage. Without such protections, the vendor is able to force the customer to pay exorbitant maintenance and support fees because the vendor knows the customer must have the maintenance and support services to fully utilize the system.

• All technology assets are acquired with the assumption that they will have a useful life long enough to merit the price paid to the vendor. As such, the strength (or weakness) of the vendor's maintenance and support obligations will have a direct impact on the product's useful life and therefore your organization's ability to receive the expected benefits of the product.

• Do not define the vendor's support obligations with a simple reference to the "then-current support policies." Ensure that the vendor's maintenance and support obligations are specifically described in the agreement. These obligations should include, among other things: specific hours of coverage; a description of problem severity levels and corresponding response time obligations; a clear statement that the vendor will provide on-site services without additional charge if remote services do not promptly fix the reported problem; a description of the vendor's obligation to provide enhancements, updates, upgrades, and so forth; and, most importantly, a clear statement that the vendor is obligated to fix the product to maintain its conformance with the Specifications described in the agreement.

• Consider including "intermediate remedies" that give your organization the ability to exert leverage short of terminating or threatening a claim under the agreement. These intermediate remedies may include liquidated damage assessments or the issuance of credits if the vendor fails to meet response times or fails to resolve any failure to conform to the Specifications.

• Ensure that the vendor is contractually obligated to offer the support services described in the agreement for the expected useful life of the technology asset. In light of the length of this commitment, you may agree to permit the vendor to apply some form of price escalation (e.g., Consumer Price Index or some other adjustment) in future years, but it is critical that the price for these future, optional maintenance services be described in the agreement.

Health care providers operate in a complex regulatory environment that can have a substantial impact on the acquisition, implementation, and use of technology. To ensure your organization's ability to fully utilize the acquired technology and to realize its promised benefits, it is critical that your organization adequately consider and address the many regulatory issues that can be implicated in a health care technology transaction.

The following issues should be considered in health care technology transactions: Guidelines:

• Health Information Networks (HINs). The development of interoperable electronic health records (EHRs), and the creation of HINs (at either the community or the regional level) to facilitate the interchange of those EHRs, present a myriad legal issues that must be considered and addressed in such transactions. Although each transaction presents its own unique legal issues, common legal issues include those related to the selection of appropriate legal structures, obtaining financing and identifying potential sources of government funding, antitrust, HIPAA, and Stark and Anti-Kickback laws and regulations.

• HIPAA/State Confidentiality Laws. HIPAA's Privacy Regulations impose restrictions on uses and disclosures of patient information protected under HIPAA (referred to as Protected Health Informationor PHI). HIPAA's Security Regulations require those covered by HIPAA to implement certain physical, technical, and administrative safeguards to protect PHI. The requirements that HIPAA impose must be carefully considered prior to acquiring any health care technology that use, transmit, or store PHI. In addition, most states have enacted laws to protect the confidentiality of patient information. These laws vary from state to state and must always be carefully reviewed to determine their impact on the technology.

• Excluded Provider. The OIG has ruled that hospitals and health systems that purchase items or supplies from "Indirect Providers" who have been excluded from the federal health care programs may not receive any reimbursement for those items and services, and may face additional civil monetary penalties. The OIG defines "Indirect Providers" as those individuals or entities who provide items and services to health care providers, practitioners, or suppliers without billing the federal programs. Generally, Indirect Providers include individuals and entities that manufacture or supply certain medical equipment and supplies to direct providers for use in their practice. The direct providers subsequently bill the federal programs for these items and services. Any time a hospital contracts with an individual or entity for the provision of reimbursable supplies or services, the hospital should protect itself by: (i) confirming that the individual or entity has not been sanctioned or excluded from participation in those programs by checking the OIG web site (www.oig.hhs.gov); and (ii) including the "Excluded Provider" warranty (described above) in its agreements.

• Federal Physician Self-Referral (Stark) Law. The Stark Law generally prohibits physicians from referring patients to an entity for certain health services if the physician (or an immediate family member) has a financial relationship with the entity, and further prohibits entities from billing for any services resulting from such referrals, unless an exception applies. Hospitals have been correctly reluctant to provide referring physicians with hardware, software, or other technology resources due to a concern that such arrangements violate the Stark Law. The "Phase II interim final rule" to the Stark Law created a new exception that in certain circumstances permits the provision of technology to physicians to enable the physician’s participation in a "community-wide health information system." That rule also clarified that certain technology may be provided under the "medical staff incidental benefits" exception. A recent proposed regulation would allow a hospital to provide hardware, software, information technology, or training necessary and to be used solely for e-prescribing. Comments also are being solicited for a broader exception. All of the Stark exceptions are narrow, and any plan to provide technology or related services to physicians should be reviewed carefully to ensure compliance with the Stark Law.

• Federal Anti-Kickback Law. The anti-kickback law prohibits an individual or entity from knowingly and willfully offering, soliciting or accepting remuneration of any kind to induce a patient referral for, or the purchase of, an item or service paid for by any federal health care program. Similar to the Stark Law concerns, hospitals traditionally have been reluctant to provide technology resources to a referring physician out of a fear that the technology will be viewed as remuneration in exchange for the physician’s referrals. Although there is a recent proposed safe harbor which parallels the proposed Stark exception for e-prescribing discussed above, any arrangement with a referral source should be carefully reviewed.

• State Physician Self-Referral and Anti-Kickback Laws. Many states have laws analogous to the federal laws discussed above that should be considered and addressed for the same reasons.

• Private Inurement/Private Benefit/Excess Benefit Issues. Under the Internal Revenue Code, tax-exempt organizations that provide certain financial or other benefits to private individuals or for-profit companies may jeopardize their tax-exempt status. An excess benefit may trigger an excise tax and other penalties.

• Beneficiary Inducement Issues. Under the prohibition on beneficiary inducement, health care entities may not provide something of value to a patient or prospective patient if they know or have reason to know that it will influence the patient’s choice of provider. If the particular technology or service being acquired involves a direct interface between the vendor and your patients, beneficiary inducement issues should be reviewed carefully to ensure that the transaction does not violate this prohibition.

• Private Use Limitations. These limitations restrict the degree to which private parties may use facilities that are financed with the proceeds of tax-exempt bonds. Private use that exceeds certain limitations may jeopardize tax-exemption. Although "private use" issues are not frequently implicated in routine technology acquisition agreements, they should be reviewed and addressed in any transaction where a private party (e.g., a technology services vendor) will be utilizing bond-financed property to provide services.

• Unrelated Business Income. Tax-exempt organizations that generate income from business activities not substantially related to the role that qualified them for tax-exempt status must pay Unrelated Business Income Tax (UBIT) on that income. For example, if a tax-exempt hospital permits physicians or other entities to access and use certain technology, or provides technology-related services to those individuals or entities, any fees received for these activities are likely to trigger UBIT.

• Telemedicine/Licensure Issues. Although licensing requirements vary by state, physicians generally must be licensed to practice medicine in the state(s) in which they practice. Many new health care technologies are directly at odds with traditional licensing requirements. For example, these new technologies may enable a radiologist in California to use a teleradiology or picture archival and communication system (PACS) to access and view images of a patient in Idaho. Other technologies enable physicians to monitor multiple intensive care units from a centralized, remote location. Although these technologies may offer a number of significant benefits, particularly to rural areas of the country where specialty care is limited, state licensing and telemedicine laws must be carefully reviewed to ensure that the use of this technology complies with applicable laws.

• E-Prescribing Regulatory Barriers. Although many health care providers are embracing electronic prescription-writing systems as a means of reducing costs and medical errors, a number of states still do not have laws enacted that permit electronic prescriptions. Other states may permit electronic prescriptions generally, but may interpret electronic signature requirements in a manner that limits your organization's ability to receive the full benefit of its system.

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.