Healthcare IT
Getting Ready for Open Payments
Today, the Centers for Medicare and Medicaid Services (“CMS”) released additional tips regarding submitting Open Payments data.[1] A quick refresher: Submitting data through CMS’s application, Open Payments, is the means to fulfill the Sunshine Act, a federal regulatory requirement that applicable manufacturers, group purchasing organizations (“GPOs”), and health care providers disclose: a) certain transfers of value given to physicians and teaching hospitals, as well as b) any ownership or investment interest physicians, or their immediate family members, may have in their company. As previous Open Payments reporting entities know all too well, submitting data in the Open Payments system requires careful attention to detail, and can often be a time-consuming, painstaking process. CMS’s notice included a new document, “Open Payments Submissions Suggestions,” highlighting, among other things, two key issues for reporting entities to be aware of heading into this year’s submission period: Accuracy is important. While users may submit data in the appropriate field and format, if the content of the submission contains errors – even minor errors such as stray punctuation – the content of the submission will not be valid. Takeaway for reporting entities: Carefully reviewing and validating submissions, and ensuring enough time during the process to do so, is key to a smooth and stress-free Open Payments submission process. Note that even extra spaces at the tail end of a field will cause your submission to error out – one must scrutinize that closely. Submit early in the reporting period. While reporting entities have until March 31, 2019 to report data, CMS reminded users that the system becomes busy towards the end of the reporting period – we have, in fact, seen the system hang as the submission deadline nears. Should reporting entities uncover problems, they may find themselves scrambling to meet the reporting deadline. Takeaway for reporting entities: Allotting enough time to review and validate data well in advance of the March 31, 2019 deadline ensures that any uncovered issues can be addressed without becoming major obstacles to meeting the reporting deadline. We recommend that you complete your data formatting and input no later than six weeks prior to the deadline (roughly mid-Feb.) to allow time for initial submission, clean-up of errors, and correction of those errors for final submission. We hope this notice was helpful, and we are happy to answer further questions. Dorsey Health Strategies has extensive experience in preparing and submitting Open Payments submissions on behalf of our clients, and we’d be pleased to help your organization with this year’s submission. If you’d like to learn more about how we can support you, please contact us at 612.492.6418. [1] Note that the Open Payments submission window is fast approaching, opening on February 1, 2019.
January 29, 2019
by Shira Hauschen
Healthcare IT
FDA Testing New Approaches for Review of Digital Health Device Applications
On January 7, 2019, FDA Commissioner Scott Gottlieb announced significant updates to the FDA’s pilot Software Pre-Certification Program, sometimes referred to more broadly as a Digital Health Pre-Certification Program (“Pre-Cert”). Pre-Cert was originally announced in 2017 as part of the FDA’s Digital Health Innovation Action Plan. The FDA envisions the program as a streamlined process for bringing digital health technologies to market. More specifically, the FDA hopes to develop Pre-Cert into a program by which certain digital health developers can become precertified as part of an “Excellence Appraisal.” Excellence-appraised developers could then take advantage of streamlined premarket submission processes for their digital devices. To date, the FDA has been working with a variety of stakeholders, including nine companies “represent[ing] a wide range of companies and technology in the digital health sector,” in developing the program. In connection with the announcement earlier this week, the FDA issued “three documents that, together, launch us into the next phase of the agency’s vision of Pre-Cert.” The first of the three documents is a Regulatory Framework for Conducting the Pilot Program within Current Authorities (the “Framework”). This document builds out the regulatory framework within which the FDA will implement Pre-Cert. Here are some highlights: At least to start, Pre-Cert is limited to software as a medical device (“SaMD”), 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. The FDA hopes eventually to expand the program to review all medical device software products, including software in a medical device (“SiMD”) and other software that could be considered accessories to hardware medical devices. The FDA intends to utilize the De Novo classification process (section 513(f)(2) of the FD&C Act), an existing pathway for certain new types of low to moderate risk devices to obtain marketing authorization as a Class I or Class II device as opposed to automatic Class III designation, for the next phase of Pre-Cert. Here is an overview of the proposed process: Participants with a SaMD product may participate in an Excellence Appraisal, as well as an optional Review Determination Pre-Submission. When submitting a product for De Novo Review, an excellence-appraised developer would submit a streamlined “Pre-Cert De Novo Request,” in which it would not need to re-submit information reviewed during the Excellence Appraisal or the optional Pre-Submission. Assuming premarket requirements are met, the FDA would classify the device by written order and, if the device is Class II, establish special controls, which may include Excellence Appraisal elements and postmarket data collection elements. Following a De Novo order, an excellence-appraised developer would also be able to take advantage of a streamlined “Pre-Cert 510(k)” process, in which the developer can again leverage submission requirements already documented during the Excellence Appraisal and optional Pre-Submission process. The FDA expects review of a Pre-Cert 510(k) to be more efficient than the review of a traditional 510(k). The Pre-Cert 510(k) can also be used for modifications to devices, assuming a 510(k) is required for the modification. The second document is a 2019 Test Plan (the “Test Plan”). The Test Plan lays out the scope and approach of the Pre-Cert pilot in 2019. The primary purpose of the Test Plan “is to assess whether the Excellence Appraisal and Streamlined Review components together produce an equivalent basis for determining reasonable assurance of safety and effectiveness for a SaMD product… as compared to the traditional paradigm.” Here are some highlights: Consistent with the Framework, the scope of the Test Plan is limited to: (i) selected SaMD with De Novo Requests, and (ii) selected 510(k) submissions, which would be tested as if they were follow-on 510(k)s for devices classified through a Pre-Cert De Novo Request. The FDA plans to prioritize selection of submissions that will enable evaluation and testing of all four components (Excellence Appraisal, Review Pathway Determination, Streamlined Review, and Real-World Performance plan) outlined in the Working Model (discussed below), and to focus on cases representing a broad spectrum of software developers (e.g., small and large firms, low- and high-risk products, companies not traditionally considered medical device manufacturers). During the Test Plan, the FDA will apply both the proposed Pre-Cert pathway and the traditional review process to each test case, enabling it to refine Pre-Cert and confirm the validity of the overall program. Developers participating in the Pre-Cert pilot, after an Excellence Appraisal and optional Pre-Submission, will still need to submit full traditional marketing submissions. Internally, the FDA will then create a “mock Streamlined Review package” and review the submission on parallel paths, traditional and “mock Streamlined.” Similarly, the FDA will also be internally conducting retrospective tests of SaMD regulatory submissions previously reviewed. Finally, the third document released is an updated Working Model (currently v1.0). The Working Model, which has been updated over time with continuous public input, describes in greater detail the goal, vision, scope, and process for Pre-Cert. It also includes summaries of public comments that have been received and FDA responses to them. Pre-Cert, if implemented and successful in accomplishing FDA’s stated goals, could have a significant impact on the healthcare industry beyond the software developers it promises to impact directly. Digital health is increasingly becoming an important tool for healthcare businesses. Streamlining processes for bringing digital health technology to market and modifying existing technology will in turn increase the rate at which providers are able to utilize updated digital health technologies in practice. As this technology continues to garner the focus and support of regulatory bodies, it will be important not only for developers to understand the FDA’s streamlined approval process, but also for providers to prepare for the potential transformative effect digital health tools can have on the care they provide.
January 11, 2019
by Claire H. Topp and Alex Stoflet
Healthcare IT
HIMMS, Chronic Care Management, and the Top 5 Overlooked Items
Harnessing existing digital health solutions to improve chronic care management was a prominent topic at HIMMS this year (amongst many others, including AI and cybersecurity, both of which we will cover in upcoming blog posts). While this is not a new topic, it was particularly “buzzy” this year due to the ever-increasing number of large technology and wearables vendors entering the healthcare space, and as medical device manufacturers look to pair services with their existing devices. Chronic care management, as its name denotes, involves higher-touch and ongoing communication between the patient and the provider. Since digital health solutions are a cost-effective means to connect patients and providers, and because providers can use them to reach patients at home to help correct behaviors that contribute to or ameliorate chronic conditions, digital health solutions hold great promise as an effective chronic care management tool – and, indeed, as HIMMS this year made apparent, digital health solutions are poised for exponential growth. As with any relatively new field, however, we have noticed that certain key issues tend to be overlooked, often at great cost. Here are the top 5 overlooked issues we have noted: Value proposition in a crowded market: Make no mistake about it: this is a crowded market with many different types of vendors hoping to launch the next big thing in digital chronic care management solutions. So many of the pitch decks and conversations we have been privileged to be a part of tend to focus on the market size in terms of clinical need: that there are X number of patients with Y chronic condition who would welcome Z solution. The mistake, however, is presuming that this suffices to capture attention. The barrier to market entry is relatively low (FDA considerations, if applicable, notwithstanding!), and the customers – providers and patients – are relatively wary of yet another device, application, or website to manage. Investors and customers alike will ask, what, specifically, is your digital health chronic care solution’s real value proposition; what truly differentiates you? Effectively managing a chronic condition is the baseline minimum expectation. You must offer something more. EHR integration – the how and where: Many sellers of digital health chronic care solutions tout the ability of the device or software program to integrate with a provider’s EHR and/or with a patient-facing application so that providers and patients can monitor the relevant condition. This is all to the good, as transparent, real-time results are a key facet of chronic care management. The item that is missed, however, is how that information will be displayed in the EHR; where, exactly, will it appear? Is that in readable and, importantly, reportable format for the providers? It does a provider little good if a blood viscosity result appears in the EHR as a pdf attachment that is not searchable as a discrete data element. It is important to ask vendors and potential partners this at the outset, and to obtain the answer in writing. Process flow: Providers and medical device manufacturers alike are doing a good job of convening clinical experts to discuss particular care needs and associated care management regimen. This is then translated into the digital health offering. What is missed, however, is thinking through the end-to-end process between provider, patient, and both their interactions with the software, to ensure that it’s as seamless and hassle-free as possible. Patients who would be, well, patient with a clinician who is taking a few extra moments to answer a question would not necessarily be as patient with extra clicks or wait time from a digital health program. Providers, in turn, are looking for the least amount of clicks to enable them to do what they do best: offer the patients helpful advice. Mapping out the exact flow of when and how the software – and any integrated devices – will behave, and who is required to do what, is critical. Data ownership and access: While vendors – medical device and software and analytics alike – race to develop in-house chronic-care solutions, many are looking to partner with providers to provide clinical input and data and to serve as a beta testing and initial customer site. Partnerships are proliferating, and while good attention is paid in the negotiating process to the typical business terms, we have noted that data flow, ownership, and access tends to be a secondary thought. To be clear, HIPAA, privacy, and cybersecurity are still at the front of everyone’s minds; however, the operational brass tacks of exactly what data will display where, which party will provide that data, and exactly who will access the data and its derivatives is still oft-overlooked. Just as we recommend process flows from the user-end perspective (see above point), we also have found that data maps are instrumental to a successful partnership. If you have created one for your organization for cybersecurity and breach incident response, you will find that to be a useful starting point; you will then want to discuss and create a new, macro-level flow that reflects the flow across the parties. Then, check with counsel, and ensure that the relevant contracts (e.g., partnership, services, and/or BAA agreement(s)) align with that data map. Licensure – you probably need it: “Chronic care management” encompasses so many conditions that it can, at times, be used as a marketing lure to sell wellness-related devices and services. Any company that considers itself in the “wellness” sphere and employing people to provide ongoing advice – whether by phone, video, e-mail, or other means – should make a point to check with counsel as to whether professional licensure is required. It does not matter what label you give to those employees (e.g., “coach” vs. “counselor,” or “care guide” vs. “RN”), rather, it matters what type of care is being offered through the digital health solution and what condition(s) it is addressing. A digital health solution that addresses a specific clinical condition is likely one that is regulated, which means that the employees interacting with the patient are also likely to need some form of relevant licensure. This one is a mission-critical ask, so be sure to check with counsel early on (and title your employees correctly on your website and sales materials). We welcome your suggestions for additional focus topics within this series on digital health-related issues. Please contact Shira Hauschen at Hauschen.Shira@Dorsey.com with any comments, suggestions, or questions.
March 20, 2018
by Shira Hauschen
Healthcare IT
EHR Vendors Beware: eClinicalWorks Settles with DOJ for $155 Million
The Department of Justice (“DOJ”) announced on May 31, 2017, a $155 million settlement of its lawsuit alleging False Claims Act (“FCA”) and Anti-Kickback Statute (“AKS”) violations committed by eClinicalWorks (“eCW”), one of the nation’s largest electronic health records (“EHR”) software vendors. Brendan Delaney, the original qui tam plaintiff in the case, will receive approximately $30 million as a result of the settlement. The DOJ’s complaint alleges that eCW knowingly made or used false records or statements material to false claims paid or approved by the Government and knowingly caused healthcare providers to present false or fraudulent claims for federal incentive payments that were paid or approved by the Government. More specifically, the complaint alleges eCW falsely attested to its certifying body that it met certification requirements under the Meaningful Use program, and in turn eCW caused its healthcare provider customers to make false claims for incentive payments under the Meaningful Use program by representing to those customers that eCW met applicable certification requirements. The Meaningful Use program, which was established by the Department of Health and Human Services (“HHS”) pursuant to the HITECH Act, provides for incentive payments to healthcare providers who demonstrate meaningful use of certified EHR technology. The complaint contends that eCW implemented certain “hardcoding” practices to pass certification tests without developing software that actually met certification requirements. EHR software is required to generate and transmit prescriptions using “Rx.Norm,” a standardized drug vocabulary, in order to meet certification requirements for the Meaningful Use program. However, the complaint alleges that eCW used publicly available test scripts, which identified sixteen drugs that would be tested for compliance during certification testing, to “hardcode” only the sixteen drugs necessary to pass testing into its software rather than programming the capability to retrieve any code from the database using Rx.Norm codes, which would be required for all of the other drugs. Thus, according to the complaint, eCW was able to pass certification testing without actually meeting certification requirements and falsely attested to meeting certification requirements. Relying on eCW’s representations regarding meeting certification requirements, its healthcare provider customers then made claims for incentive payments believing they satisfied Meaningful Use program requirements through their use of eCW’s software. The complaint also alleges that eCW’s system and software failed to satisfy a number of additional certification requirements, including data portability requirements, audit log requirements, and requirements to reliably record diagnostic imaging orders and reliably perform drug-drug and drug-allergy checks. According to the complaint, eCW had a number of internal communications and/or communications with customers acknowledging issues that demonstrated its failure to satisfy these certification requirements. Again, despite these alleged failures, eCW attested to meeting certification requirements. In addition to causing customers to make false claims for incentive payments under the Meaningful Use program, the complaint also alleges a number of AKS violations by eCW. First, pursuant to a “referral program,” eCW allegedly paid current users for each provider they referred who executed a contract with eCW, resulting in payments totaling in excess of $140,000 to users between 2011 and 2015. Second, through a “site visit program,” eCW allegedly paid current users to host prospective customers at their facilities, with final payouts to current users based on the number of users at the prospective customer’s practice and an additional payment if the visiting practice purchased eCW’s software, resulting in payments totaling in excess of $240,000 to users between 2011 and 2015. Third, through its “reference program,” eCW allegedly paid current users to serve as references for prospective customers and would pay an additional amount if the prospective customer purchased eCW’s software. Finally, eCW allegedly paid “consulting” and “speaker” fees to influential users who promoted its software. Unfortunately, the complaint spends much less time on AKS issues and does not provide a detailed analysis as to the aspects of these arrangements it found objectionable (e.g., the complaint fails to analyze any of the arrangements under the multi-factored test often used for AKS implications of “marketing activities,” as exemplified in OIG Advisory Opinion 12-02). As part of the settlement, eCW entered into a five-year Corporate Integrity Agreement (“CIA”) with the HHS Office of Inspector General (“OIG”). Among other things, the CIA requires eCW to: establish a corporate compliance program addressing identified issues; engage a “Software Quality Oversight Organization” to assess the effectiveness, reliability, and thoroughness of various aspects of eCW’s EHR software, policies, and practices, and to submit reports to eCW and OIG; engage an “Independent Review Organization” to review eCW’s arrangements with actual or potential sources of health care business or referrals and internal practices related to such arrangements; and provide at no cost certain options to its customers, such as free upgrades to software updated to address eCW’s noncompliance issues and the option for existing customers to transfer data to another vendor without penalties or service charges. It remains to be seen whether this settlement signals (or catalyzes) an increasing scrutiny of EHR software vendors under the False Claims Act. Regardless, the settlement serves as a warning and reminder for EHR software vendors to review current practices and products to ensure compliance with certification requirements and to analyze marketing and other activities for compliance with AKS rules.
June 12, 2017
by Alex Stoflet
