Alliance of Community Health Plans Supports Consumers’ Right To Access Their Own Health Information
* * *
- Makes recommendations to get the right data to the right people at the right time while keeping it private and secure
* * *
"These rules are an important step in health care affordability, putting patients first and giving them the power to make wise health care decisions. Safe and secure information sharing is critical to improving coordinated patient care and health outcomes," said ACHP President and CEO
The technical standards required to implement the proposed rule are not ripe for adoption. For this reason, ACHP recommends CMS issue an interim final rule to provide more time for maturity of the standards, greater clarity about the expectations of health plans and allow for additional stakeholder feedback to refine and strengthen the rule. ACHP's 24 member organizations are eager to work with HHS to continue refining the rule, particularly around implementation and nonprofit, regional health plans.
ACHP also recommends that CMS updates the implementation timeline with requirements phased in 18 months from the issue of the final rule. Ideally, CMS would synchronize the requirements of health plans and providers to a 2022 timeline, which would allow for a reasonable timeframe for consumer education, the maturity of standards to make sure consumers are provided actionable information and help ensure cost efficiencies in modernizing the technology.
Nonprofit health plan members of ACHP are dedicated to making sure the right data is received at the right time from the right source by the right person while making sure information is kept private and secure. They take their commitment to health plan members -- their care, their information, and their privacy -- very seriously and are weary of a technology solution that endangers that privacy just for the sake of deploying technology.
ACHP member health plans often work with small margins, operating judiciously and maximizing the value of every dollar. As a result, finding sufficient funding to implement the interoperability rules would place additional burdens on plans already attempting to deliver the most valuable care possible. That is why ACHP also recommends that CMS consider grant funding be made available, particularly for smaller, community-based organizations, to fully stand up the systems required ensuring privacy and safety of patient data.
Lastly, ACHP encourages HHS to collaborate with
"ACHP and its members are committed to patient safety and quality coverage," said Connolly. "We look forward to serving as a resource to ONC and CMS as we collectively work to modernize current health data systems and improve care coordination."
Full comment letter to CMS here (https://achp.us16.list-manage.com/track/click?u=bb67b9dcf3991aae5e186cf4f&id=ab3a2fb4ba&e=7513314648).
Full comment letter to ONC here (https://achp.us16.list-manage.com/track/click?u=bb67b9dcf3991aae5e186cf4f&id=821c32907e&e=7513314648).
About ACHP
* * *
To:
Attention: CMS-9115-P
P.O. Box 8013
Submitted via www.regulations.gov
RE: Medicare and Medicaid Programs: Patient Protection and Affordable Care Act; Interoperability and Patient Access for
Dear Administrator Verma,
ACHP appreciates the opportunity to comment on the proposed rule to promote patient access to their electronic health information and interoperable health data exchange.
ACHP member organizations support interoperable health care data exchange. Employing modern technology and transparent processes will enhance coordinated care, improve ACHP Response: Medicare and Medicaid Programs: Patient Protection and Affordable Care Act; Interoperability and Patient Access (CMS-9115-P)
While the ACHP member organizations are generally supportive of the goals of the proposed rule, it is critical that CMS recognize the distinction between the minimal health data that payers possess and the comprehensive medical records maintained by clinicians. As detailed below, ACHP wants to make sure that reliable information is received at the right time by the right person from the right source, so that consumers can trust that the data they receive is actionable, private, and secure.
In summary, ACHP offers the following comments:
1. ACHP supports the use of open APIs (application programming interface) for data sharing, but the technical standards required to implement the proposed rule are not ripe for adoption. ACHP recommends that CMS issue an interim final rule to provide more time for feedback on the following suggestions. CMS should:
a) identify the standards for APIs, align them with ONC's standards, and adopt implementation guides;
b) provide greater clarity about the technical standards, allow for a staged implementation to consider the operational realities of these requirements and the further development of industry standards;
c) explain how payer APIs will be measured, monitored, and enforced;
d) invite plans to test standards and use cases for the purpose of developing an interoperability implementation process for the industry over the next several years; and
e) provide federal grant funding opportunities and other support so that health plans may afford the necessary workforce and contractors to implement the scope of work envisioned by the rule.
2. The scope of data that plans are being asked to provide is excessive. To serve the goal of providing consumers with actionable and meaningful data, without creating unintended consequences, ACHP member plans request that CMS provide more guidance on how payers may offer the appropriate, minimum necessary information in response to an enrollee's request. Most importantly, health plans should not be asked to provide clinical data or proprietary contract information.
ACHP Response: Medicare and Medicaid Programs: Patient Protection and Affordable Care Act; Interoperability and Patient Access (CMS-9115-P)
3. ACHP member companies are unable to comply with the
4. ACHP is concerned about keeping health information private and secure under the proposed rules. We request that CMS consider the following to increase the confidence of health care entities and consumers before requiring data transfers to unregulated third party applications:
a) Establish liability parameters;
b) Identify protocols that transfer liability and regulatory burden from one actor to another;
c) Identify best practices to hold non-HIPAA entities accountable for managing PHI; d) Create a "white list" or other source of trusted app vendors that plans may safely rely upon.
5. Conceptually, ACHP members agree that sharing plan information with other plans is important to coordinate our enrollees' health care, but there are operational considerations that must be addressed.
6. ACHP agrees that provider directory information should be made available to enrollees through an API, but there is disagreement on how to address poor data quality and other issues that must be settled first.
7. ACHP agrees that a Trusted Exchange Network concept will allow for broader interoperability, but descriptions of an exchange network need to be further defined. Finally, ACHP member plans offer their thoughts on the requests for information in the CMS proposed rule.
ACHP Comments and Recommendations on the Proposed Rule
PATIENT ACCESS THROUGH APIS
ACHP applauds the goal of making patient data available in a standardized format through an API so that third parties can offer applications that make the data available in an understandable, convenient and timely manner for enrollees.
We have several concerns with the proposed rule's implementation requirements:
A. the technical standards,
B. the scope of data,
C. the timeframes proposed, and
D. privacy. ACHP Response: Medicare and Medicaid Programs: Patient Protection and Affordable Care Act; Interoperability and Patient Access (CMS-9115-P)
1. Technical Standards
RECOMMENDATION: ACHP requests that CMS publish an interim final rule to further explore the standards and compliance provisions so these critical aspects of the rule will have the full benefit of the industry's experience and solutions. It is important to allow for ample time to consider the operational realities of these requirements, provide greater clarity about the rules, allow for the further development of industry standards, and provide for a public comment period as the full panoply of consequences becomes clearer over time.
OUR REASONING: Unlike health care providers who have had many years of experience with several stages of Meaningful Use of Electronic Health Records (EHRs) certification, APIs are a new concept to health plans. This marks the first time that every health plan in the country will have to work with - or even identify - IT vendors to implement an API platform to meet the proposed rule data access requirements.
The rule refers to API specifications that are aligned with HL7 FHIR standards, which were engineered for clinical interoperability, not for information maintained by insurers. Instead, the payer community is familiar with HIPAA-named administrative transaction standards such as EDI standards defined by ASC X12N. The rules further anticipate that the
RECOMMENDATION: ACHP seeks greater clarity about the technical standards, and requests a staged implementation to consider both the operational realities of these requirements and for the further development of industry standards. ACHP requests that CMS invite plans to test standards and use cases for the purpose of developing an interoperability implementation process for the industry over the next several years. OUR REASONING: ACHP supports the overall goal of identifying a set of base standards adopted by ONC for APIs and FHIR to improve information sharing among health care stakeholders. We applaud the Administration's efforts to steer the industry away from pointto- point data sharing solutions that tend to block information, frustrate the coordination of patient care and increase the cost of doing business. Standard APIs and FHIR-based applications will be a great opportunity for health plans to better engage enrollees for care management and allow a more transparent and collaborative process with providers. Our members require greater clarity about the four sets of data exchanges called for in the proposed rule. Simply put, there is a lack of identified and available standards that have been finalized, tested and are mature for industry-wide use to provide these data sets to enrollees, health plans, providers and others.
While work on these standards is underway, it will be some time before any are ready for adoption and use. The new initiatives underway for payers, most visible in the
ACHP Response: Medicare and Medicaid Programs: Patient Protection and Affordable Care Act; Interoperability and Patient Access (CMS-9115-P)
We recognize that the
Even if efforts are underway to help bridge these significant standard development gaps, we are unable to forecast our plans' capabilities to implement them, assess how long it will take, or the resources required, to comply with the proposed rule.
RECOMMENDATION: ACHP supports the alignment of the technical standards between ONC and CMS and does not support a separate set of standards for health plans. We ask that CMS clearly identify the standards for APIs, align them with ONC's standards and adopt implementation guides.
OUR REASONING: Perhaps to address the lack of payer-available standards, CMS is referring plans to the API technical standards that ONC is proposing for adoption in its proposed rule for health care providers, IT developers and health information networks. ACHP member plans appreciate the willingness of CMS to provide flexibility, but we believe that it would be helpful if CMS identified the API specifications necessary to meet the data access requirements.
It is also clear that USCDI is not yet appropriate for health plans. CMS is proposing that plans be ready to receive and disclose USCDI information, including clinical data and financial data, but the USCDI does not yet include financial data - information that is typical in an Explanation of Benefits. CMS must also recognize that payers do not have all of the clinical data that is available to providers.
RECOMMENDATION: ACHP requests further explanation about how payer APIs will be measured, monitored and enforced.
OUR REASONING: As health plans are not required by CMS to submit their API technology to an ONC-like certification process, it is unclear how CMS would assess compliance with the rule's requirements. The rule is silent on enforcement or an audit procedure, creating uncertainty about health plans' responsibilities and ability to comply. It is unclear how payer APIs will be measured, monitored and enforced.
If these requirements are to be enforced as a condition of annual contract for MA plans, for instance, CMS should define the process to determine compliance, and a process for correcting actions before blocking a contract. ACHP member plans are concerned that patient care may be disrupted, so CMS might consider a monetary incentive or penalty, instead of an all-or-nothing condition of a contract.
ACHP Response: Medicare and Medicaid Programs: Patient Protection and Affordable Care Act; Interoperability and Patient Access (CMS-9115-P)
If there was more time, a mature solution built for multiple payer organizations could be developed that anticipated many typical plan internal and integration scenarios. Given that health plans do not widely use FHIR APIs, this is not possible in the short-term, but CMS could invite plans to test standards and use cases for the purpose of developing an interoperability implementation process for the industry over the next several years. RECOMMENDATION: ACHP requests that CMS arrange for federal grant funding opportunities and other support so that health plans may afford the necessary workforce and contractors to implement the scope of work envisioned by the rule.
OUR REASONING: For payers, significant resources will be necessary to collect data from numerous sources and conform them into a data set that could supply an API. With multiple membership and claims data engines, the required data is typically spread across several different payer platforms, operational and analytic data stores, and multiple provider tracking systems. The technical integration tools required must be selected and licensed to provide HL7 and FHIR development support. It is unclear how many vendors are in a position to provide the necessary roadmaps to offer this support to the payer community. Moreover, it is unusual for payers to have in-house IT staff experience with HL7 and FHIR. It will require several months to build the consulting resources and internal staff training to develop the necessary competency for an API project like the one anticipated by the rule. Constructing these APIs is a non-trivial undertaking. The implementation roadmap appears to assume an ability to receive notifications and take responsibility for accepting, consuming and storing information pushed from external parties. This is an effort well beyond simply being capable of publishing internal data to interested parties.
Finally, it is clear that FHIR standards will evolve over time, creating a non-trivial lifecycle of investments for several years to maintain compliance.
Without a widely-available solution, ACHP member plans in particular are faced with an unlevel playing field between the very large and well-capitalized health plans and smaller, community-based plans that cannot spread this capital investment across millions of enrollees. This is particularly important given the ACHP member plans' participation in the individual market with scarce competition. We want to continue to support our individual plan members, but this rule would create an additional burden on our non-profit, smaller health plans.
As a result, we believe that CMS' assessment of payers' initial and ongoing investment is too limited. More importantly, there are better ways to accomplish these policy goals than asking each individual plan to create multiple processes while spending significant resources to collect data from numerous data sources and conform them into a data set that could supply an API. Supporting the
2. Scope of Data
RECOMMENDATION: ACHP member plans request that CMS provide more guidance on how payers may offer the appropriate, minimum necessary information in response to an enrollee's request.
OUR REASONING: The scope of data that plans are being asked to provide is ill-defined, excessive for a consumer's needs, and is more likely to create unintended consequences than it is to provide actionable data for consumers. The "minimum necessary" standard regulates the use of PHI by covered entities and their business associates for purposes of treatment, payment and health care operations. There is no urgent need to exceed the minimum necessary threshold by expanding the definition of health information or by promoting access to a patient's full record, regardless of purpose.
The subject areas covered by the API-ready data requirements are broad in scope. At a minimum, plans are likely to be asked to provide information related to plan eligibility, evidence of benefits, pre-authorizations, subrogation, coordination of benefits and claims that have, or are undergoing a grievance and appeal process. Many of these areas are selfcontained within specialized health plan systems and may require access to attachments - current infrastructure will need significant rationalization and investment to support some of these operations, particularly if plans are relying on external partners and solutions. Health plans claims data systems operate according to HIPAA transaction standards, but this exchange of information between providers and plans is not comparable to an enrollee's request for information. Rather, claims data encompasses multiple data elements that are meaningless and unhelpful for consumers. Indeed, the data in a claims database is not designed to advance clinical care, so it is important to identify which elements within a claim - items that are part of an Explanation of Benefits, for example - should be provided to the consumer.
RECOMMENDATION: ACHP asks CMS to remove the requirement that clinical data be shared by health plans with third-party apps. Clinical information may be valuable for payer to payer communications for the purpose of care coordination, but asking payers to provide clinical information to consumers will result in unintended safety issues.
OUR REASONING: Asking health plans to provide clinical data to consumers is inappropriate for several reasons. As previously stated, payers' information systems are not designed to capture or maintain clinical data as a core purpose. Under HIPAA Minimum Necessary requirements, only the data that is minimally needed to support provider/health plan payment and operational functions are submitted by providers to plans (i.e., administrative purposes, quality reporting, risk adjustment and utilization management). Accordingly, ACHP Response: Medicare and Medicaid Programs: Patient Protection and Affordable Care Act; Interoperability and Patient Access (CMS-9115-P)
Indeed, CMS just issued a proposed rule for the inpatient rehabilitation facility prospective payment system for Fiscal Year 2020. One of the purposes of the rule is to reconcile a patient's medication list with a subsequent provider when that patient is discharged or transferred from a post-acute care setting. By proposing 22 standardized patient assessment data elements and seven social determinants of health data elements, the proposed rule will support better care continuity and coordination, clinical decision-making, early clinical intervention and better data exchange and interoperability between care settings. This is exactly the appropriate prism through which clinical data should be regulated, not through health plans.
Providing a "data dump" rather than a refined response to a data request carries with it a high risk of unintended consequences. For example, payer databases include contracted rates with providers and risk scores. Some of the data health plans collect and use on enrollees' behalf is proprietary. There are serious risks inherent in making this information and cost-sharing public because it may be reverse-engineered to determine proprietary contracted rates.
One of the data classes referenced in the CMS proposed rule to be made available by health plans is clinical laboratory information. This is another example of data that is not routinely collected and not maintained by health plans in their systems. While health plans do receive claims for clinical laboratory services, none of those claims contain the actual clinical laboratory results. Only a small fraction of actual laboratory data is collected by health plans, usually in non-structured ways.
ACHP members agree with sharing personal health information that is important to the consumer for their use, but we oppose sharing information that is meaningless to the consumer, could provide an unfair competitive advantage to others, or allow for inappropriate uses. Health plans need standards to follow to address the purpose of the information and prevent the release of data that could lead to bad or unintended outcomes.
3. Health Plans Require More Time to Assess and Implement the Rules RECOMMENDATION: CMS should remove the
OUR REASONING: Smaller, nonprofit health plans are especially unable to meet the January
1, 2020 effective date in the proposed rule. If all of the standards and implementation guides are ripe for adoption, health plans need at least 18 months from the publication date of a final set of rules to orchestrate the entire data and systems flow process. Alternatively, CMS ACHP Response: Medicare and Medicaid Programs: Patient Protection and Affordable Care Act; Interoperability and Patient Access (CMS-9115-P)
ACHP member plans need time to make changes to legacy systems, work with their vendors and plan for the monetary and human resource investments needed for compliance. In addition, more time is needed for standard organizations such as HL7 to complete work on defined standard and data content and for plans to implement these new standards. CMS may consider a phased-in timeline for open APIs starting in 2022, tying the phases to the development of standards.
RECOMMENDATION: CMS should develop appropriate and reasonable timeframes for various data categories (e.g., adjudicated and non-adjudicated claims, encounter data) rather than impose a strict one-business-day deadline.
OUR REASONING: CMS acknowledges that payers' ability to provide data within one business day will depend on providers and other plan partners submitting the data on a timely basis. Health plans need sufficient time to modify contracts and educate providers about these new timing considerations.
We recommend that CMS reference the current explanation of benefits (EOB) as the basis for defining the data structures and financial data elements that should be made available to beneficiaries via APIs. For formulary and drug benefit data, we recommend defining the specific, available elements in a detailed FHIR-based pharmacy benefit standard as an addition to USCDI.
The timeline for making these data available via API, i.e., within one day of claim adjudication/encounter receipt, is not operationally feasible. We strongly recommend a more realistic timeframe determined by industry consensus, so health plans might verify and validate requested information before uploading it to the API-accessible site. 4. Privacy
RECOMMENDATION: It is our belief that consumer privacy is paramount and extra care should be taken to increase the confidence of health care entities and consumers before requiring data transfers to unregulated third party applications. We recommend that CMS:
a) Establish liability parameters - Work with OCR and
b) Identify protocols that transfer liability and regulatory burden from one actor to another;
c) Identify a common set of industry best practices to hold non-HIPAA entities accountable for collecting, using, managing and storing PHI in conjunction with
d) Create a "white list" or other source of trusted app vendors that plans may safely rely on to relieve plans from the burden of vetting apps. Consider utilizing the experience ACHP Response: Medicare and Medicaid Programs: Patient Protection and Affordable Care Act; Interoperability and Patient Access (CMS-9115-P)
OUR REASONING: ACHP member companies are very concerned about the privacy of health information moving from a HIPAA environment to a non-HIPAA environment when information is disclosed to a third-party application. Third-party vendors working with healthcare provider organizations accounted for more than 20 percent of breaches in the healthcare sector last year, according to a
RECOMMENDATION: CMS should engage all stakeholders, including all relevant federal agencies, in a consumer education effort to ensure that people understand the risks associated with using apps. The requirement on plans to inform their enrollees about apps, how to protect their data and how to complain to the OCR and
OUR REASONING: Consumers must have enough information to make a well-informed decision about whether to trust a third-party app. Individuals should be able to grasp both the benefits and the risks of sharing information with entities not regulated under HIPAA. Health plans should be able to obtain objective evidence of the scope of consumer authorization, i.e., clear description of which specific data types the consumer authorized a third-party app to access. We are also concerned about security risks to internal systems if third-party apps are able to introduce malware or perform other damaging actions in health plan systems.
Additionally the lack of robust regulation related to use of PHI (including sensitive data such as mental health, STIs, substance use disorder, reproductive health etc.) increases the likelihood of harm to patients when the app they use is not subject to HIPAA or other strict privacy and security controls. Recent examples of technology companies using data in ways consumers did not know about, expect, or authorize suggest PHI from trusted health care entities could be used in ways that ultimately harm consumers. New interoperability requirements should follow - not precede - regulation of all apps that receive PHI (not just a subset of those apps).
ACHP Response: Medicare and Medicaid Programs: Patient Protection and Affordable Care Act; Interoperability and Patient Access (CMS-9115-P)
CMS must issue additional guidance about how to handle the following issues: a) Information being made available meets the needs of individuals regardless of language or cultural issues.
b) All of the health information subject to the HIPAA right of access may not be transferable through the API. This is a complex concept and will need to be sufficiently understandable to individuals.
c) Many enrollees are children and have particular issues related to consent. All stakeholders will need to accommodate (and possibly refine/develop) rules for minor access and control over health information and educate members accordingly.
RECOMMENDATION: CMS should work with the ONC to include a more detailed definition of what would be considered "individual access" in the Trusted Exchange Framework and Common Agreement (TEFCA), and create a set of best practices or code of conduct that the
OUR REASONING: ACHP is concerned about the Common Agreement protections in TEFCA, which is closely related to the Trusted Exchange Network participation requirement. The language in the Common Agreement definition of "individual access" contemplates that consumer-controlled apps would not necessarily have to be Participants or End Users but could instead "connect to" a Participant or End User. It is difficult to understand how an entity "connects" to the framework without being at least an End User. There needs to be more clarity about how individuals can connect to the infrastructure without giving up their rights to control how information in a personal app is further disclosed.
In the proposed rule, CMS repeatedly states that when a non-HIPAA covered entity discloses an individual's confidential health information that is not consistent with the privacy notice and terms of use to which the individual agreed, the
5. Plan-to-Plan Coordinated Exchange
RECOMMENDATION: CMS should clarify plan-to-plan data standards and prohibit the exposure of proprietary information to competitors.
OUR REASONING: We agree that leveraging interoperability to facilitate care coordination will help reduce unnecessary care and give consumers greater access to a more comprehensive history of their medical care across settings. From a conceptual standpoint, we agree that sharing this information is important to facilitate enrollees' care. ACHP Response: Medicare and Medicaid Programs: Patient Protection and Affordable Care Act; Interoperability and Patient Access (CMS-9115-P)
Our member plans are concerned, however, that some of the information CMS anticipates being shared with other payers will be used against us for competitive reasons. Payers should not be required to expose proprietary information or trade secrets.
ACHP member plans are primarily concerned that CMS is asking plans to share an enrollee's information up to 5 years after disenrollment with a competitor health plan, and cumulative data if a plan has access to multiple years of health information for an enrollee, through the USCDI data set. First, the USCDI is primarily clinical data and health plans have very limited clinical data. While plans may have limited lab orders they do not have clinical notes or other treatment information that would meet the care coordination goals sought by CMS. Second, plans would be forced to accept other plans' "bad data" without having any ability to parse out how it was misleading or contained partial information. Third, consumers frequently churn in and out of health plans and payers may be required to accept and share data for benefits they do not support and have no ability to incorporate into their data set. We are further concerned, as has been noted earlier, with the fact that there is no finalized, tested and mature standard to achieve this plan-to-plan information exchange. Without having such standard identified and defined, health plans should not be required to pursue this exchange, as it would mean that each health plan would have to use their own set of data content and standard format for exchange.
6. API Access to Published Provider Directory Data
RECOMMENDATION: CMS should create a multi-stakeholder, public-private partnership to establish data exchange standards related to provider directories, devise a demonstration project or pilot program to develop best practices, and set an appropriate implementation date that allows for adequate testing.
OUR REASONING: ACHP applauds the effort to make provider directory information available to enrollees and prospective enrollees through an API. We agree that broad availability of provider directory data would allow for innovation in applications or other services that help consumers more easily compare provider networks.
We look forward to additional guidance that CMS intends to provide on best practices relevant to FHIR-conformant open APIs to help organizations subject to the requirements proposed in the rule making. At the moment, there is no industry agreement about how to address provider directory issues.
ACHP agrees that updating these directories will be challenging as data quality continues to be poor. There is inconsistent adherence to and enforcement of existing accuracy rules that makes the CMS National Plan and Provider Enumeration System data unreliable.
This may be a good opportunity for a demonstration project or pilot program to develop best practices and make sure all carriers are prepared to launch an API solution with common ACHP Response: Medicare and Medicaid Programs: Patient Protection and Affordable Care Act; Interoperability and Patient Access (CMS-9115-P)
RECOMMENDATION: CMS should wait for TEFCA to be finalized before asking plans to participate and offer flexibility so plans may decide which approach best leverages existing trust networks and HINs.
OUR REASONING: ACHP agrees that a Trusted Exchange Network concept will allow for broader interoperability beyond one health system or point-to-point connections among payers, patients and providers. The preliminary descriptions of an exchange network need to be further defined. It appears that CMS is requiring plans to support new trading partner services for participants in the network, such as creating and managing accounts and connectivity of participating organizations. In addition, participating in a Trusted Exchange Network would require plans to provide operating costs to monitor and provide IT support - which means additional investment in new staff or outsourced contractors.
Leveraging existing trust networks is tricky because they are uneven in scope and geographic availability. There are a limited number of networks today, and there is a need to expand and integrate more plans and providers into these networks. There also needs to be recognition for the differing level of operations of each network. For instance, some networks do not support secure messaging or electronic querying - the third criterion required by CMS for a Trusted Exchange Network. For some plans, this may mean joining more than one network to meet all of CMS' criteria.
THOUGHTS ON RFIs
Thank you for seeking input on how HHS can more broadly incentivize the adoption of interoperable health IT systems and use of interoperable data across settings such as long term and post-acute care facilities, behavioral health and those settings serving individuals who are dually eligible for Medicare and Medicaid and/or receiving home and community based services. We offer the following measure concepts that can address the assessment of interoperability in these settings.
ACHP's members are long-time proponents of value-based health care payment models. Evaluation of value must incorporate meaningful measurement of value for all stakeholders, and requires interoperability across provider settings. Without such interoperability, the measures necessary for evaluating and paying for value are not possible. Metrics that evaluate value will require collection of data elements from multiple settings for a single measure, as well as longitudinal measurement to assess outcomes over time.
Additionally, value-based payment has rightly brought increased emphasis among health plans on reducing waste. The most effective and patient-centered approaches to waste ACHP Response: Medicare and Medicaid Programs: Patient Protection and Affordable Care Act; Interoperability and Patient Access (CMS-9115-P)
Tracking of patient reported outcomes, such as functional status, across time - and therefore across settings - would support critical value-based payment goals. Consistent collection and sharing of patient reported social needs as a vital sign will support care coordination and accuracy of information that is likely to change over time. Contribution of data to community level measures would support shared responsibility for improvement and would incentivize data sharing across care settings.
Thank you for seeking comment on the principles promoting interoperability in innovative payment and service delivery models through the Innovation Center ("CMMI"). The exchange of information across a variety of non-traditional data sources supports the social determinants of health and quality measure development necessary for value-based payment. We agree that CMMI should pilot the exchange of information across a variety of non-traditional data sources, including patient access and sharing of their own data via APIs. We believe this is crucial to understanding the minimum necessary data required to achieve specific use cases, as well as to build capacity for data sharing among PACs and community based organizations.
ACHP asks that CMS promote innovation and relevance of data by allowing for a range of data sources, rather than specifying a limited set. Every community and health care market has different contributing factors to the health status of its population, and the data needed to monitor, improve and pay for value will vary, accordingly.
Our member companies believe that patient matching is a critical component to the success of health care data sharing. Indeed, patient matching presents a significant barrier to data exchange and the usefulness of data that is successfully exchanged between entities. There is no industry consensus on how to proceed. The discussions range from consideration of supporting a Universal Patient Identifier (UPI) to using biometrics, referential matching, machine learning, and a host of algorithms, in lieu of a UPI. ACHP cannot make a recommendation at this time about how to proceed. Accordingly, CMS should consider creating a public-private initiative to solve the patient-matching dilemma. ACHP Response: Medicare and Medicaid Programs: Patient Protection and Affordable Care Act; Interoperability and Patient Access (CMS-9115-P)
ACHP believes that leveraging common APIs and standards to share health data between these entities is a meaningful way to ensure the entire marketplace is progressing at the same rate. We reiterate the concern about exposing proprietary information to our plans' competitive disadvantage. Without time for further clarification and analysis, we also note that exchanging data between payers and providers via APIs may pose challenges to integrated delivery systems. Responsibilities for collecting and updating certain data may be a shared responsibility across multiple organizations and it would be unclear "which side of the house" would be responsible for sharing and in what form. Conclusion
Thank you for consideration of ACHP's recommendations. If you have questions or require additional information, please contact
President and CEO
* * *
To:
Submitted electronically via www.regulations.gov
Re: [RIN 0955-AA01]: 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program
Dear Dr. Rucker,
ACHP appreciates the opportunity to comment on the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program proposed rule.
ACHP members support interoperable health care data exchange. Employing modern technology and transparent processes will enhance coordinated care, improve outcomes and reduce costs. These goals are aligned with our members' mission to improve the health system and health care for individuals and their families. ACHP agrees with the proposed rule's purpose of providing patients with easy and immediate access to their medical information, but notes that this data is kept in electronic medical record systems by their clinicians. Health plans, on the other hand, receive only enough health care data to pay claims and perform other administrative tasks. Accordingly, the proposed rule's requirement that health plans must share clinical data with consumers is inappropriate at best, ACHP Response: 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program [RIN 0955-AA01]
While the ACHP member organizations are generally supportive of the goals of the proposed rule, it is critical that ONC recognize the distinction between the minimal health data that payers possess and the comprehensive medical records maintained by clinicians. As detailed below, ACHP wants to make sure that reliable information is received at the right time by the right person from the right source, so that consumers can trust that the data they receive is actionable, private, and secure.
General Comments
Given our specialized membership, ACHP will not respond in full to the ONC proposed rule that is directed to non-health plan entities. There are a few provisions, however, that are incorporated by reference in the complementary CMS proposed rule on interoperability. There are other sections that we request either clarification or believe it is important to explain the impact ONC's proposed rule would have on community health plans. Accordingly, this comment letter covers three topics:
1. Technical standards that incorporated by reference in the CMS rule
2. Definitions of HIN and HIE
3.
Technical Standards of APIs
ONC's proposed rule refers to requiring the use of open Application Programming Interface (API) specifications and HL7 FHIR standards, which were engineered for clinical interoperability, not for information maintained by insurers. Instead, the payer community is familiar with HIPAA-named administrative transaction standards such as EDI transactions defined by ASC X12N. The rules further anticipate that the
These long-term efforts to create provider interoperability standards are unlike the new initiatives underway for payers, most visible in the
ACHP requests that ONC work with CMS to determine exactly which API and FHIR standards are applicable to health plans. We further recommend that ONC clarify that only data classes ACHP Response: 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program [RIN 0955-AA01]
Definitions of EHI, HIN and HIE
As part of its information blocking provisions, ONC proposes to define Electronic Health Information (EHI) as electronic protected health information (ePHI) and any other electronic information that:
* Identifies an individual or could reasonably be used to identify an individual
* Relates to the individual's health or condition
* Relates to the provision of healthcare to an individual
* Relates to the payment for the provision of healthcare to an individual
ONC requests comments on whether the definition of EHI should be the same as the definition of PHI under HIPAA. We strongly support the alignment of the two definitions. Aligning the two definitions will make sure that negotiated rate and price information will not be included. Further, if the definitions are identical, then the only difference is whether the information is in the hands of a covered entity under HIPAA (referred to PHI) or a non-HIPAA covered entity (referred to EHI).
Second, ONC also proposed defining a Health Information Network (HIN) as an entity that "enables, facilitates, or controls the movement of information between or among different individuals or entities that are unaffiliated." ACHP believes that this definition is too broad and could unintentionally include health plans. Current business practices that require confidentiality of communication may potentially become subject to data blocking provisions in which two entities may inadvertently form an HIN. Health plans, however, are not contemplated as being part of the information blocking provisions of the 21st Century Cures Act and should not be considered an HIN. ACHP requests that ONC clarify the definition to make clear that health plans are not included.
In another part of its information blocking provisions, ONC proposes to define a Health Information Exchange (HIE) as "an individual or entity that enables access, exchange, or use of EHI primarily between or among a particular class of individuals or entities or for a limited set of purposes." It is unclear how an HIE is distinguished from an HIN, and it is unclear whether health plans could be construed to be an enabler of the access to or exchange of EHI. ACHP recommends that ONC clarify the differences between the two terms (HIN and HIE) and provide examples of those differences. ACHP also requests ONC clarify in the final rule that health plans are not included in the definition of HIE.
First, there are federal legislative proposals being contemplated to address the issue of surprise billing. ACHP encourages HHS to collaborate with
ACHP encourages HHS to work with
The solution is not forcing health plans and their contracted providers to reveal their negotiated prices that are created as part of complex and multi-layered agreements.
Second, access to price information alone is an inappropriate, insufficient way for consumers to evaluate the value of services and health care professionals. It is imperative that consumers are equipped with a full range of comparative data on value, quality, safety, effectiveness, convenience and price to make informed decisions about their care.
Keeping in mind that consumers should receive quality-related information along with price information, ACHP recommends the following list of data categories that may be most helpful to consumers:
* Out-of-pocket costs such as deductibles, copayments, and coinsurance
* Individualized cost estimates for pre-approved procedures, making clear the difference between a price estimate and a binding quote
* For non-risk-based arrangements, encounter data with de-identified aggregate price data, to help providers proactively manage care
* For risk-based relationships, claim and encounter information may be appropriate for individual consumers, and providers may need this information to participate in value based care arrangements
Health plans already have existing processes for informing their members about coverage and cost-sharing prior to receiving care. In fact, several ACHP member companies are leaders in ACHP Response: 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program [RIN 0955-AA01]
We recommend that providers be required to publish pricing data both by line item (e.g., billing code) and by bundled services. Alongside these data, health care facilities should publish the percentage of time when an out-of-network provider is used so that a patient can calculate the risk of receiving a "surprise" bill when using that facility.
Third, ACHP supports the use of FHIR-based standards for enabling payer price transparency.
This information may be shared, where appropriate, before the services are delivered. An API exchange could facilitate such an approach for providers to request and display cost information from payers and/or practice management software to enable clinician and patient to engage in shared decision-making on necessary pharmaceutical, device or other treatment interventions. At the moment, there is no set of standards available for this level of price transparency.
ACHP requests that ONC work with CMS and the health plan industry to create the workflows necessary to support providers and payers that would appreciate these value-based relationships.
Conclusion
Thank you for considering our recommendations. We look forward to serving as a resource to the
Sincerely,
President and CEO.
Australian Central Bank Cuts Rates And U.S. May Soon Follow
Rep. Neal Seeks Information on Expanding Long-Term Care Services Through Medigap
Advisor News
- Nationwide Financial Services President John Carter to retire at year end
- FINRA, FBI warn about generative AI and finances
- Prudential study: Babies born today will likely need nearly $2M to retire
- Economy performing better than expected, Morningstar says
- Advisors have more optimism post-election
More Advisor NewsAnnuity News
- Prudential Financial to Reinsure $7B Japanese Whole Life Block with Prismic Life
- Nationwide Financial Services President John Carter to retire at year end
- Pension Rights Center: PRT deals could lead to ‘nationwide catastrophe’ regulated
- Allianz Life Retirement Solutions Now Available Through Morgan Stanley
- Midland Advisory Focused on Growing Registered Investment Advisor Channel Presence
More Annuity NewsHealth/Employee Benefits News
- CVS Health to cut another 13 jobs connected to its offices in Hartford
- Findings from Icahn School of Medicine at Mount Sinai Broaden Understanding of Dementia (Self-funded Personal Care Is Common And Costly For People With Dementia Across The Income Spectrum): Neurodegenerative Diseases and Conditions – Dementia
- Health care impacted by cybersecurity, regulation and AI in 2025
- MNsure sets record as more than 167,000 Minnesotans sign up for health insurance
- Indiana Black Legislative Caucus Unveils 2025 Legislative Agenda
More Health/Employee Benefits NewsLife Insurance News
- Exemption Application under Investment Company Act (Form 40-APP/A)
- Prudential Financial to Reinsure $7B Japanese Whole Life Block with Prismic Life
- Nationwide Financial Services President John Carter to retire at year end
- PHL Variable policyholders: moratorium on policy benefits ‘inequitable’
- How to identify ideal prospects for long-term-care insurance
More Life Insurance News