Canada: "Compliance with Laws" - Representation and Warranty in Large System Procurement Agreements

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.

To print this article, all you need is to be registered on Mondaq.com.

Click to Login as an existing user or Register so you can print this article.

Authors
Martin P.J. Kratz
 
In association with
Related Video
Up-coming Events Search
Tools
Print
Font Size:
Translation
Channels
Mondaq on Twitter
 
Register for Access and our Free Biweekly Alert for
This service is completely free. Access 250,000 archived articles from 100+ countries and get a personalised email twice a week covering developments (and yes, our lawyers like to think you’ve read our Disclaimer).
 
Email Address
Company Name
Password
Confirm Password
Mondaq Topics -- Select your Interests
 Accounting
 Anti-trust
 Commercial
 Consumer
 Criminal
 Employment
 Energy
 Environment
 Family
 Finance
 Government
 Healthcare
 Immigration
 Insolvency
 Insurance
 International
 IP
 Law Performance
 Law Practice
 Litigation
 Media & IT
 Privacy
 Real Estate
 Strategy
 Tax
 Technology
 Transport
 Wealth Mgt
Regions
Africa
Asia
Asia Pacific
Australasia
Canada
Caribbean
Europe
European Union
Latin America
Middle East
U.K.
United States
Worldwide Updates
Check to state you have read and
agree to our Terms and Conditions

Terms & Conditions and Privacy Statement

Mondaq.com (the Website) is owned and managed by Mondaq Ltd and as a user you are granted a non-exclusive, revocable license to access the Website under its terms and conditions of use. Your use of the Website constitutes your agreement to the following terms and conditions of use. Mondaq Ltd may terminate your use of the Website if you are in breach of these terms and conditions or if Mondaq Ltd decides to terminate your license of use for whatever reason.

Use of www.mondaq.com

You may use the Website but are required to register as a user if you wish to read the full text of the content and articles available (the Content). You may not modify, publish, transmit, transfer or sell, reproduce, create derivative works from, distribute, perform, link, display, or in any way exploit any of the Content, in whole or in part, except as expressly permitted in these terms & conditions or with the prior written consent of Mondaq Ltd. You may not use electronic or other means to extract details or information about Mondaq.com’s content, users or contributors in order to offer them any services or products which compete directly or indirectly with Mondaq Ltd’s services and products.

Disclaimer

Mondaq Ltd and/or its respective suppliers make no representations about the suitability of the information contained in the documents and related graphics published on this server for any purpose. All such documents and related graphics are provided "as is" without warranty of any kind. Mondaq Ltd and/or its respective suppliers hereby disclaim all warranties and conditions with regard to this information, including all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement. In no event shall Mondaq Ltd and/or its respective suppliers be liable for any special, indirect or consequential damages or any damages whatsoever resulting from loss of use, data or profits, whether in an action of contract, negligence or other tortious action, arising out of or in connection with the use or performance of information available from this server.

The documents and related graphics published on this server could include technical inaccuracies or typographical errors. Changes are periodically added to the information herein. Mondaq Ltd and/or its respective suppliers may make improvements and/or changes in the product(s) and/or the program(s) described herein at any time.

Registration

Mondaq Ltd requires you to register and provide information that personally identifies you, including what sort of information you are interested in, for three primary purposes:

  • To allow you to personalize the Mondaq websites you are visiting.
  • To enable features such as password reminder, newsletter alerts, email a colleague, and linking from Mondaq (and its affiliate sites) to your website.
  • To produce demographic feedback for our information providers who provide information free for your use.

Mondaq (and its affiliate sites) do not sell or provide your details to third parties other than information providers. The reason we provide our information providers with this information is so that they can measure the response their articles are receiving and provide you with information about their products and services.

If you do not want us to provide your name and email address you may opt out by clicking here .

If you do not wish to receive any future announcements of products and services offered by Mondaq by clicking here .

Information Collection and Use

We require site users to register with Mondaq (and its affiliate sites) to view the free information on the site. We also collect information from our users at several different points on the websites: this is so that we can customise the sites according to individual usage, provide 'session-aware' functionality, and ensure that content is acquired and developed appropriately. This gives us an overall picture of our user profiles, which in turn shows to our Editorial Contributors the type of person they are reaching by posting articles on Mondaq (and its affiliate sites) – meaning more free content for registered users.

We are only able to provide the material on the Mondaq (and its affiliate sites) site free to site visitors because we can pass on information about the pages that users are viewing and the personal information users provide to us (e.g. email addresses) to reputable contributing firms such as law firms who author those pages. We do not sell or rent information to anyone else other than the authors of those pages, who may change from time to time. Should you wish us not to disclose your details to any of these parties, please tick the box above or tick the box marked "Opt out of Registration Information Disclosure" on the Your Profile page. We and our author organisations may only contact you via email or other means if you allow us to do so. Users can opt out of contact when they register on the site, or send an email to unsubscribe@mondaq.com with “no disclosure” in the subject heading

Mondaq News Alerts

In order to receive Mondaq News Alerts, users have to complete a separate registration form. This is a personalised service where users choose regions and topics of interest and we send it only to those users who have requested it. Users can stop receiving these Alerts by going to the Mondaq News Alerts page and deselecting all interest areas. In the same way users can amend their personal preferences to add or remove subject areas.

Cookies

A cookie is a small text file written to a user’s hard drive that contains an identifying user number. The cookies do not contain any personal information about users. We use the cookie so users do not have to log in every time they use the service and the cookie will automatically expire if you do not visit the Mondaq website (or its affiliate sites) for 12 months. We also use the cookie to personalise a user's experience of the site (for example to show information specific to a user's region). As the Mondaq sites are fully personalised and cookies are essential to its core technology the site will function unpredictably with browsers that do not support cookies - or where cookies are disabled (in these circumstances we advise you to attempt to locate the information you require elsewhere on the web). However if you are concerned about the presence of a Mondaq cookie on your machine you can also choose to expire the cookie immediately (remove it) by selecting the 'Log Off' menu option as the last thing you do when you use the site.

Some of our business partners may use cookies on our site (for example, advertisers). However, we have no access to or control over these cookies and we are not aware of any at present that do so.

Log Files

We use IP addresses to analyse trends, administer the site, track movement, and gather broad demographic information for aggregate use. IP addresses are not linked to personally identifiable information.

Links

This web site contains links to other sites. Please be aware that Mondaq (or its affiliate sites) are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of these third party sites. This privacy statement applies solely to information collected by this Web site.

Surveys & Contests

From time-to-time our site requests information from users via surveys or contests. Participation in these surveys or contests is completely voluntary and the user therefore has a choice whether or not to disclose any information requested. Information requested may include contact information (such as name and delivery address), and demographic information (such as postcode, age level). Contact information will be used to notify the winners and award prizes. Survey information will be used for purposes of monitoring or improving the functionality of the site.

Mail-A-Friend

If a user elects to use our referral service for informing a friend about our site, we ask them for the friend’s name and email address. Mondaq stores this information and may contact the friend to invite them to register with Mondaq, but they will not be contacted more than once. The friend may contact Mondaq to request the removal of this information from our database.

Security

This website takes every reasonable precaution to protect our users’ information. When users submit sensitive information via the website, your information is protected using firewalls and other security technology. If you have any questions about the security at our website, you can send an email to webmaster@mondaq.com.

Correcting/Updating Personal Information

If a user’s personally identifiable information changes (such as postcode), or if a user no longer desires our service, we will endeavour to provide a way to correct, update or remove that user’s personal data provided to us. This can usually be done at the “Your Profile” page or by sending an email to EditorialAdvisor@mondaq.com.

Notification of Changes

If we decide to change our Terms & Conditions or Privacy Policy, we will post those changes on our site so our users are always aware of what information we collect, how we use it, and under what circumstances, if any, we disclose it. If at any point we decide to use personally identifiable information in a manner different from that stated at the time it was collected, we will notify users by way of an email. Users will have a choice as to whether or not we use their information in this different manner. We will use information in accordance with the privacy policy under which the information was collected.

How to contact Mondaq

You can contact us with comments or queries at enquiries@mondaq.com.

If for some reason you believe Mondaq Ltd. has not adhered to these principles, please notify us by e-mail at problems@mondaq.com and we will use commercially reasonable efforts to determine and correct the problem promptly.