The mhealth Revolution: A Clash of Innovation & the Law. Intellectual Property Protection, Licensing, and Security for mhealth Applications

Transcription

1 The mhealth Revolution: A Clash of Innovation & the Law Intellectual Property Protection, Licensing, and Security for mhealth Applications By Kimberly Bullock Gatling The health care industry s mobile health ( mhealth ) revolution has been on a fast-paced trajectory in recent years. All the while, health care providers, patients, and software application developers have been left to ponder on questions regarding patent protection, licensing, and security for these latest innovations. The Food and Drug Administration s ( FDA ) recently issued guidance on Mobile Medical Applications 1 provided some long-awaited clarity on how it regulates mobile medical applications, including mobile phone applications; however, the FDA s guidance is appropriately void of guidance on protection and licensing of this rapidly-evolving technology. This article explores the current state of intellectual property protection for mhealth applications, as well as licensing considerations that should be important to any health care provider or end-user. This article will also highlight some security concerns with mhealth applications, particularly in the case where end-users are executing financial transactions via the mhealth application. I. mhealth Devices and Software as a Service mhealth devices and applications are used for the collection, storage, and transmission of patient medical information, and include mobile applications which, in essence, turn a smartphone into a medical device. These devices and applications do not target just the health care professional user: one count estimated that in 2013, there were 97,000 mhealth applications 1 Guidance for Industry and Food and Drug Administration Staff; Mobile Medical Applications, (September 25, 2013).

2 available across major application download services, with 59 percent of patients in emerging markets using mhealth applications and services. 2 Forecasters predict that the number of mhealth apps will continue to grow at a rate of 25 percent annually for the near future such that 500 million consumers and health care providers will use a mhealth app by The range of mhealth software applications currently in use runs the gamut from applications that allow patients to communicate and receive information from their providers, to applications that enable providers to monitor patients in real-time, to applications that enable end-users to track their own medical conditions separate from their providers. Additionally, these devices and applications are providing secure communication channels that enable health care providers to discuss patient treatment with other medical professionals. There is also the role that smart devices enabled with mhealth applications play in the retrieval of electronic medical records ( EMRs ). From a technical perspective, essentially all of the above-described mhealth software applications are delivered over the Internet (a/k/a the cloud ) to the respective smart devices. In simplest terms, this means that the software is stored on and runs from a remote server. This is commonly referred to as software as a service or SaaS because at least some portion of the software program is not stored on the end-user s device. For example, a health care provider may access a mhealth software application via the Internet from a desktop or laptop computer. Additionally, both the health care provider and the patient may access the software application from a mobile device, wherein the mobile device has downloaded an interface (commonly 2 McLoughlin, P. and Crespo, M. (2013). The Proliferation of Mobile Devices and Apps for Health Care: The Promises and Risks. Retrieved from (accessed March 15, 2014). 3 Jacob, S. (2014). Mobile Health Reaches Its Tipping Point. Retrieved from (accessed March 16, 2014). 2

3 referred to as the app ) that facilitates transmission of information to and from the software stored on the back-end server. In general, all of the data storage and processing is performed on the back-end server. II. Patent Protection for mhealth Applications As everyone now knows, health care is a very lucrative industry, and the mhealth revolution certainly seems to be setting its own trends. As one industry analyst noted, there are more industries involved in the development of wireless medical devices than there are for other medical devices. 4 This leaves many health care providers asking themselves: Can I develop an app for that? After reckoning with all the technical complexities of mhealth app development and server architecture (that any experienced software developer would understand), the mhealth app developer must also reckon with the infamous Health Information Portability and Accountability Act ( HIPAA ). HIPAA requires covered entities, such as hospitals and physicians, to comply with security and privacy regulations designed to protect patients protected health information ( PHI ). 5 PHI is defined as individually identifiable health information that is transmitted or maintained in electronic media or in any other form. 6 The HIPAA security standards establish the measures a covered entity must take to ensure the confidentiality, integrity, and availability of all electronic PHI created, received, maintained, or transmitted by the covered entity. 7 After sifting through software source code, server architecture, and HIPAA, any developer would naturally want to know how it can protect its investment and know-how in its 4 Nerac Analyst (February 2014). The Role of Patents and the Wireless Medical Device Market. Nerac Blogs, retrieved at (accessed March 20, 2014) C.F.R Id C.F.R , et seq. 3

4 unique mhealth application. It is ironic that the recent boom in development of mhealth applications coincides with a period of flux and uncertainty surrounding patentability of software applications and business methods under the United States Patent Act. 8 Software patent claims are often written in the form of method claims for instructing a processor to perform certain enumerated steps. In the landmark case of Bilski v. Kappos 9 pertaining to patent eligible subject-matter, the Supreme Court noted that Patent Act contemplates broad categories of patent-eligible subject matter: processes, machines, manufactures, and compositions of matter. The Court noted, however, that judicial exceptions to patent eligibility exist for laws of nature, physical phenomena, and abstract ideas. In life following Bilski, cases such as Alice Corp v CLS Bank 10 emerged that tested the bounds of Bilski, particularly relating to software and business method patents. The U.S. Supreme Court will hear oral arguments in the Alice Corp. case on March 31, 2014, and a decision is expected by the end of June 2014, with the fundamental question being whether software and business methods are patentable under 35 U.S.C The patent bar is particularly hopeful that the Court will provide a more detailed explanation of what is a nonpatent eligible abstract idea. This Supreme Court decision will provide critical guidance on the patentability of computer-implemented inventions, including software such as mhealth software applications. In the meantime, the U.S. Patent and Trademark Office is busy with prosecution of patent applications for mhealth devices and applications. Even after getting past the hurdle of whether a mhealth application is patent-eligible in light of Bilski and Alice Corp., the application must 8 35 U.S.C. 101 et seq U.S. (2010); 130 S.Ct (2010). 10 Alice Corp. v. CLS Bank, 768 F. Supp. 2d 221 (D.D.C. 2011); 717 F.3d 1269 (Fed. Cir. 2013). 4

5 still satisfy the other requirements for patentability for being new and nonobvious. As with all types of patent applications, mhealth software applications are closely examined to make sure the claimed technology has not been previously used, publicly disclosed, patented, or described in a printed publication. 11 The applications are further analyzed by the Patent Office to determine whether the claimed technology is more than an obvious combination of prior uses, publications, and/or patents. 12 Another matter worthy of nothing is that the United States recently moved from a firstto-invent patent system to a first-to file patent system. Therefore, any health care provider or developer should be vigilant about seeking patent protection for its innovative mhealth technology. III. Licensing mhealth Apps As noted above, most mhealth applications are technically SaaS applications. For those health care providers that are more interested in using mhealth apps than developing them, licensing becomes a key issue. Unlike traditional software licenses, when the software fully resides on the customer or licensee s computer or server, SaaS remains in the cloud and is typically accessed via a web browser or app (interface) that is downloaded onto the user s mobile device. Thus, rather than the user being concerned about integration of the software application with his local computer environment as with typical licensing, the user is more concerned with performance, availability, and security of the SaaS. This is particularly important in the health care context wherein providers and patients are depending on the mhealth application for timely and accurate data processing, and are expecting such data processing and storage to be highly secure U.S.C Id. 5

6 In addition to all of the obvious reasons why a health care provider must be very careful about implementing the use of mhealth apps with patient care, the provider should also be wary of unknowingly exposing himself to liability because of a failure to closely review the SaaS license terms. The following is a summary of some of the terms that should be closely examined by any health care provider or end-user (licensee) that is licensing a mhealth software application from a vendor (licensor). A. Availability and Service Levels. Depending on how critical the application is to patient care, the health care provider should demand that the licensor of the mhealth application guarantee a certain percentage of uptime, such as 99.99%, excluding scheduled downtimes. The provider may demand that the scheduled downtimes occur only on weekends or on weekdays in the middle of the night. Similarly, the health care provider should demand that the vendor respond to software failures within predetermined periods of time. It is typical for software failures to be categorized into severity levels, with the most severe failures demanding the quickest response and resolutions time periods. B. Ownership of Data. As previously referenced, all of the data transmitted through SaaS is stored on the vendor s remote server. This makes it vitally important that the license agreement specify that (i) the licensee solely owns the underlying data, such as all the PHI and other confidential and proprietary information, and (ii) the vendor will maintain the data in strict confidence. The license agreement may grant the vendor a limited license to use the data only for purposes of hosting the relevant software and performing its obligations under the agreement. The license agreement should further specify how often and the manner in which the licensee has a right to export the data from the vendor s server. For example, the agreement may provide that the licensee is entitled to periodic copies of all data, as well as data upon request at any time. 6

7 Because the licensee has no control over storage of the data in SaaS, the licensee should demand that the vendor perform regular backups of the data to an off-site storage facility (e.g, daily or monthly). C. Data Security and Breach. In light of the HIPAA provisions regarding data breaches, as well as general data security concerns, the license agreement should further require the vendor to comply with specific security measures. These measures can range from the specifications of the data center housing the server (e.g., limited physical access requiring personnel authentication, monitored security system, and appropriate HVAC system), to data encryption (e.g., firewall protection and encrypted connections), to breach notification procedures. The health care provider should demand control over the timing and method of notification to its patients in the instance of any breach. D. Indemnification and Limitation of Liability. Without hesitation, the licensee should demand that the agreement provide for indemnification of the licensee in the case of the vendor s breach of its confidentiality and security obligations. Additionally, in this era of patent trolls, health care providers should demand indemnification for claims brought against them or their patients for infringement of third party intellectual property rights. The licensee should ensure that the vendor s indemnification obligations are not subject to any limitation of liability provisions. E. Insurance. Of course, the indemnification clauses may be only as good as the vendor is solvent, which is why appropriate insurance obligations are key. The vendor should be required to procure and maintain insurance with appropriate limits to cover the vendor s activities under the agreement. As an aside, the health care provider should also proactively obtain insurance, including coverage for security breaches and patent infringement claims. 7

8 F. Warranties. The licensee should expect the vendor to warrant that (i) the mhealth application will perform in accordance with the specifications provided by the vendor, (ii) the application won t infringe any third party intellectual property rights, and (iii) the vendor will comply with all applicable laws and regulations, expressly including HIPAA. IV. Financial Security There may be cases where health care providers are using mhealth apps with patients wherein the patients may opt in to additional features on a pay-as-you-go basis. Similarly, there are many consumers paying for mhealth apps separate and apart from the direction of their respective health care providers. In these instances, it is common for the consumer to pay for the service via the application, such as with a credit card or PayPal account. This implicates additional security concerns regarding financial transactions. In light of recent, highly publicized cyber-security attacks, all licensees should be especially concerned about proper processing and storage of credit and debit card information. At a minimum, the mhealth application license agreement should provide for the vendor s compliance with the Payment Card Industry Data Security Standard ( PCI DSS ). PCI DSS is a proprietary information security standard for organizations that handle cardholder information for the major debit, credit, prepaid, e-purse, ATM, and POS cards. The PCI DSS requirements cover maintenance of a secure network, protection of cardholder data, maintenance of a vulnerability management program, implementation of access control measures, regular network testing, and maintenance of an information security policy. 13 Ideally, licensees should insist that the mhealth vendor use a tokenization method for credit and debit card payments, which is a best practice in PCI DSS compliance. Tokenization is 13 PCI Security Standards Council. Retrieved from (accessed March 15, 2014). 8

9 a method of protecting card data by substituting a card s primary account number ( PAN ) with a unique, randomly generated sequence of numbers, alphanumeric characters, or combination of a truncated PAN and a random alphanumeric sequence, known as a token. 14 Tokens have no meaning without the proper detokenization function to extract the original PAN. When tokenization is used in the context of a SaaS, the software vendor accepts the credit or debit card information, encrypts it (converts it to a token), and sends the token to the vendor s payment processor where the data is then decrypted and the transaction is authorized. The payment processor then sends a token representing the transaction back to the software vendor. The software vendor never stores the actual credit or debit card number. Therefore, if the software vendor suffers a data breach, only the meaningless tokens are misappropriated. This is one of the most secure methods for processing credit and debit card payments. Health care providers should inquire about this method, particularly when their patients are using mhealth apps under the direction of the health care providers and are provided with the option to self-pay for additional features. V. Conclusion mhealth devices and apps are inevitably becoming a way of life in the health care industry. Health care providers are uniquely positioned to provide input on development of new apps to suit their practice needs and to license apps already in the marketplace. In both instances, the wise health care provider should become knowledgeable about the forms of protection for mhealth apps as well as considerations that should be given to mhealth app 14 Vijayan, J. (February 12, 2012). Banks push for tokenization standard to secure credit card payments, retrieved from ecure_credit_card_payments (accessed March 15, 2014). 9

10 license provisions. Hopefully, integration of mhealth devices and apps will be mutually beneficial to both health care providers and their patients. 10