Source: https://www.wsgr.com/publications/PDFSearch/digital-health-report/Winter19/digital-health-report.htm
Timestamp: 2019-04-19 11:21:44+00:00

Document:
Two Prongs Making Digital Health Patents Right?
Digital health entrepreneurs often come forward with a seemingly straightforward question: “Is what I’m doing regulated by the FDA?” Whether developing a medical app to track biometric data through a smartphone, leveraging accelerometers in wearables to evaluate joint health, or training complex algorithms to help health care providers make better treatment decisions, the possibilities—and questions—are vast. While every situation is different, this article briefly outlines a framework for thinking about your product or service and its intersection with the United States Food and Drug Administration (FDA) regulations. In it, we present a brief introduction to the FDA’s regulation of devices generally in order to set the stage for a deeper dive into a particular kind of regulated device—Software as a Medical Device, or SaMD. In particular, we will discuss what is and, based on new FDA guidance, what is not regulated as SaMD.
To identify the boundaries of SaMD, it is helpful to have a working understanding of how the FDA regulates medical devices overall. In general, a medical “device” is an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including any component, part, or accessory, which is i) intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, ii) or intended to effect the structure or any function of the body. What makes a device unique from a drug, for example, is that a device does not achieve its purpose through a chemical action in the body.1 Examples of devices range from a simple tongue depressor to cuttingedge laser surgical devices. The definition of device also encompasses certain software. To avoid confusion, there are two types of software the FDA classifies as a device which are not the topic of this article: software that is integral to a medical device (e.g., it drives or controls a hardware device), and software that is used in the manufacture or maintenance of a medical device. We are focused on a third category: Software as a Medical Device (SaMD), which is defined by the FDA through incorporation of the International Medical Device Regulator’s Forum’s (IMDRF) definition as software intended to be used for one or more medical purposes, that perform the purposes independently of a hardware medical device. SaMD is unique in that it achieves its purpose without being tethered to a particular device, i.e., it operates “independently” of a hardware device. In fact, SaMD is deployed on a diverse array of platforms (e.g., personal computers, smart phones, network servers) easily accessed and distributed (e.g., through the internet or cloud) on general-purpose (non-medical) hardware (e.g., a smartphone or wearable device). Second, the software must have a “medical purpose,” as opposed to the abundance of software used in healthcare (administrative, financial software), that is not itself medical in nature. “Medical purpose” aligns with the definition of a “device” above, including in vitro diagnostics. The evolving nature of defining what SaMD is appears limited only by the creativity of those developing it. Because of this ever-changing landscape, it is particularly important to highlight recent FDA guidance that defines software functions which are actually excluded from the definition of a device. As discussed below, this delineation is part of an effort to streamline the development of software products that balance a low risk of harm with high degree of potential benefit.
The recent changes to the definition of “device” originate in the 21st Century Cures Act (the Cures Act),2 which focused, among other things, on ways to bring medical products to market more quickly. One way in which it sought to do this was to amend the definition of “device” under the Food, Drug and Cosmetic Act (the FD&C Act) to exclude certain software functions, and direct the FDA to issue a follow-up report and guidance. Since the Cures Act, the FDA has published two draft guidances3 (collectively, the FDA Guidance) and a more recent report4 (the FDA Report) discussing in more detail the software functions excluded from the definition of a “device” and therefore from more stringent FDA regulatory review, as well as impacts to patient health and best practices.
Providing certain types of clinical decision support to a health care provider, unless interpreting or analyzing a clinical test or other device data.
1. Administrative support of a health care facility: The definition of device excludes a software function intended for administrative support of a health care facility, including: processing and maintenance of financial records, claims or billing information, scheduling appointments, business analytics, information about patient populations, admissions, practice and inventory management, analysis of historical claims data to predict future utilization or cost-effectiveness, determination of health benefit eligibility, population health management, and laboratory workflow. Historically, these have already been considered these to be non-device functions, but the FDA’s Guidance adds additional clarity for developers.
2. Maintaining or encouraging a healthy lifestyle: Software functions that promote a healthy lifestyle and are unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition are excluded from the definition of “device.” The FDA has previously provided guidance on what it means to promote a “healthy lifestyle,”6 categorizing these “general wellness” products into two categories of intended use: a) an intended use related to maintaining or encouraging a general state of health or a healthy activity, or b) an intended use that relates to the role of a healthy lifestyle by helping to reduce the risk or impact of certain chronic diseases or conditions, where it is well understood and accepted that healthy lifestyle choices may plan an important roles in health outcomes for the disease or conditions. If your software function relates to b), it is not to be excluded from the definition of “device,” because the function relates to the mitigation or prevention of a disease or condition. However, the FDA Guidance makes clear that the FDA will continue not to enforce applicable requirements for this type of general wellness software where it presents a low risk to the safety of users. Making this concept more concrete, the FDA Guidance outlines a number of examples of what it considers healthy lifestyle claims (i.e., not related to the diagnosis, cure, mitigation, prevention or treatment of a disease or condition), including weight management, physical fitness, relaxation or stress management, mental acuity, self-esteem, sleep management, or sexual function. Furthermore, it will amend the Mobile Medical App guidance such that apps that had been classified as “mobile apps for which FDA intends to exercise enforcement discretion” will not be “examples of mobile apps that are NOT medical devices”—offering much clearercut guidance for developers.
3. Electronic patient records: Software functions that are intended to serve as electronic patient records are not devices. More specifically, a software function that transfers, stores, converts formatting, or displays electronic patient records are not devices if the records a) are created, stored, transferred, or reviewed by health care professionals (or individuals working under them), b) the records are certified by the Office of the National Coordinator for Health Information Technology (ONC), and c) the software is not intended to interpret or analyze patient records, including imaging data, for the purpose of diagnosis, cure, mitigation, prevention, or treatment of a disease or condition.
4. Transferring, storing, converting, or displaying data: Software that is used to transfer, store, convert the format of, or display clinical laboratory test or other device data and results is not considered a device, unless such function is intended to interpret or analyze clinical laboratory test or other device data, results, and findings. Note that software functions that analyze or interpret medical device data in addition to transferring, storing, converting formats, or displaying clinical lab test or other device data remains subject to FDA oversight.
5. Providing certain clinical decision support7: Finally, software may also be excluded from SaMD if it satisfies all four of the following elements: 1) it is not intended to acquire, process, or analyze a medical image/signal from an in vitro diagnostic device or a pattern/signal from a signal acquisition system; 2) it is intended to display, analyze, or print medical information about a patient or other (e.g., general) medical information; 3) it is intended to support or provide recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition; and 4) it enables such health care professional to independently review the basis for such recommendation, so the health care professional does not primarily rely on the software recommendation in making a clinical diagnosis or treatment decision. The fourth element is the most critical; the point is that while software that is not a medical device may assist a health care professional to reach a treatment recommendation, the software must enable the health care professional to separately come up with such treatment recommendation, without relying primarily on the software itself. Software may provide such independent basis for review by clearly explaining: a) the purpose of the software function; b) the intended user (e.g., vascular surgeon); c) the information input in the software to generate such recommendation (e.g., patient age and gender); and d) the software’s rationale behind such recommendation. For example, software that helps health care professionals diagnose diabetes in patients by taking information (e.g., lab test results, patient parameters) input by the health care provider and making suggestions based on whether such input information matches established, readily available external guidelines may be excluded from SaMD. Conversely, software that manipulates or analyzes data from a patient’s CT scan and provides a 3D reconstruction with software-imposed markers to help the health care provider visualize where to place catheters in a surgery, would probably not be excluded from SaMD because the health care provider is not able to independently verify (i.e., apart from the software’s own algorithm) how the software generated this recommendation.
The relative complexity of medical device software coupled with increased connectedness, diversity of operating platforms, and rapid development cycles are just some of the unique features of SaMD versus traditional medical devices that present new challenges and call for evolving FDA (and international) guidance. As an entrepreneur in the digital health space, you can leverage the evolving clarity from the FDA to focus on products that clearly will not be regulated as a device, or dive in knowing that your software product will be regulated, and be educated about the FDA approval process.
1 21 U.S. Code § 321(h).
2 21st Century Cures Act. H.R. 34, 114th Congress. 2016. https://www.gpo.gov/fdsys/pkg/BILLS-114hr34enr/pdf/BILLS-114hr34enr.pdf.
3 Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act Guidance: https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM587820.pdf; Clinical and Patient Decision Support Software Guidance: https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM587819.pdf.
4 Report on Non-Device Software Functions: Impact to Health and Best Practices—December 2018: https://www.fda.gov/downloads/MedicalDevices/DigitalHealth/UCM628128.pdf.
5 General Wellness: Policy for Low Risk Devices: https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm429674.pdf.
6 Clinical and Patient Decision Support Software—December 2017: https://www.fda.gov/downloads/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm587819.pdf.
7 Clinical and Patient Decision Support Software—December 2017: https://www.fda.gov/downloads/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm587819.pdf.
When determining whether to allow a patent application claiming inventions in the digital health space, the United States Patent and Trademark Office (USPTO) will review this application from various perspectives, including whether the claimed invention is directed to subject matter that is patent eligible under 35 U.S.C. § 101 (Section 101). While the issue of Section 101 patent eligibility is a threshold question that is considered across all technologies, the Section 101 question has particular relevance to digital health technology, which typically implicates software, data processing, and computers—implications that frequently give rise to Section 101 questions during patent prosecution and even patent litigation.
In January 2019, the USPTO issued a guidance (the January 2019 guidance), providing an updated framework for analyzing the question of patent eligibility under Section 101.1 Effective immediately, the January 2019 guidance may have broad implications across all industries with U.S. patents and patent applications related to digital health, software, diagnostics, and life science technologies.
At a high level, the original Section 101 framework required, inter alia, determining whether a patent claim is “directed to” a judicial exception, i.e., Step 2A. Judicial exceptions included abstract ideas, laws of nature, or natural phenomena. If the claims were directed to a judicial exception under the original Step 2A test, the claims were preliminarily determined to not be patent-eligible unless an “inventive concept” could be found in Step 2B.
As part of the original Step 2A test, USPTO examiners (examiners) were instructed to analyze the patent claim as a whole and compare their finding with court decisions determining whether the patent claim was or was not directed to a judicial exception. As a guide, the examiners relied on the USPTO’s “Eligibility Quick Reference Sheets” (USPTO reference sheets). Last updated in July 2018, the USPTO reference sheets listed more than 100 examples of subject matter directed to a judicial exception (abstract ideas) and just eight examples of subject matter not directed to an abstract idea. The USPTO reference sheets and its examples of abstract ideas and non-judicial exceptions continued to grow and evolve as more and more court decisions interpreting Section 101 came forth.
Realizing that relying on an ever growing USPTO reference sheets was impractical and that the current Step 2A framework could yield inconsistent conclusions among the examiners as to whether a claim was directed to a judicial exception, the January 2019 guidance offers a new Prong-One and Prong-Two approach for Step 2A.
In sum, the January 2019 guidance offers simpler and narrower categories for what should qualify as an abstract idea, which should have a positive impact on the patent eligibility of digital health software-related patent applications as they are prosecuted at the USPTO. The January 2019 guidance further offers a clearer structure on how to evaluate the “integration into a practical application” prong, which should offer more consistency of the patent eligibility analysis across examiners in all industries implicated by Section 101 issues, including digital health, software, diagnostics, and life sciences. The accompanying USPTO examples of hypothetical claims should also serve as a helpful tool for digital health companies to consider as they evaluate the merits of seeking patent protection around their intellectual property.
1 See 2019 Revised Patent Subject Matter Eligibility Guidance, 84 Fed. Reg. 50 (Jan. 7, 2019).
2 “Mathematical concepts” is defined as “mathematical relationships, mathematical formulas or equations, mathematical calculations.” See Fed. Reg. Vol. 84, No. 4 at 52 (Jan. 7, 2019). “Certain methods of organizing human activity” is defined as “fundamental economic principles or practices (including hedging, insurance, mitigating risk); commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations); managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions.” See id. “Mental processes” is defined as “concepts performed in the human mind (including an observation, evaluation, judgment, opinion). See id.
3 Only in rare circumstances should a claim that does not recite one of the three subject matter groups qualify as a “tentative abstract idea.” In such cases, the examiner should go through the rest of the other Section 101 analysis steps. If still found to be a tentative abstract idea, the application is to be brought to the Technology Center Director and the Section 101 rejection must be approved by the Technology Center Director.
4 For example, a modification of internet hyperlink protocol to dynamically produce a dual source hybrid web page. See MPEP 2106.05(a) for more information concerning improvements in the functioning of a computer or to any other technology or technical field, including a discussion of the exemplar provided herein, which is based on DDR Holdings, 773 F.3d at 1258–59. See also USPTO Finjan Memorandum (discussing Finjan and Core Wireless).
5 For example, an immunization step that integrates an abstract idea into a specific process of immunizing that lowers the risk that immunized patients will later develop chronic immune mediated diseases. See, e.g., Classen Immunotherapies, Inc. v. Biogen IDEC, 659 F.3d 1057, 1066–68 (Fed. Cir. 2011). See also Vanda Pharm. Inc. v. West-Ward Pharm. Int’l Ltd., 887 F.3d 1117, 1135 (Fed. Cir. 2018) (holding claims to the practical application of the natural relationships between iloperidone, CYP2D6 metabolism, and QTc prolongation to treat schizophrenia, not merely the recognition of those relationships, to be patent eligible at Mayo/Alice step 1 (USPTO Step 2A)), and USPTO Vanda Memorandum (discussing Vanda)).
6 For example, a Fourdrinier machine (which is understood in the art to have a specific structure comprising a headbox, a paper-making wire, and a series of rolls) that is arranged in a particular way that uses gravity to optimize the speed of the machine while maintaining quality of the formed paper web. See MPEP 2106.05(b) for more information concerning use of a judicial exception with, or in conjunction with, a particular machine or manufacture, including a discussion of the exemplar provided herein, which is based on Eibel Process Co. v. Minnesota & Ontario Paper Co., 261 U.S. 45, 64–65 (1923).
7 For example, a process that transforms raw, uncured synthetic rubber into precision-molded synthetic rubber products by using a mathematical formula to control operation of the mold. See MPEP 2106.05(c) for more information concerning transformation or reduction of a particular article to a different state or thing, including a discussion of the exemplar provided herein, which is based on Diehr, 450 U.S. at 184.
8 Robert W. Bahr, Changes in Examination Procedure Pertaining to Subject Matter Eligibility, Recent Subject Matter Eligibility Decision (Berkheimer v. HP, Inc.) (Apr. 19, 2018), available at https://www.uspto.gov/sites/default/files/documents/memo-berkheimer-20180419.PDF; see also Training: Well-Understood, Routine, Conventional Activity (posted May 7, 2018), available at https://www.uspto.gov/sites/default/files/documents/berkheimer-training-20180427.pptx.
For a fuller explication of the USPTO April 2018 Berkheimer Memo, please refer to: Peter S. Kang, Get Your Facts Right: Berkheimer’s Impact on the Second Alice/Mayo Step of the Patent Eligibility Analysis, WILSON SONSINI GOODRICH & ROSATI DIGITAL HEALTH REPORT, Fall 2018, available at https://www.wsgr.com/publications/PDFSearch/digital-health-report/Fall18/digital-health-report.htm.
9 84 Fed. Reg. at 56.
11 Subject Matter Eligibility Examples: Abstract Ideas, available at https://www.uspto.gov/sites/default/files/documents/101_examples_37to42_20190107.pdf.
15 Id. at 18, 19.
Welcome to the second installment of our series on Health Insurance Portability and Accountability Act of 1996 (HIPAA) for digital health entrepreneurs. If you missed the first, then a brief re-introduction is in order: This series is specifically tailored to HIPAA topics that impact our digital health clients, particularly for those wading into health privacy for the first time. The first installment laid some basic groundwork outlining the law; in this article, we will dig deeper into a particular topic—business associates.
If you have begun to explore HIPAA on your own, you may have noticed that much (although certainly not all) of what is freely available on the internet is geared toward advising “covered entities.” As discussed briefly in the last article, covered entities are defined by HIPAA as health care providers (who transmit any health information in electronic form in connection with certain health care transactions), health plans, and health care clearinghouses.1 It makes sense that the spotlight tends to focus on covered entities, because HIPAA applies to nearly every organization that directly provides, insures, or bills for health care in an industry worth trillions. The cost of compliance (and noncompliance) for these entities isn’t trivial.
1) “New Territory”: You are developing a new product or service, adding a feature, or moving into the health care vertical for the first time, and want advice about whether your plans will require you to comply with HIPAA.
2) “BAA Pusher”: You have launched a product or service and have been successfully marketing it to customers; you are pretty sure you are not regulated by HIPAA, but all of a sudden a potential customer is pushing you to sign a business associate agreement (BAA). You want to know whether you can take the position that you are not providing business associate services, and thus avoid the BAA, without losing the deal.
3) “You’re not a business associate even if you want to be”: Maybe you are comfortable with signing a BAA, and have had your HIPAA house in order for some time. You want to enter into a partnership or collaboration with a covered entity, e.g., a hospital or clinic to beta test your platform and solicit feedback from providers. The problem is that you aren’t actually offering any “services” to the covered entity. Even where you may wish to receive, and the covered entity may be willing to give, access to protected health information (PHI), the key takeaway is that a business associate agreement is not a sufficient legal basis if no business associate services are being rendered. More discussion is on this point below.
Under any of these scenarios, the answer to “does this make me subject to HIPAA” can be a complex one; however, this article will give you an initial framework to think about the implications of your product or service in the context of HIPAA.
What Are Business Associate Services?
Here is the bottom line first: Not all services provided to a customer in the health care space will render you a business associate. If your product or service is only marketed to individual users, or your customer is involved in health care, but is not a covered entity, then, as a general rule, HIPAA is not implicated. That said, many of our clients launch their product as directto-consumer first (e.g., a wellness tracker in the App Store), but have plans to expand its functionality to connect both individual and provider customers in the future, which may involve HIPAA compliance. The key is to be future-oriented about your product arc and where it may eventually intersect with HIPAA, while knowing where you stand today. The rest of this section focuses solely on the scenario where you target your product or service to a covered entity customer, which gives rise to implications under HIPAA.
Why does the law separate these into two separate baskets of services? Looking closely at the language, (2) expressly defines certain services that aren’t inherently business associate services, but will be if PHI is exchanged. On the other hand, (1) is a bit more nebulous—the service must relate to a “function or activity regulated by HIPAA.” While the regulations provide certain examples, the list is not exhaustive. Because of this, it may be relatively straightforward to determine whether your product or service falls within the ambit of a business associate, and other times it can be more complex.
Is my target customer a “covered entity”?
If yes, will I create, maintain, receive, or transmit PHI, or will my product or services otherwise involve the disclosure of PHI?
If still yes, then does the service itself fit within the definition of a business associate?
If you make it past the first two questions answering “yes” and on the third answer “no,” you should pause, as this may indicate an issue. Your covered entity customer must have a legal basis for sharing PHI with you. If there is no business associate service being rendered, then another legal basis must exist. Generally speaking, for our clients, that alternative legal basis would be to obtain a HIPAAcompliant authorization from any individual for whom PHI will be disclosed. We often hear that obtaining a HIPAA authorization from individuals is not scalable, because it is individualized and must be coordinated with the covered entity. We tend to agree with this from a business operations perspective; however, if your model relies on you receiving PHI without providing a business associate service, then it might be a signal to rethink the model.
It is worth noting that it is the covered entity’s responsibility to ensure there is an adequate legal basis to initially use or disclose PHI. Occasionally our clients ask for a retrospective review of whether a business associate agreement should have been entered into with their customers. Even where the answer is yes, the client is likely performing a business associate service, the risk for them is low because the covered entity should be the one to require the BAA be signed. However, as a matter of good business practice, we encourage clients to proactively determine whether they think their services would qualify them as a “business associate”, and sign (or decline to sign) BAAs uniformly across customers.
Given the proliferation of cloud computing solutions, the agency responsible for enforcing HIPAA—the Department of Health and Human Services, Office of Civil Rights (HHS-OCR)—has taken steps to clarify through guidance when and how cloud service providers (CSPs) are regulated under the law. You can view detailed information on the types of services providers HHS-OCR considers to be CSPs by viewing the National Institute of Standards and Technology guidance on the topic,3 but generally CSPs “offer online access to shared computing resources with varying levels of functionality depending on the users’ requirements, ranging from mere data storage to complete software solutions (e.g., an electronic medical record system), platforms to simplify the ability of application developers to create new products, and entire computing infrastructure for software programmers to deploy and test programs.”4 HHS-OCR is clear that when a covered entity or a business associate engages a CSP to create, receive, maintain or transmit electronic PHI (ePHI) on its behalf, the CSP is itself a business associate.
Quite often we are asked whether our client (or its subcontractor) would be considered a business associate if it is not able to access the ePHI because, e.g., the data is encrypted and they don’t have the code. HHS-OCR is clear and emphatic on this point—the CSP is still a business associate even if it processes and stores only encrypted ePHI and lacks an encryption key for the data. Lacking an encryption key does not exempt a CSP from HIPAA regulation. This point is often confused with the so-called “conduit exception” under HIPAA, whereby service providers who only incidentally handle PHI are not considered business associates. The examples of conduits given by HHS-OCR are the United States Postal Service and some other private couriers; it does not include CSPs whose role is tied to managing ePHI, regardless of whether the CSP itself has direct access.
If you are offering cloud services that relate to ePHI, either directly or through a third-party CSP (e.g., Amazon Web Services), be prepared to execute a BAA with your covered entity customer or with the thirdparty CSP provider as your subcontractor.
On the way are more real-world examples and analyses of how HIPAA is impacting the digital health industry. Of course, if this has provoked questions about HIPAA, privacy in general, or anything digital health related, please reach out to your WSGR attorney for more information.
1 See definition of “covered entity” at 45 C.F.R. 160.103.
2 See definition of “business associate” at 45 C.F.R. 160.103.
3 SP 800-145, The NIST Definition of Cloud Computing, available at: http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf.
4 HHS-OCR Guidance on HIPAA and Cloud Computing, available at: https://www.hhs.gov/hipaa/for-professionals/special-topics/cloud-computing/index.html.

References: § 321
 § 101
 v. 
 v. 
 v. 
 v.