Healthcare apps: part 1 The arrival of ‘mHealth’ has created a market with huge innovation potential. In the first of a two-part article, Mark Heaney, Michael Short and Tyler Beas explain how to avoid becoming over-regulated and under-protected “All mHealth services utilise software or mobile applications that either control hardware or process data held within the app.” 46 Intellectual Property Magazine April 2015 www.intellectualpropertymagazine.com Healthcare has gone mobile. The combination of widespread wifi and 4G internet connectivity, ubiquitous mobile phone and tablet usage, wearable sensors and an increased desire for personalised medical care, means that a relatively new industry has been flourishing: ‘mHealth’. This is due largely to the advances being made in health care mobile apps that are available to patients as well as clinicians. As developers find ways to make technology mobile where it was once only accessible from within a hospital, there are two major factors to consider: intellectual property protection and healthcare regulation. These issues share one key characteristic: they can progress quickly from being cheap and simple to being costly and complex. This article discusses how to avoid falling into the trap of being ‘over-regulated and under-protected’ in the UK, EU and US. mHealth software mHealth, includes many new technologies with medical purposes which can be used outside of the ‘traditional’ setting of a doctor’s surgery or hospital by virtue of using mobile devices. This could include an encyclopedia of medical know-how to allow access on the move or technology for ‘telesurgery’ where surgical procedures can be conducted from a remote location using robots and virtual reality technology. All mHealth services utilise software or mobile applications that either control hardware or process data held within the app. Within this app is the developer’s inventive idea, expressed by way of source code and brought to life by the screen of a mobile device or the functionality of a hardware accessory. Regulating mHealth software The Medicines and Healthcare Products Regulatory Agency (“MHRA”) governs the placement of medical devices in the UK market in accordance with the Medical Device Directive 93/42/EEC (“the Directive”) Under clause 2(a) of the Directive, a medical device includes software that is intended for the: • “Diagnosis, prevention, monitoring, treatment or alleviation of disease; • Diagnosis, monitoring, treatment, alleviation of or compensation for an injury or handicap; • Investigation, replacement or modification of the anatomy or of a physiological process; or • Control of conception.” As a result of EU Directive 2007/47/EC, and guidance from MHRA in 2014,1 software placed on the market on its own can be a medical device subject to the same levels of conformity as mainstream medical devices such as thermometers, drug delivery systems and prostheses. The Directive defines a number of classes into which a device, and hence software, may be categorised with each class requiring a different level of regulation. Class III is the most highly regulated and covers items such as defibrillators and pacemakers. Class IIa covers medium risk devices such as therapeutic and diagnostic tools and Class IIb is reserved for such devices that have potentially hazardous consequences if they fail. All other devices fall into Class I. Class I device regulation is minimal and provides steps such as selfdeclaration by the manufacturer, placing a CE (declaration of conformity) mark on the device and registration with the relevant national authority. Classes II and III require prior approval from a relevant national body after strict quality assurance testing and auditing. The majority of health software will either be unregulated or fall into Class I or Class II. For example, software that provides general medical information (first aid) or administrative services such as appointment mHealth www.intellectualpropertymagazine.com April 2015 Intellectual Property Magazine 47 bookings is unlikely to be regulated. Software used to measure temperature, heart rate, blood pressure or blood sugars is likely to be Class I devices in the form of an accessory to a physical device (the sensor). Software that allows a clinician to review patient data gathered over a period of time and then processes the data into a presentation may be a Class IIa device whereas the same software for use monitoring an intensive care patient may fall into Class IIb. In the US, the Food and Drug Administration (“FDA”) is the relevant regulator and its treatment of software is similar to that of the MHRA. In February 2015,2 the FDA issued nonbinding recommendations detailing its approach to regulating mobile medical applications through interpreting the Federal Food, Drug and Cosmetic Act (“FDCA”). Under section 201(h) of the FDCA, a software application may be subject to regulation as a medical device where it is: • “Intended for use in the diagnosis or the cure, mitigation, treatment or prevention of disease or to affect the structure or any function of the body of man.”; and • “Intended to be used as an accessory to a regulated medical device or to transform a mobile platform into a regulated medical device” As in Europe, the US system caters for three classes of medical device. However, the FDA has discretion not to regulate software that does not “pose a risk to a patient’s safety if the mobile app were to not function as intended”. For example, the FDA recommendations explicitly state that the FDA may choose not to regulate software for collecting blood glucose levels whereas this would likely be covered by Class I in the EU. Regulatory requirements for Class I devices are largely similar to those in the EU (registration with the FDA, self-declaration that the Quality System Regulations have been met, labelling requirements and premarket notification to the FDA) with more stringent controls and premarket approvals for Class II and III devices. The timescales and costs for meeting regulatory requirements vary. Meeting the class I regulatory requirements in the UK could involve simply paying a small sum (currently £70) to be a registered manufacturer with the MHRA. A Class II filing in the US (a 510(k)) can cost in the order of $5,000. But more complicated software may require implementation of ISO standards, preparation of technical files for audit by a notified body and clinical trials. This may push the costs into the hundreds of thousands of pounds and delay entry to the market by months or even years. This added expense and burden is an important factor when considering how best to protect the value of such software through intellectual property. Where software is concerned, there are two primary intellectual property rights that can offer protection against unauthorised use or reproduction: patents and copyright. Protecting mHealth software through copyright The scope of copyright protection for software is summarised by the Agreement on Trade-Related Aspects of Intellectual Property Rights (“TRIPS”) to which both the US and the EU are signatories: Article 10(1) “Computer programs, whether in source or object code, shall be protected as literary works under the Berne Convention.” Article 9(2) “copyright protection shall extend to expressions and not to ideas, procedures, methods of operation or mathematical concepts as such.” The UK has replicated this position through the Copyright, Designs and Patents Act 1988, as amended in 1992 and 2003.3 In the US, the Copyright Act protects software as a literary work under 17 USC §102(a)(1). Similar to Article 9(2) of TRIPS, the Copyright Act contains a clear exception: 17 USC§102 (b) “In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.” Both the EU and US, therefore, provide copyright protection for software in its coded form where it exists as a set of instructions. Ideas, processes, concepts and methods are explicitly excluded. Furthermore, recent case law from the Court of Justice of the EU has further restricted what is protectable under copyright law. SAS v WPL (C-406/10) confirmed that the functionality, programming language and formatting of data files (such as application programming interfaces (APIs)) all fall outside of the scope of copyright protection. In the US, a lower level District Court in the case Oracle v Google4 had previously clarified that copyright law did not protect functions or methods, but this case was recently overturned by the middlelevel Federal Circuit Court of Appeals.5 The “structure, sequence and organisation” of an API is now regarded as something that can attract copyright protection, subject to a possible Supreme Court ruling. Despite its limitations, copyright protection has its benefits: it prevents literal copying of source and object code; it is available for all types of software irrespective of quality or function; it lasts for the lifetime of the author plus a minimum of 70 years after death; it is inexpensive to register the right in the US (as little as $35) and in the UK it vests in the owner automatically, for no cost, and without any required registration process. Developers must note that the inclusion of open-source code compromises the ability to protect new code through copyright. Copyright protection has its place in an intellectual property strategy for software but a high-value idea, in particular one where the value can be “seen” through the user interfaces, programming language or data flows, would be inadequately protected by this alone. Protecting mHealth software through patents Patent protection grants innovators a monopoly for the exploitation of a new technical invention. Once granted, it allows the holder to prevent third parties from dealing in the patented invention. However, protection is not available for something that is simply an obvious or trivial advancement. The protection lasts for 20 years which is usually more than sufficient for a software product life cycle. Registration is a time-consuming and expensive process (as is running an infringement action once a patent is granted) but the protection obtained can be considerable provided the holder is able and willing to exercise their rights in court. Article 52 of the European Patent Convention contains an important provision regarding what is a patentable invention: (1) “European patents shall be granted for any inventions, in all fields of technology, provided that they are new, involve an inventive step and are susceptible of industrial application; (2) “The following in particular shall not be regarded as inventions within the meaning of paragraph 1: ... (c) schemes, rules and methods for performing mental acts, playing games or doing business and programs for computers; ... mHealth 48 Intellectual Property Magazine April 2015 www.intellectualpropertymagazine.com (3) “Paragraph 2 shall exclude the patentability of the subjectmatter or activities referred to therein only to the extent to which a European patent application or European patent relates to such subject-matter or activities as such.” In short, article 52 starts by creating a wide scope of inventions (“all fields of technology”), then narrows it to exclude “programs for computers” then expands it again by only excluding “programs for computers as such”. The “as such” restriction is ambiguous and has led to many court cases in the UK and EU regarding what ‘extra’ a computer program needs to have to become a patentable invention. According to the EPO, the “as such” restriction means that if an invention has technical character it is not excluded from patentability just because it is implemented by a computer program. This can be shown by the program achieving a technical effect or having a technical application beyond the ordinary running of the software, such as controlling or interacting with external hardware. The UK case of Symbian6 moved the UK approach, set out in Aerotel, 7 of requiring an effect outside of the program itself towards that of the EPO and suggested that improved performance of a computer resulting from an inventive program was sufficient even though the novel effect only took place within the computer itself. As a result, the UK and EPO approaches today should reach the same result in the majority of scenarios, with the EPO approach slightly favouring the patentee. In the US, 35 USC §101 governs patentability: “Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.” There are no specific exclusions relating to computer programs and the case of Diamond v Diehr, 450 US 175 (1981) confirmed that an invention “does not become non-statutory simply because it uses a mathematical formula, computer program, or digital computer”. However, “laws of nature, physical phenomena and abstract ideas” have been rejected as being patentable by the US Supreme Court8 and the recent cases of Bilksi9 and Alice10 have developed a patentability test requiring that there is an inventive concept that ensures the invention amounts to significantly more than an abstract idea. Under Alice, implementing an idea through a computer (through generic code and standard computer platforms) will not, on its own, satisfy this test. Therefore, although software patents are obtainable in the US, it is likely that the software must be shown to be solving a technological problem or improving a technological process. Avoiding the trap The relationship between intellectual property protection and health software regulation becomes vital as software becomes more complex. Software with simple functionality contained only within the program itself is less likely to be regulated but is also less likely to be eligible for patent protection. Copyright protection preventing literal copying of the software may be the only option for a developer, but it may be sufficient if it is of low value. In contrast, software that interacts with hardware to achieve a diagnostic result is likely to undergo strict regulatory measures, but its value is more likely to be able to be protected with patents. The risk lies in software that encounters the regulatory barrier prior to achieving the “threshold” for patent protection (eg, software that has a diagnostic purpose but cannot be said to achieve a technical effect). For example, software that simply processes data for more timely and accurate diagnosis or treatment of a patient may not reach the patent threshold if it simply aggregates data that the clinician would have reviewed anyway. In essence, unless the clinician had a ‘technical problem’ for which the software provided a ‘technical solution’, the software may be regulated but protected only by copyright. This may result in increased cost, delayed commercialisation and inadequate protection (particularly if the user interfaces, programming language and data flows are important factors). Once the software appears on the marketplace there is little protection available to stop non-literal copying of its functionality. Competitors can then generate competing software that is likely to be able to take advantage of the existing regulatory compliance so as quickly to achieve a cheaper solution that fulfils the requirements of regulatory compliance. Therefore, developers must assess carefully the functionality of their software throughout the development phase. A sensible development strategy involves ensuring that if software is to have a diagnostic or therapeutic purpose, it is developed in such a way as to have (or, at the very least, can be argued to have) a technical effect. This at least provides an opportunity for patent protection and may avoid software being over regulated yet under protected. Footnotes 1. MHRA: ‘Medical device stand-alone software including apps’, 8 August 2014. 2. Mobile Medical Applications: Guidance for Industry and Food and Drug Administration Staff, 9 February 2015. 3. Copyright (Computer Programs) Regulations 1992 and the Copyright and Related Rights Regulations 2003. 4. Oracle America, Inc v Google Inc, 872 F Supp 2d 974 (ND Cal 2012). 5. Oracle America, Inc v Google Inc, 750 F.3d 1339 (Fed Cir 2014). 6. Symbian Limited v Comptroller General of Patents  EWCA Civ 1066. 7. Aerotel v Telco; Macrossan’s Application  RPC 7. 8. Diamond v Chakrabarty, 447 US 303, 309 (1980). 9. 130 S.Ct. 3218 (2010). 10. 134 S. Ct. 2347 (2014). “The risk lies in software that encounters the regulatory barrier prior to achieving the ‘threshold’ for patent protection (eg, software that has a diagnostic purpose but cannot be said to achieve a technical effect).” mHealth Authors Mark Heaney (left) is a partner and Michael Short (middle) an associate in the intellectual property department of Baker Botts’ London office. Tyler Beas (right) is an associate in the IP team at Baker Botts’ Dallas office.