When Is Compliance Voluntary? Some Perspectives

From time to time, we hear about compliance with federal regulatory requirements being "voluntary" for the regulated entity. In my experience, voluntary compliance is a loaded term that only works within a defined context. Bear in mind that my perspective is informed by having been concerned with the role of Health Information Technology (HIT) as used by healthcare providers, so I have always carried the bias of viewing compliance through the lens of both an HIT developer and an HIT provider user of same. Let me offer a few examples of how voluntary compliance plays out such that it is rarely voluntary considering other factors:

First, one could always make the decision not to comply and to wait and see what happens. This is not the same as "fraud" or willful negligence. I am not speaking of intentional acts of non-compliance but deliberate acts of doing nothing to comply because the costs of doing so may outweigh the negative consequences, and until and unless something becomes required, there is no negative outcome to compel a different approach. However, over the course of time, while it may be that there is no immediate consequence in terms of how one may normally think of suffering civil or criminal penalties that come from a formal finding of non-compliance, there is almost always a long-term consequence. Remember the Framm oil commercials? Pay me now or pay me later?

One could take the choice of not undertaking the effort to comply with something where there is optionality to comply or not. It may also be in such a case there is not a negative consequence to no act now for something that may become required in the future, but it may also be a hedge bet that it will bear out in one's favor in the long run to make such a decision. And sadly, it does not always work that way. Let me give two examples.

1. There is now a requirement under Medicare Part B to bill Medicare for discarded amounts for separately billable drugs. When a Medicare patient is given a medication that packaged as a single use or single dose medication but the whole quantity of the packaging is not administered, the provider is required to bill for any "wasted" quantity not administered. Without getting into the complexity of how Medicare defines billable amounts for Part B drugs, if this quantity can at least be rounded to at least one billing unit under Medicare rules for Part B drugs, the provider must bill for the discarded amount. This policy has to do with supporting CMS's ability to evaluate the way that drug manufacturers package medications as single use so that the packaging is "right sized" and not resulting in significant amounts of discarded amounts. CMS is starting to hold drug manufacturers accountable for the costs of discarded amounts billed to Medicare under Section 90004 of the Infrastructure Investment and Jobs Act of 2021. Back in 2007, this was initially a policy that was optional to the provider to bill for discarded amounts. In my experience, almost no hospitals took steps to bill for discarded drugs at the time. HIT developers responding to their clients likewise may not have invested in the necessary enhancements to develop capabilities to automate the process of clinical and financial integration to seamlessly support billing for discarded amounts. When this policy became mandatory in 2017, I observe both providers and HIT developers who did not take earlier steps to enable compliance were caught athwart as the compliance timeline was short, and while delayed some, did not provide for a great lead time for design, development, rollout and adoption.
2. The adoption of ICD 10 back in 2015 was a lesson in how to design HIT systems to anticipate changes in compliance requirements. For those not familiar with ICD 10, for my purposes here, I am speaking of it as the coding system in use for billing in healthcare in the US to describe diagnosis (ICD-10-CM) and inpatient procedures (ICD-10-PCS). Prior to the adoption of ICD 10, its predecessor version of ICD 9 had been in use for more than 20 years. Starting in the1990s and continuing through the 2000s, one might have designed HIT and coding practices and processes to only account for ICD 9 as if it would not change. This may have led to "hard coding" or hard wiring ICD 9 into software design, business logic, reference database structures, and coding routines. By hard coded or hard wired, I mean systems and processes were designed to specifically refer to ICD 9 codes rather than describing a type of diagnosis or procedure codes to be used without making specific reference to particular ICD 9 code values. This may be a complex topic to follow but one example is the design of condition-based order sets. One could define an order set for Diabetes by developing an underlying reference database structure to point to a code set for diagnosis of a particular type out of a vocabulary code set for diagnosis (e.g., of ICD-9-CM or ICD-10-CM) and have a business logic to identify the code set value for Diabetes from the applicable diagnosis code set but not specifically define the code set values for Diabetes in the structure of the order set. This is important because if the specific code set values for Diabetes were designed into the order set, then when the diagnosis code set changes, the order set is no longer functional because it uses a now obsolete code set value. This happened in many ways when ICD-9-CM was obsoleted, and ICD-10-CM adopted.

In both of these cases, a decision could have been made to either address the optionality of a compliance requirement in the present or to defer the expense of doing so until it really became necessary. For the discarded drug example, when the requirement became mandatory, it caught many off guard because the compliance timeline was short, and there was high pressure to develop usable solutions to a complex requirement without a lot of time. For the ICD 10 example, the use of hardcoded or hard-wired references to ICD-9 codes in business logic of HIT, in reference database structures, in search routines or other applications was exposed and immediately broken unless redesigned. In both cases, considerations of short-term costs and expediency had to be balanced (even if not consciously or as learned in hindsight) against longer-term costs and pressure of having to respond when requirements became mandatory. Were those the right choices? It depends on the circumstance, but I would argue foresight and engaging in complete thoughts of design for change would have been the better path in both cases.

And last, there are those occasions where compliance may be voluntary in terms of how the regulations are written, but the choice of non-compliance is no choice at all if one cares to remain credible or viable. There is no better example of this than the attainment of certification under ONC's HIT certification program or the use of Certified HIT as a hospital or a physician/clinician who participates in Medicare. ONC's certification program is officially "voluntary", and the election to use Certified HIT as a Medicare participating provider is also "voluntary". However, both are laden with consequence if one understands what it means to not pursue what is "voluntary".

1. For an HIT developer of products that align to ONC's certification program for the functionalities, capabilities, and interoperability requirements that are defined within ONC's program, it may be "voluntary" for the developer to seek certification, but it is folly to think that they would be considered viable in the HIT market if they did not.
2. For the provider user of HIT, if they participate in Medicare as a hospital or as a physician/clinician who is reimbursed under Medicare Part A or B, it may be "voluntary" to elect to use Certified HIT, but if they do not, they face consequence in terms of reduced payments under Medicare. Further, if they desire to participate in any of what are called "Advanced" Alternative Payment Models whether developed under regulation by CMS (such as the Medicare Shared Savings Program Accountable Care Organization model) or as a program under the CMS Innovation Center (such as Primary Care First), use of Certified HIT is a must.

In both of these cases, "voluntary" is a fallacy if one is serious about being considered viable in the market either as HIT developer or provider when one considers where voluntary ends and mandatory begins.

Why do I bring all this up? The choice never ends. We see many new HIT requirements coming all of the time including ONC's new certification rulemaking, and CMS's proposals around updating HIPAA standards for healthcare attachments and for payer interoperability and electronic prior authorization. We anticipate more with every cycle of CMS payment system rulemaking for quality measures, value-based programs, and payment policies that all create annual updates to requirements for use of HIT. All of these create demands for new development and adoption by HIT developers and their provider customers. In the balance of choosing to act now or later, it is a critical decision that must be undertaken. In an era of provider burnout and regulatory overload, while we must work to help regulators understand the real impact they have on those regulated, we have to take care not to build traps for ourselves in how we respond. I urge complete whole thinking to model out the impacts of how to respond to what is "voluntary".

If these things are nagging you, I am here to help. Reach out to me at [email protected] and let's talk.

#cms #hhs #hit #onc #CHIT #CEHRT #Medicare #HIPAA