Download a PDF of The Sequoia Project ‘s Response to the Proposed Rule Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Interoperability and Patient Access for Medicare Advantage Organization and Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans in the Federally-facilitated Exchanges and Health Care Providers (CMS-9115-P)

Dear Administrator Verma:

The Sequoia Project is pleased to submit comments to the Centers for Medicare & Medicaid Services (CMS) on the proposed rule Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Interoperability and Patient Access for Medicare Advantage Organization and Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans in the Federally-facilitated Exchanges and Health Care Providers. We appreciate CMS’s demonstrated commitment to consider thoughtfully the comments that it receives from stakeholders in response to such proposed rules. The Sequoia Project is a non-profit, 501(c)(3) public private collaborative that advances interoperability for the public good. The Sequoia Project previously served as a corporate home for several independently governed health IT interoperability initiatives, including the eHealth Exchange health information network and the Carequality interoperability framework. The eHealth Exchange health information network and Carequality now operate under their own non-profit corporations. The Sequoia Project currently supports the RSNA Image Share Validation Program, the Patient Unified Lookup System for Emergencies (PULSE) and Interoperability Matters. Our comments on the proposed rule are based on our organization’s significant experience supporting large-scale, nationwide health data sharing initiatives, including assessments of interoperability and security capability of exchange participants. Through these efforts, we serve as an experienced, transparent and neutral convener of public and private-sector stakeholders to address and resolve practical challenges to interoperability, including in-depth development and implementation of trust frameworks and associated agreements. This work extends to several crosscutting projects, including patient matching, improving the quality of clinical documents exchanged, information blocking, and other matters prioritized by these stakeholders, such as health IT disaster response. Our deep experience implementing national-level health IT interoperability, including our track record of supporting and operationalizing federal government and private sector interoperability initiatives provide a unique perspective on interoperability-related provisions of the proposed rule. In this letter, we provide priority high-level comments intended to help CMS strengthen the ultimate final rule. We share an overall aim to improve the health and health care of patients and our nation through more seamless patient and provider access to patients’ health information. Overview The Sequoia Project supports CMS’s focus on interoperability and patient access to data. We provide comments based on our experience. In these comments, we highlight:

• The Sequoia Project agrees with CMS’s goals and general approach to advance interoperability and patient access to health information. We strongly support CMS’s work with the private sector, including the Da Vinci project and Health Level 7 (HL7®). We also suggest that CMS take an approach that decouples the semantics of interoperability from specific transport approaches, a model that seems to be increasingly used in CMS incentive program requirements in recent years and reflected in the focus by both ONC and CMS on interoperable data sets backed by standards for specific data elements.
• The Sequoia Project strongly supports effective public and private-sector efforts to address potential information blocking. As part of these comments, we are conveying to CMS the perspectives of the Information Blocking Workgroup of The Sequoia Project’s Interoperability Matters Cooperative, attached as Appendix 2.
• We agree that effectively addressing patient privacy concerns and refinements to current HIPAA implementation approaches are important to more effective interoperability. In February 2019, we provided suggestions in this area in response to a recent request for information from the HHS Office of Civil Rights (OCR). We indicated support for OCR’s desire to evaluate potential revisions to provisions of HIPAA regulations that may impede value-based or coordinated care.
• The Sequoia Project generally supports CMS’s proposed approach for health plans to use open APIs and the use by reference of ONC standards rather than CMS defining standards in its own rules. At the same time, we have concerns about CMS’s proposed timing and associated burdens for health plans and providers. For example, we believe that the plan adoption timetable proposed by CMS is overly aggressive given when this proposed rule was released, especially given the need for coordinated timing with ONC on implementation of standards-based open APIs across ONC and CMS regulatory requirements. We believe that CMS must provide adequate time for implementation and testing, which is typically at least 18 months from publication of a final rule.
• We strongly support the proposal for health plans to participate with existing trusted exchange networks, which have proved their value in enabling and scaling standardsbased interoperability at a national scale. We also support CMS’s plans to test ways to promote interoperability across the health care spectrum through models tested by the Center for Medicare and Medicaid Innovation (CMMI) and proposal to require that Innovation Center model participants may, where appropriate, be required to participate in a trusted exchange network that meets the criteria outlined above for health plans.
• In general, we do not believe that a new Condition of Participation (CoP) to require electronic exchange of specified information is necessary given other current and forthcoming policies, including ONC’s parallel efforts on information blocking as required under the 21st Century Cures Act, and may also create new burdens on hospitals. In contrast, we believe hospitals and facilities should be incentivized to participate in a broader set of exchange activities through trust exchange networks, as CMS proposes for health plans. We recognize that the initial focus on admission, discharge, and transfer (ADT) messages reflects a laudable intent to be focused and prioritized but at the same time, think that a focus on ADT exchange using the messaging standard referenced in the proposed rule (i.e., HL7® Messaging Standard Version 2.5.1), is too narrow given the broad scope and need for exchange. Moreover, there are a variety of current and emerging approaches to event notification that can be used by hospitals to meet the intent of the proposal. We believe therefore that referencing a specific data transport standard is premature. If CMS proceeds with this proposal to use CoPs for event notification, we suggest a focus on the functional need to send event notification rather than specific mechanisms or standards. We also urge that CMS be mindful of comments from the hospital community and others on the feasible timing to implement such a new CoP, which should likely be at some point after the effective date of the final rule.
• In its Request for Information on Advancing Interoperability Across the Care Continuum, CMS outlines the lack of adoption/use of certified health IT among post-acute care (PAC) providers and its efforts to increase standardization of data in this area. We agree with the importance of this issue. We note recent positive signs in this area, including a significant increase in connectivity in this community.
• In its Request for Information on Policies to Improve Patient Matching, CMS asks how it can leverage its program authority to support those working to improve patient matching. We agree with CMS on the importance of accurate patient matching and provide detailed comments to CMS, including a review of our own work and the need for private sector led efforts with strong federal government support. We highlight the Sequoia Project’s A Framework for Cross-Organizational Patient Identity Management.

Conclusions We thank CMS for providing the opportunity to comment on this proposed rule. We strongly support CMS’s focus on interoperability and are eager to assist in advancing a national agenda. Most respectfully, Mariann Yeager CEO, The Sequoia Project cc: Mark Roche, M.D. Alex Mugge Appendix 1: Detailed Comments CMS Goals and Approach CMS seeks to advance interoperability and patient access to health information using available authority, including its authority over various health plans. It states: “[w]hen a patient receives care from a new provider, a complete record of their health information should be readily available to that care provider, regardless of where or by who care was previously provided. When a patient is discharged from a hospital to a post-acute care (PAC) setting there should be no question as to how, when, or where their data will be exchanged. Likewise, when an enrollee changes health plans or ages into Medicare, the enrollee should be able to have their claims history and encounter data follow so that information is not lost.” The CMS proposal focuses on:

• Enabling patients to access their health information electronically without special effort by requiring payers subject to this proposed rule to make data available through an application programming interface (API) to which third party software applications connect to make the data available to patients;
• Ensuring that providers have ready access to health information about their patients, regardless of where the patient may have previously received care; and
• Proposing requirements to ensure specified payers make enrollee electronic health information held by the plan available through an API such that, with use of software it expects payers and third parties to develop, the information becomes easily accessible to the enrollee, and that the data flows seamlessly with the enrollee as they change providers, plans, and issuers. CMS proposals would also seek to ensure that payers make it easy for enrollees to identify which providers are in a plan’s network. Comment: The Sequoia Project wholeheartedly agrees with CMS’s goals and general approach. We also strongly applaud and support CMS’s work with the private sector, including the Da Vinci project and Health Level 7 (HL7®).

Challenges and Barriers to Interoperability (p. 7614) Patient Identifier and Interoperability CMS provides a summary discussion of the extent to which challenges in accurate patient identification and matching can be a barrier to interoperability. Comment: The Sequoia Project agrees with CMS on the importance of accurate patient matching. We provide detailed comments below to CMS’s request for information on this issue, including a review of our own work and the need for private sector-led efforts with strong federal government support. Lack of standardization CMS discusses the importance of standards for effective interoperability and the role of standards-based application programming interfaces (APIs). Comment: The Sequoia Project agrees with CMS on the importance of standards and standards-based APIs to augment existing, proven interoperability standards and approaches. We also agree with its intent to incorporate by reference several standards and implementation specifications proposed in a companion proposed rule by the Office of the National Coordinator for Health IT (ONC). Information Blocking In sections VIII.B. and C. of this proposed rule CMS proposes to publicly report the names of clinicians and hospitals who submit a “no” response to certain attestation statements related to the prevention of information blocking in order to deter health care providers from engaging in conduct that could be considered information blocking. Comment: The Sequoia Project does not have comments on this CMS proposal but does strongly support effective public and private-sector efforts to address potential information blocking. In addition, as part of these comments, in Appendix 2 we are conveying to CMS the approach taken and findings of the Information Blocking Workgroup of the Sequoia Project’s Interoperability Matters Cooperative of the Sequoia Project’s Interoperability Matters Cooperative. We urge CMS to give careful consideration to these perspectives. The central goals of Interoperability Matters are to:

• Prioritize interoperability matters that benefit from national-level, public-private collaboration;
• Focus on solving targeted, high impact interoperability issues;
• Engage the broadest group of stakeholders and collaborators;
• Coordinate efforts into cohesive set of strategic interoperability directions with an implementation focus;
• Channel end user needs and priorities;
• Bring forward diverse opinions;
• Support transparent public forums;
• Provide feedback based upon real world implementation to standards organizations and policy makers; and
• Deliver work products and implementation resources.

Lack of Adoption/Use of Certified Health IT Among Post-Acute Care (PAC) Providers CMS outlines issues associated with lack of adoption/use of certified health IT among post-acute care (PAC) providers and its efforts to increase standardization of data in this area. Comment: We agree with the importance of this issue. We note recent positive signs in this area, including a significant increase in connectivity for this community through Carequality and eHealth Exchange, even in the absence of government incentives, and a new initiative sponsored by ONC and CMS to identify/execute on opportunities to apply FHIR to PAC interoperability topics. Privacy Concerns and HIPAA CMS outlines issues related to patient privacy and HIPAA as they relate to interoperability. Comment: We agree that effectively addressing patient privacy concerns and refinements to current HIPAA implementation approaches are important to more effective interoperability. In February 2019, we provided several suggestions in this area in response to a recent request for information from the HHS Office of Civil Rights (OCR). We indicated support for OCR’s desire to evaluate potential revisions to provisions of HIPAA regulations that may impede the ongoing transformation to value-based care or interfere with coordinated care without meaningfully protecting the privacy or security of protected health information (PHI). The Sequoia Project and its related initiatives are committed to efficient and useful electronic exchange of health care information and agree with the need to strike an optimal balance between privacy and security and access to PHI to meet the range of legally and contractually permitted purposes for such information. We have seen firsthand how uncertainty about what is permitted or required under HIPAA has impeded organizational and individual willingness to share information and to engage with health information exchange initiatives, especially for allowed purposes other than treatment. Summary of Major Provisions (p. 7617) The Sequoia Project organizes our comments using the approach taken by CMS in its Summary of Major Provisions. Overall, CMS proposes multiple initiatives to enhance patients’ access to their electronic health care information.

• CMS proposes to create and implement new mechanisms for patients to access and direct the use of their health care information.
• CMS proposes to require that specified information be made accessible to patients via “open” APIs.
• CMS proposes to require several types of health plans over which it has jurisdiction to implement open APIs consistent with API technical standards proposed by ONC for adoption as well as adopted and proposed content and vocabulary standards. CMS also asks if it should separately specify standards for some of these areas in its own rules. CMS, like ONC in its companion proposed rule, addresses when updated standards may be used and must be used. Finally, CMS proposes that subject payers must make data available within one day of receiving data, while also acknowledging that this requirement will create pressures on capitated providers to provide information timely to support this as their receipt of data seem to count towards the one day. Comment: The Sequoia Project generally supports CMS’s proposed approach, including the definition of open, standards-based APIs and the incorporation by reference of ONC standards rather than CMS defining standards in its own rules. In this regard, we recommend that CMS continue to keep in mind the need for vocabularies and/or value  sets used for quality measure reporting to be aligned with the vocabularies used for the clinical data. We do have concerns about two aspects of CMS’s proposed timing. First, we believe that the plan adoption timetable proposed by CMS is overly aggressive given when this proposed rule was released; we suggest that CMS finalize a timetable based on when the final rule is effective, using an approach and timing similar to that used by ONC, while also being mindful of comments received from the health plan community on timing. Secondly, although we strongly support rapid and timely patient access to their data, we believe that the “one day” requirement may prove impractical in the context of the complex organizational structures involving health plans and their capitated or contracted providers.
• CMS proposes to require payers to support beneficiaries in coordinating their own care via payer to payer care coordination.
• CMS proposes that a plan must, if asked by the beneficiary, forward his or her (USCDI data set) information to a new plan or other entity designated by the beneficiary for up to 5 years after the beneficiary has disenrolled with the plan.
• CMS proposes a requirement for specified health plans to coordinate care between plans by exchanging, at a minimum, the data elements in the United States Core Data for Interoperability (USCDI) standard at enrollee request at specified times. Comment: We support this general approach, including the baseline requirement for use of USCDI. We also ask that CMS define more clearly what it intends to require by “forward” (as used in the preamble) or “send” (in the regulatory text), addressing, for example, the need for such information to be accessible to the receiving plan and to encourage use of a trusted exchange network in making such information available. In general, we agree with the specific elements of Version 1 of the USCDI, including addition of Clinical Notes as a Data Class, the initial set of note types selected, and ONC’s stated intention to expand this list over time. With respect to clinical notes, we draw CMS’s attention to a 2018 joint Carequality/CommonWell document “Concise Consolidated CDA: Deploying Encounter Summary CDA Documents with Clinical Notes, 9 February 2019. This white paper defines a path to improve the content in C-CDA exchange, including recommendations for including notes in C-CDAs.
• CMS is proposing to require that several specified types of health plans must participate in a trusted health information exchange network meeting CMS-specified criteria by 1/1/2020. CMS also discusses and requests comments on an approach to payer-to-payer and payer-to-provider interoperability which leverages such existing trusts networks. A trusted exchange network would need to meet the following criteria:
  • The trusted exchange network must be able to exchange PHI, defined in 45 CFR 160.103, in compliance with all applicable state and federal laws across jurisdictions.
  • The trusted exchange network must connect both inpatient EHRs and ambulatory EHRs.
  • The trusted exchange network must support secure messaging or electronic querying by and between patients, providers and payers Comment: We strongly support this proposal to focus on trusted exchange networks and networks which interconnect through trusted exchange frameworks that are in production now and have proved their value in enabling standards-based interoperability. We agree that ONC’s proposed TEFCA Draft 2 has significant promise but also agree with CMS that health plans can add significant capabilities now, including enhanced payer-topayer and payer-to-provider interoperability through existing trusted exchange networks.
• To address information blocking, CMS is proposing to publicly post information about negative attestations on appropriate CMS websites. Comment: As indicated previously, The Sequoia Project does not have comments on this specific CMS proposal but does strongly support effective public and private-sector efforts to address potential information blocking. The first project of our Interoperability Matters Cooperative has been a workgroup on information blocking; the work of that workgroup relevant to this proposed rule is attached as Appendix 2. We urge CMS to give careful consideration to these perspectives.
• CMS is proposing to publicly identify clinicians who have not submitted digital contact information to the applicable CMS system and is proposing to align program requirements for specified health plans to make provider directory information publicly available via an API. Comment: We support the proposal to align program requirements for specified health plans to make provider directory information publicly available via an API and emphasize the importance to interoperability of accurate and complete digital contact information and provider directories.
• CMS is proposing to revise the conditions of participation (CoPs) for hospitals (including short-term acute care hospitals, long-term care hospitals (LTCHs), rehabilitation hospitals, psychiatric hospitals, children’s hospitals, and cancer hospitals) and CAHs to require that these entities send patient event (ADT) notifications to another health care facility or to another community provider. CMS proposes to limit this requirement to only those Medicare- and Medicaid-participating hospitals and CAHs that possess EHRs systems with the technical capacity to generate information for electronic patient event notifications. Comment: As we communicated to CMS in our comments on the 2019 IPPS proposed rule, in general, we do not believe that a new CoP to require electronic exchange of specified information is necessary in the context of other current and forthcoming policies. We are concerned that compliance concerns and costs could hinder investments and actions to enhance interoperable data exchange. Duplicative or overlapping simultaneous requirements in incentive programs and CoPs could be counterproductive. In contrast, we believe that hospitals and facilities should be incentivized to participate in a broader set of exchange activities through trust exchange networks, as CMS has proposed for health plans. At the same time, we recognize that the initial focus on patient event notification (i.e., ADTs) reflects the high value of such notification as well as a laudable intent to be focused and prioritized in such a policy but at the same time, we think that a focus on ADT exchange using the ADT Messaging standard incorporated by reference at 45 CFR 170.299(f)(2) (i.e., HL7® Messaging Standard Version 2.5.1—HL7® 2.5.1), is too narrow given the broad scope and need for exchange. (Note that the regulatory text in the Federal Register version of the proposed rule references the standard at 45 CFR 170.205(a)(4)(i) whereas the “display copy” and the Federal Register preamble reference 45 CFR 170.299(f)(2). We ask CMS to clarify its intentions on the standard intended to be referenced.) Although it is generally true that hospitals have HL7® Version 2 ADT interfaces already in place, these interfaces tend to be highly customized and often focused on internal notifications, and the messages they exchange are not mutually comprehensible (by sender and external receiver) without intermediation. More generally, as indicated by CMS in the preamble, there are a variety of current and emerging approaches to event notification that can be used by hospitals to meet the intent of the proposal and convey the indicated data elements. For example, current initiatives are exploring use of the HL7® FHIR® standard for notifications. We believe that referencing a specific data transport standard, particularly without associated implementation guidance for this use case that can scale at a national level, is premature. If CMS proceeds with this proposal to use CoPs for event notification, we suggest that it focus on the functional need to send external event notification rather than specific mechanisms or standards, including explicitly allowing use of trusted exchange networks and frameworks. We also urge that CMS be mindful of comments received from the hospital community and others regarding the feasible timing to implement such a new CoP, which should likely be at some point after the effective date of the final rule.
• CMS plans to test ways to promote interoperability across the health care spectrum through models tested by the CMMI. It also proposes to require that Innovation Center model participants may, where appropriate, be required to participate in a trusted exchange network that meets the criteria outlined above for health plans. Comment: We support such tests as part of CMMI activities as well as the required engagement with trusted exchange networks, in line with our prior comments.
• CMS considered but did not include in this proposed rule a proposal to make updates to the Promoting Interoperability Program to encourage eligible hospitals and CAHs to engage in certain activities focused on interoperability. This concept was initially in a request for public comment in the FY 2019 IPPS/LTCH PPS proposed rule (83 FR 20537 through 20538). CMS discussed a possible strategy in which it would create a set of priority health IT or “interoperability” activities that would serve as alternatives to measures in the Promoting Interoperability Program It offered three examples of activities that might be included under such an approach, including: 1. Participation in, or serving as, a health information network which is part of the Trusted Exchange Framework and Common Agreement (TEFCA); 2. Maintaining an open API which allows persistent access to third parties which enables patients to access their health information; and 3. Participating in piloting and testing of new standards that support emerging interoperability use cases. CMS states that it expects to introduce a proposal for such “interoperability activities” in the FY 2020 IPPS/LTCH PPS and invites comments on this concept. Comment: We generally support CMS’s consideration of a shift from performance-based measurement to one focused on provider engagement with priority health IT activities. At the same time, CMS should carefully evaluate the implications of the specifics of such a shift on the incentives faced and likely resulting activities of providers and other stakeholders. In addition, we agree that active participation in sharing networks and agreements based on the TEFCA or other such exchange-related trusted agreements (as introduced and defined in this proposed rule) could eventually qualify for such an approach. At the same time, because the TEFCA has not been completed or implemented, we suggest that CMS await enough experience with the TEFCA before it finalizes any such approach focused on the TEFCA. We do believe that CMS could move more quickly in adding participation in an existing trusted exchange network as an activity, distinct from a connection to the TEFCA.

Requests for Information XI. Request for Information on Advancing Interoperability Across the Care Continuum (p. 7653) CMS is soliciting comment on several potential strategies for advancing interoperability across care settings to inform future rule-making activity in this area.

• CMS is seeking input on how HHS can more broadly incentivize adoption of interoperable health IT systems and use of interoperable data across settings such as longterm and PAC, behavioral health, and those settings serving individuals who are dually eligible for Medicare and Medicaid and/or receiving home and community-based services. CMS invites comment on specific policy strategies HHS could adopt to deliver financial support for technology adoption and use in these settings. Comment: As noted above, we have observed significant strides in both the LTPAC and behavioral health communities, particularly the former. Much of this momentum is relatively recent. By no means do we suggest that all challenges will solve themselves in the short term without CMS assistance or action; rather, we believe the recent progress by early adopters likely makes the timing right for action by CMS that focuses on incentives to adopt interoperable technology and participate in trusted exchange networks in the short to medium term.
• CMS is seeking comment on whether to move toward the adoption of PAC standardized data elements through expansion of the USCDI process. It is interested in whether the standardized patient assessment data elements implemented in CMS PAC assessment instruments in satisfaction of the IMPACT Act would be appropriate. If the full set of such standardized patient assessment data elements is not appropriate, it is seeking comment on whether a subset of these standardized items would be appropriate, and input on which data elements should be prioritized as part of a subset. Comment: This proposed approach would be a good place for CMS to start, especially as the PAC data elements were originally implemented in 2014, but we are not certain how much of this data is now collected electronically. We suggest that CMS pay careful heed to comments from implementers to assess the appropriate nature and pace of inclusion in the USCDI. We also believe that some of these data elements are of sufficiently general relevance and maturity for inclusion in the USCDI (e.g., functional status information) but other data elements such as information on pressure ulcers, although very important within the PAC community, may be too specific for the broader USCDI as it is currently conceived. Perhaps one alternative approach to immediate addition to the full data set would be to first develop FHIR implementation guides for the exchange of PAC assessment data elements (involving a CMS and ONC-led process for PAC use of FHIR® that we believe to be underway). These guides, once developed, could be adopted voluntarily right away by those who are more advanced, and phased into the USCDI and CMS requirements as appropriate, based on that initial experience. More generally, we suggest that the USCDI might move to a model where there is an ability to segment data classes and elements based on the capabilities of specific health IT, the data contained in that health IT, and the needs of specific users and exchange partners.

XIII. Request for Information on Policies to Improve Patient Matching (p. 7656) CMS seeks comments on how it can leverage its program authority to support those working to improve patient matching. General Comments: In our detailed comments below, we address the questions CMS poses in its request for information (RFI) and agree with CMS on the importance of this issue and the role of the private sector, with federal government support, in improving match rates. We highlight the Sequoia Project’s “A Framework for Cross-Organizational Patient Identity Management,” first published in 2016 and updated in 2018. We commend this report to CMS and point to ongoing work in this area by the Sequoia Project Patient Identity Management Work Group. We emphasize that much of the focus in accurate patient matching has been intra-organizational but that true interoperability and data liquidity will require accurate cross-organizational matching. More generally, although federal agencies are restricted to patient matching approaches instead of use of a unique identifier, the private sector should not be subjected to that restriction. We urge ONC to support and enable a competitive marketplace for secure identity solutions from commercial third-party enterprises. In addition, it is important to note that identity requirements for Payment and health care Operations are fundamentally different than identity requirements for Treatment. Financial transactions are reversible, and reports can be corrected, but patient care actions are often permanent. Accordingly, in our experience, providers have lower tolerance for false positives, and the different purposes of use should not be subjected to a lowest- common- denominator patient matching approach. 1. Should CMS require Medicare FFS, MA Plans, Medicaid FFS, Medicaid managed care plans (MCOs, PIHPs, and PAHPs), CHIP FFS, CHIP managed care entities, and QHP issuers in FFEs (not including SADP issuers), use a patient matching algorithm with a proven success rate of a certain percentage where the algorithm and real world processes associated with the algorithm used are validated by HHS or a 3rd party? Comment: We strongly support use of matching algorithms as part of an overall patient matching strategy. At the same time, we believe that such a specific mandate is premature and that the state of the art does not support valid and reliable cross-organizations comparison at a level to support such an approach. We do suggest that CMS consider the cross-organizational patient matching maturity model included in the above report for consideration as a baseline to build on as it seeks to improve both provider and health plan patient matching accuracy. 2. Should CMS require Medicare FFS, the MA Plans, Medicaid FFS, Medicaid managed care plans, CHIP FFS, CHIP managed care entities, and QHP issuers in FFEs to use a particular patient matching software solution with a proven success rate of a certain percentage validated by HHS or a 3rd party? Comment: We believe that such a mandate would be overly prescriptive. 3. Should CMS expand the recent Medicare ID card efforts by requiring a CMS-wide identifier which is used for all beneficiaries and enrollees in health care programs under CMS administration and authority, specifically by requiring any or all of the following:

• That MA organizations, Part D prescription drug plan sponsors, entities offering cost plans under section 1876 of the Act, and other Medicare health plans use the Medicare ID in their plan administration.
• That State Medicaid and CHIP agencies in their FFS or managed care programs use the Medicare ID for dual eligible individuals when feasible.
• That QHP issuers in FFEs use the Medicare ID for their enrollees in the administration of their plans. Comment: Wider plan use of the Medicare Beneficiary ID could enhance matching accuracy. The above-referenced Sequoia report concluded that substantially increased patient match rates (i.e., above 95%) may require a supplemental identifier in addition to the required fields. A supplemental identifier could be a national or regional shared identifier, such as a driver’s license number or the Medicare Beneficiary ID number, and/or validated cell phone number. High data quality of such an identifier at the point of capture is essential for acceptable patient match rates.

4. Should CMS advance more standardized data elements across all appropriate programs for matching purposes, perhaps leveraging the USCDI proposed by ONC for HHS adoption at 45 CFR 170.213. Comment: Additional data elements to improve patient matching efforts may include: Maiden Name, Multiple Birth Indicator, Birth Order, Telephone Number types (we note the high value of the validated cell phone number), and Email Address(es). More generally, data collection standards and their consistent application by health plans, providers and exchange organizations are a critical determinant to matching accuracy. The above-referenced Sequoia Project document addresses this issue in detail, including, notably, a maturity model for intra-organizational and cross-organizational organization processes to enhance patient matching accuracy, including rigorous information governance. Overall, the biggest opportunity to immediately enhance matching rates is standardized formats for demographic data among data sharing participants. 5. Should CMS complement CMS data and plan data in Medicaid managed care plans (MCOs, PIHPs, and PAHPs), CHIP managed care entities, MA Plans, and QHP issuers in an FFE (not including SADP issuers) with one or more verifying data sources for identity proofing? What potential data source should be considered? What are possible restrictions or limitations to accessing such information? Comment: CMS should not dictate specific solutions. 6. Should CMS support connecting EHRs to other complementary verifying data sources for identity proofing? What potential data source should be considered? What are possible restrictions or limitations to accessing such information? Comment: CMS should not dictate specific solutions. In addition, EHRs will not always be the primary way in which health care organizations manage patient matching and identify so a focus on EHR-based approaches is likely not warranted. 7. To what extent should patient-generated data complement the patient-matching efforts? Comment: Involving the patient in data entry, correction, and maintenance can maintain and enhance patient data integrity over time. This approach includes making it a practice to ask the patient at every visit whether their address or phone number has changed and also having the patient review their demographic information to ensure its correctness. Patient portals and other self-service applications can also help patients understand the extent of their identity completeness and how it can be increased. More generally, we recognize that more complete demographic data will only get us so far and we should increasingly look to approaches like biometric data, that rely on data that is “patient inherent” rather than simply “patient-generated”. Appendix 2: Recommendations of the Information Blocking Workgroup of the Interoperability Matters Forum