United States: The 21st Century Cures Medical Software Provisions: Additional Clarity For Digital Health, But Also More Questions

Key Points

  • Although the Cures medical software provisions largely align with FDA's current policies, certain of the Cures exemptions may be broader than those under current agency policy.
  • Many clinical decision support functions remain vulnerable for FDA regulation as medical devices.
  • FDA retains several avenues for applying medical device requirements to exempted medical software functions.

On December 13, the President signed into law the 21st Century Cures Act ("Cures"), which reforms many aspects of Food and Drug Administration's (FDA) oversight of medical products and authorizes funding to support the Cancer Moonshot, the Precision Medicine Initiative, efforts to combat opioid addiction, and initiatives to improve mental health. It is a major accomplishment to pass such wide-ranging FDA legislation outside the five-year cycle of user fee reauthorizations.1  Section 3060 of Cures, "Clarifying Medical Software Regulation," was one of the numerous FDA-related provisions relating to medical device regulation, and it is the focus of this alert. This provision identifies software functions that will not be considered medical devices for purposes of the Federal Food, Drug, and Cosmetic Act (FDCA), and specifies situations in which FDA may nevertheless exercise authority over these types of software. 

Section 3060 affirms much of FDA's current approach to digital health, as articulated in FDA guidances and applied by the agency in the context of individual product submissions, presubmission meetings and informal inquiries.2 Nevertheless, Section 3060 appears to depart from FDA's current policy in a number of significant respects. In particular:

  • Certain software functions that seemingly were medical devices under the FDCA, or that were potentially devices based on FDA guidances, appear to fall outside of Section 3060; examples include certain health and wellness functions and certain data transfer and monitoring functions. 
  • At the same time, Section 3060 appears not to exempt other software functions that stakeholders might have expected would be exempt from regulation as a medical device; in particular, certain clinical decision support (CDS) functions appear not to be exempted in Cures, although FDA could nevertheless determine that some of these functions either are not devices under the FDCA or should be subjected to enforcement discretion.

More broadly, it remains to be seen whether the detailed distinctions in Section 3060 will translate into clear and predictable lines of regulatory oversight, given the growing diversity of digital health solutions. 

Background

The discussions that ultimately resulted in the enactment of Cures began approximately three years ago, and FDA regulation of digital health software was a key early focus for stakeholders. The SOFTWARE Act was introduced in the House in October 2013,3 and the MEDTECH Act was introduced in the Senate in April 2015.4 These followed the inclusion in the Food and Drug Administration Safety and Innovation Act of 2012 (FDASIA) of a requirement for the issuance of a federal framework for oversight of health IT. The common theme among these efforts was a desire to provide greater clarity and certainty to developers of digital health solutions with regard to FDA regulatory requirements and to avoid unnecessary regulation of lower-risk, health-related software.

Between the initial introduction of the SOFTWARE Act and the MEDTECH Act, and last week's enactment of Cures, FDA released or updated several foundational policies addressing core aspects of digital health products. In April 2014, FDA, along with the Federal Communications Commission and the Office of the National Coordinator for Health Information Technology (ONC), finalized the FDASIA Health IT Report.5 FDA issued its final guidance on mobile medical applications in September 2013, and then updated it in February of 2015.6 That month, FDA also issued guidance announcing a policy of enforcement discretion towards medical device data systems (MDDS), medical image storage devices, and medical image communications devices.7 Finally, in 2016, FDA issued final guidance addressing general wellness applications.8 Section 3060 of Cures, "Clarifying Medical Software Regulation," addresses each of the specific topics of the aforementioned FDA guidances—mobile apps, general wellness functions, and MDDS—but also addresses electronic health records CDS. CDS is probably the most significant aspect of digital health still awaiting guidance or other formal policy clarification from the agency. 

Section 3060 amends the FDCA by adding a new subsection to Section 520 that provides for five categories of software to which the statutory definition of a device in Section 201(h) does not apply. Under Section 201(h), a device is defined as: 

an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including any component, part, or accessory, which is—

(1) recognized in the official National Formulary, or the United States Pharmacopeia, or any supplement to them,

(2) intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals, or

(3) intended to affect the structure or any function of the body of man or other animals, and

which does not achieve its primary intended purposes through chemical action within or on the body of man or other animals and which is not dependent upon being metabolized for the achievement of its primary intended purposes.9

As a result, functions that fall within one or more of those five categories would not be a medical device subject to FDA oversight. A product with multiple functions would potentially be subject to categorization as a device based on its other, nonexempt function(s).10

Section 3060 also provides other general standards and clarifications for FDA's regulation of such software, including a reservation of authority for FDA and a process for FDA to "claw back" certain software functions into the device definition. Each of the five software exemptions from the device definition is analyzed below, as are the treatment of multifunction products, the "claw back" provision and the reservation of FDA authority. 

Analysis of Exempt Software Functions

Administrative Software

The first exemption is for software functions intended "for administrative support of a health care facility . . . ," such as billing, claims, and scheduling. This exemption appears to be consistent with FDA's current approach, as expressed in the Draft Health IT Framework and in the Mobile Medical Apps Guidance.11 Moreover, the description of this category is generally understood to fall outside of the existing definition of device in Section 201(h).

Software to Support a "Healthy Lifestyle"

The second exemption addresses software for "maintaining or encouraging a healthy lifestyle." According to the exemption, software intended to assist with "maintaining or encouraging a healthy lifestyle" is not a device, so long as it "is unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition." FDA's General Wellness Guidance ("Guidance") describes products that will not be subject to device regulation as those having an intended use for "maintaining or encouraging a general state of health or a health activity," or "that relates the role of healthy lifestyle with helping to reduce the risk or impact of certain chronic diseases or conditions and where it is well understood and accepted that healthy lifestyle choices may play an important role in health outcomes for the disease or condition." By and large, this exemption appears to track FDA's existing policy. Moreover, the caveat in the exemption—that the function may not be related to diagnosis, cure, mitigation, prevention or treatment—aligns with the applicable criterion for a device under the existing statutory definition in Section 201(h). In at least two respects, however, the "healthy lifestyle" exemption in Section 3060 potentially excludes software products that would otherwise be subject to regulation under the Guidance and the FDCA. 

First, the Guidance applies only to general wellness products that are "low risk." Thus, under the Guidance, a general wellness product might still be subject to device regulation if, despite being intended for general wellness, the product is invasive, implanted, or involves "an intervention or technology that may pose a risk to the safety of users . . . if specific regulatory controls are not applied ...."12 The Cures provision does not include the low-risk caveat. It is unclear, however, whether in practice any software intended only for maintaining a healthy lifestyle would present more than a low risk.13 (Furthermore, as discussed below, FDA does have authority under Section 3060 to regulate exempted functions if they present the level of risks associated with Class III devices). 

Second, software could be developed that is intended for maintaining or encouraging a healthy lifestyle, and is unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition, but that is "intended to affect the structure or any function of the body." A structure/function product that does not achieve its primary intended purposes through chemical action is a device under section 201(h). Although it may be difficult to identify an example at this time, "structure/function" software for general wellness could conceivably fall within Section 3060, whether or not it would be exempted under the Guidance. The Guidance indicates that certain "Claims that address a specific body structure or function" are subject to enforcement discretion, while claims relating to restoring a structure or function are not. It is not clear whether the Guidance's reference to "addressing" structure/function is intended to be synonymous with "affect[ing]" structure/function (other than by restoring structure or function), but, in any event, Section 3060 seemingly extends to any structure/function claim relating to a healthy lifestyle that is unrelated to the diagnosis, cure, prevention, mitigation or treatment of disease.   

The more immediate and definitive effect of this statutory exemption is to confirm that many functions falling within the Guidance are not devices, as opposed to being subject to enforcement discretion. In the Guidance, FDA explained that it "does not intend to examine low risk general wellness products to determine whether they are devices within the meaning of the [FDCA] or if they are devices, whether they comply with the premarket and post-market regulatory requirements for devices ...."14 In other words, FDA clarified that its policy was not to subject qualifying wellness products to device requirements, but it did not opine as to whether these products were not devices, or were devices but were being granted enforcement discretion. Cures answers that question: many, if not most, of these wellness functions are not devices—so long as their intended use is within the parameters of the exemption (and subject to the "claw back" and reserve provisions analyzed below).

Electronic Patient Records

The Cures software provision also exempts certain electronic patient records. The provision includes three criteria. The criteria appear to exempt certain functions generally considered to be devices up to now, but they also leave many types of patient record software subject to device regulation (i.e., they might or might not constitute devices based on the pre-existing Section 201(h) definition).15 Functions intended "to serve as electronic patient records, including patient-provided information, to the extent that such records are intended to transfer, store, convert formats or display the equivalent of a paper medical chart" are not devices if three conditions are met:

  1. "such records were created, stored, transferred, or reviewed by health care professionals, or by individuals working under supervision of such professionals;"
  2. "such records are part of health information technology that is certified" by the ONC; and
  3. "such function is not intended to interpret or analyze patient records, including medical image data, for the purpose of the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition."

Despite some potential ambiguity, the various capabilities described in the lead-in of the exemption all appear intended to relate to "the equivalent of a paper medical chart."  In other words, a qualifying function may be intended to transfer, store, convert formats of or display information, but, in each case, the function must be performed on "the equivalent of a paper medical chart." The provision could be read to include functions that "transfer, store, [or] convert formats" more generally, or "display the equivalent of a paper medical chart."  In other words, the paper medical chart reference could be interpreted as relating to only "displaying," which would potentially allow for the transfer, storage or conversion of medical device data. That does not appear to be the intent, however, given the existence of a separate exemption that relates to MDDS and indicates that the electronic patient record exemption applies solely to digitizing paper medical charts.

MDDS

The penultimate exemption appears designed to track the device classification known as MDDS. MDDS electronically transfer, store, convert from one format to another or display medical device data. After classifying MDDS in 2011,16 FDA ultimately finalized a policy of enforcement discretion toward MDDS in 2015.

In keeping with FDA's MDDS definition, the Cures exemption covers software "for transferring, storing, converting formats, or displaying clinical laboratory test or other device data . . . unless such function is intended to interpret or analyze" such data. Much like the exemption for software supporting a healthy lifestyle, this exemption has the effect of making MDDS functionality, which, up to now, has been a medical device but granted enforcement discretion, not a device at all. Moreover, the exemption appears to be broader than FDA's MDDS definition, meaning that certain functions relating to device data transfer, storage and conversion that are currently subject to active regulation (i.e., they do not fall within the scope of MDDS enforcement discretion) would no longer be devices either. 

In particular, FDA precludes an MDDS from being used for "active patient monitoring."17 Whether the Cures exemption would include active patient monitoring is unclear, because each of the exempted capabilities themselves could be used in the context of active patient monitoring, or not. The issue of "real-time" or "active" patient monitoring has been particularly challenging in the aftermath of FDA's MDDS classification and subsequent exercise of enforcement discretion. FDA has cleared numerous types of monitoring software, but other monitoring software is marketed without FDA clearance—sometimes specifically for active monitoring. FDA has concerns about software that will be relied upon for monitoring patients with acute conditions and for whom the timely and accurate transmission of data may be critical to their well-being and to ensuring appropriate and timely treatment. If Section 3060 is interpreted to exempt MDDS-like functionality, but is intended to support "active" monitoring of the type that FDA believes should be subject to regulatory oversight (including premarket review), FDA would then need to invoke the "claw back" process in the legislation or its "reserve" authority, both of which are analyzed below.

CDS

The final exemption is designed to address some aspects of what is commonly captured under the catch-all phrase "clinical decision support". It is probably not a coincidence that, just as this has been a complicated category for FDA to address, the language of this exemption is the most complex of the five. Under the exemption, a software function is not a device if (1) it is not intended for certain uses, and (2) it is intended for each of three uses (all three must be met).

First, a function potentially qualifies for this CDS exemption, unless it "is intended to acquire, process, or analyze a medical image or a signal from an in vitro diagnostic device or a pattern or signal from a signal acquisition system . . . ." Although a signal acquisition system is not defined, in this context, it apparently refers to a wearable sensor or other instrument that obtains data from the human body. Thus, the CDS exemption might not extend to software that analyzes data derived directly from the body via an in vitro diagnostic (IVD), sensor or other instrument; more generally, this could suggest that the exemption does not apply to software that analyzes data derived directly from a medical device. Furthermore, as will become apparent from the discussion of the three mandatory criteria immediately below, the exemption appears to contemplate "back-end" analytics performed on data or other information after the data has been incorporated into a patient record or into a provider's databases. Software that analyzes data directly from an IVD or sensor would potentially remain subject to device regulation, to the extent that such software met the definition in Section 201(h) and FDA opted to exercise active regulation of it.

The three mandatory purposes that a qualifying function must have are also relatively restrictive. To qualify, an exempt CDS must have the purpose of: 

(1) "displaying, analyzing, or printing medical information about a patient or other medical information ...;"

(2) "supporting or providing recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition;" and

(3) "enabling such health care professional to independently review the basis for such recommendations that such software presents so that it is not the intent that such health care professional rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient."

The third criterion is particularly notable, because it epitomizes the challenge in attempting to differentiate between a clinician making a treatment decision that resides sufficiently within the practice of medicine and software performing relatively definitive analyses to constitute "use in the diagnosis or cure, mitigation, treatment, or prevention of disease . . . ." CDS tools currently in use or in development provide varying levels of transparency into the tool's algorithms, weights and inputs. Their outputs are couched in different levels of confidence and with a range of disclaimers about how the outputs are to be used.

At the risk of parsing the language too finely, this provision suggests that the characterization of the output of a CDS tool is less significant than the transparency of the tool itself and its intended use within a particular treatment environment. First, the provision refers to "recommendations" multiple times; this implies that a nondevice CDS tool may indeed characterize its output as a "recommendation," rather than resort to a less definitive term, such as a "suggestion" or "consideration." On the other hand, the tool must "enabl[e] such health care professional to independently review the basis" for the recommendation. With the ever-increasing complexity of clinical software algorithms and the growing trove of data inputs, it is unclear what degree of expertise and training will be required of a clinician, and what amount of transparency will be necessary with respect to a CDS tool, to "enabl[e]" the clinician to "independently" review the output's rationale. An even more subjective element of the provision is that the features enabling clinician independent review need to be sufficiently robust so "that it is not the intent that" the clinician "rely primarily" on the recommendations to make a diagnosis or treatment decision.

Analysis of Generally Applicable Provisions

Three other aspects of Section 3060 that are generally applicable merit separate discussion, because all three will fundamentally impact the scope of the five specific exemptions and how they are applied in practice. 

Multi-Function Products

For products with multiple functions, including one software function exempted under the provision and one function that is not exempted under the provision that meets the definition of a device, Section 3060 provides that FDA "shall not regulate the software function" that is exempt, but, when assessing the safety and effectiveness of the product's non-exempt device function, FDA "may assess the impact that the software function or functions . . . have on such device function or functions."18 This is consistent with FDA's general approach, since FDA would consider the impact that any accessory or component intended to be used with the device would have on the proper and safe functioning of such device. 

What this provision does not address is how to assess the contours or boundaries of a "product" that is not a physical device. A digital platform or system may run any number of applications, some of which may be used as a medical device. However one chooses to define the "product" for this purpose, the ongoing challenge for FDA and the regulated industry is to determine an appropriately dynamic method of assessing potential impact on the proper functioning of medical device software, and to identify and address threats posed by other applications on a shared system, which might not be anticipated by, or under the control of, the maker of the medical device software. To ensure safety and effectiveness in this context, there is a need for a functional and practical approach that might not be conducive to a bright line standard.19

FDA "Claw Back" and Reservation of Authority

The Cures provision grants FDA the discretion to "claw back" into the device definition certain of the exempted software functions if the agency finds that "use of such software function would be reasonably likely to have serious adverse health consequences," after issuance of notification with rationale and a proposed order, followed by a comment period and issuance of a final order. This authority applies only to functions exempted as electronic patient records, MDDS or CDS; it is not available for exempted administrative functions or "healthy lifestyle" functions. Notably, this claw back provision is premised on safety concerns—"serious adverse health consequences"—and not effectiveness concerns. Although the ineffectiveness of any product, including a software product, could have adverse health consequences, it may be difficult for FDA to make a case that ineffectiveness is reasonably likely to have "serious" adverse health consequences. More broadly, the process for exercising this authority is fairly cumbersome and might not allow for a timely agency response to particular concerns.

Section 3060 also clarifies that FDA maintains certain authorities, notwithstanding the exemptions provided. Perhaps most noteworthy among these provisions is the reservation of authority for FDA to "regulate software as a device ... if such software meets the criteria under section 513(a)(1)(C)." That is a reference to the FDCA criteria for classification of devices under Class III, subject to premarket approval. Conceivably, FDA could determine that an otherwise exempt software function falls under this reserve authority more readily than the agency could satisfy the substantive and procedural requirements of the "claw back" clause. For example, FDA could determine that a particular software function presents a "potential unreasonable risk of illness or injury"20 under Section 513(a)(1)(C), even if the agency is unable to demonstrate that the function is "reasonably likely to have serious adverse health consequences." 

Alternatively, if FDA had a concern that an exempt software function should be subject to regulation, under Section 513(a)(1)(C), FDA could determine that the function cannot be classified as a Class I device or a Class II device, because "insufficient information exists to determine that" application of general controls or application of special controls, respectively, would "provide reasonable assurance of safety and effectiveness of the device."21 Under the FDCA, a device that cannot provide a reasonable assurance of safety and effectiveness under one of those two circumstances falls within Class III. In other words, absent an examination of how general or special controls could provide a reasonable assurance of safety and effectiveness—through classification as a Class I or Class II device and compliance with the designated general and/or special controls—"insufficient information" would exist for a function to fall outside of Class III. Conceivably, FDA could take the position that the sponsor of such a product would need to demonstrate that general or special controls would provide reasonable assurance of safety and effectiveness in order to avoid regulation as a device. Although this would be a potentially aggressive reading of Section 3060, it may be a more plausible way for FDA to address a safety or efficacy concern than invoking the "claw back" provision.

Footnotes

1 It is not uncommon for Congress to pass FDA-related legislation. Outside of the user fee reauthorization packages, however, these "off-cycle" laws have generally focused on discrete issues, frequently motivated by particular public health concerns. See, e.g., The Drug Quality and Security Act of 2013, Pub. L. No. 113-54 (passed in response to a meningitis outbreak associated with medications prepared by a compounding pharmacy). This year, Congress will take up reauthorization of most of the prescription drug, medical device, generic drug and biosimilar user fee programs, which otherwise expire on September 30, 2017.

2 For example, FDA maintains an email address for informal inquiries concerning the classification of mobile medical applications. 

3 H.R. 3303, introduced Oct. 22, 2013.

4 S. 1101, introduced Apr. 27, 2015.

5 FDASIA Health IT Report: Proposed Strategy and Recommendations for a Risk-Based Framework (Apr. 2014).

6 FDA, Mobile Medical Applications: Guidance for Industry and FDA Staff (Feb. 9, 2015).

7 FDA, Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices: Guidance for Industry and FDA Staff (Feb. 9, 2015).

8 FDA, General Wellness: Policy for Low Risk Devices: Guidance for Industry and FDA Staff (July 29, 2016).

9 FDCA § 201(h).

10 See Cures Section 3060(a), adding Section 520(o)(2) to the FDCA. Note that Section 3060 also clarifies that accessories are to be classified based on their own intended use, notwithstanding the classification of any devices with which the accessory is intended for use. See Cures Section 3060(c), adding Section 513(b)(9) to the FDCA.

11 Mobile Medical Apps Guidance at 21 providing as an example of a mobile app that is not a medical device, "mobile apps that automate general office operations in a health care setting and are not intended for use in the diagnosis of disease or other conditions....).

12 General Wellness Guidance at 5.

13 The General Wellness Guidance is not restricted to software, and the prototypical examples of a general wellness product that are not low risk are likely to be physical sensors or other wearables that physically interact with the body, thereby posing potential risk. Such a sensor might be regulated as a device, even if the software that uses the sensor's data to support general wellness is not considered a device. Unlike the Guidance, the Cures exemption is specific to software. As a practical matter, it is unclear whether the maker of a wellness product comprising some type of physical sensor and software functionality would receive any additional advantage from Section 3060: the software function could take advantage of the general wellness exemption, but the physical component likely could not and thus could still be assessed by FDA under the General Wellness Guidance for a determination of whether it is low-risk.

14 General Wellness Guidance at 2 (footnote omitted).

15 Nevertheless, many electronic patient record functions would not appear to meet the definition of Section 201(h), and FDA has not indicated that it believes electronic patient record functions constitute medical devices.

16 76 Fed. Reg. 8637 (Feb. 15, 2011).

17 See 21 C.F.R. § 880.6310(a)(2) ("This identification does not include devices intended to be used in connection with active patient monitoring.").

18 Cures § 3060(a).

19 This source of confusion might or might not be compounded by the introduction in Section 3060 of the concept of a "function." Section 3060 exempts certain "functions" that are "intended" for specified uses. The FDCA's device definition in Section 201(h) refers to an "instrument ... or other similar or related article" that is "intended for use" as specified. The word "function" was probably used in Cures to avoid adopting one of the words used in the device definition (such as instrument, contrivance, or article), which might have implied that the exempt functions indeed met the definition of device notwithstanding the Cures provision. Ultimately, the introduction of the new concept of a "function" risks blurring the distinction between product claims as the primary measure of intended use, and functionality of the product, which is generally not the proper measure of intended use.

20 FDCA § 513(a)(1)(C)(ii)(II).

21 Id. § 513(a)(1)(C)(i)(I) & (II).

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
 
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
Position
Mondaq Topics -- Select your Interests
 Accounting
 Anti-trust
 Commercial
 Compliance
 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.