Published in the Third Quarter (November 2010) issue of HCM&C.

All large-scale IT system procurement or implementation or business-as-usual contract documents include terms and conditions which are representations or warranties made by one party to the benefit of the other. When a representation or warranty is breached by the party who made or makes it, legal consequences typically follow, among which might be: a problem report is filed, dispute resolution mechanisms are engaged, mediation or arbitration may be triggered, work may slow or stop, pricing may become subject to change, the contract itself may be subject to early termination, either in whole or in part, and the breaching party may be caused to indemnity or make good any damage to the other party or to third parties who are not part of the contract but are affected.

Contracts Generally:

Superficially, contracts are documents which record the bargain made between parties, and comprise the description of an exchange of value and obligations. In complex situations (such as large-scale IT procurements), contract terms also provide a mechanism for describing a variety of future risks and allocating those risks between or amongst the parties.

Risk allocation is negotiated within the contract negotiations (whether knowingly or not), and consequential to the contract's terms, conditions, representations and warranties, the parties will have either assumed or offloaded, provided for insurance, or shared, the consequences of certain types of risk events occurring in the future. This concept (of risk-allocation) is important when thinking about how contract terms will play out in areas where there is future uncertainty (such as risk of regulatory or legislative change which affect the parties' operations in future).

Contracts are also designed to appropriately motivate the parties' behaviors in a commercial sense, and to shift the cost burden of a failure appropriately (rationally, to the party best suited to mitigate or obviate the risk of the failure occurring, the party able to best predict or protect against consequences caused by a particular type of breach, to insurance, or as the parties agree based upon stated or un-stated compensation for the risk).

"Compliance with Law" Terms

One typical contract term which may not be adequately examined often enough is the usual and ordinary representation or warranty of "compliance with laws". For example, such a term might be along the following lines:

"Party A represents and warrants that: it has the authority to enter into and perform the obligations set forth in this Agreement; neither entering into nor performing the obligations contemplated in this Agreement will be in breach of any legislation or regulation or law or rule of application; it has done all things and obtained all licenses and permits necessary to enter into and perform the obligations set out herein"

This type of promise (to comply with all laws) can be parsed into several time frames and can also be modified to address a number of areas of particular risk:

  • a promise of compliance with all laws at signing
  • a promise of continued compliance with all laws during the term
  • a promise of compliance with laws and regulatory regimes known to exist or which are predictable at the time of signing
  • a promise of compliance with unknown future laws and regulations as they later become known and applicable
  • adjustment of price for changes in costs to comply in future
  • indications of any standard of compliance if other than 100% compliance is possible

The clause may provide little guidance about where compliance will be required with which laws and regulatory schemes or in which jurisdictions,.

As well, these "compliance with laws" terms are often not specifically tailored, and are given reciprocal application (applies equally to each party), or are imposed only upon the supplier with no special treatment afforded to a breach other than to treat it similarly to a breach of any other term of the agreement.

Arguably, blanket approaches to "compliance with all laws" clauses may not adequately protect the parties from specific types of risk. (One may encounter similar circumstances dealing with "force majeure" clauses which, if improperly drafted can over-ride disasterrecovery service levels (by excusing performance in the event of a failure with causes beyond either party's control, such as massive electrical or network outage)).

The Contracting Environment in Healthcare IT:

In large-scale projects, it is not unusual to involve multiple parties headquartered in multiple jurisdictions providing services and materials sourced or provided from multiple jurisdictions, and some very different bargaining positions amongst the parties. Services may be provided, data processed or stored, backups and special functions performed on data sets, human operators may be located, at different places in the world, and normal expectations about things like governing law may not apply.

Special rules may exist with respect to off-shoring or outsourcing. Foreign jurisdictions may enact rules or laws which change expectations regarding security, protection of personal information, ability to or responsibility to report breaches of data security or repurposing of data collections, regulatory compliance, etc.

Large IT system implementations may in fact not be jurisdiction bound, but may span a number of jurisdictions, making choice of laws, attornment to tribunals, and alternative dispute resolution (arbitration, mediation, escalation procedures) much more important when related to "compliance with all laws" sorts of promises.

Examples of Supplier/Vendor Concerns:

  • Which rules apply? If there are territoryspecific rules which apply, do they cause non-compliance in some other part of the vendor's organization (duty under USA Patriot Act to make disclosure to government without notifying the data custodian; duty under contract to notify the data custodian of all requests for disclosure); are the regulatory regimes for a subject-matter in flux (examples below deal with patient information protection and regulation of software as "medical device")?
  • Would attempts to hypercompliance in one jurisdiction result in diverting resources from more important corporate functions?
  • Is compliance in the vendor's long-term interests (agreement to provide source code, data formats, or data conversion software or services – removing barriers to user migration)?

Examples of Acquiror Concerns:

  • Will the organization withstand audit for internal compliance?
  • Is the possibility of non-compliance a "show stopper" for operations (either safety issues, funding issues, or reputational issues)?
  • Will insistence on hypercompliance distort the marketplace (raising pricing, driving vendors to more favorable jurisdictions, causing small or stretched vendors to drop out or consolidate) or form a non-tariff trade barrier?
  • Will insistence on over-compliance or overly conservative interpretation of regulatory compliance be an inappropriate or even illegal procurement requirement?
  • Will insistence on a particular mechanism for compliance preclude a more logical or more appropriate other mechanism?
  • Is flexibility of solutions or future interoperability with jurisdictionally broader systems negatively affected?

Real-World Illustrations:

Two examples from the Healthcare IT systems realm illustrate the concerns:

  1. Protection of Personal Health Information (a.k.a. Privacy)
  2. Regulation of Software as a Medical Device (a.k.a. SAMD)

A. Personal Health Information

The protection of personal information of any type has only relatively recently become a regulated aspect of information technology systems, beginning with early open government initiatives (FOIPPA). Recently (within the past 10 years), rules above and beyond "freedom of information and protection of personal information" regimes which bound governments, have been introduced in a variety of differing ways in a variety of different jurisdictions. In Canada, many provinces have a different variant of the theme, some treating health information as a subspecies of personal information, others elevating personal health information to have a different status, with different rules relating to access, consent, repurposing, outsourcing and offshoring (among other things). In the USA, and in each particular state within the USA, other rules apply (HIPAA, some aspects of "meaningful use" under HITECH, various state laws). Similarly, rules across the EU differ. These data protection regimes also collide with, and are sometimes over-ridden by, laws relating to law-enforcement's access to information to combat terrorism or other crime.

Healthcare IT contracts drawn during the past 10 years and up to the present, routinely have had "compliance with all laws" clauses, despite the variability in regulation of protection of personal health information, and despite the changing landscape within jurisdictions as these new regulatory schemes were designed, put into place, and are recently being modified and amended.

During the past 5 years or so, it has become more common to carve out compliance with particular parts of the "compliance with all laws" obligation dealing with protection of personal health records by identifying that set of compliance obligations as a separate set of obligations, and by ascribing specific compliance objectives (for instance, compliance with a scheduled privacy policy and procedures document, or compliance with a specific regulatory regime at the point in time of signing, specific arrangements with respect to providing Privacy Impact Assessment documents with respect to system implementations and changes, annual audit reports on breaches and potential security issues), and then allocating the burden of compliance with any changes to that particular regime (typically giving the acquiror a system which complies in all respects with all data protection rules at the time of signing, with a right to require compliance by the vendor or other parties with stricter or different protection rules enacted in future -- but at the added cost of the acquiror – sometimes but not always with a caveat that the acquiror will not alone pay for compliance efforts of the vendor if those efforts benefit other of vendor's customers). It gets complicated.

It has also become commonplace to require all parties to large healthcare IT agreements to report all security and privacy breaches to each other as those breaches become known, and to require assistance from each other (whether at the acquiror's cost or otherwise) in both dealings with any relevant Privacy Commissioner's enquiries or actions, and in mitigating (finding and stopping, then dealing with consequences of) such breaches. Those same reporting and assistance obligations are not typically spelled out with respect to other types of breach (except perhaps those dealing with patent or copyright infringements, which are breach behaviors with similar 'stop the presses' consequences).

Most healthcare provider organizations with significant IT systems will, as a part of their internal audit and control reporting disciplines, provide a statement by a senior executive officer to the organization's board (and oversight agencies as applicable) that the organization is in compliance with all laws and regulations, with an exception list of out-of-compliance situations which are known at that time. Recently, risk management offices in these types of organizations will have included specific sections of their internal audit checklists dealing with IT data security, personal information protection, external data accesses, breaches, and enquiries related to patient information protection. These requirements need to be considered when these special-purpose representations, warranties, terms and conditions are being negotiated, and since audit conditions may tighten or loosen over time within the procuring organization, mechanisms for changing reporting requirements should also be considered.

This level of contract language specificity arises as the regulatory regime first becomes apparent (as the risk is less known), then matures, and changes as the regulatory regime's focus, enforcement efforts, and rules mature and become clearer. This is particularly the case where non-compliance could become a "show-stopper" for operations, and interfere with provision of healthcare to populations. Once the regulatory regimes become better known and organized, and outcomes, potential types of breach and their consequences become more predictable, contracting language becomes more normalized and exotic or special clauses become less common.

[Contextual Timing: Alberta HIA - 2001; Ontario PHIPA - 2004; HIPAA (USA Fed) – 1996; HITECH (USA Fed) -2009; EU Data Directives related to Personal Information Protection – OECD 1980- 1999]

B. Regulation of Software as Medical Devices

Background:

There is movement in the health informatics industry, as that industry matures and consolidates, toward a more disciplined approach to protecting patient safety in the context of the life-cycle (from design through customization and implementation and maintenance through to eventual replacement) of large and complex, massively interactive, networked information systems, including data structures and software of all types. This is akin to the adoption in more traditional manufacturing operations of quality standards and assurance systems such as Six Sigma and ISO-9000 (and related) standards and doctrines.

Some regulators in most western jurisdictions have begun discussing what these standards should be, whether and where government bodies should impose and enforce regulations to force quality standards, but more basically, whether regulation of large-scale IT systems by government is required based upon any empirical evidence of risk to patient safety from such systems. The USA seems to have concluded, at least for the interim, that "meaningful use" under HITECH Act and similar granting rules is an appropriate place to begin regulating software and IT systems with an eye to protection of patient safety (and for the time being, it seems that the US-FDA has refrained from exerting any regulatory or licensing authority over IT systems in healthcare). Discussions are underway in standards bodies in the UK and the EU, with some of the northern social democracies beginning to adopt regulatory and licensing of certain software systems used in patient care, while other nations are debating the appropriate parties and places where regulation or licensing would be most effective.

Canada, though the Ministry of Health Canada's Device Licensing regulatory body (operating under the Food and Drugs Act and Medical Device Regulations) has begun to analyze the regulation of certain types of patient management software and systems as if those systems were "medical devices". Health Canada has issued several notifications and publications which are meant to alert the health informatics industry in Canada that some types of patient management systems may be captured as "medical devices" and that licenses to market or sell such systems may be required. A period of grace has been offered to permit the healthcare informatics industry to review their products and implementations to determine whether or not they will be required to obtain Device Licenses.

Risk Uncertainty, Regulations in Flux

Vendors are confused by this approach, and some have begun efforts to obtain certification as compliant with ISO:13485 quality assurance processes, in case they are required to obtain Device Licenses (as certified compliance with ISO:13485 is a precondition to certain types of licensure, in particular marketing and distribution of Class 2 and higher devices). Acquirors are also confused by Health Canada's approach, and have begun to insert requirements into their procurement discussions or processes that vendors comply with Health Canada licensing regulations (some may go further and insist on certification under ISO:13485), which may well be inapplicable and therefore wasteful of resources.

Health Canada has attempted to communicate that it will be the exception rather than the rule that electronic health record systems will fall into the classification of "Medical Device". Health Canada has also indicated that:

  • ASP delivery models are not captured.
  • Middleware (as that term is commonly understood in Canadian health informatics terms) is not a medical device.
  • Software and systems above the HIAL(Health Information Access Layer), as defined in Canada Health Infoway's publications about health information system architectures, will not be classed as "Medical Devices".
  • EMRs without special functionality such as implemented artificial intelligence to replace or supplant medical judgment will not be a medical device.
  • There is some indication that, in order to be a medical device, software must be embedded within, or immediately adjunct to, or be required for the operation of, a traditional physical medical device; or alternatively, to directly and in real-time replace or supplant clinical judgment without opportunity of a healthcare professional to intervene in diagnosis or treatment of a patient's health
  • By the time this article is published, Health Canada may have published further clarification in the form of a proposed FAQ, which should be considered alongside this article if available

This confusion amongst Acquirors and Vendors alike has the opportunity to divert scarce resources in IT and development away from implementation and improvement of healthcare IT systems toward efforts to comply with speculative standards. There is the chance that misinterpretation of the application of the Medical Device Regulations could delay or defer, or even disable mission-critical IT systems, affecting the delivery of healthcare to Canadians. That is certainly not the goal of any player in Canada's healthcare system, and would obviously be an unintended consequence, and to be avoided.

Finally, if Canada is seen to take an overly aggressive regulatory stance, out of step with other jurisdictions where similar IT systems are deployed, Vendors may redirect their attention to other marketplaces, thus isolating Canada from sources of innovative IT systems required to improve healthcare delivery to its citizens and diminish competition in the Canadian marketplace.

It is important to recognize that patient safety within the healthcare delivery systems is already highly controlled through an ecology of checks, balances, licensure, governance, professionalism, contracting, standards of care and litigation, and testing.

Medical device licensing is only one part of that ecology, but the discussion surrounding requirements for more disciplined quality assurance processes in the design, build, implement, configure, maintain, grow, replace life-cycle of IT systems is currently a very timely and welcomed topic,. However, the scope of where regulators will eventually focus their attention within healthcare IT systems is currently uncertain (within some predictable bounds).

Situation Analysis, Coping Strategies

Similar to the early stages of uncertainty in the regulation of protection of patient health information, it is possible to develop strategies as vendors and acquirors, to logically allocate the risk of non-compliance if indeed compliance is eventually required, and to identify the likelihood of a requirement for compliance.

We are currently seeing detailed analysis on both technical and legal levels, of the nature of various components of healthcare IT product families and systems, with an eye to whether or not those components or their families will fall under Health Canada's definition of Medical Device, and then what risk profile and Class of device. These analyses are taking place internally, with external expert counsel, with quality assurance consultants, and within procuring organizations.

It is our experience that knowledge gained by these analyses can be very useful to organizations, whether vendors or procurers, in their reaction to both the current Medical Device regulatory schemes, and to the growing recognition that disciplined approaches to quality assurance to protect patient safety from risks potentially introduced by automating and re-tooling healthcare IT systems.

As an example, it is possible to analyze the factors present in IT system components to determine their "deviceness" and the likelihood (or not) of requiring Medical Device licensing compliance. Adjunct to that analysis, an analysis of the delivery model or "business model" for the provision of IT systems to healthcare providers and patients can assist in focusing quality assurance requirements on the person or entity within the overall system which is most capable of recognizing lapses or risks, and which party is most adequately placed to report, mitigate, and fix problems. Further, situations exist, for instance, where software may not be sufficiently configured by a vendor to be a medical device on delivery and installation, only becoming a "device" once configured by the acquiring organization (by enabling such things as CPOE with sufficient artificial intelligence to potentially replace professional judgment in an opaque way, or to push decision making processes past problem identification and suggestion into treatment or diagnosis design or implementation).

It is also important for provider organizations to understand situations where software internally developed is for "own use" and where it starts to become distributed (on distribution, licensing may become required—internal use devices are not regulated in this way).

Finally, it is very important to realize that medical device regulations will impose a set of quality assurance compliance obligations which are appropriate to devices, and which are not entirely appropriate to highly configurable, malleable, and multi-purpose/multi-party IT systems. It is possible to substitute inappropriate regulation for appropriate quality regimes inadvertently, and to deploy scarce healthcare resources (both vendor and procurer resources) to, in essence, solve the wrong problem by obtaining compliance with device standards when compliance with other quality standards would more effectively protect patient safety.

Conclusions:

Vendor and Procurer organizations alike should be analyzing the "medical device" situation to determine whether it is really of immediate concern, and prepare and negotiate procurement and provisioning agreements (and internal audit and other control mechanisms) to suit the particular requirements arising from the particular systems at issue.

More importantly, specific quality assurance, issue and error reporting, and product recall/repair opportunities to mitigate risk to patient safety should be identified, and obligations in those risk contexts should be specifically negotiated and embedded within procurement or contract terms and conditions.

Much like the earlier experiences with uncertainty in the regulation of Privacy, blanket "compliance with laws" contract clauses are unsatisfactory when dealing with the risks associated with changing regulatory requirements having to do with quality assurance and patient safety.

An understanding of the particular regulatory risks associated with particular IT systems, subsystems and applications becomes very useful in identifying and isolating risks, allocating responsibility for compliance, and determining whether or not and to what degree future regulatory risks need to be addressed in what are typically very long-term relationships and obligations.

Quality assurance can and should be managed separately from the question of Medical Device license compliance, and assessment and negotiation of warranties of system operation, quality, errors, error reporting, problem fixing, etc (all having to do with patient safety within healthcare IT) can and should be negotiated separately from "compliance with laws" issues.

In most cases, current healthcare IT systems will not be medical devices requiring licenses – however, in all cases, both vendor and procurer organizations should be and are very focused on protection of patient safety through increasingly disciplined quality assurance processes within the design, programming, build, modification, configuration, implementation, migration etc. of modern and future healthcare IT systems.

Those quality efforts can and should be identified and contracted for in more specific terms, based upon clear understandings of the risks associated with particular system components.

We are at a stage in the quality assurance discussion where specific attention to patient safety within contract negotiations is arguably required, above and beyond generic "compliancw with law" language in contract documents.

Michael Whitt, QC Legal Editor, is a Partner and co-chair of the IT Practice Group with Bennett Jones LLP, a prominent Canadian law firm. His practice includes a focus on technical analysis of Healthcare IT systems for medical device compliance (among other things in Calgary, Alberta).

Martin Kratz, QC is a Partner and Chair of the Intellectual Property Practice Group with Bennett Jones, and also has a focus on Healthcare IT systems (among other things)in Calgary, Alberta.

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.