New » Silicon Valley Digital Health Law Blog; Kristie Prinz

template

FTC Announces Final “Click to Cancel” Rule for Subscriptions, Memberships

The Federal Trade Commission (“FTC”) has just announced the final version of its “Click to Cancel” Rule for consumer software subscriptions. The Rule will go into effect 180 days after it is published with the Federal Register. This Rule will directly apply to all digital health companies selling on a subscription basis to consumers.

Full Text of FTC Rule

The full text of the FTC Rule is linked here, at pages 222-230.

Fact Sheet of FTC Rule

The FTC has also made available a fact sheet which briefly summarizes key provisions of the “Click to Cancel Rule,” which is attached here.

Key Provisions of the FTC Rule

According to the FTC announcement, the “Click to Cancel” Rule will apply to “almost all negative option programs in any media.” The key provisions of the FTC Rule will prohibit:

misrepresenting any material fact made while marketing goods or services with a negative option feature;
failing to “clearly and conspicuously disclose” material terms prior to obtaining a consumer’s billing information in connection with a negative option feature;
failing to obtain a consumer’s express informed consent to the negative option feature before charging the consumer; and
failing to provide a simple mechanism to cancel the negative option feature and immediately stop the charges.

Revisions to Final Version of the FTC Rule

Also according to the FTC announcement, the FTC dropped from its final Rule an annual reminder requirement that would have required vendors to provide annual reminders to consumers advising them of the negative option feature of their subscription, as well as a requirement that vendors had to ask canceling consumers for approval before a vendor could tell a canceling subscriber about reasons to keep the existing agreement or of possible modifications that could be made without canceling the subscription.

Reasons for Adoption of the Rule

Why did the FTC adopt a Click to Cancel Rule? According to the FTC Announcement, the FTC was receiving 70 consumer complaints per day over negative option programs, and this number was “steadily increasing over the past five years.”

The FTC’s announcement follows a recent California enactment of a more comprehensive “Click to Cancel” law.

Does the FTC Rule Supersede California Law?

The FTC Rule should not supersede California’s more comprehensive law; in fact, the Rule specifically states in its text that the Rule will not be construed to supersede any State statute, regulation or order “except to the extent that it is inconsistent with the provisions of this part, and then only to the extent of the inconsistency.” The expected impact of the FTC Rule is primarily to bring federal regulatory law closer to California regulatory law as it pertains to subscriptions and memberships.

What do Digital Health Companies Utilizing the Subscription Model Need to do in Response to this Announcement?

All digital health companies utilizing a subscription model should revise consumer contracts and processes to comply with the FTC Rule over the next 180 days (whereas revisions must be made to comply with the new California law sooner: by the end of 2024). Digital health companies utilizing the subscription model with a business-focused customer base should similarly consider what changes to make to their contracts and processes as public policy will likely change regarding subscriptions generally along with the new FTC Rule and California law changes.

If you have questions or concerns about how new FTC “Click to Cancel” Rule or the new California ”Click to Cancel Law” will impact your digital health company, please schedule a consultation with me today at https://calendly.com/kristieprinz.

California Adopts “Click to Cancel” Law to Regulate Consumer Subscriptions

California has just adopted the new “click to cancel” law that will regulate consumer subscriptions, along with memberships and other autorenewing or continuous service arrangements with consumers.

AB 2863 amends California’s existing autorenewal law to add additional protections for consumers with respect to autorenewing or continuous billing charges.

Digital health companies need to be aware of this new law and is potential to impact contracts and customer relationships, particularly in light of the currently slow tech and life sciences market.

Text of AB 2863

To view the full text of AB 2863, please click here. The law goes into effect on January 1, 2025, applies to all contracts entered into, amended, or extended after that date.

New Requirements for Consumer Subscriptions

Under the new California law, it will now be unlawful for any digital health company in the state that makes an autorenewal or continuous service offer to a consumer in the state to do any of the following:

Fail to present the terms of the offer in a clear and conspicuous manner in visual proximity to the request for consent of the offer, which includes if there is a free gift or trial, a clear and conspicuous explanation of the price that will be charged when the trial ends;
Charge the consumer’s credit or debt card or any third party account for the automatic renewal or continuous service without first obtaining affirmative consent from the consumer to the automatic renewal or continuous service agreement;
Fail to provide an acknowledgement that includes the automatic renewal offer terms or continuous service offer terms, cancellation policy, and information regarding how to cancel in a manner that the consumer can retain, and if the offer contained a free gift or trial, the acknowledgement must include a disclosure of how to cancel and must permit the consumer to cancel before the consumer pays for the goods or services;
Fail to obtain express affirmative consent from a consumer to the automatic renewal or continuous service offer terms;
Include terms in a contract that interfere with, detract from, contradict, or otherwise undermine the ability of consumers to provide their affirmative consent to automatic renewal or continuous service terms;
Fail to maintain verification of consumer’s affirmative consent for at least three years, or one year after the contract is terminated, whichever is longer;
Misrepresent expressly or by implication a material fact related to the transaction;
Fail to provide consumer with a notice, before confirming the consumer’s billing information that clearly and conspicuously states:
- The service will automatically renew unless the consumer cancels;
- The length and any additional terms of the renewal period;
- The amount or range of costs consumer will be charged and the frequency of those charges, unless consumer stops the charges;
- One or more methods which consumer can cancel the autorenewal or service;
- If sent electronically, the notice must include a link that directs consumer to the cancellation process, or another electronic method that directs the consumer to cancellation; and
- Contact information for the business.

New Requirements for Gifts and Trials

In addition, digital health companies offering free gifts or trials at promotional or discount prices that last for more than 31 days in conjunction with an automatic renewal or continuous service offer will now be mandated to provide the same kind of clear and conspicuous notice no less than 3 days before and no more than 21 days before the expiration of the gift or trial. The only exception to this requirement is in cases of contracts that are not electronic, where the business has not collected or maintained the consumer’s valid email address, phone number, or other means of notifying the consumer electronically. “Free gifts” for the purpose of this law does not apply to a gift that is different than the subscribed product or service.

New Requirements for Contracts or Offers with Initial Term of One Year or Longer

If the contract or service offer was for an initial term of one year or longer, digital health companies will now be required to provide the specified notice at no less than 15 days and no more than 45 days before the offer renews.

Online “Click to Cancel” Requirement

Digital health companies that sign-up or subscribe consumers online will be required to provide one of two methods to allow consumers to cancel at will by either (a) a prominent link or button within the customer account or profile or within device or user settings, or (b) an immediately accessible termination email formatted and provided by the business that a consumer can email to the business without any additional requirement.

Direct Billing Requirement

Digital health companies that direct bill consumers on an automatic renewal or continuous offer basis will be required to provide a toll-free telephone number, email address, and postal address or “another cost-effective, timely, and easy-to-use mechanism for cancellation” that is described in the acknowledgement. If a telephone number is provided as the mechanism for termination, the business is required to answer calls promptly during normal business hours without obstructing or delaying the ability to cancel. If a voice mail is left by the consumer requesting cancellation, the digital health company shall be required to either process the requested cancellation in one business day or call the customer back regarding the request within one business day.

Customer Retention Offer Requirement

Digital health companies will still be permitted to make customer retention offers, provided that they must first clearly and conspicuously inform the consumer that they may complete the cancellation process at any time by stating they want to “cancel” or similar words to that effect. Once the consumer states their intention to “cancel” or uses similar words, the digital health company must promptly process the cancellation without obstruction or delay. Digital health companies making online customer retention offers will be required to display a simultaneous, prominently and proximately located and continuously displayed direct link or button labeled “click to cancel” alongside the offer. Once the consumer clicks on the button, the business is required to promptly process the cancellation.

Requirement for Material Term Changes

Digital health companies who materially change terms that have already been accepted by a consumer in the state will be required to provide to the consumer a clear and conspicuous notice of the material change and to provide information on how to cancel. If the change involves a fee that was already accepted, the digital health companies will be required to provide at least 7 days (and no more than 30 days) prior clear and conspicuous notice of the fee change and information on how to cancel.

Requirement for Annual Reminder

Digital health companies will be required to send an annual remind to consumers who have entered into annual automatic renewal agreements or continuous service agreements in the same medium that the agreement was activated or in the same medium by which the consumer is interacting with the business. If the medium was in-person or voice-based then the digital health company may submit the reminder via telephone, mail, or another internet-based communication. The notice is required to disclose the product or service to which the agreement applies; the frequency and amount of charges; and the means to cancel.

Implications of Requirements

While these new rules apply only to automatic renewal agreements and continuous service agreements with consumers, they may be applied to digital health companies in cases where they are run by sole proprietors. Also, they may be applied in other contexts to digital health companies on public policy grounds, where the terms of service or contract terms in effect are not at least as good as what is required now by law in the case of consumers.

What does this mean for Digital Health Companies?

Digital health companies need to start reviewing and updating their contracts and terms of service, as well as their practices and procedures, before the January 1, 2025 effective date of this new law. Given there are so many changes, most companies who serve a consumer client base will need to rethink their terms and practices and procedures, and companies who serve a business client base will also want to consider whether or not their current agreements and practices and procedures are aligned with the new law.

If you have questions or concerns about how this new law will impact your digital health company, please schedule a consultation with me today at https://calendly.com/kristieprinz.

Kristie Prinz to Lead New Silicon Valley Group in ProVisors

Kristie Prinz to Speak at Practicing Law Institute Program

Digital Health Lawyer Kristie Prinz introduces The Prinz Law Office

Kristie Prinz Explains Why Companies Should Review Key Customer Contracts in a Sluggish Economy

Digital Health Law Blog Kristie Prinz Introduces Self

What Constitutes “Digital Health”?

Why A Sluggish Economy is the Perfect Time to Audit and Review Key Customer Contracts

It has become increasingly clear over the past few months that businesses are in a cost-cutting mode, as the economy has become more and more sluggish. While your digital health company is likely focusing on its own cost-cutting strategy, have you stopped to consider whether your most significant customers might be doing the same? Is it possible those key customers may be focusing on how to cut the cost of their contract with your business? Could they be talking to one of your competitors? Could they be building their own proprietary product to replace the cost of your product?

A sluggish economy is the perfect occasion to audit and review your key customer contracts for weaknesses that might allow your customer to walk out the door as a cost-cutting move.

You might wonder why you should spend any resources on contracts when business is already sluggish: isn’t this exactly the time when you should be reducing legal expenses, along with all your other cost-cutting efforts?

Well, no, actually. While, it has been my experience that this is in fact what most companies do; however, I have been practicing now for 26 years and had the occasion to see a lot of sluggish economies, and given that experience, I would argue that it is exactly the wrong move to make in a sluggish economy. Why would I say this?

Imagine this: it is two months in the future. Over the last 30 days, all of your key customers have stopped paying on their contracts with you and have advised you that they are suspending performance. You are confident that they are just cutting costs and have no grounds to terminate the relationship. You pull out the executed contracts and send them to your digital health attorney to review for the first time, confident that he or she will confirm your assessment. However, instead of confirming your position, your digital health attorney tells that the signed contracts were poorly drafted and that the customers may have had valid grounds to terminate.

In this scenario, if you had known there was something you could do to interrupt this chain of events and shore up the customer relationships before they collapsed, would it have been worthwhile to do it? Presumably, yes. If the customers were your truly your key customers, you probably had a lot riding on the continuation of those relationships.

If the fact pattern seems far-fetched, I’ve actually seen it play out many times during sluggish economies. The larger and more expensive the contract, the more at risk it is for termination in a sluggish economy. If you are confident it won’t happen to your company, consider what kind of representation you had for the drafting and negotiation of that contract? Did you work with experienced software counsel who had advised other digital health, software, and SaaS companies through multiple bad economies, and involve that counsel at every stage of the negotiation and drafting process and then implement all of his or her recommendations? Or did you cut a few corners in getting your deal done? Perhaps handled a lot of the negotiation and drafting without counsel, or relied on less experienced counsel that was more affordable? If you are like many software companies, you probably cut at least a few corners–perhaps you even cut a lot of corners–and the contracts executed by you and your key customers are full of holes.

What would truly be the impact to your digital health company of a complete loss of your three largest customers? Your six largest customers? Your ten largest customers? How fast could you really recover in a sluggish economy?

If the prospect of this kind of business loss fills you with terror, then this is precisely why you should revisit your significant contracts now.

So, what is it that you can do to shore up your key client relationships now? Well, skilled digital health counsel can evaluate those contracts and identify the potential liabilities and then work with you to develop a strategy to renegotiate them. By taking the opportunity to renegotiate a weak contract before the contract terminates, you can extend the term of the relationship, fix the legal problems in the contract, and keep the customer happy in the first place by giving the customer a concession that the customer really wants in exchange for the longer relationship term that carries the relationship through the down economy.

Isn’t this a better outcome than losing a key customer altogether over a vulnerability in your contract that is exploited in a cost-cutting effort?

If your digital health company has not had its key customer contracts evaluated recently by an experienced digital health lawyer, schedule a consultation with me today at https://calendly.com/kristieprinz. Let’s identify the vulnerabilities in your key contracts before a key customer exploits the vulnerabilities as a cost-cutting move and resolve potential problems in the relationships before they arise and become the reason you lose those relationships.

California Telehealth Policy Coalition Presents Webinar on Cross-State Licensure and Compacts

Digital Health Lawyer Kristie Prinz Selected to 2024 Super Lawyers Northern California List

The Prinz Law Office Announces New Service Offerings Effective August 1, 2024

What are the Lessons to Be Learned from Today’s Worldwide Technology Disruption Over Software Update?

Does Your Digital Health Company Rely on an Annual Paid Monthly Subscription Model?

FTC Seeks to Expand Scope of “Negative Option Rule” to Apply to Subscriptions

As the Silicon Valley Digital Health Law Blog recently advised you, the FTC has just filed a complaint against a software company over its “Annual Paid Monthly” subscription contract. The FTC has separately also sought the expansion of its “Negative Option Rule” to amend the provisions to specifically apply to subscriptions by adding a “Click to Cancel” provision. A copy of the FTC notice of proposal is linked here.

What is the FTC’s Negative Option Rule?

The Negative Option Rule was adopted by the FTC in 1973, to address “negative option offers,” which the FTC defines as offers containing “a term or condition that allows a seller to interpret a customer’s silence, or failure to take an affirmative action, as acceptance of an offer.”

According to the FTC, negative option marketing utilizes four types of offers: prenotification plans, continuity plans, automatic renewals, and free trial conversion offers.

However, the FTC’s original Negative Option Rule only pertained to prenotification plans, excluding the continuity plans, automatic renewals and free trial offers that have become commonplace in 2024. Also, in the case of the original Negative Option Rule, prenotification plans were limited to the sale of goods, where sellers provided periodic notices to participating customers and then sent and charged for those goods only if the consumers took no action to cancel and decline the offer (i.e. the example of a wine club).

Also, the Negative Option Rule required clear and conspicuous disclosure of certain terms before a subscription agreement was reached. According to the FTC, those terms were as follows:

how subscribers must notify the seller if they do not wish to purchase the selection;
any minimum purchase obligations;
the subscribers’ right to cancel;
whether billing charges include postage and handling;
that subscribers have at least ten days to reject a selection;
that if any subscriber is not given ten days to reject a selection, the seller will credit the return of the selection and postage to return the selection, along with shipping and handling; and
the frequency with which announcements and forms will be sent.’

Finally, under the existing Negative Option Rule, sellers were required to define particular periods for sending merchandise, to give consumers a defined period to respond, to provide instructions for rejecting merchandise, and to promptly honor written cancellation requests.

What is “Click to Cancel’?

What would change with the FTC’s newly proposed “Click to Cancel” amendment?

Under the FTC’s proposed “Click to Cancel” rule change, the scope of the Negative Option Rule would be increased to make it pertain to not only prenotification plans but also to continuity plans, automatic renewals, and free trial conversion offers. Also, the proposed “Click to Cancel” rule provisions would mandate the following:

Businesses would be required to make cancelling a subscription or membership at least as easy as it was to start it;
Businesses would have to ask consumers if they want to hear new offers when they ask to cancel before they would be able to pitch new offers;
Businesses would be required to provide an annual reminder if enrolled in a negative option program involving anything other than physical goods, before they are automatically renewed.

Another “Click to Cancel” change is that the under the new provisions any misrepresentation of a material fact related to any of the four negative option offers, whether expressly or by implication, would constitute a violation of not only the Negative Option Rule but also an unfair or deceptive act or practice in violation of Section 5 of the Federal Trade Commission Act.

What is the Potential significance of “Click to Cancel” to the Digital Health Industry?

The potential significance of the “Click to Cancel” change to the average digital health company is that, if this proposed rule is adopted, digital health companies who sell directly to consumers will need to update consumer contracts and terms of service to confirm that they are compliant with the requirements of the Negative Option Rule, as amended.

The Silicon Valley Digital Health Law Blog will keep you posted as to the status of the FTC’s proposed rule. If your digital health company is concerned about its compliance with “Click to Cancel” please schedule a consultation with me to discuss today.

FTC Sues Software Company over Annual Paid Monthly Subscription Contract

The FTC has just taken enforcement action against a software company over its subscription contracting practices, filing a complaint against Adobe over its Annual Paid Monthly subscription contract and its consumer practices regarding the contract. A copy of the FTC complaint is linked here. If your digital health company relies on a subscription-based revenue model, there are some clear lessons to be learned from the FTC action.

In its complaint, the FTC raised concerns not only with the terms of the subscription contract and how they were drafted but also the process and practices of the company in signing up and retaining customers. According to the FTC, Adobe enrolled consumers by default in its most expensive plan without clearly disclosing the key terms of the plan, which were that they were agreeing to a year-long commitment with a large early termination fee, and that consumers only discovered the nature of what they agreed to when they tried to terminate and realized they could not do so without incurring a significant fee. The F TC stated:

Adobe hides material terms of its [Annual Paid Monthly] plan in fine print and behind optional textboxes and hyperlinks, providing disclosures that are designed to go unnoticed and that most consumers never see. Adobe then deters cancellations by employing an onerous and complicated cancellation process. As part of this convoluted process, Adobe ambushes subscribers with the previously obscured ETF when they attempt to cancel.

The FTC’s legal case focuses on The Restore Online Shopper’s Confidence Act, 15 U.S.C. §§ 8401-8405 (“ROSCA”). The text of ROSCA is published here. ROSCA prohibits unfair and deceptive Internet sales practices, and generally prohibits charging consumers for goods and services sold in transactions through a negative option feature unless the seller:

clearly and conspicuously discloses all material terms of the transactions before obtaining billing information from the consumer
obtains the consumer’s express informed consent before making the charge
provides simple mechanisms to stop recurring charges.

The FTC alleges Adobe had significantly increased its revenue by engaging in practices that violated ROSCA.

Digital Health company founders should take note that the FTC case was not limited to an action against the company: the FTC also filed suit against two of Adobe’s executives on an individual basis.

What are some of the lessons that digital health companies should learn from this FTC action against Adobe?

First and foremost, you should rethink the use of “Annual Paid Monthly” Subscription Plans. They may seem clever from a marketing perspective, but they are likely to draw heavy regulatory scrutiny going forward. Plans that are annual commitments should be clearly referenced and defined in contracts and marketing materials as “annual subscription plans” and not presented as monthly plans.

Second of all, if you are offering “Annual Paid Monthly” subscription plans, you should go out of your way to clearly and conspicuously disclose the key terms of your “Annual Paid Monthly” plan, including in particular the key facts that the plan has an annual subscription term and that it has an early termination fee. You also should be exceedingly clear about the specifics of any early termination fee, and the termination fee needs to be presented in a way that is very clear and conspicuous.

Third of all, if you are offering “Annual Paid Monthly” subscription plans, you should refrain from taking steps in the customer enrollment process to push your customers to the “Annual Paid Monthly” subscription plan. All options should be equally presented to customers without defaulting to a less favorable option.

Fourth, if you are offering “Annual Paid Monthly” subscription plans, you should make it easy for your customers to cancel. If customers are posting online complaints about the problems they have had in trying to cancel your subscription, you should take action prompt action to address those problems. It seems clear that the FTC was troubled by the complaints posted with the better business bureau against Adobe on this issue.

Fifth, even if you do not offer a subscription that looks like an “Annual Paid Monthly” subscription, you should refrain from offering subscriptions with negative options, as the FTC clearly finds them to be problematic.

Finally, if you are a digital health company, you need to become familiar with ROSCA and the government’s ROSCA enforcement practices, if it was not already on your company’s radar.

The Silicon Valley Digital Health Law Blog will continue to follow developments with this FTC enforcement action. If you have concerns about whether or not your digital health subscription contract or contracting practices will comply with the FTC’s requirements as articulated in its case against Adobe, I invite you to schedule a consultation with me today at this l ink.

Digital Health AI Start-Ups Concerned as California’s AI Legislation Moves Closer to Adoption

Many digital health AI start-ups are concerned as California’s controversial AI legislation moves closer to adoption by the California legislature. The legislation is SB 1047: Safe and Secure Innovation for Frontier Artificial Intelligence Models Act, and it would impose unprecedented new regulations on the development of AI. A full copy of the bill has been linked here.

What is SB 1047, the Safe and Secure Innovation for Frontier Artificial Intelligence Models Act?

The Safe and Secure Innovation for Frontier Artificial Intelligence Models Act (the “AI Models Act”) would create a new Frontier Model Division within California’s Department of Technology which would have oversight powers over the training of many new AI models, including digital health AI models. Under the AI Models Act, developers of these AI models would be required to build a so-called kill switch into the AI model and to potentially shut down the model until the Frontier Model Division deems that the AI model is subject to a “limited duty exemption,” which would be defined as:

a determination. . . . that a developer can provide reasonable assurance that the covered model does not have a hazardous capability, as defined, and will not come close to possessing a hazardous capability when accounting for a reasonable margin for safety and the possibility of posttraining modifications.

A “covered model” under the AI Models Act would be defined to mean an “artificial intelligence model that was trained using a quantity of computing power greater than 10^26 integer or floating-point operations, and the cost of that quantity of computing power would exceed one hundred million dollars ($100,000,000) if calculating using average market prices of cloud compute as reasonably assessed by the developer at the time of training.

As currently proposed, “derivative” AI models would be exempt from the new compliance obligations: only “non-derivative” AI models would be subject to the obligations.

A “derivative model” would be defined to be an artificial intelligence model that is derivative of another AI model, including either ” a modified or unmodified copy of an artificial intelligence model” or “a combination of an artificial intelligence model with another software. The “derivative model” would be specifically defined not to include “an entirely independently trained artificial intelligence model” or an “artificial intelligence model, including one combined with other software, that is fine-tuned using a quantity of computing power greater than 25 percent of the quantity of computing power, measured in integer or floating-point operations, used to train the original model.

How would “hazardous capability” be defined by SB 1047?

SB 1047 would define “hazardous capability” to constitute the capability of a covered model to be used in one of the following harms:

the creation or use of a chemical, biological, radiological, or nuclear weapon in a manner that results in mass casualties
at least $500 million dollars of damage through cyberattacks on critical infrastructure via a single incident or multiple related incidents
at least $500 million dollars of damage by an AI that autonomously engages in conduct that would violate the Penal Code if taken by a human
bodily harm to another human
the theft of or harm to property
other grave threats to public safety and security that are of comparable severity to the harms described above.

Penalties for noncompliance with this legislation would include punitive damages and a civil penalty for a first violation not to exceed ten percent of “the cost of the quantity of computing power used to train the covered model to be calculated using average market prices of cloud compute at the time of training” and 30 percent of the same in case of a second violation. The legislation authorizes joint and several liability against the developers directly where

(1) steps were taken in the development of the corporate structure among affiliated entities to purposely and unreasonably limit or avoid liability.

(2) The corporate structure of the developer or affiliated entities would frustrate recovery of penalties or injunctive relief under this section.

If passed, damages could be awarded for violations occurring as of January 1, 2026.

How would SB 1047 affect Digital Health AI start-ups in San Diego, Orange County and Silicon Valley?

If SB 1047 is adopted, the costs of compliance for digital health AI start-ups is going to increase, to the extent that their models are not deemed “derivative.” Digital health companies already face a significant compliance obligation that many other start-ups do not face to the same degree, as they not only have privacy compliance concerns but also HIPAA and FDA compliance concerns. SB 1047 would impose an additional layer of compliance headaches on already cash-strapped digital health companies in California.

What has been the reaction to SB 1047 from the Silicon Valley start-up community?

As you might expect, the reaction from the Silicon Valley start-up community has largely been one of alarm.

Bloomberg has been reporting on the Silicon Valley reaction, and indicated that that a key concern is that this law is going to “place an impossible burden on developers–and particularly open-source developers, who make their code available for anyone to review and modify– to guaranteed their services aren’t misused by bad actors.” Bloomberg also reported that a general partner at Andreessen Horowitz indicated that some startup founders are so concerned that they are wondering if they should leave California because of the bill.

Bloomberg also reported that the a key point of contention in the startup community is the idea that AI developers are responsible for people who misuse their systems, pointing to Section 230 of the Communications Decency Act of 1996, which has shielded social media companies from liability over content users create on platforms.

Author Jess Miers of the Chamber of Progress criticized the legislation on the basis that it would “introduce a high degree of legal uncertainty for developers of new models, making the risks associated with launching new AI technologies prohibitively high.”

The Silicon Valley Digital Health Law Blog will continue following legislative developments relating to SB 1047 as the legislation continues to be considered by the California legislature.

If you have questions regarding your digital health company’s potential compliance obligations under SB1047, please schedule a consultation with me at this link.

The Prinz Law Office Announces Launch of New Subscription Plans

HHS Publishes Proposed Rule Defining Information Blocking Penalties for Medical Providers

The Department of Health and Human Services (“HHS”), the Office of the National Coordinator for Health Information Technology (“ONC”) and the Centers for Medicare & Medicaid Services (“CMS”) have just published a proposed rule defining the consequences for medical providers who fail to comply with the new information blocking regulations.

HHS previously established information blocking penalties for IT providers, health information exchanges, and networks of up to $1 million per violation. A full discussion of the previously proposed information blocking regulations was previously published on the Silicon Valley Digital Health Law Blog at this attached link

The newly announced proposal linked here will establish penalties in the form of financial disincentives for the medical providers who violate the information blocking regulations and are also Medicare-enrolled providers or suppliers. (For the avoidance of doubt, the proposed rules do not apply to medical providers who fail to comply with the regulations but are not Medicare-enrolled providers or suppliers.) The proposed financial disincentives are as follows:

“Eligible Hospital(s)” or “critical access hospital(s)” would not be deemed to be a “meaningful electronic health record (“EHR”)” user, meaning that an “eligible hospital” would not be able to earn the three quarters of the annual market basket increase associated with qualifying as a meaningful EHR user and a “critical access hospital” would have its payment reduced to 100 percent of reasonable costs from the 101 percent of reasonable costs it might otherwise have earned in an applicable year.
A health care provider that is an a “MIPS eligible clinician” would not be a “meaningful EHR user” in an applicable information blocking performance period and would also be required to report on the Promoting Interoperability performance category of MIP, as not earning a score.
A health provider that is an accountable care organization (“ACO”), ACO participant, or ACO provider/ supplier will be barred from participating in the Shared Savings Program for at least a year.

What are the potential financial implications for these disincentives?

According to reporting by Healthcare IT News, the consequences to an “eligible hospital” deemed to be non-compliant “could result in a median disincentive amount of $394,353, ” whereas the consequences to a group of “MIPS eligible clinician(s)” deemed to be non-compliant could result in a loss ranging $1,372 to $165,326 for group sizes ranging from two to 241 clinicians.

HHS, ONC and CMS are currently seeking comments on the proposed rule. Comments should be submitted on or before January 2, 2024 at 5 p.m. ET. The submission instructions are published at this attached link.

DEA Extends COVID-19 Telemedicine Rules

New California Law to Mandate Release of VC Investment Diversity Information

Governor Newsom has just signed SB 54, which will require venture capital firms in the state of California to annually report the diversity of founders they are backing. According to Tech Crunch’s reporting, SB 54 will result in amendments to the Business and Professional Code and also will amend part of the Government Code pertaining to venture capital.

SB 54 goes into effect as of March 1, 2025, and requires the following aggregated information to be reported on all VC investments:

The gender identity of each member of the founding team, including nonbinary and gender-fluid identities.

The race of each member of the founding team.

The ethnicity of each member of the founding team.

The disability status of each member of the founding team.

Whether any member of the founding team identifies as LGBTQ+.

Whether any member of the founding team is a veteran or a disabled veteran.

Whether any member of the founding team is a resident of California.

Whether any member of the founding team declined to provide any of the information described above.

Failure to timely comply with the reporting requirement may result in the assessment of a penalty of One Hundred Thousand Dollars ($100,000.00) to be assessed against a “covered person.” SB 54 defines “covered person” as any person who does both of the following:

Acts as an investment adviser to a venture capital company.

Meets any of the following criteria: (i) Has a certificate from the Commissioner of Financial Protection and Innovation pursuant to Section 25231 of the Corporations Code. (ii) Has filed an annual notice with the Commissioner of Financial Protection and Innovation pursuant to subdivision (b) of Section 25230.1 of the Corporations Code. (iii) Is exempt from registration under the Investment Advisers Act of 1940 pursuant to subsection (l) of Section 80b-3 of Title 15 of the United States Code and has filed a report with the Commissioner of Financial Protection and Innovation pursuant to paragraph (2) of subdivision (b) of Section 260.204.9 of Title 10 of the California Code of Regulations.

SB 54 provides that reports will be due by March 1st of each year.

Tech Crunch reports that supporters of SB 54 have argued that this law will make venture capital more “transparent.” According to Tech Crunch, less than 3 % of all venture capital investments go to women or black founders.

Tech Crunch reported that SB 54 was opposed by the National Venture Capital Association and TechNet, though both organizations professed to support generally the concept of diversity in venture capital.

Although the impact of SB 54 will go beyond just the digital health industry, this new law is likely to have a significant impact on digital health companies, particularly those having diverse founders, as mandated reporting will likely incentivize venture capital firms to further focus on considering diversity in investment. If your digital health company has diverse founders, you definitely will want to keep this law on your radar screen going forward.

FDA Releases Final Guidance on Cybersecurity for Medical Devices

The Food and Drug Administration (“FDA”) has issued final guidance to advice developers on their compliance obligations for premarket submissions. To view the FDA’s finalized document, please click here: Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions (fda.gov). The guidance issued by the FDA supersedes the earlier draft guidance issued on April 8, 2022 as well as the “Content of Premarket Submissions for Management of Cybersecurity in Medical Devices” issued October 2, 2014.

The guidance describes recommendations regarding the cybersecurity information to be submitted for the following:

Premarket notification (510(k)) submissions;
De Novo requests;
Premarket Approval Applications (PMAs) and PMA supplements;
Product Development Protocols (PDPs)
Investigational Device Exemption (IDE) submissions;
Humanitarian Device Exemption (HDE) submissions;
Biologics License Application (BLA) submissions; and
Investigational New Drug (IND) submissions.

The FDA states in its release that “this guidance applies to all type of devices within the meaning of section 201(h) of the Federal Food, Drug, and Cosmetic Act (“FD&C Act”), including devices that meet the definition of a biological product under section 351 of the Public Health Services Act, whether or not they require a premarket submission.” In addition, the FDA says that the guidance applies “to devices for which a premarket submission is not required (e.g. for 510(k) exempt devices)” as well as “cyber devices as defined in section 524B of the FD & C Act.” Finally, the FDA states that the guidance applies to the device portion of a combination product “when the device constituent part presents cybersecurity considerations, including but not limited to devices that have a device software function or that contain software (including firmware) or programmable logic.” Although the FDA indicates in the release that the guidance should not be construed as “legally enforceable responsibilities,” the FDA advises that the guidance represents its “recommendations” on the topic of cybersecurity.

What exactly recommendations exactly does the FDA make in this guidance?

First of all, the FDA recommends that device manufacturers follow the quality system requirements found in the QS regulation in 21 CFR Part 820, which may include establishing cybersecurity risk management and validation processes where appropriate in accordance with FDA’s guidance “Content of Premarket Submissions for Device Software Functions.” The FDA says that healthcare facilities may manage devices within their own frameworks such as the National Institute of Standards Technology (“NIST”) cybersecurity framework. The FDA also points to the following frameworks to consider: the Medical Device and Health IT Joint Security Plan, which is available at https://healthsectorcouncil.org/the joint-security plan; IEC 81001-5-1; and ANSI, ISA 62442-4-1.

Second of all, the FDA recommends that device manufacturers implement security controls, which include authentication; authorization, cryptography, code, data and execution integrity; confidentiality; event detection and logging; resilience and recovery, updatability and finally, patchability.

Third, the FDA recommends that the manufacturers must establish and maintain procedures for verifying the device design, which verification must confirm that the design output meets the design input requirements. The FDA again points to 21 CFR 820.30 for guidance on the procedures for verification.

Fourth, the FDA recommends transparency in advising users of relevant security risks through labeling, and provides specific examples of information to include in labeling. The FDA points to IEC TR 80001-2-2 and IEC TR 80001-2-9 for further guidance on labeling to comply with the standards.

Fifth, the FDA recommends that manufacturers establish a plan for how to identify and communicate to users vulnerabilities identified after releasing the device in accordance with 21 CFR 820.100, which plan can also support security risk management processes described in the QS regulation. The FDA states that these plans should include the following elements:

Personnel responsible;
Sources, methods, and frequency for monitoring and identifying vulnerabilities (e.g. researchers, NIST vulnerability database (NIST NVD), third party manufacturers;
Identify and address vulnerabilities identified in “CISA’s Known Exploited Vulnerabilities Catalog” available at https://www.cisa.gov/known-exploited-vulnerabilities-catalog;
Periodic security testing;
Timeline to develop and release patches;
Update processes;
Patching capability (i.e. rate at which update can be delivered to devices);
Description of their coordinated vulnerability disclosure process; and
Description of how the manufacturer intends to communicate forthcoming remediations, patches, and updates to customers.

The FDA points to its “Postmarket Cybersecurity Guidance” for additional recommendations on plans.

Digital health companies should definitely take the time to review and familiarize themselves with the new guidance, as it is likely that health care customers will be expecting compliance with this new guidance going forward, regardless of whether or not digital health companies’ products are actually subject to FDA regulation. Even though this guidance constitutes merely a recommendation to those digital health companies which are subject to FDA regulation, it provides specific minimum recommendations that health care customers will likely expect their providers to be compliant with going forward.

HHS Issues Final Rule Implementing Information Blocking Penalties

The Department of Health and Human Services Office of Inspector General (“HHS-OIG”) recently issued on June 27, 2023 its final rule on information blocking penalties. The final rule establishes statutory penalties for committing information blocking of up to a $1 million penalty per violation. According to an HHS website, enforcement assessing penalties began as of September 1, 2023.

To view the text of the final rule pertaining to information blocking, please click here: https://www.federalregister.gov/documents/2023/07/03/2023-13851/grants-contracts-and-other-agreements-fraud-and-abuse-information-blocking-office-of-inspector.

In case you are unfamiliar with the original legislation pertaining to information blocking, this is explained at the HealthIT.gov website: https://www.healthit.gov/topic/information-blocking. The brief explanation is that information blocking is a prohibited practice by an actor “likely to interfere with the access, exchange, or use of electronic health information (“EHI”), except as required by law or specified in an information blocking exception.” To view an HHS worksheet defining EHI in more detail, please click here: https://www.healthit.gov/sites/default/files/page2/2021-12/Understanding_EHI.pdf

Actors may include health care providers, health information networks or health information exchanges, and health IT developers of certified health IT. To view an HHS worksheet defining actors, please click here: https://www.healthit.gov/sites/default/files/page2/2020-03/InformationBlockingActors.pdf.

The information blocking legislation defined eight information blocking exceptions:

preventing harm;
privacy;
security;
infeasibility;
health IT performance;
licensing;
fees; and
content and manner.

To view the HHS worksheet defining these information blocking exceptions in more detail, along with the conditions required to meet the terms of each information blocking exception, please see the attached link: https://www.healthit.gov/sites/default/files/2022-07/InformationBlockingExceptions.pdf.

The information blocking legislation was mandated in 2016 by the 21st Century Cures Act which made information sharing of electronic healthcare information the norm. To view the full text of the legislation, please click on the link: https://www.congress.gov/114/plaws/publ255/PLAW-114publ255.pdf.

The information blocking legislation is certainly not new legislation, so digital health compliance professionals are likely already familiar with the provisions. However, given the fact that the enforcement phase of the information blocking legislation has just commenced, digital health companies should take the time to review their current information sharing practices to ensure that they are familiar with the rules relating to information blocking and that they remain in compliance with them.

HIPAA Privacy Rule Update on Reproductive Health Anticipated

The final update to the HIPAA Privacy Rule on reproductive health is anticipated to be issued soon by the Department of Health and Human Services (“HHS”).

HHS issued a Notice of Proposed Rulemaking on April 17, 2023 to solicit comments on its proposal to modify the Standards for Privacy of Individually Identifiable Health Information (“Privacy Rule”) under the Health Insurance Portability and Accountability Act of 1996 (“HIPAA”) and the Health Information Technology for Economic and Clinical Health Act of 2009 (“HITECH Act”). The comment period on the proposed update closed as of June 16, 2023.

If adopted, the proposed update would modify existing standards permitting uses and disclosures of protected health information (“PHI”) by prohibiting uses and disclosures of PHI about reproductive health care for criminal, civil, or administrative investigations or proceedings against individuals, covered entities or their business associates or other persons for seeking, obtaining, providing, or facilitating reproductive health care that is lawful under the circumstances in which it is provided.

The update was originally prompted by an executive order from President Biden directing HHS to take actions to strengthen the protections under HIPAA for reproductive health information following the Supreme Court’s decision in Dobbs v. Jackson Women’s Health Organization. Attached is a link to the Court’s decision: https://www.supremecourt.gov/opinions/21pdf/19-1392_6j37.pdf. A copy of President’ Bidens’s executive order may be viewed here: https://www.govinfo.gov/content/pkg/FR-2022-07-13/pdf/2022-15138.pdf.

According to the HHS Notice, the proposed Privacy Rule will “strengthen privacy protections for individual’s PHI related to reproductive health care” in order to “avoid the circumstance where an existing provision of the Privacy Rule is used to request the use or disclosure of any individual’s PHI as a pretext for obtaining PHI related to reproductive health care for a non-health care purpose where such use or disclosure would be detrimental to any person. ”

To view the full HHS notice on the anticipated HIPAA Privacy Rule update, please click here: https://www.federalregister.gov/documents/2023/04/17/2023-07517/hipaa-privacy-rule-to-support-reproductive-health-care-privacy. For additional HHS commentary on the proposed Privacy Rule updates, please click here: https://www.hhs.gov/hipaa/for-professionals/regulatory-initiatives/hipaa-reproductive-health-fact-sheet/index.html.

ATA releases Toolkit Intended to Advise on Eliminating Disparities in Healthcare

DEA Considers Regulations on the Prescribing of Controlled Substances via Telemedicine

The DEA conducted a two day listening session last week to receive practitioner comments on regulations relating to the prescribing of controlled substances via telemedicine. Transcripts of the public comments are available for viewing at this link: https://www.deadiversion.usdoj.gov/Telemedicine_listening_session.html.

According to reporting by Fierce HealthCare, the listening sessions were held in response to a backlash from doctors and telehealth groups after the DEA released proposed rules in February, 2023 that would have reinstated the restrictions that existed before the COVID era on the prescribing of controlled substances via telehealth. In particular, the proposed rule would mandate that Schedule 2 medications or narcotics be prescribed in-person and Schedule 3 medications or higher could be prescribed for 30 days via telehealth but would require an in-person visit prior to refill. Fierce HealthCare reported that the DEA received a record 38,000 comments on its proposed telemedicine rules, which were among the highest ever received in DEA history.

The American Telemedicine Association (“ATA”) has opposed the DEA’s February, 2023 position, asserting that the DEA’s plans will “simply limit. . . . access to legitimate health care”. See ATA’s March 28, 2023 letters to the DEA at this link, in which the ATA submitted comprehensive recommendations regarding the proposed rules: https://www.americantelemed.org/press-releases/ata-action-submits-comprehensive-recommendations-to-dea-on-proposed-rules-regarding-remote-prescribing-of-controlled-substances/.

The ATA has advocated for a special registration process for telemedicine prescribing of controlled substances without a prior in-person visit based on seven key tenets, stated in its press release attached here:

The Special Registration process should work in conjunction with the existing registration process.
Telemedicine providers should not be required to maintain local addresses in every state where they practice.
Special Registration should include the elements DEA needs to monitor for illegitimate practitioners and illegal prescribing practices.
Special Registration should not be limited to any specific specialty or treatment condition. Schedule II prescribing could involve additional oversight but should not have additional restrictions.
Dispensers (pharmacies and pharmacists) should be able to identify legitimate prescribers who have a current Special Registration.
The location of the patient should not require any registration unless otherwise required because controlled substances are dispensed or administered at that site.
The Special Registration process should not place any arbitrary limits on a clinician’s ability to practice within the scope of their authority.

According to Fierce HealthCare the DEA was originally mandated fifteen years ago within the Ryan Haight Act to develop a special registration process for remote prescribing, which was mandated again by Congress in 2018, but the DEA failed to act on both occasions. The ATA and other advocates are pushing the DEA to follow through on the prior mandates to keep COVID-era telemedicine flexibilities in place.

The Silicon Valley Digital Health Blog will continue to follow this issue as it develops. Clearly, the DEA’s next steps will have a tremendous impact on patient access to telemedicine going forward.

New HIPAA Security Rule Assessment Tool Released

California Considers Adoption of Controversial Veterinary Telehealth Bill

The California legislature is currently considering a controversial new telehealth bill that would dramatically expand the access to veterinary care for animal patients located in California. AB 1399 would change California’s existing law to permit a veterinarian-client-patient-relationship to be established solely via telemedicine. Existing California law limits the practice of veterinary telemedicine to existing veterinarian-client-patient-relationships only, where the animal has previously been examined by the veterinarian, except in cases where the advice is given in an emergency. See the attached link to view the bill in its entirety: Bill Text – AB-1399 Veterinary medicine: veterinarian-client-patient relationship: telehealth. (ca.gov)

Proponents of AB 1399 argue that passage of this bill is necessary to make permanent the COVID-era relaxation of California’s existing regulations, which permitted care virtually when local veterinary practices were inundated with new patients and human caretakers were dealing with challenging personal circumstances. They argue that California continues to deal with a shortage of veterinarians and telemedicine improves access to care for California animals, many of whom would not otherwise receive care at all. Attached are links to arguments and statements in support of the bill by Dr. Christie Long and the SFSPCA.

However, critics of AB 1399 warn of the unintended consequences of relaxing the existing regulations to California animals. In particular, the American Veterinary Medical Association has opposed the bill on this ground (see the attached link). While the California Veterinary Medical Association had also opposed AB 1399 (see the attached link), it just recently amended its position after several new amendments were made to the bill. Attached is a copy of the letter published by the CVMA explaining the change of position: AB-1399-Friedman-NEUTRAL-position.pdf (cvma.net).

For the digital health community, the adoption of AB 1399 and permanent relaxation of existing veterinary care restrictions in California would be a clear win for digital health providers seeking to expand access to veterinary care to more of the state’s animal residents. The adoption of AB 1399 in this state could also have the effect of influencing other states with similar restrictions in place to also consider relaxing their regulations.

The Veterinary Virtual Care Association, a global nonprofit association dedicated to developing standards for veterinary virtual care, is actively tracking the current status of veterinary telehealth laws around the country at the following website: The VVCA Telemedicine Regulatory Map – Veterinary Virtual Care Association. According to the VVCA’s regulatory reporting map, Michigan, Connecticut and the District of Columbia are currently the only states not requiring that telemedicine be tied to a veterinarian-client-patient-relationship. If accurate, this means that California’s adoption of AB 1399 would set an important national precedent for veterinary telemedicine law.

Kristie Prinz to Present on Best Practices in Drafting Digital Health SaaS Contracts to Add & Retain Customers

Date: November 14, 2023
Price: $99 General Admission; $125 Late Admission
Registration

The digital health industry has exploded during the COVID-19 pandemic, resulting in an increasing number of digital health SaaS transactions. However, given the relative youth of the industry, few business lawyers or businesspeople negotiating digital health SaaS transactions are familiar with the best practices to pursue in negotiating and drafting digital health contracts.

Silicon Valley Digital Health Lawyer Kristie Prinz has been practicing in this field as it has emerged and will present a webinar looking at what you need to know if you are negotiating and drafting digital health SaaS contracts to add and retain customers. In this presentation, she will explore:

What is digital health?
What constitutes a digital health contract?
What are the essential terms in a well-drafted digital health contract?
What are the key considerations you need to have in negotiating digital health contracts?
What are the common issues that arise in digital health contract negotiations?
What are the problems with digital health clauses that are most likely to cause a dispute?

Kristie Prinz is the founder of The Prinz Law Office, which is based in Silicon Valley. Her digital health practice focuses on advising mid-market and early-stage digital health companies on the negotiation and drafting of complex commercial transactions.

Kristie is a regular speaker, media contributor, and author on digital health and SaaS transactions issues. She founded the Silicon Valley Software Law Advisors Group and the Life Science Advisors Group and she is the author of the Silicon Valley Digital Health Law Blog. Kristie is also a graduate of Vanderbilt Law School and is licensed to practice law in the states of California and Georgia. For more information about Kristie, check out her digital health blog at siliconvalleydigitalhealthlaw.com and her personal website at kristieprinz.com.

To register for the event, please sign up at Best Practices in Drafting Digital Health SaaS Contracts Tickets, Multiple Dates | Eventbrite

The Risks of Closing a Deal by Signing the Customer Contract

Perhaps one of the very worst decisions I see digital health companies make is negotiating to close a deal by agreeing to sign the customer’s contract.

While it can potentially save time and upfront legal fees to agree to sign the customer’s proposed contract and perhaps get cash in the door faster, the legal fallout from making such a poor decision can have devastating consequences.

How does this happen? Well, it has been my experience that it largely happens because the digital health company has not invested the time and money into developing a contract appropriate to the transaction, or perhaps has not found the right attorney with the skills to draft an appropriate contract. Since the customer is unwilling or simply unable to do the work for the digital health company, the customer instead proposes the seemingly easier solution of using one of its already approved templates. The digital health company is often very eager to close the deal as soon as possible and therefore agrees to sign the customer contract.

Why is signing the customer contract such a poor decision?

Customer Contract Has Nothing to Do with the Products or Services

Well, typically the customer contract has absolutely nothing to do with the digital health company’s product and/or services. So, there will be no terms in the contract to define how the product should function or to set any expectations about how the services will work. The customer obligations will never be defined, and the terms of payment will be poorly defined at best.

Customer Contract Will Be Silent on Implementation and Specific Liability Risks

Additionally, the customer contract will likely be silent on the implementation requirements and process for getting the customer up and running, which will often be extensive in larger customer deals. The customer contract will likely also be silent on the liability risks specific to the digital health company and the digital health company’s products and services. Furthermore, the customer contract will also likely be silent on any terms about the process, expectations, and costs and expenses for transitioning to a new service provider when the relationship ends.

Customer Contract Will Be Drafted to Favor Customer

Finally, the customer contract will likely drafted only for the benefit of the customer and be full of terms that are favorable only to the customer at the expense of the digital health company.

Consequences of Signing the Customer Contract

While I would argue that the execution of a customer contract is actually bad for both sides, since the terms of the relationship are never actually agreed upon, I would also argue that the practice is particularly bad for the digital health company, which will deliver products and services without any memorialization of any essential terms of the relationship by which the company is working.

What can happen? Well, what I have seen happen in the past is that digital health companies are put in a very vulnerable position when the customer decides to terminate the relationship and stop making payments previously understood to be due and payable. Often the digital health company has little in the contract to fall back on in support of its position that it is owed the payments it was expecting, and often has no choice but to concede its position.

However, this is actually not the worst case scenario: in the worst case scenario, the digital health company not only loses fees that were due but also ends up with a judgment entered against the company on behalf of the customer, where the company is ordered to pay back the fees they already collected and even pay damages to the customer.

Digital health companies often rationalize poor decision-making by claiming that they do not have an available alternative to signing a customer contract in order to get a deal done, but the truth of the matter is that companies always have choices in negotiation. The savvy digital health company will opt to spend the money to draft an appropriate contract for the transaction, and then refuse to do a deal that does not include the key terms and conditions memorializing the delivery of its products and services. It is always better to avoid making mistakes that may save a few dollars up front but become very costly over the longer term.

So, if you are a digital health company who finds itself in this situation, you may want to rethink your inclination to execute your customer’s contract. Perhaps you should instead opt to draft a new contract that better suits the terms of the proposed transaction.

Updated 6.1.24

Will Your Digital Health Company’s Contracts be Vulnerable to a Recession?

If your digital health company is like most companies right now, your company is nervous about the possibility of an impending recession. Of course, the real challenge is how to handle those nerves, and what steps your digital health company should take to better protect itself in the current environment. The conventional wisdom is to focus on generating more sales and to cut costs, particularly costs that executives perceive to be expensive such as legal expenses that digital health companies might otherwise spend on negotiating and drafting contracts with customers of digital health software and services. However, the reality is that the conventional wisdom is completely wrong in the current environment and may have dire consequences for a digital health company, if the digital health company blindly follows convention in the current climate. In fact, a savvy digital health company will anticipate that a recession is exactly when good contracts matter the most, and exactly when companies should focus more of their resources on ensuring that contracts, particularly key contracts, will not fall victim to their customers’ cost-cutting efforts.

Why would contracts be more vulnerable in a recession? Well, digital health customers are making the same kinds of calculations that digital health companies are making, except that they will examine the spending commitments that they have already made on digital health software and services and explore how they might be able to reduce those commitments. Accordingly, the digital health contracts they have already signed will receive extra scrutiny, and potentially become the subject of a dispute.

If you believe your digital health company is immune to economy-driven renegotiation efforts, you may want to reconsider your position. It has been my experience that, whereas in good economies, my client base is largely comprised of digital health companies trying to close large business deals with software customer, in poor economies, my client base is the quite the opposite: digital health customers engage me to advise them on how to renegotiate or terminate altogether software and/or services that they no longer want to pay for. In fact, in the last recession, my entire business was almost entirely comprised of advising health technology software customers on problems with their previously signed contracts and how those problems might be exploited to escape their previously agreed to financial commitments. Ironically, the experience of advising health technology software customers in the last recession became the basis for the digital health contract drafting practice I have built today, as the experience I developed from advising customers on how to exploit drafting vulnerabilities in their previously signed contracts enabled me to thereafter advise digital health companies on drafting best practices to avoid subsequent customer disputes.

What can your digital health company do today to protect itself against economy-driven contract vulnerabilities in a recessionary environment?

First and foremost, identify your digital health company’s most significant contracts and have a digital health contracts lawyer review them now for vulnerabilities. Once any contract vulnerabilities are identified, your digital health company can work closely with the digital health contracts lawyer to adopt a strategy that addresses and deals with any such vulnerabilities before the customer decides to exploit them.

Second of all, identify your digital health company’s contracts that may be up for renewal during the anticipated recession, and have a digital health contracts lawyer identify any terms and conditions pertaining to renewal and any laws that your company may be subject to relating to the issue of renewal, which might be exploited by a customer, if such terms and conditions or laws were not closely followed by the company.

Third, closely involve your digital health lawyer in the negotiation and drafting of any new contracts during the anticipated recession, so that you can avoid entering into new contracts with otherwise avoidable vulnerabilities that might be exploited by an economically-motivated customer in the future.

All in all, working closely with a digital health contracts lawyer to anticipate and address potential customer renegotiation and termination tactics in a depressed economy can ensure that your digital health company will survive and thrive through a recession. Investing a few extra resources with a digital health contracts lawyer today can save your digital health company significantly later when customers look to attack vulnerabilities in your companies’ contracts to solve financial issues later in a depressed economy.

Talk with an Expert Series: Beau Fernald Shares Software Implementation Best Practices

Best Practices in Drafting Digital Health SaaS Contracts to Add & Retain Customers

What is digital health?
What constitutes a digital health contract?
What are the essential terms in a well-drafted digital health contract?
What are the key considerations you need to have in negotiating digital health contracts?
What are the common issues that arise in digital health contract negotiations?
What are the problems with digital health clauses that are most likely to cause a dispute?

The Prinz Law Office Adopts New Fixed & Subscription Billing Options

FTC Announces Settlement with Twitter Over Deceptive Use of Account Security Data

The Federal and Trade Commission (“FTC”) announced today a settlement with Twitter, Inc. (“Twitter”) in which Twitter agreed to pay $150 million for its alleged misuse of user account security data, specifically email addresses and phone numbers, for advertising purposes. The government alleged that the misuse of account data was in violation of a 2011 FTC Order against Twitter, which prohibited the company from misrepresenting the extent to which it maintains and protects the security, privacy, confidentiality, or integrity of any nonpublic consumer information. The government alleged that the misuse of consumer data also violated the EU-US Privacy Shield, and the Swiss-U.S. Privacy Shield.

The FTC press release is attached here. The complaint is attached here, and the stipulated order is attached here.

In addition to the paying a $150 million fine, the government announced that Twitter has agreed to the following:

Twitter will not profit from deceptively collected data;
Users will have other options to multi-factor authentication such as apps or security keys that do not require the provision of phone numbers;
Notify all users that Twitter misused the phone numbers and emails collected for targeted advertising and to provide users with information about Twitter’s privacy and security controls;
Implement and maintain a comprehensive privacy and information security program which requires an assessment of the potential privacy and security requirements of new products;
Limit employee access to users’ personal data; and
Notify the FTC if it experiences a data breach.

With this enforcement action against Twitter, the FTC is clearly making a statement to companies in the business of collecting consumer data that they need to truthfully disclose the purposes for which data used for advertising purposes is collected, and that failure to disclose this information will have potential federal regulatory consequences. Digital health companies should take note of this particular enforcement action, and ensure that they avoid engaging in the same practices that were the subject of this enforcement action.

Kristie Prinz Explains Why Not to Use the Term “SaaS License”

Arbitration vs. Litigation in Digital Health Contracts: Which Option is “Better”?

I was recently asked by a client whether arbitration or litigation was “better.” The issue had been raised by an attorney on the other side of the contract, who had not only tried to persuade my client to revise the specific clause in that case, but had also provided my client the unsolicited advice that “he should prefer litigation over arbitration” in all cases.

My client, who had elected to include an arbitration clause in his company’s standard contract terms, was unsure what to do and how to respond, and so he reached out to me for guidance.

While the debate over whether selecting arbitration or litigation as the preferred dispute resolution option for a particular organization is not a dilemma specific to the digital health industry, it is one that clients often raise with me in frustration, hoping that I can advise them that one option is definitively “better” than the other. The answer, like many things in the law, is not so black and white, and it should not be decided without considering the pros and cons of each option and the specific contract scenario you are addressing.

First of all, let’s assume you have no arbitration clause in your contract and a dispute arises, then the only contractually available forum to hear the dispute will be a courtroom. If your company does not have an in-house legal department with litigators on staff, then you will need to hire a litigation support to handle the litigation process, either from the plaintiff side or the defense side. You will incur costs every time a motion is filed or defended, and you will incur costs for discovery, depositions, mediation, and the trial preparation, all until the case is either settled or a judgment is reached. This process could take years to go through.

On the other hand, let’s assume you have an arbitration clause in your contract and a dispute arises, then the contractually available forum to hear the dispute will be a courtroom. However, your opponent may not want to arbitrate the case, and so your opponent may file in court first, in which case you will have to file to compel the case to arbitration. Alternatively, your opponent may be unwilling to participate in the arbitration, so you may have to file a motion to compel your opponent participate in the arbitration. Once you win any motion in court, you will then have to initiate the arbitration with the private organization that will handle the arbitration, which will generally be AAA or JAMS in the US, but there are other organizations that handle commercial arbitration internationally. This will require you to pay the filing fees, which are often far higher than is required to initiate a case in a court. Once the case is initiated an arbitrator will be appointed to hear the case, and the parties will decide on the format for the case, and the case will proceed outside of court within the private dispute resolution process of the organization selected.

What are the advantages? Well, arbitration is intended to be a commercial process rather than a legal process, so it is much less formal. It also can be faster, as there is no judicial backlog to slow down the process. There are fewer rules governing the process, so it often viewed as less predictable. But fewer rules also means that the process is more easily managed by business-people who are not litigators. The goal of arbitration is generally to get to a rendered decision as quickly as possible, which may be advantageous.

In contrast, the court option is very formal. It can be slow, which may be a negative in some situations and a positive in other situations. And it is governed by rules and precedent, which will require knowledge and familiarity with both to proceed through. Most litigated cases settled, so the goal of litigation may not be to get to a judgment. Instead, the goal may actually be to get to a settlement.

Is one option necessarily cheaper than the other? Arbitration is generally perceived in the business world to be cheaper, due to the faster process and the relaxed rules, but because the process is a private commercial process, the fees for the administration of the case can be higher in some situations and it is still possible to incur legal fees during the process. In contrast, discovery, depositions, and motion hearings can drive up the cost of a litigation process, both in terms of legal hours billed but also in terms of other costs.

It is important to recognize that getting an arbitration award may not actually be better than a mediated settlement to the party owed an award, since a voluntary settlement may be easier to enforce than a decision. On the other hand, the process is private and stays completely confidential and outside of court records, which may be preferred by both parties, and the informality may be less stressful on both sides of the dispute.

In the end, the choice between arbitration vs. litigation is one of personal or commercial preference. You have to expect that a commercial litigator who spends his career in the courtroom is going to prefer to stay as far away from arbitration as possible. In contrast, transactional lawyers are generally going to prefer to stay as far away from litigation as possible.

I generally recommend to clients that they should contemplate the type of dispute that would arise from a particular set of contract terms before deciding how they prefer to resolve that dispute. For example, if a dispute arises, would an informal private solution to resolving the dispute be better than the formality of litigation? Will the other side have significantly more resources to apply towards the dispute? Would the other side benefit from delaying the resolution of the dispute and causing you to invest significant resources in the process? What will be the anticipated filing fees for each side in the dispute?

All in all, arbitration vs. litigation is not a decision that should be made without some careful consideration of the underlying issues and the consequences of each decision. There are valid reasons why parties gravitate to one option or the other. It is up to your business to decide what should be your organization’s preferred standard with respect to a particular type of contract, and whether or not you will be willing to concede your position upon request by a particular client. You may realize that your preferred position is going to be the same in every case, or alternatively, that your position may require review on a scenario by scenario basis.

Introduction to Negotiating and Drafting SaaS Contracts

Introduction to Software Contracts Workshop for Lawyers

Intro to Software Contracts for NonLawyers

Date: May 23, 2022
Time: 9 a.m. PST
Price: $699 Register

How are software contracts unique from other business contracts? What do you need to know to negotiate them?

Silicon Valley Digital Health Lawyer Kristie Prinz will be teaching an introductory workshop on software contracts negotiation for nonlawyers. The virtual workshop will be interactive and participants will be invited to help direct the focus of the workshop.

In this workshop, she will address:

What are the key considerations you need to have in negotiating software contracts?
What are the key terms that need to be addressed in a software contract?
What are the primary causes of disputes in software contracts and how do you avoid them?
This workshop is intended for entrepreneurs and other non-lawyers who are negotiating software contracts and need a practical, interactive overview on how to negotiate these contracts.

Kristie Prinz is a Software, SaaS, and Technology Transactions Attorney based in Silicon Valley, who has been representing software and SaaS companies in technical transactions for 22 years. Prior to arriving in Silicon Valley, Kristie practiced law in Atlanta, Georgia. Kristie is a nationally-recognized speaker, media contributor, and author of the Silicon Valley Software Law Blog. Kristie is the founder of the The Prinz Law Office and the Silicon Valley Software Services Advisors Group. Kristie is also a graduate of Vanderbilt Law School and licensed to practice law in the states of California and Georgia.

This event is intended for developers, entrepreneurs and software company executives who do not have a law degree but are actively negotiating and draft SaaS agreements for their companies.

To register, please sign up here.

Introductory Digital Health Contracts Workshop for Lawyers

Introduction to Digital Health Contracts Workshop for Non-Lawyers

Introduction to Digital Health Contracts

Best Practices for Negotiating SaaS Contracts & Managing SaaS Customer Relationships

Legal Developments Impacting the Software Industry 2019

Best Practices for Negotiating SaaS Contracts & Managing SaaS Customer Relationships

Best Practices for Negotiating Master Services Agreements in an Uncertain Economy

Date & Time: April 6, 2020, 10-11:30 a.m. PST
Price: $125 Early Bird, $150 General Admission, $175 Last Minute & On-Demand Register on Eventbrite

With the rapidly developing changes affecting businesses due to the worldwide spread of the coronavirus infection, and the widespread fear of the potential economic fallout, what are some of the best practices your business should be implementing immediately in negotiating master service agreements with customers and service providers?

The Prinz Law Office is sponsoring a webinar on “Best Practices for Negotiating Master Services Agreements in an Uncertain Economy” which will provide an overview on how companies should approach the negotiation of master service agreements (“MSAs”) in the current economic climate, and steps you can be taking to protect your business in uncertain times. At this webinar, you will learn the following:

What terms should be in a well-drafted MSA?
What special concerns do you need to address in uncertain times?
What steps can you take to protect your company against the risks of doing business in uncertain times?

Silicon Valley Tech Transactions Lawyer Kristie Prinz will be presenting this webinar. Ms. Prinz is a technology transactions attorney in Silicon Valley who has been representing early stage and mid-market technology companies for more than 21 years. Ms. Prinz is a nationally-recognized speaker, media contributor, and author on software, technology, and intellectual property-related issues. She publishes the Silicon Valley Software Law Blog and the new Silicon Valley Privacy Law Blog. Ms. Prinz is a graduate of Vanderbilt Law School and is licensed to practice in the states of California and Georgia.

This program is intended for in-house counsel and attorneys, as well as IT professionals, consultants, and other businesspeople working in the technology industry.

Negotiating Consulting Services Agreements in an Uncertain Economy

Introduction to Negotiating & Drafting SaaS Agreements

Digital Health Lawyer Kristie Prinz Presents on Negotiating Digital Health Contracts

Drafting Problems with Fee Terms in Digital Health Contracts

When a client sends me a digital health software agreement to review or update, I always make a priority of reviewing any terms in the contract involving fees and then carefully reviewing the website and any marketing materials or fee schedules to confirm that the fee terms in the contract clearly match the fees listed outside the contract. Then, I will also confirm that the contract terms clearly articulate how the fees listed on the website and in other marketing materials or a fee schedule are to be calculated. I have generally found it to be rare for the contract terms and website, marketing materials, or fee schedule to match. More often than not, it is clear upon review of all of the supplemental materials that the fee terms of the contract are poorly drafted and make no sense.

So, what are some of the usual discrepancies that I will find?

One common issue I often see is that the marketing materials or the fee schedule suggest that the license or subscription fees are being calculated according to the number of authorized users, but there are no terms in the contract to explain what constitutes an authorized user, what rights the authorized users obtain through the license or subscription, whether authorized users are made available in blocks of users or individually and for what fees, or how you would add or drop authorized users. Whether your contract is a license or a SaaS subscription, just listing the total fees and total users and not drafting contract terms describing the relationship between the licensee and users or subscriber and users and how that relationship works is completely inadequate. Those terms need to be clearly defined in the contract and not just in marketing materials.

A second issue that I frequently come across upon review is that the marketing materials or fee schedule suggest that there are multiple types of software licenses or SaaS subscriptions being offered to the customer, each of which provides different levels of functionality or services for a different fee, but the terms of the contract only reflect a single level of functionality or services and provide no clarification as to what functionality or services are comprised by that single offering. Whether the contract is a software license or a SaaS subscription, the contract always needs to define the scope of the license or subscription being offered for a particular fee, and if multiple options are being made available for different fees, the contract needs to carefully describe the base option extended and the add-on option extended and how the various options and the applicable fees work.

A third issue I frequently come across upon review is that a fixed fee amount for “professional services” is listed in the fee schedule or marketing materials. However, often the terms of the contract are completely silent on what professional services are being provided under the software license or SaaS subscription, what the hourly or project rate is for the services and how many hours are being provided, or any other clarification about what constitutes the “professional services” to be provided under the agreement. Moreover, it’s generally unclear as to how fees would be billed for additional professional services.

In general, the problem with many contracts is that companies are relying on marketing materials and fee schedules to justify fees that are never explained in the contract terms. However, the contract terms are what is binding on the customer–not the marketing materials, vague fee schedule, or other supplemental documents. So, clearly, digital health software companies need to exercise the same sort of drafting caution that I exercise in my reviews, and go through each and every marketing material and fee schedule to confirm that any fee described is carefully explained in the terms of the contract. Where disparities exist, companies need to identify those disparities and revise their contract terms to address the issues. When they fail to exercise such care in their drafting, they significantly increase the risk of future customer disputes.

Why Digital Health Companies Should Plan for Customer Negotiations over Insurance Requirements

If your digital health company is like most, you postpone the procurement of insurance policies until you absolutely have to obtain them, expecting to be able to obtain whatever you need on demand. You likely do not consider that not having certain insurance in place may delay the signing of your next big customer contract.

However, if you anticipate negotiating a significant customer contract soon, you should be anticipating your needs in advance of actually starting those negotiations, or you may find yourself in a situation where you have to commit to maintaining insurance during the relationship that you may not actually be able to buy on the open market. Why is this a problem? Well, this puts you in the position of potentially breaching the terms of the “significant” deal before you ever start performing those terms, which can obviously have serious consequences for your company’s business if your breach is ever discovered. Since the usual insurance terms in these types of deals require the submission of certificates of insurance as proof of coverage, any failure to procure the insurance required is not likely to stay undiscovered for an extended period.

Notwithstanding the foregoing, even if you do not breach the terms of the negotiated deal, it is far better to negotiate the scope of indemnification risks you will be incurring with advance knowledge of the terms of the insurance policies you already have in place, as you can then negotiate limits of liability within the coverage of the insurance coverage previously obtained.

So, what types of insurance requirements should a digital health company anticipate when it goes to negotiate a significant deal?

First and foremost, companies should anticipate the requirement of a general commercial liability policy. This is a standard commercial insurance policy that every business, regardless of whether or not in the software industry, should keep.

Second of all, companies should anticipate the requirement of a commercial auto insurance policy to cover the risk that employees or contractors may have an accident while traveling back and forth to a customer or business partner’s work site.

Third of all, companies should anticipate the requirement of an errors & omissions policy to cover the risk that company workers will intentionally or negligently act in a way that harms the customer or business partner.

Fourth, companies should anticipate the requirement of a cyberinsurance policy to cover the risks of hack attacks, data breaches, and third party cybercrimes, as well as notification costs and other costs to remedy a breach after it occurs.

Fifth, companies should anticipate the requirement of an umbrella policy to cover losses in excess of the insurance limits available.

What types of limits of coverage should a digital health company anticipate? In my experience, larger deals will come with larger expectations, so the more significant the deal, the more insurance your company should be lining up in advance.

The bottom line is that doing some advance planning with respect to insurance before your software company commences negotiations on a significant deal will save your company the worry down the road of being discovered to be in breach of the deal you just closed if you find that meeting the insurance requirements you agreed to is not quite as easy as you anticipated. Furthermore, it will enable you to go into negotiations better prepared to be able to negotiate terms that actually protect your company.

Key Mistakes Companies Make in Negotiating Digital Health Software Contracts

What are the key mistakes companies make when negotiating digital health software contracts?

First and foremost, the most common mistake I run into negotiations is that companies often end up negotiating with the wrong contract as the starting point. For example, the parties may negotiate from a software license template when they need a SaaS agreement template instead, or they may negotiate from a master services agreement or a hosting agreement when the deal they were doing actually involved SaaS terms. I have also seen parties negotiating from an end user license agreement when they needed a SaaS agreement. A knowledgeable digital health software attorney will know and understand that the terms of a well-drafted template will be completely different based on the digital health technology model under negotiation and will be able to ask the right questions in order to identify the right technology model and therefore the necessary baseline terms that need to be addressed in a well-drafted agreement.

Another common issue I run into is that even if the parties choose the right initial type of contract to begin the negotiations with, they begin the negotiation with a template that was designed for an entirely different digital health product or relationship than what is currently being contemplated. Obviously, it is going to require less negotiation to reach a good deal when the starting point for the negotiation is a set of proposed terms that applies to the right type of transaction and the particular product or relationship under negotiation. Also, the terms of the signed contract are far more likely to be meaningful when they were developed around the right digital health product and services. Otherwise, they are likely not to include the key deal terms or contemplate any of the issues that could come up between the parties. I see many signed contracts that are little better than a handshake because the terms agreed to are almost completely irrelevant to the transaction. An experienced digital health software attorney is going to be able to ask the right questions to determine whether the contract terms were written for the appropriate product or services.

A third issue I run into is that the contracts do not sufficiently contemplate how the relationship will evolve over time. A standard practice in the industry is to rely exclusively on a list of prices to determine on the fee-related issues in the agreement. What is typically missing is all the terms that explain how the pricelist will be implemented. While this might not be fatal to the relationship if there is some sort of initial agreement on the price to be paid overall, few digital health business relationships are up-front, fixed price relationships. Most relationships now are intended to generate recurring revenue streams and anticipate new fees as new seats, services, and functionality are added. So, a mere pricelist is almost never adequate to support an ongoing relationship. Thus, if an experienced digital health software attorney is not involved with the deal, there is a high likelihood that the contract signed will not have all the necessary terms to explain precisely how all the fees will be assessed going forward.

A fourth issue typically overlooked are all the technical concerns about the transaction. In many digital health software deals, the service level is absolutely critical to the transaction. However, more often than not, the service level agreement being relied on by the parties was copied off the Internet and has absolutely no significance or relevance to the service being offered or provided. Also, even where the service level agreement was obtained in a more thoughtful way, it is very common to find the agreement full of terms that are so poorly written or that have so many carve-outs that it is completely unenforceable. In addition, many relationships contemplate the performance of a variety of services which are never addressed in the contract at the technical level required to reach any sort of understanding regarding those services. An experienced digital health software counsel will be able to ask the right questions to understand all the technical aspects of the deal between the parties and will be able to determine all the terms that have been omitted from the contract before it is executed.

A fifth issue typically missed is the contemplation of all the issues that could arise with regard to the suspension of services. The service provider frequently has the ability to “suspend” a company’s access to the software and the data stored therein at any time and could just as easily erase all of that data. However, few contracts that I see really address the issue of suspension at the level required to address all possible issues that could arise between the parties. An experienced digital health software counsel will ask the right questions to identify these issues and address them in the contract.

A sixth mistake that I often encounter is contracts that contain elaborately negotiated indemnification clauses but never really contemplated all the related issues such as whether the indemnification could ever be enforced and whether the focus of the indemnification clause negotiated was on the liabilities most relevant to the transaction. An experienced digital health software counsel will be knowledgeable about software indemnification clauses and all the issues relevant to the clauses in order to ensure that the maximum amount of protection is in place.

The bottom line is that an experienced digital health software counsel understands technology sufficiently to ask enough questions about the relationship envisioned to determine all the key terms that were never contemplated in the agreement, and can add that additional level of skill and expertise to the negotiation of the deal that a general business lawyer or business person simply cannot. Technology deals are fundamentally technical and only someone that understands technology and technical deals sufficiently is going to be able to evaluate proposed terms sufficiently to negotiate them appropriately in order to look after the party’s best interests.

Is Your Digital Health Agreement Silent on Implementation?

If your digital health company is like most companies these days, you likely set up a software interface and train your customers on how to use the product at the very beginning of the relationship. You probably even charge some sort of fee for these initial services that you provide. And the set-up process may run anywhere from days to weeks to complete.

Moreover, if you are like most companies, you are probably relying on an agreement which is either completely silent or almost completely silent on the specifics on how this “implementation” phase of the relationship will work, except for all of the fees you will be charging for the services. And you probably are charging your customer other fees on top of the implementation fees while the implementation process is ongoing.

If this sounds familiar, you are likely committing one of the most common contracting mistakes I see: leaving your company extremely vulnerable to a dispute over the implementation phase of your company’s services.

Now, I know it is easy to say “I’ve always done things this way and I’ve never had a dispute.” I hear this from clients frequently as well as the argument “This is the real world. We don’t have the time to spend on such issues. You are just overlawyering.” However, from my side of the desk, whenever there is a customer dispute over any software product, it virtually always involves a dispute over an implementation process and the financial obligations tied to that implementation process.

Why is this? Well, companies are largely using overly simplistic contracts to sign up their customers. When they hire an attorney to draft a customer agreement, they tend to retain the services of an attorney who lacks industry-specific knowledge about drafting these contracts and who fails to ask the right questions about the company’s business model or set-up practices. And, in the rare cases where the company actually does retain a knowledgeable attorney, the company may discount the importance of addressing the implementation process in the contract and not provide to the attorney the necessary information regarding the implementation process in order to enable the attorney to draft the appropriate terms required in the contract.

If you wonder what the “real-world” consequences are of this approach, they are as follows: if something changes at your customer’s company while implementation is continuing, your customer will likely call up an attorney like me to find a way to terminate your contract for material breach, and the attorney will raise the issue on the fact that the agreement is silent on implementation. And then the customer may start claiming you breached the contract.

What can your digital health company do to avoid running into problems over implementation?

First of all, if you sell a digital health product that your customer cannot immediately utilize upon the execution of the contract, you need to make certain there are well-drafted, company-specific terms regarding your implementation process in your contract. Those company-specific terms should address such issues as the specific milestones for your implementation process, what will constitute the successful performance of each milestone by the company, what date each milestone will be completed, and what steps are required from the customer during the process and whether failure to perform any step constitutes a material breach or changes the company’s implementation obligations in any way.

Second of all, if your digital health company will charge the customer fees for the implementation process or during the implementation process, your contract needs to contemplate how the fees are deemed “earned” in relation to the implementation services performed. It is not uncommon today to see contracts where hundreds of thousands of dollars are being exchanged during the implementation period, but if the contract does not actually articulate how those fees are earned by the digital health company, it could be argued that the fees were not actually incurred until the implementation process is complete and the customer provides final approval to the successful implementation. Also, if the contract is drafted in such a way that fees are being charged for services and functionality that are unavailable until a future date, this could be used against your company in a dispute to allege the occurrence of a material breach.

Third, if the customer is promised “training” as part of the implementation process, the specific terms of the exact training extended to the customer should be carefully defined. Does the “training” constitute pre-recorded webinars made available over the Internet, or does it constitute live, on-site, seminars taught by instructors on a particular date? Who can attend the “training”? When can they attend? How long will the training sessions last? What will be taught in the training sessions? Who absorbs the fees to provide the training sessions? What happens if the training sessions do not happen as scheduled? It is not uncommon for disgruntled customers to argue that they did not receive the training promised to them and that they were therefore unable to use the software as promised, and argue that this failure constituted a material breach.

The bottom line is that if your customer agreement fails to provide detailed, company-specific terms on implementation and your digital health company does in fact have an implementation process that is necessary before a customer will “go live” with your product, then you are leaving your digital health company vulnerable to potential customer disputes. Taking the time to draft the appropriate customer contract terms before you retain a new customer can significantly reduce your digital health company’s risk of a very costly customer dispute down the road.

How to Recognize a Poorly Written Digital Health Contract

In my experience, the first sign of a poorly drafted digital health contract is that contract completely confuses the software licensing and SaaS technology models, so that it’s extremely unclear as to what kind of product that the software provider is actually selling. If the product is a software license, the contract should contain a clear license grant confirming the licensee’s rights in the intellectual property and defining the scope of the license. Any hosting, maintenance, technical support, or other services should be made available by separate written agreement (i.e. hosting contract, maintenance contract, technical support contract, professional service contract) but should not be included in the face of the license agreement. On the other hand, if the product is a SaaS agreement, no license grant should be included in the contract and the contract should instead contain a clear grant of access and use rights. The terms “licensor” and licensee” should be absent from the contract. On the other hand, services like hosting and maintenance will generally be included in the contract as the bundle of services provided to the subscriber via subscription, as well as other services such as back-up, disaster recovery, technical support, and transitioning services. In addition, a SaaS agreement will generally include a service level agreement and an acceptable use policy, and it will address the policies and procedures taken to ensure the security of the platform. These technology models are very clear and defined technology frameworks. If the contract merges and mixes up the models, then this is a good indication that the contract is poorly drafted.

A second sign of a poorly drafted digital health contract is that the contract fails to discuss the concept of “users” and how they are granted, and just refers to an invoice or schedule that lists a number of “users” and assigns a price to that number. Both software licenses and SaaS agreements can provide rights to “users” but the license grant or the access rights grant needs to contemplate “users” in terms of who is authorized to be a “user” and what rights are provided to a “user”. In addition, the contract should explain how users are made available (i.e. individually or in increments), how they can be increased or decreased during the term or a renewal period, and the costs of each user or the user increments. Where users are not addressed in the contract and are only referenced in a schedule, they don’t actually have any rights in either the software or the services and so it’s unclear what is actually being sold by a provider.

A third sign of a poorly drafted digital health contract is that the contract provides for periodic rather than up-front billing but fails to address what happens when those periodic payments are late. Is suspension employed at some point after the payment is late? If so, what kind of notice is provided and how is that notice delivered? Is the data still accessible after suspension? If so, what kind of fee is assessed for removing the data after suspension and in what format is it removed? If the data is in the cloud, how fast is it purged? A well-drafted contract contemplates the potential relationship problems that might arise and defines how those scenarios will be handled rather than leaving them to be dealt with in the future.

A fourth sign of a poorly drafted digital health contract is that the contract fails to set customer expectations about either the functionality and features of the software in the case of a software license or, alternatively in the case of a SaaS contract or other software services contract, the quality and nature of the services that will be provided. In software services contracts, the value of the relationship is entirely tied to what is being delivered. Hosting contracts and SaaS agreements should generally have service level agreements which carefully define the service level being provided, provide a guaranty as to uptime and define any exceptions to that uptime, and provide a service credit that can be easily applied in a service failure. They should also address in detail the backup services being provided, the security services employed to keep the host or SaaS platform secure, and the disaster recovery services, as well as any transitioning services made available and how those work. Technical support is going to generally be available in software licenses, hosting contracts, and SaaS agreements, so is all of these cases how those services will work will need to be carefully defined. The bottom line is that these services relationship should be defined in detail and not left for future interpretation. A poorly drafted contract is going to be very unclear about what the software provider is providing under the relationship, which creates enormous opportunities for disputes to arise, since there may not really be anything agreed upon in the contract.

A fifth sign of a poorly drafted digital health contract is that the contract fails to define specifically what version or module of the product the contract even applies to. Few vendors sell a single product without at some point making available optional features and services that can be “added on” for an additional charge. Many, if not most, contracts fail to fully describe the functionality, features or services that the contract applies to, which creates the potential for disputes as new functions, features, services, and/or products are made available, as the scope of what the original agreement applied to is simply not clear.

Finally, a sixth sign of a poorly drafted digital health contract is that the contract fails to contemplate and set expectations about what will be required for implementation, how long it will take, what would constitute a successful implementation, what milestones would arise in the implementation and how it would be verified that they were successfully performed, and any responsibilities the customer must meet at defined steps in the process. In multiple user scenarios and in many data-focused software products, implementation is a lengthy and very involved process, yet most software contracts are completely silent about implementation. This sets parties up for disputes over implementation. A poorly drafted contract is going to leave customer expectations for implementation largely undefined.

This list is certainly not exhaustive but provides some guidelines for what to look for in order to identify a poorly drafted digital health contract.

In summary, a digital health contract should provide significant clarity on the product or services being sold so that a layperson should be able to understand from the terms how the product or service will work and what kinds of expectations he or she should have about the product or service, the applicable fees, any set-up required, etc. If a contract raises more questions than it answers, then this is a fairly strong indication that the contract is poorly drafted.

Is your Digital Health Software Company Signing Customers to Contracts Based on the Appropriate Contract Model?

Is your digital health software company signing customers to contracts that are based on the appropriate technology contracting model?

In digital health contracts (as in software contracts generally), perhaps the single most common issue that gets confused is the difference between a software license and a software-as-a-service agreement. But the concepts are very different. In a software licensing model, the digital health company offers a physical piece of software via cd-rom or electronic download from a website to be downloaded, installed, run, and operated on a piece of hardware that is typically physically on site at a particular company or residential location. There may be one user or multiple users of the software. The software may be installed on a single piece of hardware or multiple pieces of hardware. There may be services associated with the software that are offered to the licensee such as implementation, customization, training, maintenance, and technical support. In some cases, the company may even offer separate hosting services. However, the digital health software itself is made available to the licensee as a tangible product.

What is different about the software-as-a-service model? In the SaaS model, the digital health company generally makes no tangible software product available to its users, and the product itself is only available “on the cloud” as a hosted platform. As in the licensing model, there may be one user or multiple users of the platform. But the platform itself is only accessible through the cloud. Thus, the quality of the various services provided is critical because the ability to access and use the hosted platform is entirely dependent on the quality of the experience delivered. In the SaaS model, there is no separate maintenance service provided because that is all expected to be included as part of the hosted platform service package, along with the hosting and technical support. You may still have separate implementation, customization, and training services, however, that are made available separately from the hosted platform. The key feature of this model, though, is the very fact that you are offering a “service” model rather than a “tangible product” model.

What is the primary issue I see contractually? More often than not, companies say they are offering a “SaaS” model but their contract is in fact based on the software licensing model. What alerts me to this fact? Usually it’s the presence of a license grant to the software and the lack of any clauses explaining all the various services provided pursuant to the platform. It’s also not uncommon to see a maintenance agreement attached to the agreement, which is not what I typically expect to see in the hosted platform model. Also, there is often a lack of attention to any of the issues or concerns that you would have in a model where you never receive a physical product, and where you have absolutely no control over data security, your ability to save or download the data on the platform, or how well you can access the platform in the first place. Another problem that you may see is a lack of concern over how you are charged for accessing the model when some sort of set up process is involved. Obviously, if you are being charged on a monthly basis for accessing a platform and a set of related services, you don’t want to be charged until set-up is complete and you can access the platform and immediately use it. This is less of an issue in a licensing model where the fee is usually billed once and not charged again during the life of the product.

The bottom line is that these two models are very distinct business and technology models and the contract will absolutely not be correctly set up if the appropriate technology model is not determined and/or understood in advance of drafting. The same is true in contract reviews: it is impossible to provide accurate feedback in reviewing a contract if the technology model is not thoroughly understood before the review is started. Everything starts with the technology model.

So, if you retain an attorney like me to work with your digital health company on contracts and you are asked about your technology model, be prepared to answer the question. Thoroughly sorting out the terms as they relate to the model is critical to the proper drafting or proper revision of your contracts, and spending billable time on this issue is time very well spent, as the job cannot be done properly otherwise.

When does a Digital Health Company need a Service Level Agreement?

I often find that many digital health companies are unfamiliar with the concept of a service level agreement and have no idea when they might need one.

A “service level agreement” or “SLA” is a technical agreement that defines that parties’ expectations of the level of service that will be provided in a particular service provider relationship and establishes how a customer will be compensated if the service at any given time does not meet the expectations as defined in the agreement. It is usually drafted as a schedule to another agreement such as a master service agreement (“MSA”), software services agreement (“SaaS agreement”) or hosting services agreement rather than standing alone as the sole agreement defining a relationship between two parties. In the digital health industry, I would expect to see a service level agreement present in any agreement involving a software as a service (“SaaS”) or hosting relationship; however, a service level agreement could be appropriate in other tech-related service relationships as well, in which metrics or standards for the delivery of the service mattered to the customer and not just the accomplishment of a particular service milestone. For example, a “service level agreement” might be appropriate in a business relationship with a provider of Health Information Technology (“HIT”) services, in a back-up or disaster recovery relationship, or in a data service relationship–these are all scenarios where a customer might have expectations beyond merely whether a particular task was performed or not that one or both parties might want to address in a separate service level agreement.

If you are questioning why it is customary to have a “service level agreement” and not just rely on a standard warranty or material breach clause, consider this: if an interruption in service occurs with a particular relationship and then resumes for any reason, does either the consumer or the provider really want to treat that interruption as a material breach and terminate the relationship? In many cases, the answer is “no.” From the provider’s perspective, the interruption may very well have affected its entire customer base, so of course, the provider doesn’t want to go out of business over a single incident. At the same time, it is frequently not in the consumer’s best interest to treat an interruption as a material breach either. The consumer may believe the service provider is the best provider in its industry to deliver a particular service, either because of the pricepoint, the technology or service offered, or the reputation of the particular provider. Also, the cost in terms of time and resources of finding an alternative provider might be higher than the consumer is willing to take on at that time. There might be no other alternative to the particular provider, or the financial costs of changing providers could be too high. Obviously, there may be legal consequences as well in terms of the cost and expense of enforcing a warranty clause and terminating a contract for material breach that could easily dissuade a particular consumer against exercising such rights.

Thus, for all of these reasons, a “service level agreement” or “SLA” is frequently relied upon by knowledgeable service providers and customers to define the parties’ expectations about the delivery of a particular technical service and to provide an alternative mechanism for compensating service failures outside of the standard warranty/breach framework. Where no such agreement exists, the parties often have no real expectations defined for the service, which more often than not will eventually bring a premature end to the relationship.

What types of terms should you expect to find in a “service level agreement” or “SLA”? As with most technical agreements, it is my view that the terms in a particular service level agreement need to be tailored to the particular relationship between two parties and not just copied from a third party’s agreement, so no single set of terms will be appropriate in all cases. For example, if you are a digital health SaaS company and you rely on a third party to host your software, then the service level agreement you adopt needs to contemplate the service level agreement terms of the third party hosting your software and not be written independently of the hosting relationship. If you are procuring another technical service, you should make sure that the service level agreement reflects the expectations of your business or your customer base. If you don’t have expectations for what you are buying, then you need to do your homework and talk to an attorney, competing service providers, other businesses, etc. to understand the problems you might run into with the particular service and understand what expectations are reasonable for the particular service being procured. The worst drafting mistake you can make in adopting a particular set of terms for a service level agreement is to simply use a third party’s terms rather than customize the terms to the particular relationship, since the third party’s terms will likely have no relevance to your relationship. Having said this, there are some terms that are commonly found in service level agreements. These include such concepts as as “service availability,” “exclusions,” “scheduled downtime,” “uptime,” “service level guarantee,” “service credit,” “business hours,” “priority response times,” and “service level reporting.”

The bottom line is that if you are on either side of a technical service relationship, it is important to consider whether a service level agreement might be advisable to define the parties’ expectations for the relationship beyond just whether or not a particular service is performed. There are no single set of terms that should be adopted in all scenarios, but you need to be knowledgeable enough about what you are buying or selling to develop clear expectations in advance of the commencement of the relationship. As a digital health company, you are both a buyer and seller of services, and therefore it would be prudent to define expectations for the service not only with your customers but also with your service providers, so that you obtain the services required to meet your customer’s expectations as well.

Private Coalition of Health Insurers and Major Tech Companies Announce New Standard for Claims Data Sharing

The CARIN Alliance, which is a coalition of companies from the health and tech industries, has just announced the release of a new standard for sharing health claims data in conjunction with the Blue Button Developers Conference. The announcement is linked here.

The newly released standard is linked here: CARIN Blue Button Implementation Guide CI Build.

According to FierceHealthcare, the standard was developed by working group comprised of alliance members and includes more than 240 claim data elements. FierceHealthcare reports that 20 organizations, including Apple, Anthem, Blue Cross Blue Shield, Cambia Health Solutions, Google, and Humana have agreed to test an application programming interface (“API”) employing the standard in anticipation of a product lunch of the standard next year.

CNBC reports that the significance of the news is that this is the first time that industry has agreed to standards for sharing claims data to third party developers, and the Alliance aspires not only to make the data available to consumers but also to provide fraud detection functionality and functionality to help consumers avoid paying bills with errors in them.

FierceHealthCare reports that the new standard “builds” on Blue Button 2.0, which was released by the Centers by Medicare and Medicaid Services (“CMS”) last year and is an API enabling Medicare beneficiaries to access to their Medicare claims data. A web page dedicated to Blue Button 2.0 is linked here. FierceHealthCare reported on the Blue Button 2.0 initiative by CMS here.

Obviously the development of new digital health standards is a victory for the digital health industry, which has arguably been slow to develop industry standards along the lines of what exist in the tech industry generally.

For more information on how to join The Carin Alliance, click here. For a list of alliance members, please click here.

Is Digital Health Software Subject to FDA Regulation?

If you work in the software industry, you may be surprised to discover that digital health software products may be subject to regulation by the Food and Drug Administration (“FDA”). Some software is considered a software as a medical device (“SaMD”) product or software in a medical device (“SiMD”) product.

So, how do you know whether or not a digital health product you are building is going to be considered a SaMD or SiMD product?

The FDA issued a “Policy for Low Risk Devices” on September 27, 2019, which provides general nonbinding recommendations to clarify its policy on health software that has been deemed not to be a device under Section 201(h) of the FD&C Act. In this policy, the FDA specifically stated that software intended “for maintaining or encouraging a healthy lifestyle and is unrelated to the diagnosis, cure, mitigation, prevention, or treatment of a disease of condition” does not constitute a “device” under section 201(h) of the FD & C Act. According to the FDA policy, general wellness products will not be examined to determine if they are devices and comply with the regulatory requirements for devices. The FDA further defines general wellness products to include products meeting the following requirements: (1) they are intended for only general wellness use as defined in the guidance and (2) they present a low risk to the safety of users and other persons.

In the Policy for Low Risk Devices, the FDA states that a “general wellness product” has the following:

(1) an intended use that relates to maintaining or encouraging a general state of health or healthy activity, or

(2) an intended use that related 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.

The FDA then provides examples of the specific types of uses that would fall under each category.

The FDA also states the test for assessing the degree of risk for general wellness products:

(1) Is the product invasive?

(2) Is the product implanted?

(3) Does the product involve an intervention or technology that may pose a risk to the safety of users and other persons if specific regulatory controls are not applied, such as risks from lasers or radiation exposure?

If all of the above answers are “no,” then the product is deemed to be low risk and not subject to FDA regulation.

The FDA also issued a “Policy for Device Software Functions and Mobile Medical Applications” on September 27, 2019, which provided nonbinding recommendations for regulation software applications intended for use on mobile platforms or on general purposes computing platforms.

In the “Policy for Device Software Functions and Mobile Medical Applications” the FDA clarified that it intended to focus its regulatory oversight to “only those software functions that are medical devices and whose functionality could pose a risk to a patient’s safety if the device were to not function as intended.” The FDA listed three categories of software functions that would be subject to this regulatory oversight focus:

(1) Software functions that are an extension of one or more medical devices by connecting to such device(s) for purposes of controlling the device(s) or analyzing medical device data.

(2) Software functions (typically, mobile apps) that transform the mobile platform into a regulated medical device by using attachments, display screens, or sensors, or by including functionalities similar to those of currently regulated medical devices.

(3) Software functions that become a regulated medical device by performing patient-specific analysis and providing patient-specific diagnosis, or treatment recommendations.

The FDA also clarified that it intended to exercise enforcement discretion for software functions that “help patients. . . . self-manage their disease or conditions without providing specific treatment or treatment suggestions” or “automate simple tasks for health care providers.” The FDA listed four categories of software functions that would be subject to this regulatory enforcement discretion:

(1) Software functions that provide or facilitate supplemental clinical care, by coaching or prompting, to help patients manage their health in their daily environment.

(2) Software functions that provide easy access to information related to patient’s health conditions or treatments.

(3) Software functions that are specifically marketed to help patients communicate with healthcare providers by supplementing or augmenting the data or information by capturing an image for patients to convey to their healthcare providers about potential medical conditions.

(4) Software functions that perform simple calculations routinely used in clinical practice.

The FDA also provided a list of categories of software functions that are not medical devices:

(1) Software functions that are intended to provide access to electronic “copies” of medical textbooks or other reference books with generic text search capabilities.

(2) Software functions that are intended for health care providers to use as educational tools for medical training or to reinforce training previously received.

(3) Software functions that are intended for general patient education and facilitate patient access to commonly used reference information.

(4) Software functions that automate general office operations in a health care setting and are not intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease.

(5) Software functions that are generic aids or general-purpose products.

(6) Software functions that are intended for individuals to log, record, track, evaluate, or make decisions or behaviorial suggestions related to developing or maintaining general fitness, health, or wellness.

(7) Software functions that enable individuals to interact with EHR software certified under the ONC Health IT Certification Program.

(8) Software functions that provide patients with simple tools to organize and track their health information.

(9) Software functions that provide easy access to information related to patients’ health conditions or treatments.

(10) Software functions that provide patients with simple tools to organize and record their health information.

(11) Software functions that are specifically marketed to help patients document, show, or communicate to providers regarding potential medical conditions.

(12) Software functions that enable, during an encounter, a health care provider to access their patient’s personal health record (health information) that is hosted on a web-based or other platform.

(13) Software functions for health care providers certified under the ONC Health IT Certification Program, such as those that help track or manage patient immunizations by documenting the need for immunization, consent form, and immunization lot number;

(14) Software functions that help asthmatics record (i.e. collect and log) inhaler usage, asthma episodes experienced, location of user at the time of an attack, or environmental triggers of asthma attacks;

(15) Software functions certified under the ONC Health IT Certification Program that prompt the health care provider to manually enter symptomatic, behavioral, or environmental information, the specifics of which are pre-defined by a health care provider, and store the information for later review;

(16) Software functions that record the clinical conversation a clinician has with a patient and sends it (or a link) to the patient to access after the visit;

(17) Software functions that allow a user to record (i.e. collect and log) data, such as blood glucose, blood pressure, heart rate, weight, or other data from a device to eventually share with a health care provider, or upload it into an online (cloud) database, or personal or electronic health record (PHR or EHR, respectively) that is certified under the ONC Health IT Certification Program;

(18) Software functions that enable patients or health care providers to interact with PHR systems or EHR systems that are certified under the ONC Health IT Certification Program;

(19) Software functions that meed the definition of Non-Device-MDDS, which are functions solely intended to transfer, store, convert formats, and display medical device data or results, without controlling or altering the functions or parameters of any connected medical device.

(20) Software functions that display patient-specific medical device data.

(21) Software functions that are intended for transferring, storing, converting formats, or displaying clinical laboratory test or other device data and results, findings by a health care professional with respect to such data and results, general information about such findings, and general background information about such laboratory test or other device, unless such function is intended to interpret that data, results, and findings.

The policies provide much more detail about the scope of the regulatory authority to be exercised over software than what can be captured in a blogpost, but this overview at least summarizes the key points of the guidance.

If you are developing a digital health software product, you will want to carefully consider how the FDA will classify your product, and you will likely want to consult with an attorney who focuses in this niche. FDA legal practice is a narrow practice niche which includes a small circle of attorney practitioners, so it may be challenging to find a lawyer who practices in this specialty area outside of Washington, D.C. It is possible that a medical device patent attorney in your area may have this expertise or may be able to make a good referral for you, so that is a possibility you may want to explore.

What is the Concept of “Digital Health”?

What is the concept of “Digital Health”? If you work in the field and are still unsure of how exactly to define the term, then you are in good company: while there seems to be some consensus regarding what is included in the concept of “Digital Health,” there is still some confusion on the scope of everything that is included under the “Digital Health” umbrella.

The Food and Drug Administration (“FDA”) has attempted to answer this question by defining “Digital Health” to broadly include mobile health, health information technology, wearable tech, telehealth, telemedicine, and personalized medicine.

In contrast, the World Health Organization (“WHO”) provides a slightly different definition of “Digital Health” defining it to constitute “e-health” and emphasizing instead of the areas of technology encompassed in the term the themes or goals of the “Digital Health” movement: strengthening health systems and public health, increasing equity in access to health services, and working towards universal health coverage.

A quick search of the Internet will quickly generate many other slightly different definitions of what actually encompasses the term “Digital Health.”

So, the truth of the matter is, if you are unclear what the parameters of “Digital Health” really are, you are not alone. In all honesty, I am not completely clear as to what the current industry thinking is on how the concept of “Digital Health” and the concepts of “Health Technology” and “Medical Technology” overlap with one another. The best answer is probably that the term “Digital Health” is evolving as the technology itself continues to develop.

For the purposes of the Silicon Valley Digital Health Blog, when we talk about “Digital Health,” we will be talking about the apps, software, SaaS products, and digital devices employing and connecting with this software for wellness, medical, and health care purposes.

Silicon Valley Digital Health Law Blog’s Kristie Prinz to present on “Introduction to Negotiating & Drafting SaaS Agreements”

Best Practices for Negotiating SaaS Agreements in an Uncertain Economy

Best Practices for Negotiating Development Agreements in an Uncertain Economy

Date & Time: April 13, 2020, 10-11:30 a.m. PST
Price: $125 Early Bird, $150 General Admission, $175 Last Minute & On-Demand Register on Eventbrite

With the rapidly developing changes affecting businesses due to the worldwide spread of the coronavirus infection, and the widespread fear of the potential economic fallout, what are some of the best practices your business should be implementing immediately in negotiating software, website, and technology development agreements?

The Prinz Law Office is sponsoring a webinar on “Best Practices for Negotiating Development Agreements in an Uncertain Economy” which will provide an overview on how companies should approach the negotiation of development agreements in the current economic climate, and steps you can be taking to protect your business in uncertain times. At this webinar, you will learn the following:

What terms should be in a well-drafted development agreement?
What special concerns do you need to address in uncertain times?
What steps can you take to protect your company against the risks of entering into development transactions in uncertain times?

This program is intended for in-house counsel and attorneys, as well as developers, consultants, and other businesspeople purchasing or performing development services.

Silicon Valley Digital Health Law Blog’s Kristie Prinz to Present Webinar on “Best Practices for Negotiating SaaS Contracts & Managing Customer Relationships”

Silicon Valley Digital Health Law Blog’s Kristie Prinz to Present on Negotiating SaaS Contracts for Clear Law Institute

Takeaways for Digital Health Industry from New Study on Costs of Data Breach

If you are a digital health provider, then your company has likely had occasion to negotiate indemnification clauses relating to data breaches. Moreover, your company has probably had to provide warranties around data security or employee bad acts that would provide some protections to your customers in the event of a data breach.

But have you ever taken the time to really consider what the cost of a possible data breach might actually be for your company?

Network World recently published an article looking at the results of a 2016 data breach study conducted by the Ponemon Institute and IBM and determined that the total average cost for a breach is now $7 million, and that average cost per compromised record is now $221. Network World further reported that the same study concluded that the average cost of a data breach of more than 50,000 records was $13 million.

Obviously, these costs are significant enough that unlimited liability indemnifications relating to data breaches have the potential to generate significant expenses, as do actions for breaches of warranties relating to data security.

So, what can software companies do to protect themselves against data breach liabilities?

First and foremost, companies need to take data security seriously and enact policies and procedures that prioritize data protection.

Second of all, companies need to carefully negotiate clauses related to cyberrisk and cyberliability with the expectation that a data breach will occur that is going to trigger the application of all such clauses down the road. In particular, if you agree to take on unlimited liability of all costs related to a data breach, you need to be prepared to cover the expected costs that will arise from any such data breach. Similarly, in negotiated services contracts, companies need to take the time to carefully define the full scope of services they provide with respect to data protection and data security in such a way that a data breach will not constitute a material breach so long as the services are fully performed in accordance with the defined scope of services.

Third of all, companies need to purchase cyberinsurance in order to ensure that they have sufficient coverage in the event of a data breach. While cyberinsurance is a relatively new insurance product which has in the past often had many gaps in coverage, Tech Republic suggested in an article published today that the newer policies are starting to close some of the earlier policy gaps to coverage. However, Tech Republic reported that companies should still watch for coverage limits in cyberinsurance policies for regulatory actions, cost of call monitoring, credit monitoring, forensic investigations, hacks that began prior to the coverage term, and attacks that have third party consequences.

The bottom line is that software companies need to have contractual and insurance protections in place to protect the businesses against the consequences of the inevitable data breach that affects their business. With data breaches as well as costs on the rise, companies of all sizes need to be prepared to deal with the fallout of a cyberbreach when it occurs.

THE SILICON VALLEY DIGITAL HEALTH LAW BLOG