Is Pharma Rethinking Twitter?

A belated happy new year to all.

While we were away recharging our batteries to gear up for what is already an intense election season marked by increasing talk of drug pricing issues, we caught up on a few new developments regarding some drug marketing and promotion issues that we frequently address (in addition to managed markets issues).  In particular, we came across some interesting material on Twitter that merited a closer look to see how brands have been utilizing that medium in the wake of FDA’s June 2014 release of its social media guidance regarding the presentation of risk and benefit information.

As many readers are undoubtedly aware, most brand manufacturers have shied away from utilizing Twitter for brand messaging. While there are many reasons underscoring that cautious approach, one of the principal hurdles expressed by manufacturers was an inability to convey textually relevant – and regulated – product information within the confines of Twitter’s 140 character limitation.

Twitter’s space constraints proved to be an insurmountable obstacle for marketers trying to squeeze product benefit and efficacy claims, along with significant risk information, to comply with FDA’s guidance:

Regardless of character space constraints that may be present on certain Internet/social media platforms, if a firm chooses to make a product benefit claim, the firm should also incorporate risk information within the same character-space-limited communication. The firm should also provide a mechanism to allow direct access to a more complete discussion of the risks associated with its product.

*     *     *

The prominence of risk information should be comparable to the benefit information within each individual character-space-limited communication, taking into consideration any formatting capabilities available on the specific Internet/social media platform.

*     *     *

If a firm concludes that adequate benefit and risk information, as well as other required information, cannot all be communicated within the same character-space-limited communication, then the firm should reconsider using that platform for the intended promotional message.

As a result, Twitter has remained a rather quiet corner of the pharma marketing world.

During our holiday reading, though, we came across a recent Twitter approach used by one manufacturer that may create a path forward for greater use of Twitter for branded messaging. To be sure, we do not have any insight into whether the tweet in question has led to more meaningful – or measurable – engagement with patients or health care providers, but we will be interested to see if other manufacturers adopt similar approaches for branded tweets.

The tweet we are describing is Janssen’s tweet for Xarelto, which came in early January 2016. [DISCLOSURE: Janssen is not a client.]

While some readers likely may be more interested in how an ad campaign involving Chris Bosh, Arnold Palmer, Kevin Nealon and Brian Vickers actually came together, we, of course, were focused more on the language of the tweet and the use of Twitter to convey messaging for a branded product.

In our view, what is most noticeable is that the tweet appears to avoid FDA’s social media guidelines entirely while at the same time making full use of Twitter’s character limitation and embedding a video into the tweet.  Specifically, the tweet itself contains no information about the product’s benefits or efficacy (as would trigger certain requirements in FDA’s social media guidance), but instead alerts a Twitter user that a new product ad is available for viewing. The video itself is embedded in the tweet, ready for viewing, and links to a YouTube video that contains additional product information, including benefit and risk information. But because the tweet does not make an explicit product benefit claim, there appears to be no need to incorporate specific risk information within the same tweet, as required by FDA’s social media guidance.

Note too that even though no product claims are made, the content of the tweet is consistent with FDA guidance in that it highlights significant risk information for the product – the boxed warning in bold – and links to the package insert to convey the seriousness of particular risks. Obviously, a different scenario would be presented by a product with no boxed warning.  And we think that this approach likely does not lend itself well to satisfying FDA’s other social media guidance regarding the correction of product-related misinformation by independent third parties (i.e., user generated content).

While it may be too soon for the manufacturer to measure the reach and/or pull through of this particular tweet, the structure of the tweet raises a number of interesting questions for all manufacturers to consider.  First, assuming that these types of tweets are consistent with FDA’s guidelines, can manufacturers achieve the same messaging impact if they do not include product benefit claims within the tweet?  Second, do tweets with embedded video content offer manufacturers a better path forward to regulatory compliance with FDA social media guidelines governing risk and benefit information, and should they begin looking at other potential ways to link to other DTC product content they control besides videos, like product websites, print ads or mobile app downloads?  Finally, if manufacturers get comfortable with this approach, will they begin exploring greater use of other social media and publishing platforms like Facebook, Instagram and Pinterest?  While we will continue to monitor use of these types of sites for product messaging, we are aware that one site not typically associated with customer or prescriber engagement – LinkedIn – recently has been mentioned as one social media platform that manufacturers and their senior officers are getting more accustomed to using.

Follow me on Twitter at @MarkAMcAndrew.


Reminder For Manufacturers Offering Co-Pay Offset Programs in Massachusetts: The initial July 1, 2015 statutory expiration date has been extended to 2017

As many readers will recall, in 2012 Massachusetts became the last state in the US to allow its residents to participate in co-pay assistance or drug coupon programs offered by pharmaceutical manufacturers.  A provision contained within the commonwealth’s 2013 budget legislation relaxed the otherwise rigid statutory anti-kickback prohibition to allow the use of drug co-pay cards and coupons by individuals with health care and prescription drug benefits funded by any health care insurer, except for drug products that have AB rated generic equivalents.  Under the 2013 budget legislation, the exception was due to expire on July 1, 2015.

At the beginning of 2015, however, new legislation was enacted that extended the sunset provision of the co-pay assistance exception until July 1, 2017.

As a result, brand manufacturers that had been administering coupon, rebate and co-pay assistance programs over the past couple of years – and that wish to continue running such programs after July 1, 2015 – should consider a number of steps to minimize possible disruption and confusion among consumers, pharmacies and claims processors.

First, manufacturers and their program administrators should ensure that any literature disseminated to or accessible by patients and prescribers, such as hard copy materials or website pages, reflects an appropriate expiration date.  Existing vouchers, coupons or other materials designating a July 1, 2015 expiration date may be met with confusion by patients as well as by pharmacists.

Second, manufacturers and their program administrators should contact relevant claims processors to ensure that any adjudication edits reflecting a July 1, 2015 expiration date for existing offset programs are updated if the programs are to continue.  Without an updated program expiration date, secondary claims applicable to the offset programs will likely reject, thereby causing confusion and frustration to patients, prescribers and pharmacists.

Finally, in the event that the changes above cannot be implemented in a timely fashion, manufacturers and their program administrators should expect an uptick in patient, prescriber and pharmacist call volume and other communications as they attempt to ascertain whether a coupon or voucher opportunity is still available.

The Future of Drug Coupons and Co-Pay Cards – Part 2

In our last post, we addressed a few key points regarding the possible use of drug coupons and co-pay cards by Medicare beneficiaries in connection with purchases of Part D covered drugs.   As our readers know, this issue was the subject of an OIG report and Special Advisory Bulletin that called into question whether drug manufacturers have implemented sufficient safeguards to ensure that Medicare beneficiaries do not use coupons or co-pay cards to obtain drugs paid for by the Part D program.

We also indicated in our last post that we would address at a later date separate legal developments that could impact the use of drug coupons and co-pay cards.

Today is that day, and it’s a good thing we waited because some significant court proceedings concluded earlier this week in a case involving the use of drug coupons and co-pay cards by commercially insured populations.

As some industry watchers may recall, several welfare benefit plans serving union members filed a proposed class action lawsuit in 2012 against Merck challenging Merck’s co-pay subsidy programs that utilized drug coupons and co-pay cards.  The suit, styled Plumbers and Pipefitters Local 572 Health and Welfare Fund, et al. v. Merck & Co., Inc., No. 3:12-cv-01379 (D. NJ), alleged that Merck’s co-pay subsidy programs caused the benefit plans to pay more for Merck branded drugs when less expensive generic products were available, and did this by subverting the cost sharing provisions in applicable PBM contracts with network pharmacies.    

The suit alleged two bases of liability.  First, the plaintiffs alleged that Merck’s co-pay subsidy programs constituted insurance fraud by use of US mail and wires, and therefore violated the Racketeer Influenced and Corrupt Organizations Act (RICO).  Second, the plaintiffs asserted that Merck, through its co-pay programs, wrongfully interfered with contracts between the unions’ PBM and the PBM’s network pharmacies.  The argument was that Merck’s co-pay programs interfered with the pharmacies’ purported contractual obligation to collect co-payment amounts directly from covered members.     

On June 30, 2014, the court dismissed the RICO claims, joining a growing number of federal courts that have addressed similar RICO issues involving challenges to manufacturer co-pay card and coupon programs.  New England Carpenters Health and Welfare Fund v. Abbott Laboratories, No. 12-cv-1662 (N.D. Ill. 2014); Am. Fed’n of State, Cnty. & Mun. Emps. Dist. Council 37 Health & Security Plan et al. v. Bristol-Meyers Squibb Co. et al., No. 12-cv-2238, (S.D.N.Y. 2013);  New England Carpenters Health and Welfare Fund v. GlaxoSmithKline LLC., No. 12-cv-1191 (E.D. Pa. 2014). 

However, the court left the plaintiffs’ tortious interference claims intact.  In particular, the court applied certain legal principles and accepted certain key facts alleged by the plaintiffs as true:  (i) that the PBM performing services for the plaintiffs had “valid and enforceable contracts” with retail network pharmacies that required the pharmacies to collect co-payments directly from patients; and (ii) that Merck, despite its knowledge of the pharmacy network contracts, induced the pharmacies to participate in its coupon and co-pay card programs which had the effect of causing the welfare benefit plans to spend more money on Merck branded drugs, as opposed to less costly generics.  

Curiously, as Merck’s attorneys argued in the company’s pleadings, despite repeated requests, the plaintiffs actually never produced any copies of the pharmacy network contracts that Merck’s coupon programs allegedly interfered with.  Throughout the litigation, the precise terms of the pharmacy network contracts remained unknown, including the provisions that plaintiffs asserted required the pharmacies to collect co-payment amounts directly from covered members (and therefore precluded pharmacies from accepting coupons). Even a casual observer would expect that the plaintiffs would be required, at some point, to produce a copy of an actual contract that now was at the heart of the case, right?  

At the beginning of October 2014, however, Merck’s attorneys discovered what would become the silver bullet to end the litigation.               

Likely during the course of researching case law, one of Merck’s attorneys uncovered a number of recent legal decisions that contained copies of pharmacy provider contracts utilized by the plaintiffs’ PBM.  And lo and behold, those network pharmacy contracts directly refuted the allegations made by the plaintiff welfare benefit plans.

In particular, not only did the pharmacy provider contracts permit network pharmacies to redeem manufacturer coupons and co-pay cards to offset the cost of a patient’s co-payment, but the contracts required the pharmacies to do so.  In a section of the network contract fittingly entitled “Coupons,” the PBM actually required its network pharmacies to “accurately apply all coupons to a Member’s claim, including the Copayment, if applicable.” 

So much for plaintiffs’ allegations that the pharmacy network contracts required the pharmacies to collect co-payment amounts directly from covered members, and therefore prohibited pharmacies from accepting coupons.  Game, set and match on the tortious interference claim.

Merck’s attorneys quickly brought the contents of the pharmacy provider agreements to the court’s attention via a motion for judgment on the pleadings.  The end result, after some back and forth between the attorneys, was the entry on November 3, 2014 of a joint stipulation for the voluntary dismissal of all claims in the action, with prejudice

So while the dismissal with prejudice ends this particular lawsuit, some observers may ask whether this the end of the issue regarding the use of drug coupons and co-pay cards by commercially insured populations? 

We think not. 

In particular, the result in this case appears to be based on the specific contractual language in pharmacy network contracts utilized by one specific PBM.  Other PBMs and third party payers may take a more restrictive view on coupon use, and could incorporate contractual prohibitions in pharmacy provider contracts and/or manufacturer formulary rebate agreements.  Further, even if a particular PBM or payer does not currently preclude member coupon use (or pharmacy redemption), it is entirely possible that the PBM may revise its network agreements to prohibit the practice. Industry observers need only look to the approach taken by UnitedHealthcare to prohibit the redemption of drug coupons and co-pay cards for certain specialty drugs by pharmacies in its specialty pharmacy network.

So for now, interested industry participants may wish to review relevant contractual language and be cognizant of these issues as contract negotiations continue to play out.

As always, we will continue to follow these issues and provide appropriate updates.

The Future of Drug Coupons and Co-Pay Cards

Over the last several weeks, we’ve been following a number of developments around potential legal challenges to the use of drug coupons and co-pay cards. As many of our readers know, the battle between manufacturers and payers boils down to a fundamental issue: are manufacturers’ efforts to subsidize consumers’ out of pocket costs via drug coupons and co-pay cards as a means to promote new starts and/or product adherence appropriate when those approaches are viewed by insurers, plans and their PBM partners as a means to distort and skew formulary controls that may ultimately lead to higher overall costs for the entire healthcare system?

We’ve commented before about the tension between manufacturers and payers with respect to the availability of drug coupons and co-pay cards. Recently, however, several potential legal issues have come to light that have generated significant confusion within the industry, all of which collectively could undermine the administration of manufacturer programs involving drug coupons, co-pay cards and other offset strategies.

We’ll address one important issue in this post:  the possible use of drug coupons and co-pay cards by Medicare beneficiaries in connection with purchases of Part D covered drugs, which was addressed last week by OIG in its report and Special Advisory Bulletin.  We will follow up with a second post on another issue later in the week.

By way of background, regulators historically have viewed the subsidization of a beneficiary’s cost sharing amount as a prohibited inducement that could support a violation of the federal anti-kickback statute. Accordingly, manufacturers have been extremely sensitive to this issue, and typically include language and disclaimers on their materials stating that the coupons or co-pay cards cannot be used for prescriptions for which payment may be made in whole or in part under a federal or state health care program, like Medicare or Medicaid.

As our readers are aware, OIG confirmed this legal interpretation last week in its report.  The report, compiled after an investigation that spanned well more than a year, called into question whether manufacturers have implemented sufficient safeguards to ensure that Medicare beneficiaries do not use coupons or co-pay cards to obtain drugs paid for by the Part D program.

We’ll spare our readers a full recap of OIG’s report, but we think it’s important to highlight a few areas that did not get as much attention as may be warranted. In our view, OIG’s analysis could have benefited from a truly comprehensive evaluation of the types of coupon and co-pay card programs the office purported to review, including the assumptions that appear to have piqued OIG’s interest in the first place.

For starters, instead of conducting a comprehensive review of whether Medicare beneficiaries actually have used coupons or co-pay cards in connection with prescriptions that are paid for by the Part D program, OIG appears to have relied upon the findings of surveys concluding that approximately 6-7 percent of seniors reported using coupons to purchase prescription drugs paid for by Medicare. As OIG must have known, the conclusions drawn by the NCHC survey it cites, as well as the other surveys and studies relied upon, have been questioned by a number of industry participants.  See here for one example.

Which of course raises a fundamental question: shouldn’t OIG have conducted an independent review and analysis to determine whether Medicare beneficiaries actually do use drug coupons and co-pay cards to purchase drugs that are paid for by Part D plans? And further, if OIG verified instances of such coupon use, is the magnitude of the issue as significant as the 6 to 7 percent figure alleged in the surveys?

By taking a full and fresh look at the assumptions underlying its investigation, at least then OIG presumably would have been able to resolve a couple of key issues that continue to be the subject of discussion within the industry:

First, if Medicare beneficiaries are using drug coupons and co-pay cards, are claims for the covered Part D drugs actually submitted by a pharmacy to a Part D plan for reimbursement?

Or, in other words, do Medicare beneficiaries using coupons present to a pharmacy as cash paying customers, such that a claim for reimbursement for the drug is never submitted by a pharmacy to the Part D plan?  A typical example would be where a patient’s out of pocket cost for the brand, using a coupon or co-pay card, is less than the out of pocket cost for the generic alternative.

The surveys cited by OIG do not appear to address such a scenario, which in turn may have led to an imprecise figure (6-7 percent) that potentially overstates the scope of the purported issue.

A second and related issue sidestepped by OIG is whether the growth of preferred or narrow pharmacy networks has had any impact on purported drug coupon or co-pay card use by Medicare beneficiaries.  According to estimates by Adam Fein, approximately 75% of Medicare beneficiaries in 2014 enrolled in a Part D plan with a preferred network design, up from 43% of beneficiaries that chose plans with narrow networks in 2013.

With so many seniors now being exposed to narrow network designs having reduced or no co-payments for certain generic drugs, are OIG’s assumptions about the scope of drug coupon use by the Medicare population still accurate?

Third, OIG’s report also relies upon survey data suggesting that drug coupons and co-pay cards increase Part D program costs because they “encourage Medicare beneficiaries to obtain more expensive brand-name drugs when lower cost alternatives are available.”  In particular, OIG relies upon data from one survey to support its view that well more than half of drug coupons (58% according to OIG) are for brand drugs with an existing generic alternatives, thereby implying that in the majority of instances, drug coupons for brand drugs could sway a patient to choose the brand drug over a generic equivalent.

Again, OIG’s analysis merely recites the survey findings in support of its view, apparently without conducting an inquiry into the conclusions or even considering that different interpretations of the data may exist. For example, at least one commentator indicated that the survey results can actually be read to suggest that less than 10 percent of drug coupons (8.3%) are used to purchase brand drugs when an “FDA-approved therapeutic equivalent” exists (as opposed to an in-class generic that forms the basis for the 58% figure).

Again, without exploring the underlying survey data and findings, OIG does not consider other possible interpretations, but simply accepts the survey findings as evidence that a problem exists.

Against this backdrop, OIG’s conclusions about the scope of the issue, as well as its cautionary warning to manufacturers in the Special Advisory Bulletin, are rather unsettling:

Regardless of future action by CMS, the offerors of coupons ultimately bear the responsibility to operate these programs in compliance with Federal law. Pharmaceutical manufacturers that offer copayment coupons may be subject to sanctions if they fail to take appropriate steps to ensure that such coupons do not induce the purchase of Federal health care program items or services, including, but not limited to, drugs paid for by Medicare Part D. Failure to take such steps may be evidence of intent to induce the purchase of drugs paid for by these programs, in violation of the anti-kickback statute.

More troubling, however, is OIG’s reluctance to provide affirmative guidance to manufacturers as to what it considers “appropriate steps” to be, despite its willingness to do so in prior bulletins on inducement issues.    To be sure, OIG did appear to validate certain approaches taken by manufacturers, such as (i) the use of notices on coupons and related literature; and (ii) the use of claims edits in the processing of coupons.

But in OIG’s view, the efforts employed by most manufacturers fall short.

As a result, OIG’s report has caused manufacturers to assess their current practices and the potential risks of liability under the anti-kickback statute (and, as a result, the False Claims Act).  But while the principal focus of OIG’s report is the existence and scope of manufacturer safeguards, given the expansive interpretation that some enforcement authorities (not to mention qui tam relators) may give to the anti-kickback statute, it may be worthwhile for all industry participants (like PBMs, Part D plans and pharmacies) to evaluate potential liability issues in the context of their existing mechanisms for identifying and/or auditing coupon use by government beneficiaries.

In our view, the one silver lining in OIG’s report and bulletin lies in its ultimate finding that CMS already maintains the data necessary to allow manufacturers and other industry participants to preclude drug coupon and co-pay card use by Medicare beneficiaries.  Getting CMS to participate in such a discussion, however, may be a different story, in light of the agency’s apparent reluctance to provide relevant data in the past to facilitate the development of a technical solution to block coupon use by government program beneficiaries.

Specifically, it may be worthwhile for manufacturers to press CMS for access to one of the following data sources to effectively and quickly solve these issues:

1.          ongoing access to Part D beneficiary enrollment status; or

2.          ongoing access to a complete listing of all Part D plans’ BIN and PCN

If drug coupon and co-pay card use by Medicare beneficiaries is as significant of an issue as OIG and some industry stakeholders believe it to be, CMS and manufacturers should open an immediate dialogue to facilitate additional safeguards and solutions to the issues alleged by OIG.  

In the end, does CMS really want to be viewed as impeding industry efforts to preclude coupon use by government beneficiaries, and therefore hindering industry efforts to comply with applicable law?

Some Thoughts on Apple’s Healthcare Play and the Challenges for Medical App Makers (and for Apple)

As if we needed any reminders, Apple has introduced a countdown clock for its September 9thspecial event” at which most observers believe the company will launch new versions of its iPhone, as well as a wearable device many are calling the iWatch.  True to form, Apple is not providing any formal pre-event details about the content of the announcement, but over the past few months a number of industry insiders have published nuggets of information purporting to outline certain functionalities of Apple’s new offerings, including the new iOS, HealthKit, the Health app, and the iWatch itself.

One thing seems clear from this steady drumbeat of information:  Apple is going all in on health and fitness.   

To be sure, there are a variety of other players in the wearable space trying to capture that market as well, but as Fred Wilson pointed out several months ago, when Apple decides to do something, we should “pay attention to what Apple does. It is more important than you think.”  We could not agree more.

Of course, we’ve written previously about the opportunities for Apple and other companies in the mobile healthcare space, and have speculated with the rest about what Apple may do.  But now that Apple has signaled its entry into healthcare (by a cannonball into the pool, as some might suggest), we thought we’d take a step back and assess a few key issues and challenges that we think will come to the forefront very quickly not just for app developers, but also for Apple.

For starters, we’d be remiss if we did not comment on Apple’s navigation of certain regulatory challenges relating to FDA regulation of mobile medical apps.  We’re not privy to the amount of discourse between the two, but in our view, it appears that Apple has been downright masterful in facilitating the creation of a more flexible and pragmatic regulatory environment.  Look no further than FDA’s evolving views on the types of apps that will be subject to FDA approval and oversight, as well as FDA’s proposed guidance issued last June to deregulate medical device data systems (MDDS).

The end result, of course, is that it appears that Apple has paved the way for the development of a health and wellness ecosystem that will allow and encourage individuals to aggregate health and wellness data from multiple iPhone and iWatch apps.  So get ready for an explosion not just in the development of health and fitness apps, but also in the volume of patient generated healthcare data arising from those apps.  All signals point to Apple’s belief that a “health revolution” can be founded upon a data-centric platform, where its Health app will provide a dashboard for health and fitness data, and HealthKit will allow cross-app access and sharing of a user’s health data, with the overarching goal of empowering users to better understand and manage their health and wellness.

And therein lies one set of critical challenges for Apple and the app developer community.

Again, we go back to Fred Wilson and some comments he made about Apple at TechCrunch Disrupt last May:  “Their stuff in the cloud is largely not good.  I don’t think they think about data and the cloud.”  Uh oh.  

Irrespective of whether Fred Wilson is right or wrong, his statement highlights a fundamental question about the potential challenges for an app ecosystem designed largely around the creation and sharing of health data, one of the more highly regulated data sets not just in the US but around the world.

To be sure, the world will likely find out more on Tuesday about Apple’s approach to leveraging HealthKit and its Health app and how it thinks about healthcare data, most likely by reference to some its collaborations with pilot partners like Mayo Clinic and Epic.  But we also view Tuesday’s event as the beginning of a slower process that will determine whether Apple’s approach to healthcare data will give app developers such as hospitals, physicians and other health care providers the comfort they need to push them to participate in the ecosystem and be a part of Apple’s health revolution.    

There is no question that Apple will sell a lot of iWatches packed with sensors that can measure or track a variety of personal health data points.  The larger issue is whether app developers will find HealthKit and its developer terms friendly enough and not overly burdensome or confusing so that they engage in the ecosystem and create apps to leverage users’ health care data.  While Apple appears to have successfully navigated the regulatory waters at FDA for the time being, healthcare data privacy laws such as HIPAA and similar state privacy laws present an entirely new paradigm for Apple to maneuver.  In many ways, Apple is in uncharted waters.  

By way of background, let’s start with some basics around healthcare data privacy.  As an initial matter, the restrictions in HIPAA regulating the use and/or disclosure of certain individually identifiable health information, known as “protected health information” or PHI, generally apply only to “covered entities” like health care providers, health plans or health care clearinghouses and the so-called “business associates” of covered entities (third parties that perform certain functions on behalf of covered entities).

Many existing companies with wearables or health apps like Map My Run and Fitbit are not “covered entities,” are not specifically subject to HIPAA, and therefore are not bound by HIPAA’s restrictions on the use and disclosure of health data.  That said, however, many app developers attempt to be sensitive to user privacy, and have implemented policies that they will not use, disclose or sell any identifiable user information to third parties.  This does not mean that the wearable company or app developer will not disclose any information to a third party, but rather that the company or app developer can disclose, if it wishes, “de-identified” information about users.

To “de-identify” health data, many app developers look to HIPAA’s de-identification standards as a benchmark.  Under HIPAA, PHI can be de-identified in one of two ways: (i) through an expert determination by a statistician; or (ii) by the removal of 18 types of identifiers. See this chart from CMS for a good description of the two approaches.

In our experience, if app developers seek to de-identify user data, they generally rely on the second method above, which is generally referred to as the de-identification “safe harbor.”

So, while many current health app developers may already have a passing knowledge of HIPAA and standards for de-identifying user information, app developers seeking to utilize HealthKit and the purported iWatch will need to get comfortable with Apple’s evolving view on data privacy and security.  In fact, Apple already has issued some important guidance as to its views on data privacy and security and how app data can be accessed and disclosed by developers. 

From what we have observed in published reports about HealthKit, however, we think there are some lurking legal and regulatory landmines that may cause some critical developer segments – like hospitals, physicians and other healthcare providers – to be extremely cautious about developing apps to participate in Apple’s proposed healthcare ecosystem. 

The more significant challenge in our view relates to iCloud and how it will interact with HealthKit and the healthcare data generated by apps utilizing HealthKit APIs. While Apple’s new App Store terms and conditions indicate that HealthKit cannot be used to store users’ health information in iCloud, Apple’s revised developer agreement and iCloud addendum takes a more nuanced approach that may cause confusion among the developer community. 

In particular, except with Apple’s permission, Apple’s new iCloud addendum prohibits developers from using iCloud to receive, transmit or maintain any individually identifiable health information (including “protected health information”) or use iCloud in a way that would make Apple the developer’s or any other third party’s “business associate” for purposes of HIPAA.  Essentially, this provision means that Apple will not commit to complying with the privacy and security requirements of HIPAA relating to protected health information.  Nor will it sign a business associate agreement with a “covered entity,” such as a hospital, physician or other health care provider, that would require it to comply with HIPAA. 

Apple’s reluctance to provide such HIPAA assurances likely will give some potential “covered entity” app developers (like hospitals) pause about developing or utilizing apps leveraging HealthKit or iCloud. It should come as no surprise to Apple that potential developers that are also health care providers would be concerned about HIPAA compliance, particularly in light of the recent data breach involving Community Health Systems in which certain information for 4.5 million patients was compromised by hackers. 

But it is worth noting too, however, that Apple’s iCloud addendum appears to permit app developers to use iCloud to store, receive, transmit or maintain user health information that is not individually-identifiable.  So it appears that app developers can use iCloud to store, maintain, transmit or back up any de-identified health data generated by their apps.  

In light of Apple’s distinction between “individually identifiable” and non-individually identifiable health information, we question whether additional restrictions imposed upon developer use of HealthKit data would apply to user health data that is de-identified by app developers.  As most readers are likely aware, recent reports have detailed Apple’s changes to certain provisions of its iOS developer license agreement to prohibit developers from doing a number of things, including (i) selling health information collected through HealthKit “to advertising platforms, data brokers or information resellers,” (ii) from using user health information from HealthKit for purposes other than providing the health or fitness function or services relating to the app, and (iii) from disclosing health information collected through HealthKit to any third party without the user’s consent, and then only for the purpose of enabling the third party to provide health or fitness services to the user. 

However, the precise parameters of these restrictions are ambiguous, as it is unclear whether app developers are permitted to utilize de-identified data, as many currently are doing.  To inject further ambiguity into an already murky framework, if Apple intends to permit app developers to use HealthKit data that is de-identified, we question whether some of the data is capable of de-identification in accordance with de-identification methods typically utilized by app developers and related parties. 

As we noted above, most developers in our experience de-identify individually identifiable information through the de-identification “safe harbor” process (i.e., the removal of 18 types of identifiers), as opposed to through an expert determination, which can be a lengthy and costly undertaking.  Importantly, of the 18 types of identifiers that must be removed to render health information suitably de-identified within HIPAA’s standards, app developers would be required to remove “biometric identifiers, including finger and voice prints.”

Of potential concern to app developers, the list of potential biometric identifiers is not exhaustive, and conceivably could include identifiers based upon health care data measured by an app, like a user’s heart beat for example.  If an app developer were forced to remove the very health data that her app measured or tracked in the course of de-identifying the data, it would entirely defeat the purpose of the app and the developer’s incentive to develop within the Apple healthcare ecosystem.     

While we all hope to learn more about Apple’s plans to develop its health app ecosystem on Tuesday, Apple will need to address two basic issues relatively quickly:  (i) because the success of Apple’s entry into the healthcare space depends largely upon the ability of the app developer ecosystem to build apps that leverage HealthKit, developers will need to have clarity and comfort with the data use and/or security requirements that Apple is imposing upon them, and (ii) in light of Apple’s imposition of certain data security requirements on developers, it will need to have a framework in place to monitor whether app developers are in compliance with those data security requirements.   

As we said many months ago, we think Apple has a unique opportunity to transform how consumers think about their own health, fitness and wellness, how they interact with their healthcare providers, and ultimately, to redefine how healthcare is delivered.  

But as those opportunities depend upon Apple’s ability to create the necessary data security foundation to work with and leverage multiple health data sources, the success of its strategy may hinge on whether users, as well as app developers, are comfortable with Apple’s efforts to address data privacy and security in a meaningful way.

We’ll find out more tomorrow.

The Importance of Medicare Coverage Gap Discount Agreements for New Pharma Companies Entering the Market

With rebate contracting season now well underway, we thought it might be a good time to return to an issue that we’ve discussed recently with a number of industry participants, including new pharmaceutical manufacturers bringing products to the market for the first time.

For many pharma companies waiting for FDA approval of their first NDA, the months leading up to agency approval are filled with a variety of activities ranging from investor meetings, pricing and reimbursement issues, manufacturing planning, and sales and marketing strategy, to name a few. 

Not to be ignored, however, is a company’s approach to managed markets and payer relationships.  As most industry participants are well aware, developing an effective managed care strategy for obtaining formulary access – and therefore product reimbursement – from health plans, commercial insurers and government funded health care programs is a critical component of any comprehensive commercialization strategy.

One strategic prong that many new manufacturers consider is contracting with Medicare Part D plans.  With total enrollment in drug plans covered under Part D (Part D Plans and Medicare Advantage) approaching 40 million lives according to CMS’ latest figures from June 2014, the Part D market constitutes a significant revenue opportunity. 

But without proper advance planning, new manufacturers could be shut out of the Part D market and excluded from Part D formularies for an extended period of time, damaging company prospects for product adoption and leading to the loss of significant revenue and potential market competitiveness.  

To ensure that a product can obtain formulary placement with Part D plans, CMS regulations require drug manufacturers to have a Medicare Coverage Gap Discount Program Agreement in place with CMS by January 30th in the year prior to formulary placement.  

In other words, if a new manufacturer with a newly approved product, or an existing manufacturer seeking to list its products on Part D formularies for the first time, did not have a Medicare Coverage Gap Discount Agreement in place by January 30, 2014, those products would be excluded from coverage under Part D beginning January 1, 2015, and potentially through 2016.  

So, for start up pharma companies or other first time entrants expecting to make Medicare Part D formulary access and reimbursement a component of their managed markets strategy in the next couple of years, please be advised to explore the details surrounding Medicare’s Coverage Gap Discount Program.  For those who do not, exclusion from Medicare Part D has the potential to significantly impair go-to-market strategies and projected product revenues. 

However, if pharma companies have missed the January 30, 2014 deadline, certain arrangements may be available to ensure that products can obtain eligibility for Part D coverage in 2014 and 2015 while arrangements are made to contract with CMS for the 2016 plan year.

Additional information can be obtained by contacting us via the contact form.



In Apple’s Healthcare Play, Will BYOD = Bring Your Own Data?

By now, most interested observers are well aware of historical growth in the bring your own device (BYOD) movement, in which businesses permit their employees to bring their own devices to the workplace environment and connect them to corporate networks.  With this evolution well underway, we’ve lately been giving some thought to how this “bring your own” type of approach might work in other contexts.  Healthcare seemed like a reasonable place to start, particularly in light of the recent frenzy of reports surrounding Apple’s apparent interest in the healthcare space.

Since we broke the news a couple of weeks ago about a meeting in December 2013 between senior Apple and FDA officials regarding mobile medical apps, much has been written about Apple’s potential plans.  Of course, Nick Bilton at the New York Times kicked things off (thanks Nick!), followed closely by the folks over at 9to5Mac and others.

As we sifted through the reports and rumors, we became encouraged about the level of discourse about Apple’s possible healthcare play.  Much of the discussion has centered around Apple’s assembly of a high caliber team of experts with deep experience in medical sensors and patient monitoring technologies, which gave further credence to reports of Apple’s possible introduction of an “iWatch” that would allow users to track health and fitness data generated by sensors embedded in the wearable.  Some even raised the possibility that Apple might be interested in developing medical devices, peripherals or accessories for the iPhone.

We’ve also heard rumors about Apple’s planned release of a software product known as “Healthbook” that purportedly would be a part of an iOS8 release.   The potential functionalities to be contained in Healthbook seem to vary by whoever is reporting on it, and include the capability of measuring and/or monitoring a user’s vital signs, blood pressure, hydration levels and glucose levels, as well as tracking data related to certain physical activities like steps taken or miles jogged.  Apple, it was said, may be aiming to redefine the already crowded fitness tracker market.

While many of the items seem like interesting projects, apart from the possible introduction of an “iWatch,” the reports speculating about Apple’s rumored plans in the healthcare space seemed…well…unsatisfying.

Particularly for a company that creates categories and is defined by its emphasis on creating an easy, intuitive user experience.  There must be more to it, right?

The more we thought about it, we began to piece together a framework of a possible approach that Apple could take in the healthcare space.  Most industry observers acknowledge that the healthcare sector is ripe for disruption, and as we’ll see below, our views on this issue are heavily influenced by markets that Apple has created and/or redefined in the not too distant past (hint, think iTunes).

What follows is an attempt to connect dots based upon the state of the healthcare industry, trends affecting the delivery of healthcare, and general technology trends.  And the end result is a possible approach that Apple could embrace that would bring it directly into, among other places, the multi-billion dollar turf controlled by a few long-entrenched providers of electronic health record systems (EHRs).

We start with a fairly unremarkable fact:  the healthcare industry today is undergoing a major transformation not just in how care is delivered and by whom, but also by the degree to which individuals, as purchasers of health care items and services, are being asked to bear an ever increasing portion of the costs of their healthcare.  These trends coincide with the continuing evolution in internet technologies, digital tools and mobile software, to the point where we see transformations in entire industries over a few years (if not overnight) where those types of changes otherwise would have happened over the course of a decade or more.

The introduction of the iPod, iTunes and the iTunes store are very good examples of this with respect to the music industry, and all of those developments dramatically changed not only how digitized music was distributed, but also how millions of people accessed, organized and interacted with that content.  It was (and still is in some ways) a distribution system that is fragmented among many players, but iTunes and newer, similar digital media services now provide users with easy to use interfaces backed by digital hubs that make it much easier for users to store, organize, access and consume their data, whether it be music, movies, e-books or television shows.

But what does this have to do with Apple’s foray into healthcare?

Well, we think Apple has a unique opportunity to transform how consumers think about their own health and wellness, how they interact with their healthcare providers, and ultimately, to redefine how healthcare is delivered.  Like those other industries that Apple and others similarly upended, (can it really be only a bit more than a decade since the launch of the iTunes store?), these transformations are already well underway in the healthcare space.  Apple’s further entry into the industry, however, has the real potential to accelerate these shifts in ways for which many long-entrenched industry players will be unprepared or unable to respond effectively.

As the title to our post suggests, we think the transformation will be based on data.

But more specifically, we think it will be based on Apple’s ability to create the necessary foundation and a user experience that aggregates multiple health data sources and empowers patients to generate, understand, control and manage relevant information about their health and wellness.   What’s more, many of the components to embark on such an approach are already in place:  the iPhone, the App Store, iCloud, iBeacons and the rumored iWatch, to name a few.

To understand how this shift could occur, let’s take a couple of steps back to examine how and where healthcare data currently exists.  Most patient-specific healthcare data historically has resided in paper records and in EHRs, both of which are typically under the control of a patient’s physician or a facility where the patient is seen, like a hospital.  And perhaps more importantly, a large portion of the data that resides in these records is generated by a healthcare provider and recorded in a clinical setting, such as your doctor’s office or at a hospital.

We see this paradigm changing.  And fast.

Building upon the commercial success of a variety of health and fitness trackers, we, like some other experts, can envision a day in the not too distant future when a significant portion of relevant and actionable patient data is not generated or recorded by a physician or other healthcare worker at the doctor’s office or a hospital, but rather by the individual herself, in her own home, using mobile or wearable technology.

The volume of this patient generated healthcare data is already significant, and we think it will explode exponentially if Apple, as rumored, introduces a commercially successful “iWatch” laden with medical sensors.  Such a product, along with Apple’s continued support of third party app developers, will play a critical role in the transformation as well, as the number and complexity of mobile medical apps available on the App Store will enable greater numbers of patients to participate in their own health care through self-monitoring.

Look no further than AliveCor’s launch this week of its mobile ECG Heart Monitor as an over the counter product as evidence of what’s ahead for patients and their healthcare providers.  This is the kind of monitoring that previously could be conducted only in a clinical setting.

We interpret all the rumors about Apple’s entry into the healthcare space to point to its development of a health and wellness ecosystem that will allow and encourage individuals to aggregate health and wellness data from multiple iPhone or “iWatch” apps.  In fact, there were some reports that Steve Jobs viewed iCloud as serving the role of a digital hub that would allow users to store and manage medical data.  Perhaps the latest signals from Apple suggest that it now is gearing up to try to redefine the category, putting in motion concepts that Steve Jobs may have developed several years ago.      

But surely this concept of has been tried by others before, no?   The short answer is of course, yes, as proponents of Microsoft HealthVault or Google Health can attest. 

To be sure, Apple will certainly face challenges.  But where others have failed to gain traction, we think there are a number of advantages and trends favoring Apple’s success not only in knocking down the fragmented silos of medical data, but also in taking things many steps further.   As an initial matter, Apple’s experience and success in developing an integrated and intuitive hub for the organization, storage and management of digital content – iTunes – demonstrates its seeming ability to implement a uniform strategy and user experience that would allow patients to manage their healthcare data from a variety of sources.   

The availability of relevant patient data is another encouraging sign.  In particular, the patient generated health data to be organized is already being created and recorded by millions of users of fitness trackers and other health and wellness apps and by mobile medical devices that are currently approved by FDA.  Further, self-monitoring patients are already sharing data they generate with their physicians

In addition, recent regulatory changes will make it much easier for individuals to obtain access to additional heath data that previously had been subject to any number of restrictions.  For example, recent changes to the HIPAA regulatory framework now make it possible for patients to obtain lab test results directly from a lab without physician approval.   Other recent changes to HIPAA’s privacy rule further enhance a patient’s ability to access their health data in EHRs and direct the transmission of their records to online health records portals. 

So while industry trends clearly indicate an evolving view to giving patients greater access to their own healthcare data, to date the data remains fragmented across various repositories, including existing app developers.  Further, because in many instances available data may be raw data that is difficult for users to interpret or visualize, general access to that data may be meaningless to the individuals who create it.  Against this changing environment, Apple has a real opportunity to leverage its historical design expertise (not to mention the rumored legions of medical experts it has hired) to create a user-friendly interface that provides individuals a meaningful opportunity to review, manage, understand, and most importantly, share their data.   

We will leave it to the medical experts to determine how best to portray or display health data in ways that are most meaningful and actionable to patients, but we think one critical aspect of such an undertaking is that the structure of the data to be collected and managed must be standardized.  From Apple’s perspective, this could serve two important purposes:  first, by standardizing the format of patient generated health data, it sets the criteria for all mobile medical app developers who wish to sell their apps through the app store, and thereby sets parameters for how that app data relating to an individual could be transmitted to and stored in Apple’s digital hub (iCloud?); and second, a standard data convention also could ensure that it can be transmitted and integrated into an EHR system.

And EHR integration may be Apple’s real opportunity to transform the healthcare space. 

While the volume of patient generated health data continues to grow with the launch of each new wearable or other mobile medical app, patient data will continue to be created by physicians and other healthcare providers in clinical settings and maintained in EHR systems.  As many are aware, the federal government has financially incentivized  healthcare providers to implement EHR systems, and as of October 2013 had paid  almost $17 billion in incentive payments to physicians and hospitals to implement EHR systems meeting certain criteria (i.e., meaningful use).  In HHS’ view, greater deployment of EHR technology will lead to improvements in patient care through, among other things, better care coordination. 

But that view is not shared by many in the healthcare industry, including physicians who are challenged by certain aspects of the EHR systems on a daily basis, as well as by some hospital personnel who bristle at the significant prices charged by a few entrenched incumbents (up to $700 million for an Epic implementation).  Typical complaints include a poor user experience, limited flexibility to use third party applications within the system, and limited ability to navigate the systems.  

But the view underlying many of these issues seems to be that the dominant EHR providers have failed to innovate, and continue to market decades-old legacy systems with limited functionality, and which are generally closed to integration with third party developers or applications.  In short, the view is that the technology underlying the EHR systems has not kept pace with similar content management systems used in other industries.

Enter Apple?

If Apple’s play in the healthcare industry is based upon the creation of a digital hub to support the aggregation and storage of patient generated healthcare data, we think that approach could lead to major innovations – and disruption – in the EHR industry.  Specifically, it seems to be a good bet that Stage 3 of the Meaningful Use requirements will require EHRs to integrate patient generated health data.  In other words, in order for the hospitals and others that have deployed EHR systems to continue to receive billions of dollars in incentive payments from the federal government, those EHRs will be required to accept data transmissions of patient generated health data.

If that is the case, it makes sense, from a hospital’s perspective, to allow only one point of entry to its EHR system, as opposed to creating separate interfaces or APIs to allow potentially thousands of mobile medical app developers to transmit user generated data to, or pull patient data from, an EHR.   The same may hold true where a patient wishes to provide her physician access to certain data that may reside in an Apple data hub:  it would be much easier for physicians to access one centralized data repository than for the physician to access data libraries for each medical app that the patient may utilize.  In our view, Apple is best situated to capitalize on these trends, particularly given the already deep penetration of Apple products like iPhones and iPads among healthcare providers and healthcare facilities.

To be sure, there may be additional, potential hurdles along the way, such as HIPAA concerns and possible FDA regulation of an EHR connectivity solution or API, but we think these issues can be effectively managed, particularly in light of other file sharing services’ (like Box) ability to manage those issues in the healthcare space.  We will try to address those potential issues in a later post.

In the end, if Apple’s entry into the healthcare space proceeds toward developing a healthcare data hub parallel to the solutions offered by EHR systems, it may not be too far of a reach for Apple to work more closely with healthcare providers to create a more user friendly and fully integrated records framework, particularly given the incumbent EHR providers’ reported inability to create a meaningful mobile experience. 

Given Apple’s history of competing with entrenched incumbents that fail to innovate, we will be watching these developments closely.

Google, Apple and Mobile Medical Apps

Hey folks, sorry for the lack of posts lately.

We are doing our best to get back to our regularly scheduled programming, but we wanted to take a quick detour to address some recent events in an area that we also follow very closely.

Like a lot of people, we are really excited about the advances in mobile technology and how they can be applied in the healthcare environment to facilitate health and wellness in general, and more specifically, drive greater patient engagement and more efficient delivery of patient care.  Mobile health, or mHealth as it is frequently called, is an area that is rapidly evolving, as more and more established tech companies seek to expand their portfolios with, among other things, wearable sensor products, diagnostic tools and other monitoring products and accessories.

As the field becomes more crowded each day with companies and developers introducing new and more robust mHealth products, the odds of implicating FDA’s regulatory authority over mobile medical apps becomes a more pressing issue.

As many of our readers may know, FDA’s authority to regulate mobile medical apps stems from what device classification (i.e., I, II or III) the mobile app falls into depending upon the potential risk to the user.  As many industry watchers also are aware, FDA will from time to time exercise its enforcement authority against unapproved medical devices, sometimes with drastic consequences.  The background of FDA’s enforcement action last November against 23andMe should be required reading for anyone seeking to develop and introduce an mHealth product in the US, as it provides a highly visible cautionary tale about the importance of working within FDA’s regulatory framework applicable to medical devices.

In short, although 23andMe’s product was not a mobile medical app, FDA’s issuance of a warning letter to the company for marketing an unapproved medical device forced the company to suspend a significant part of its business – conducting health-related genetic tests.

To head off similar misfortunes, many mobile medical app developers are learning that engaging FDA in a dialogue about possible regulatory hurdles in the approval process is a path well worth taking.  In fact, the chief architect of FDA’s mobile medical app policy, Bakul Patel, endorsed such a path, especially for new developers:

We also encourage these developers to work with the FDA earlier, especially if they have questions on the risk level of their app.

Which is why we are so interested to see two of the most dominant companies in the tech space – Google and Apple – recently engaging FDA on mHealth issues.

There’s already been a lot of coverage of Google’s foray into the mHealth arena with possible medical uses for Google Glass, as well as its efforts to develop a smart contact lens to measure glucose levels in the tears of diabetics.

As the members of the Google X team noted in their blog post, they have already begun discussions with FDA, even though possible approval and commercialization may take up to five years.  These meetings between Google X staffers with FDA, further detailed in other press reports based upon FDA’s public calendars, suggest that Google is cognizant of potential regulatory hurdles for mobile medical apps and is taking a proactive approach to working with FDA.

What has been less well-publicized (silent, in fact!) is that Apple appears to have made engaging with FDA on mHealth issues a critical priority.  Whether Apple’s outreach corresponds to rumored plans to unveil an iWatch containing medical sensors is unclear, but there is no question that Apple views a dialogue with FDA as a key piece of its mHealth strategy.

For example, last month several senior level executives who seem to have been enlisted in the effort and met with senior FDA officials to discuss mobile medical apps, according to FDA’s public calendar.  And this was no ordinary “meet and greet” like the Google meeting with FDA (again, according to the FDA calendar).

Among the Apple attendees:

The lineup from FDA?  Again, another group of senior level staff, including Jeff Shuren, the director of FDA’s Center for Devices and Radiological Health (CDRH), Bakul Patel, who drafted FDA’s mobile medical app guidance, and two senior legal advisors.

Oh, to have been a fly on the wall in that meeting.  While it’s impossible to know whether this meeting occurred as the opening of Apple’s dialogue with FDA, or rather as part of an ongoing dialogue with FDA that began long ago, one thing is clear:  the senior level nature of the meeting appears to demonstrate Apple’s extremely strong commitment to the mHealth space and foreshadows a major product announcement or initiative in the mobile medical industry (fully loaded iWatch?)

Again, while we don’t have any knowledge of either Google’s or Apple’s discussions, we view these meetings as extremely encouraging signs that these tech powerhouses are sensitive to FDA’s regulatory framework and appear to be taking steps to work with the agency to bring new mobile health care tools and products to market quickly.

We can’t wait to see what they both come up with.


Refill Reminders and HIPAA: Some Practical Considerations

By now, we suspect most if not all of our readers are aware of the final rules issued by HHS earlier this year to regulate sponsored refill reminder programs, the litigation initiated by Adheris, Inc. last month challenging those rules, and the subsequent, revised guidance on refill reminders and patient messaging programs issued by HHS on September 19th.  

For those unaware, the issue was essentially this:  under new HIPAA rules that were scheduled to go into effect on September 23rd, refill reminders and other types of patient messaging sponsored by drug manufacturers to promote medication adherence would constitute marketing, and therefore require a HIPAA compliant authorization from the patient receiving the communication, unless the financial remuneration received by the entity in exchange for making the communication was “reasonably related to the [entity’s] cost of making the communication.”

In the preamble to the final rule, HHS explained that under HIPAA’s definition of “marketing,” the amount of remuneration that could be paid in connection with sponsored communications like refill reminders was limited to the cost of “labor, supplies, and postage to make the communication” (i.e., the pharmacy’s cost of drafting, printing and mailing the refill reminders).  If the payment to a covered entity or business associate for making refill reminders generated a profit or included payments for other costs, HHS stated that it would view those payments as not being reasonably related to the cost of making the communication, and therefore in violation of HIPAA’s marketing restrictions.

These rules naturally posed a significant threat to the livelihood of a number of for-profit companies like reimbursement hubs and other support service providers that work with drug manufacturers and pharmacies to administer patient messaging programs. Despite a prolonged effort by a number of parties, including trade associations and patient support groups, to have HHS clarify an expanded scope of the refill reminder exception from HIPAA’s marketing restrictions, HHS only issued revised guidance when confronted with a lawsuit filed by Adheris challenging the regulations on constitutional grounds.

The key takeaway from the guidance clarifies that the following payments are permissible (without a HIPAA-compliant authorization) and will not trigger a violation of HIPAA’s marketing restrictions:

•     For payments by a manufacturer to a doctor or pharmacy, those payments may cover only the reasonable direct and indirect costs related to the refill reminder or medication adherence program (or other excepted communications), including labor, materials, and supplies, as well as capital and overhead costs.

•     For payments by a manufacturer to a business associate that contracts with a doctor or pharmacy to assist in carrying out the refill reminder or medication adherence program (or to make other excepted communications), those payments may be only up to the fair market value of the business associate’s services.

But much has been written already about HHS’ guidance, and we don’t want to parrot here what can be read in the guidance itself.

Instead, we want to note some observations and, given that HHS’ guidance went into effect last week, provide some practical tips for administering refill reminder and patient messaging programs in the wake of HHS’ clarification.

1.     In addition to patients and the entities administering refill reminder programs (like Adheris), the big winners from HHS’ guidance may be the consultants who will now be called upon to analyze the “reasonable and direct costs” or the “fair market value” of the refill reminder or patient messaging program (much like determinations of FMV of compensation or remuneration in the context of Stark and Anti-kickback analyses).

2.     Companies administering sponsored refill reminder and medication adherence programs will need to undertake their assessment of costs and FMV based upon the form of the messaging used in the particular program.   For example, while many reminder and adherence programs involve mailers or letters, messaging programs can also utilize telephone or IVR, in-store messaging, text message and even newer technology products like GlowCaps or smart pillboxes.  Each of those methods have different costs, and it therefore will be important for interested parties to evaluate and document relevant program costs based upon the medium and tools used.

3.     In connection with assessments of costs, we note that a number of years ago, Avalere Health prepared a methodology to calculate the cost to a pharmacy to administer patient messaging programs.  The methodology was actually prepared in connection with an earlier version of HHS’ proposed rulemaking on refill reminder programs, and provides an extremely helpful summary of components of the various direct and indirect costs related to different types of messaging programs.

4.    Finally (and obviously), the principal way for companies engaged in sponsored messaging programs to insulate the programs from scrutiny is to obtain a HIPAA-compliance authorization from the patients receiving the communications.

Interestingly, Adheris asserted in its court filings that obtaining patient authorization was “not economically feasible,” without further explanation of the potential costs involved.   We note that as technology continues to evolve rapidly and patients become more comfortable with new patient engagement tools, we expect it to become much easier (and cheaper) to obtain HIPAA-compliant authorizations.

In fact, we’re aware of a couple of efforts already underway to facilitate this process, and look forward to seeing more from others involved in developing new and innovative healthcare tools.



Follow up on the Use of Co-Pay Cards in Health Insurance Marketplaces

For those following along, we wrote an item last month that took the position that Qualified Health Plans (QHPs) offered through the health insurance exchanges did not appear to constitute a “Federal health care program” as would make those plans subject to the federal anti-kickback statute.

As a result, we thought that the use of drug co-pay cards and coupons would be permissible by individuals purchasing drugs covered under a QHP.   At that time, we also noted that it was possible for HHS or CMS to issue additional guidance on this issue.

Well, HHS has now spoken.  And HHS confirmed our interpretation.

Apparently before or after her testimony yesterday regarding efforts to remedy issues relating to, Secretary Sebelius released a letter to Congressman Jim McDermott, from Washington’s 7th District, responding to a letter his office had submitted requesting HHS’ view of whether QHPs are considered federal health care programs under Section 1128B of the Social Security Act.

While a full copy of HHS’ October 30, 2013 letter can be accessed here, the key portion is as follows:

The Department of Health and Human Services does not consider QHPs, other programs related to the Federally-facilitated Marketplace, and other programs under Title I of the Affordable Care Act to be federal health care programs.  This includes the State-based and Federally-facilitated Marketplaces; the cost-sharing reductions and advance payments of the premium tax credit; Navigators for the Federally-facilitated Marketplaces and other federally funded consumer assistance programs; consumer-oriented and operated health insurance plans; and the risk adjustment, reinsurance, and risk corridors programs.  This conclusion was based upon a careful review of the definition of “Federal health care program” and an assessment of the various aspects of each program under Title I of the Affordable Care Act and consultation with the Department of Justice.

So, because a QHP is not considered a federal health care program, there can be no violation of the anti-kickback statute even if a drug co-pay card or coupon was used in conjunction with an insured’s purchase of a covered drug.  Note too that HHS’ interpretation was reached in “consultation with the Department of Justice.”

However, HHS limited its interpretation to programs under Title I of the Affordable Care Act.  In our prior post, we also surmised that the use of drug co-pay cards and coupons by populations covered by Alternative Benefit Plans (ABPs) would be prohibited.   Given that ABPs are covered under Title II of the ACA, and because ABPs are required to be approved under a Medicaid State Plan Amendment, it appears that the anti-kickback statute would be implicated by the use of drug co-pay cards and coupons for drugs covered by an ABP, just as with the general Medicaid population.

In the end, any incremental benefit that manufacturers may achieve through the use of co-pay cards and coupons by individuals insured under a QHP is entirely dependent upon the number of individuals actually purchasing coverage through the health insurance marketplace.  While Secretary Sebelius noted yesterday that enrollment to date likely is a “very small number,” we expect those number to increase as the technical challenges are addressed.