Two Little Letters -- A World of Difference

Earlier this week, I blogged about the FDA's new Digital Health Center of Excellence, the virtual group responsible for all things regulatory in nature affecting digital health. As a part of their remarks to begin the first of two listening sessions, the FDA provided a list of thirteen areas on which the DHCoE will focus. Included among these were "Software as a Medical Device" and "Software in a Medical Device". I wanted to dive a bit deeper into what appears on the surface to be a small difference but in reality has a mighty impact -- at least it does today. 

Software as a Medical Device 

 In 2013, as a part of their final document titled "Software as a Medical Device (SaMD): Key Definitions" the International Medical Device Regulators Forum (IMDRF) released its definition of "Software as a Medical Device" (SaMD): 

The term “Software as a Medical Device” (SaMD) is defined as software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.

According to the IMDRF SaMD can be interfaced with or used in combination with medical devices and includes in-vitro diagnostic (IVD) medical devices. SaMD is capable of operating on general purpose (ie., non-medical) platforms and includes mobile apps and the cloud. However, SaMD is not necessary for a hardware medical device to achieve its intended medical purpose, specifically if the software's intended purpose is to drive a hardware medical device the software is not considered SaMD.

Software in a Medical Device

By comparison, the definition of "Software in a Medical Device" (SiMD) is a less granular. IMDRF defines it as software that is embedded in or is a part of a medical device. Health Canada has adopted the IMDRF definition of SaMD but goes on to establish four exceptions to their definition that may help to illuminate what is SiMD versus SaMD. These four categories of software are not considered to be SaMD by Health Canada:

• Software intended for administrative support of a healthcare facility,
• Software that enables clinical communication and workflow including patient registration, scheduling visits, voice calling, video calling,
• Software intended for maintaining or encouraging a healthy lifestyle, such as general wellness apps, and
• Software intended to serve as electronic patient records or tools to allow a patient to access their personal health information.

What does this mean?

It seems as though each week brings a new entry into the deep learning healthcare space. New uses for software, including predicting disease risk or progressions, using AI to detect abnormalities that may otherwise go unnoticed, using machine learning to improve the quality of diagnostic imaging, and providing real-time monitoring of critical vital signs are all recent examples of how innovators have applied software to create solutions to complex healthcare problems.

But regulation of SaMD is still in its infancy. Payers are working to adapt to changes in technology, but are struggling to keep pace with the rapid evolution. The FDA has taken the lead in modernizing its regulatory structure by creating the Digital Health Center of Excellence in an effort to provide innovators with a one-stop entry point to the FDA. The DHCoE also will be able to help developers to understand what data they need to collect in order to best position their products for FDA approval.

Payer acceptance seems to be lagging behind the FDA's efforts. Commercial payers often make digital health tools available to their subscribers and software in the form of electronic health records have become ubiquitous in most modern facilities. Acceptance of SaMD as a part of a benefit plan, and making payment for it to providers still seems to be on the horizon.

Medicare beneficiaries face the added complication of Medicare benefit categories. Medicare, as a defined benefit program, has little leeway to modernize its benefit structure to address technological shifts like SaMD. By law, Medicare is only allowed to make payment for services in defined benefit categories. For instance, Medicare can only pay for physician services and for supplies and equipment provided as a part of those services -- but those requirements do not clearly include SaMD.

Recently CMS did acknowledge that SaMD may be eligible for separate payment in the inpatient setting. CMS recently granted new technology add-on payment status to an AI software that has been shown to reduce the time to treatment and improve clinical outcomes in stroke patients. This acknowledgement by CMS that SaMD may be coverable and warrant payment under the IPPS could indicate the beginning of a shift in the paradigm that stand-alone software cannot be a coverable medical device.

Conclusion:

It isn't enough to create a newer better mousetrap -- especially in the healthcare space. Innovators in this space need to think about how to position their products in the market. The best solution may not always be to target traditional insurance reimbursement. Supporting the value proposition to payers in the commercial space by demonstrating overall system savings may encourage adoption, while demonstrating to policy makers in the federal space that the product is already contemplated in a benefit category may be a better play.

Knowing the audience, their needs and requirements and being able to incorporate those into the overall product strategy is key in this time of rapidly evolving technology.

John Warren is the Owner and Principal Consultant at Gettysburg Healthcare Consulting in Hanover, Pennsylvania. He worked at CMS for 22 years and he directed divisions responsible for rate setting and payment policy development as well as program integrity and medical review. He has consulted with numerous clients in the Medicare space interested in navigating Medicare coverage, coding and reimbursement. Visit http://www.policypros.net for information about GHC and it's services