This February, draft federal rules on health data interoperability, information blocking, health IT certification, and health data exchange related to Medicare/Medicaid conditions of participation were proposed by the Centers for Medicare and Medicaid Services (CMS) and the Office of the National Coordinator for Health IT (ONC). After releasing these proposed new rules CMS and ONC opened the field to comments and questions from interested and invested parties such as health care companies, providers, and current and future patients. In part 1 of this series, ONC Rules On APIs, Information Blocking, and Data Exchange, we dove into the implications that stakeholder sentiments on the ONC rule may have on digital health or health IT-enabled companies. Here we’ll focus on how the top issues raised by stakeholders on the CMS Interoperability and Patient Access Proposed Rule may impact your current business model and product designs. While the CMS rule targets providers and health plans, the changes this rule will demand, in it’s final form, will have impacts on digital health companies or technology vendors. Companies building health technologies or offering health IT enabled services must design solutions that address provider burdens and patients’ desired outcomes in order to be successful in today’s CMS-influenced health care markets. Understanding public input on the draft versions of these federal rules and preparing for the final versions should not be overlooked—this can improve your company’s sustainability trajectory. Our experts at Elevation Health Consulting have poured over the array of submitted public comments and distilled the following top five takeaways:
1. API-based access for patients and caregivers to their health information: CMS’ rule requires Medicare Advantage organizations, state Medicaid Fee For Service (FFS) programs, Medicaid managed care plans, Children’s Health Insurance Program (CHIP) FFS programs, CHIP managed care entities, and Qualified Health Plans (QHPs) issuers in Federally Facilitated Exchanges (FFEs) (excluding issuers of Stand Alone Dental Plans (SADPs)) to implement, test, and monitor an openly-published API that is accessible to third-party applications and developers. This is designed to help give patients access to their longitudinal health information via the Application Programming Interface (API). CMS’s intent here is to provide patients and caregivers with the full breadth of the patient’s electronic health information so that the patient can fully control their information and actively engage in their own health care. Commenters were largely in favor of this change. However, there were concerns that the information provided to the patient might be of minimal value or difficult to interpret (such as a document with a billing code, or an imaging test that does not include the image itself). They were also concerned that individuals may not understand the HIPAA implications of downloading or sharing their health information through an API.
What this may mean for your company – This issue raises an opportunity for health IT developers to create user-centered health IT interfaces that allow patients to better access their health data, interpret their health conditions in actionable layman’s terms, and transmit their health data to their care team . Patients require more information in order to more easily and effectively engage in their care and make decisions that truly represent the outcomes they desire for themselves. The market is ripe for middleware products that provide “data access with guidance” to provide patients and caregivers maximum utility of the health data CMS is enabling them to now access and control.
2. APIs between providers and payers: The CMS proposed rule included a request for information (RFI) regarding the sharing of information across APIs between providers and payers. The data to be shared falls into two categories: payer/claims data (e.g., billing codes that indicate what services were provided) and encounter data (e.g., physician notes, clinical encounter details not added to billing data). The RFI signals CMS’s interest in exchanging both types of data but falls short on clarifying the implementation approach. As a result, many commenters requested that CMS also include requirements for dates-of-service data. Commenters noted the lag time between the dates services are delivered to a patient and when claims are processed. Without the availability of dates-of-service information, commenters were worried that large scale data analyses will result in faulty conclusions and therefore should only be for educational purposes.
What this may mean for your company – If your company is in the business of collecting, storing, or exchanging health data via APIs, it will be critical to ensure date-of-service metadata as part of your platform’s design. Even if CMS does not require date-of-service information this time around, it will most probably be included in a future version of the rule. Most importantly dates-of-service metadata that travels with exchanged health data will allow your data platform to immediately be more valuable to your “provider” and “payer” clients who will be using this data to improve their revenue models.
3. Patient Event Notification Requirements in Conditions of Participation (CoPs): CMS has proposed new Conditions of Participation (CoPs) that require Medicare and Medicaid participants to meet certain data interoperability capabilities or lose the ability to participate in Medicaid and Medicare programs – even if they never received health IT incentives (a.k.a Promoting Interoperability Incentives) from CMS. One such CoP requirement involves notifying the patient’s primary care physician (PCP) of a new patient event outside of the PCP’s office. Commenters on this requirement fell into two groups: those who do not receive health IT incentives felt that these rules were punitive and costly. However, data interoperability and continuity of care advocates were very much in favor of this CoP requirement and felt that requiring everyone to participate would result in significantly improved patient outcomes.
What this may mean for your company – If your company supports health professionals and their practices in serving Medicaid and Medicare beneficiaries, they’re going to need your application or service to support patient event notification to the patient’s primary care physician. Building on the previous section, dates of services will be important for creating a comprehensive medical record. Clients who have not been previously incentivized to adopt health IT may be more reluctant to adopt digital platforms and services that do not directly correlate to CMS requirements. Your company must design relevant revenue models that recognize which stakeholders are in a position to support any products to meet CMS’s interoperability CoP requirements, including patient event notification capabilities. Our experts at Elevation are familiar with numerous areas of additional HIT funding and novel approaches to revenue models that support various health care providers, whether they do or do not fall within federal definitions for Meaningful Use Health IT Incentive dollars.
4. CMS is doubling down on National Plan and Provider Enumeration System (NPPES). In July 2018 CMS updated the National Plan and Provider Enumeration System (NPPES) to include digital contact information for providers. However, many providers have not added their information to the system. CMS is now requiring that providers add their practice information and proposes public reporting of providers who do not add their contact information within a specified timeframe. While many commenters supported this update, some worried about its practicality in modern distributed health care practices, such as telehealth. While it may have been true that a typical doctor’s office used to have one address and phone number, it may not be practical or realistic to assume that all healthcare providers do. Those who work in multiple locations (such as a multi-office private practice or a hospital system) or health care professionals who do not have a traditional office probably don’t have one single address. Other considerations include telehealth professionals who worry about their own safety if they are required to add their home address and phone number.
What this may mean for your company – While CMS is getting pushback on this requirement from some stakeholders, you and your company will have to provide a product or services that can incorporate different care delivery modalities for the practicing providers – whether it be institution-based, community-based, telehealth/virtual, mobile – but takes physician safety seriously. This suggestion is particularly important for Health IT companies employing telehealth models where they have providers deliver care exclusively through their remote platforms.
5. Timing of the Trusted Exchange Networks requirements. One new provision would require MA plans, Medicaid managed care plans, CHIP managed care entities, and QHPs in the FFEs to participate in trusted exchange networks. Many commenters were very supportive of this provision, but they want CMS to ensure that requirements to participate in trusted exchange networks are aligned with ONC’s final Trusted Exchange Framework and Common Agreement (TEFCA) guidelines and do not go into effect until they have reasonable time to comply with TEFCA. The final TEFCA rule is expected at the end of 2019.
What this may mean for your company – ONC’s TEFCA rule may be released as early as this year. Enactment dates can differ from the date a rule is released, so paying close attention to them could save you and your company time, money, and headaches. Building in a buffer within your business strategies and product release timeline lines that allow you to incorporate the TEFCA rule and enable your clients to become TEFCA complaint could result in significant cost and time savings. For example, it will be crucial to determine if and how your product will interface with or serve as a health information service provider (HISP) and what local or regional data exchange partnerships will make sense for your company. Our experts here at Elevation Health Consulting have spent the better part of their careers working with ONC and CMS on all the rules and guidelines mentioned in this blog. We can help you work through the business implications of these new regulations.
Overall, commenters were supportive of improving API capabilities to exchange data, both between providers and payers, and payers and patients. Stakeholders seemed to be unified in seeking increased utility of health data for improved patient outcomes as well as streamlined and optimized payments. However, there are several pitfalls an unsuspecting health tech company could find themselves when providing digitally-enabled services to health providers, payers and patients if certain aspects of this draft rule survive in the final version. Paying close attention to the CoPs and enactment dates are key. Our experts are available to aid you in navigating these changing rules and regulations to help you and your company optimize compliance, maximize revenue, maximize relevance in today’s health care delivery market.
