This post will cover how healthcare technology vendors can proactively manage the risk that the Anti-kickback Statue (“AKS”) presents them, with a specific focus on contracting with healthcare providers. Two other major areas of risk are: 1) the sales and marketing processes, and 2) when partnering to co-develop or push product that is somehow reimbursable through a federal healthcare program. This blog’s earlier posts on the Practice Fusion litigation spelled out the consequences of noncompliance:
Even well-intentioned technology developers face AKS risk because when contracting with healthcare providers for certain products and/or services, certain financial models give the Office of the Inspector General (“OIG”) and Department of Justice (“DOJ”) tremendous pause, even if they are not categorically illegal. For example, the OIG has stated in an advisory opinion that billing contracts based a percentage collection can implicate the AKS because it presents a risk of fraud or abuse by providing the vendor with an incentive to up-code. For example, a healthcare provider sends a patient’s Medicare claim to a biller, who in turn up-codes the patient’s bill making it more expensive, with that remuneration then flowing back to the provider who distributes a second cut (the percentage on collections) back to the biller. This is a classic AKS violation, which criminalizes referring or recommending a service or product that is reimbursable (at least in part) through a federal healthcare program in exchange for something of value.
The same principles can apply to technology contracts. Even contracts by which the developer receives a cut of federal money secondhand can implicate the AKS. For example, the DOJ has repeatedly threatened certified EHR vendors with prosecution for violating the AKS for implementing referral programs. The DOJ argues that the AKS is implicated because the EHR is reimbursable through the EHR Incentive Program, which paid healthcare providers for implementing and/or using (depending on the year) the EHR (who in turn paid the developers subscription fees). In other words, secondhand federal money carries risk. Doing business with healthcare systems that receive funds for healthcare technology through grants would likewise implicate the AKS.
If your contracts and products implicate the AKS there are some means you can take to protect yourself. First, check and see if an exception could apply. If it does, it operates as a safe harbor. You can find a list of exceptions below:
https://www.law.cornell.edu/cfr/text/42/1001.952
For example, a discount on a product reimbursable through a healthcare program, like a telehealth solution paid for by a federal community health grant, could implicate the AKS. But you can find safe harbor by applying the discount exception, which is aimed at ensuring that the federal government gets its money back if the grant calls for clawbacks.
Even if you cannot find safe harbor in an exception, there are other ways you can protect yourself. While the AKS doesn’t appear to require a lot, it is intent-based: the defendant must violate it knowingly and willingly. It is a criminal statute as well, so it must be strictly constructed. If the intent of the payment of something of value is not to induce the purchase of an item reimbursable under a federal healthcare program, then you may not have violated the AKS. For example, a healthcare technology vendor may enter into a contract where they take a cut of all revenue generated by telehealth visits. The AKS is implicated, but is it violated? Healthcare providers like these arrangements because it operates as a pay-as-you-go (which is great for new delivery models) and holds their partners financially accountable. But there’s a lot of risk because the vendor is financially motivated to generate more patient visits to make more money.
As a developer you want to address the following three (3) factors to minimize your AKS risk:
- Control costs. Ensure that costs to federal healthcare programs are properly controlled for.
- Don’t practice medicine. Ensure that medical decision making stays with the clinician and free of financial motivation.
- Be interoperable. Ensure that patients (and clinicians and healthcare organizations) do not become trapped into referral loops because their clinical records are trapped in your system and cannot be extracted.
You want to do this in contract and in practice, preferably by practices that are backed up with written policies and procedures. Let’s take that telehealth vendor who is getting a cut of every patient visit. First, to control costs and protect medical decision making make sure that visits are not being ordered when they are not necessary. Ordering visits should be placed squarely on the physician, and this responsibility should be spelled out in contract. The contract should further specify that the developer is in no way responsible for stating whether ordering a visit is appropriate clinically, legally, or under any insurance policy: and staff should be instructed to do the same. The developer should be able to terminate the underlying agreement in the event its platform is used to violate any law, and it should do so if a healthcare provider demonstrably commits fraud with its technology. The developer and customer should require each other to maintain policies and procedures that protect against fraud, waste, and abuse. These are just a few – but important – considerations.
Finally, commit to an exit with the customer. The OIG and DOJ look at data illiquidity very unkindly because patients can become trapped in a health system when their records are hostage. If the product is certified to the right criteria under the ONC Health IT Certification Program, the Government will grant it the presumption that it is interoperable, and committing to that in contract can go a long way to proving that a certain technology doesn’t lend to the creation impermissible referral patterns. However, that program doesn’t actually address telehealth outright, so that vendor’s approach might be different. To start, the developer would want to specify upfront and in contract what data is captured, how it is retained (and backed up), and how it will come out of the system at the end of the contract. If there’s a fee, that should be specified that as well. There should be no surprises at the end of the relationship between the developer and provider with respect to what happens to patient data.
eHealth Law Blog 