Outsourcing is a buzz word for various types of transactions. Outsourcing
consists of one party, the Vendor, providing regular services to another party,
the Customer, over an extended period at an agreed cost and level of
performance. Outsourcing information technology ("IT") resources takes many
formats.
One outsourcing trend in the healthcare industry is for vendors of
healthcare software applications, such as clinical information systems, to
provide Customers a choice. Customers may follow the classical license model
with the software installed on the Customer's systems, or they may elect the
Vendor's outsourcing services referred to as remote hosting of the Vendor's
software applications. If the healthcare provider chooses the remote hosting
option, it is in essence outsourcing a core technology system. As such, the
healthcare provider will be faced with many of the complex business and legal
issues normally associated with outsourcing whereby the Customer transfers to a
Vendor resources and services that the Customer had previously owned and managed
internally.
The following reviews a few of the important and interesting issues
grappled with when a healthcare provider acquires new healthcare related
computer resources that will be hosted and serviced by the Vendor remotely at
the Vendor's location.
Acceptance is often a hot button issue in the acquisition of computer
resources and becomes even more of an issue when the Vendor is also remotely
hosting the application. In that case, two items are being accepted, the
software application and the hosting service.
Acceptance involves various issues. With respect to the software, the
Vendor may seek to trigger acceptance on such standards as the software performs
"in all material respects" or "substantially in accordance with the
Documentation." With respect to both the software and the hosting services,
Vendors often seek to trigger acceptance on "first productive use," "first live
use," or "when all errors reported within the acceptance period have been
corrected." Healthcare providers prefer something more akin to the perfect
tender rule. For purposes of acceptance, the Customer should, at a minimum,
insist that the application perform in accordance with the documentation but
only after determining that the documentation adequately describes the desired
features, functionalities, and performance capabilities of the software and
hosting service.
Vendors argue that if the Customer places the application into live or
productive use for the benefit of actual patients, then the software should be
deemed accepted. Vendors support that position with various logical arguments,
including that the healthcare provider has the opportunity to fully test the
software prior to placing it into such use and must have been satisfied with its
performance to take such a step. From the Vendor view, the healthcare provider
should not take advantage of the benefits of the software and service to treat
and charge patients without accepting and paying the Vendor.
Anyone who has ever sat in front of a computer screen, however, knows
that until you actually use a new computer resource or service in a real life
situation, you can not know how it will function when rolled out to the
provider's staff. From the Customer's view, the Customer has not had a
reasonable opportunity to inspect the product and service until it has sat
behind the wheel and driven a few miles - usually at least 30 days of acceptance
testing during live use.
The agreement should also provide for acceptance of the remote hosting
service. The acceptance criteria should correspond to and often mirror some of
the service level agreements ("SLAs"). A principal metric for both acceptance
and SLAs involves response times. This metric raises the question of how to
address the network connection between the Vendor's server and the Customer's
server. Initial SLAs from a Vendor often measure only the time within the
Vendor's system - from the moment the request is received at Vendor's gateway
until the moment the response is available for the Customer at Vendor's gateway.
The Customer, however, is concerned with the time it takes to get from query to
answer; when the doctor requests an x-ray, how long must she wait to view the
x-ray that is hosted on Vendor's system. An appropriate metric therefore should
include the connection between the Customer's system and the Vendor's system and
factor in the parties' control or lack of control over such connection.
The acceptance process should include an opportunity for the Vendor to
correct errors that arise during the acceptance testing and for the Customer to
retest. It should not allow a continuous period for the Vendor to keep trying to
fix errors. Rather, the acceptance process should include a deadline by which
the Vendor must have demonstrated that the application and service perform as
promised. The deadline should be a specified, fixed date. If acceptance has not
occurred by the date specified, then the Customer may reserve its rights and
allow the Vendor additional time to achieve final acceptance or, alternatively,
terminate the contract and obtain any agreed upon remedies such as a refund of
fees paid to date.
Service level agreements are key to a successful outsourcing arrangement.
They should be viewed not as a means of extracting a penalty from a Vendor that
has failed to perform at an agreed level, but more as a means of monitoring and
managing the level of performance desired by the Customer. Those involved in
negotiating SLAs can easily lose sight of the true nature of a successful
outsourcing. The parties should view the outsourcing as a team, each member
seeking its own personal success but knowing its success is dependent on the
other member's success. If the Customer extracts monetary remedies that inflict
economic hardship on the Vendor, the long term result is likely to be the
opposite of what the Customer truly wants and needs.
Applying the team concept in crafting SLAs should result in effective
SLAs that enhance the likelihood of a successful outsourcing. Effective SLAs
usually consist of (i) metrics that are focused on key performance indicators,
(ii) reasonable monetary penalties for failure to achieve targeted performance
levels, (iii) the ability for the Vendor to gain back the monetary penalties
through performance that exceeds specific targets, (iv) a method to determine
and remedy the cause of the failure, and (v) a process for periodic review and
adjustment of the SLAs. The SLAs also need to include a metric, such as excess
repetitive failures, by which the Customer may declare the Vendor's performance
unacceptable and a corresponding process for the termination of the outsourcing
arrangement.
Often SLAs are a numerical measurement of a key aspect of the Vendor's
performance. A key performance indicator for remote hosting is system
availability. The basic approach for measuring system availability consists of
comparing the number of hours that the system is actually available for Customer
use against the number of hours it was scheduled to be available over a set time
period. Such an equation is rife with opportunities to skew it to the point it
becomes meaningless to the Customer or unreasonably burdensome to the Vendor. In
that regard, the definitions of the terms "available" and "scheduled" are key.
If the "scheduled" hours are reduced by the number of hours devoted to emergency
repairs (a typical provision in some Vendor's standard SLAs), then time that the
system is unavailable for emergency repairs will actually enhance the Vendor's
performance rating regarding system availability because not only is such time
not counted as downtime but it reduces the denominator of the equation. The time
period over which the metric is measured may also be used to skew the equation.
Because SLAs are often a percentage, the longer the period over which the
measurement is made, the more favorable it is for the Vendor as it will allow
poor performance to be lost in the average spread out over a longer period.
Healthcare is a highly regulated industry. Long term agreements for the
provision of services which directly affect healthcare services must stipulate
how changes in the law will be addressed. In essence, the question involves what
obligations and liabilities, if any, the Vendor should have if a change in law
requires, or may be complied with by, a change or addition to the application or
services provided by the Vendor. In approaching this question, Customers must
remember that the applicable laws and regulations most often govern the
healthcare provider, not the Vendor or its software or services.
Privacy and security in healthcare mean HIPAA. In most healthcare
outsourcing transactions, the standard HIPAA business associates addendum will
be insufficient. In addition to the standard covenants regarding the
confidentiality of the protected health information ("PHI") and not using any
PHI other than in connection with the services provided under the agreement with
the Customer, the parties, through the BAA or a provision in the Agreement,
should also address how they will respond if a breach of security occurs and PHI
is or might have been obtained by an unauthorized person. The provision should
require not simply that the Vendor will report any unauthorized disclosure to
the healthcare provider. The Vendor should be obligated to provide the
healthcare provider all information and assistance required or reasonably
requested for the healthcare provider to comply with enacted laws to fight
identity theft.
Those laws need to be reviewed to determine their applicability. Many,
like New Jersey's Identity Theft Prevention Act, N.J.S.A. 56:8-161, et. seq.,
apply to all businesses and impose certain obligations on both the businesses
that own the personal information and vendors that serve those businesses. For
example, under the New Jersey Act, "personal information" means an individual's
first name or initial with the last name linked to one of three categories of
information, one of which is the individual's Social Security Number. The New
York law regarding identity theft has a similar definition which also includes
the SSN as one element. Insurance companies and healthcare providers have long
used the SSN as a patient identifier, and therefore there is a great likelihood
that patient information contained within the healthcare provider's information
systems will include patients' Social Security Numbers. Consequently, an
evaluation should be made as to whether any of the new identity theft statutes
are applicable and then document compliance obligations as appropriate.
The above is a short sample of issues to address when a healthcare
provider acquires a new IT solution through remote hosting by the Vendor of the
solution. The main point to remember is that the transaction is not merely a
different way of licensing the Vendor's solution. In order to effectively
represent the healthcare provider, counsel must also address the outsourcing
related issues.
Published March 1, 2006.
