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
Similar Articles
Relevancy Powered by MondaqAI
Finnegan, Henderson, Farabow, Garrett & Dunner, LLP
 
In association with
Related Topics
 
Similar Articles
Relevancy Powered by MondaqAI
Finnegan, Henderson, Farabow, Garrett & Dunner, LLP
Related Articles
 
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
Registration (you must scroll down to set your data preferences)

Mondaq Ltd requires you to register and provide information that personally identifies you, including your content preferences, for three primary purposes (full details of Mondaq’s use of your personal data can be found in our Privacy and Cookies Notice):

  • To allow you to personalize the Mondaq websites you are visiting to show content ("Content") relevant to your interests.
  • To enable features such as password reminder, news alerts, email a colleague, and linking from Mondaq (and its affiliate sites) to your website.
  • To produce demographic feedback for our content providers ("Contributors") who contribute Content for free for your use.

Mondaq hopes that our registered users will support us in maintaining our free to view business model by consenting to our use of your personal data as described below.

Mondaq has a "free to view" business model. Our services are paid for by Contributors in exchange for Mondaq providing them with access to information about who accesses their content. Once personal data is transferred to our Contributors they become a data controller of this personal data. They use it to measure the response that their articles are receiving, as a form of market research. They may also use it to provide Mondaq users with information about their products and services.

Details of each Contributor to which your personal data will be transferred is clearly stated within the Content that you access. For full details of how this Contributor will use your personal data, you should review the Contributor’s own Privacy Notice.

Please indicate your preference below:

Yes, I am happy to support Mondaq in maintaining its free to view business model by agreeing to allow Mondaq to share my personal data with Contributors whose Content I access
No, I do not want Mondaq to share my personal data with Contributors

Also please let us know whether you are happy to receive communications promoting products and services offered by Mondaq:

Yes, I am happy to received promotional communications from Mondaq
No, please do not send me promotional communications from Mondaq
Terms & Conditions

Mondaq.com (the Website) is owned and managed by Mondaq Ltd (Mondaq). Mondaq grants you a non-exclusive, revocable licence to access the Website and associated services, such as the Mondaq News Alerts (Services), subject to and in consideration of your compliance with the following terms and conditions of use (Terms). Your use of the Website and/or Services constitutes your agreement to the Terms. Mondaq may terminate your use of the Website and Services if you are in breach of these Terms or if Mondaq decides to terminate the licence granted hereunder for any reason whatsoever.

Use of www.mondaq.com

To Use Mondaq.com you must be: eighteen (18) years old or over; legally capable of entering into binding contracts; and not in any way prohibited by the applicable law to enter into these Terms in the jurisdiction which you are currently located.

You may use the Website as an unregistered user, however, you are required to register as a user if you wish to read the full text of the Content or to receive the Services.

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 or with the prior written consent of Mondaq. You may not use electronic or other means to extract details or information from the Content. Nor shall you extract information about users or Contributors in order to offer them any services or products.

In your use of the Website and/or Services you shall: comply with all applicable laws, regulations, directives and legislations which apply to your Use of the Website and/or Services in whatever country you are physically located including without limitation any and all consumer law, export control laws and regulations; provide to us true, correct and accurate information and promptly inform us in the event that any information that you have provided to us changes or becomes inaccurate; notify Mondaq immediately of any circumstances where you have reason to believe that any Intellectual Property Rights or any other rights of any third party may have been infringed; co-operate with reasonable security or other checks or requests for information made by Mondaq from time to time; and at all times be fully liable for the breach of any of these Terms by a third party using your login details to access the Website and/or Services

however, you shall not: do anything likely to impair, interfere with or damage or cause harm or distress to any persons, or the network; do anything that will infringe any Intellectual Property Rights or other rights of Mondaq or any third party; or use the Website, Services and/or Content otherwise than in accordance with these Terms; use any trade marks or service marks of Mondaq or the Contributors, or do anything which may be seen to take unfair advantage of the reputation and goodwill of Mondaq or the Contributors, or the Website, Services and/or Content.

Mondaq reserves the right, in its sole discretion, to take any action that it deems necessary and appropriate in the event it considers that there is a breach or threatened breach of the Terms.

Mondaq’s Rights and Obligations

Unless otherwise expressly set out to the contrary, nothing in these Terms shall serve to transfer from Mondaq to you, any Intellectual Property Rights owned by and/or licensed to Mondaq and all rights, title and interest in and to such Intellectual Property Rights will remain exclusively with Mondaq and/or its licensors.

Mondaq shall use its reasonable endeavours to make the Website and Services available to you at all times, but we cannot guarantee an uninterrupted and fault free service.

Mondaq reserves the right to make changes to the services and/or the Website or part thereof, from time to time, and we may add, remove, modify and/or vary any elements of features and functionalities of the Website or the services.

Mondaq also reserves the right from time to time to monitor your Use of the Website and/or services.

Disclaimer

The Content is general information only. It is not intended to constitute legal advice or seek to be the complete and comprehensive statement of the law, nor is it intended to address your specific requirements or provide advice on which reliance should be placed. Mondaq and/or its Contributors and other suppliers make no representations about the suitability of the information contained in the Content for any purpose. All Content provided "as is" without warranty of any kind. Mondaq and/or its Contributors and other suppliers hereby exclude and disclaim all representations, warranties or guarantees with regard to the Content, including all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement. To the maximum extent permitted by law, Mondaq expressly excludes all representations, warranties, obligations, and liabilities arising out of or in connection with all Content. In no event shall Mondaq 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 of the Content or performance of Mondaq’s Services.

General

Mondaq may alter or amend these Terms by amending them on the Website. By continuing to Use the Services and/or the Website after such amendment, you will be deemed to have accepted any amendment to these Terms.

These Terms shall be governed by and construed in accordance with the laws of England and Wales and you irrevocably submit to the exclusive jurisdiction of the courts of England and Wales to settle any dispute which may arise out of or in connection with these Terms. If you live outside the United Kingdom, English law shall apply only to the extent that English law shall not deprive you of any legal protection accorded in accordance with the law of the place where you are habitually resident ("Local Law"). In the event English law deprives you of any legal protection which is accorded to you under Local Law, then these terms shall be governed by Local Law and any dispute or claim arising out of or in connection with these Terms shall be subject to the non-exclusive jurisdiction of the courts where you are habitually resident.

You may print and keep a copy of these Terms, which form the entire agreement between you and Mondaq and supersede any other communications or advertising in respect of the Service and/or the Website.

No delay in exercising or non-exercise by you and/or Mondaq of any of its rights under or in connection with these Terms shall operate as a waiver or release of each of your or Mondaq’s right. Rather, any such waiver or release must be specifically granted in writing signed by the party granting it.

If any part of these Terms is held unenforceable, that part shall be enforced to the maximum extent permissible so as to give effect to the intent of the parties, and the Terms shall continue in full force and effect.

Mondaq shall not incur any liability to you on account of any loss or damage resulting from any delay or failure to perform all or any part of these Terms if such delay or failure is caused, in whole or in part, by events, occurrences, or causes beyond the control of Mondaq. Such events, occurrences or causes will include, without limitation, acts of God, strikes, lockouts, server and network failure, riots, acts of war, earthquakes, fire and explosions.

By clicking Register you state you have read and agree to our Terms and Conditions