Download the PDF of The Sequoia Project’s Response to The Department of Health and Human Services (HHS) Proposed Rule: 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program (RIN 0955-AA01)

Dear Doctor Rucker:

The Sequoia Project is pleased to submit comments to the Office of the National Coordinator for Health Information Technology (ONC) on the proposed rule 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program. We appreciate ONC’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 indepth 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 and detailed comments intended to help ONC finalize this proposed 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. As part of these comments, in Appendix 2, we are conveying to ONC the approach taken and findings of the Information Blocking Workgroup of the Sequoia Project’s Interoperability Matters Cooperative. The central goals of Interoperability Matters are to:

  • Prioritize interoperability challenges 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.

We urge ONC to give careful consideration to these perspectives.

Overview of The Sequoia Projects Comments
The Sequoia Project supports the congressional intent of the 21st Century Cures legislation for greater data liquidity. We appreciate the ways in which ONC approached carefully its implementation responsibilities. Our detailed comments are in the attached Appendices 1 and 2.

Overall:

  • The Sequoia Project generally supports ONC’s approach to open Application Programming Interfaces (APIs) and the specification of several standards, including HL7® FHIR®. Of the ONC’s options for the version of FHIR® and associated standards for the final rule, we strongly support Option #4—FHIR® Release 4 (or the latest balloted version of FHIR®). In addition, to provide greater flexibility for ONC and to encourage and enable use of updated SDO-developed implementation specifications, we suggest that such implementation specifications be designated in ONC guidance rather than included in the final regulation. It is our understanding that ONC’s position is that implementation guides must be referenced in regulation in order to be included in certification criteria, but we believe that ONC should modify its conformity assessment methods to accommodate updates to implementation guidance without rule-making. We strongly encourage ONC to examine whether they have any flexibility on that question and/or consider other ways to address the concerns that motivate our request. Note that, for FHIR® Release 4, the applicable implementation guide would be US Core STU 3.1.0, which is expected to be published late 2019.
  • We ask ONC to emphasize that the proposed initial set of FHIR resources to be used with the proposed API, the API Resource Collection in Health (ARCH), is always bounded by the scope of the US Core Data for Interoperability (USCDI), that the USCDI will only include data classes and data elements that have SDO-developed implementation guides, that the ARCH will only reference HL7® FHIR® resources, and, moving forward, is transitioned as rapidly as possible to a private sector, SDO-developed implementation specification, such as the HL7® US Core.
  • We urge ONC to take careful heed of comments from providers and developers on the practicality and reasonableness of its proposed timelines and the burdens that these timelines could create, both from the standpoint of technology development and implementation and the need for development and implementation of complex new organizational policies.
  • We urge ONC to also recognize the need for flexibility for providers and developers and the need to set realistic expectations for the revised data export functionality; we encourage ONC to consider carefully feedback from the developer community on the potential challenges and cost associated with this proposed criterion.
  • On information blocking, although much of ONC’s focus is identification of “reasonable and necessary” activities that interfere with the access, exchange, or use of electronic health information (EHI) and do not constitute information blocking, the proposed practices, definitions, and the other regulatory and sub-regulatory discussions and provisions, will also have a substantial impact on implementation of this rule.
    In particular, the proposed definitions of “access,” “exchange,” “use,” and “electronic health information” (EHI) are very broad. These will interact with each other, with ONC’s definitions of the four actors, with the rule’s descriptions of information blocking practices, and with the seven proposed exceptions. The result is an extensive and heterogenous set of scenarios and use cases that will be subject to complex compliance and enforcement processes. The impact, foreseen and unforeseen, may exceed and even be inconsistent with Congress’ intent to define and limit information blocking.
  • We are especially concerned with the implications of the very broad definition of EHI and the likely impracticality of applying the information blocking provisions to this extensive, highly situational and largely non-standardized data set We suggest that enforcement focus most heavily on access to the USCDI (including API access), which will evolve over time to include more and more EHI. We pledge to work closely with the community and ONC to achieve this goal.
  • One area of great concern to The Sequoia Project is the definition of “Health Information Exchanges” and “Health Information Networks”. We believe that the distinctions between these two categories are unclear and the definitions too broad (especially for HINs) and could sweep in organizations (e.g., provider organizations and SDOs and similar organizations) that would otherwise not have liability for the very high maximum fines applicable to HIEs and HINs. These definitions could similarly subject a broad array of organizations to the very stringent requirements (e.g., on pricing and licensing) associated with the exceptions relevant to these actors.
  • Overall, we believe that the seven categories of “reasonable and necessary” exceptions are the right ones and indeed, are essential to practical implementation of the information blocking prohibition. We do, however, have concerns and questions about specific elements. We especially highlight our concern with the proposed requirement that “[t]o qualify for any of these exceptions, an individual or entity would, for each relevant practice and at all relevant times, must satisfy all applicable conditions of the exception”.
    Such a strict compliance standard may add clarity, but it is at odds with the complexity that underlies healthcare operations, for example in responding to complex security threats, and may inadvertently ensnare many individuals and organizations who are
    acting in good faith as it seeks to identify or deter a relatively few “bad actors”. We also have concerns with the costs that will be result from organizations needing to manage these complex policies and to document their actions. We comment selectively on the proposed exceptions in Appendix 1. Additional comments and recommendations on the exceptions are in the attached report (Appendix 2) from the Information Blocking Workgroup of the Interoperability Matters Cooperative.
  • Finally, we provide general and explicit comments on the Patient Matching Request for Information. We agree with ONC on the importance of this issue and of the role of the private sector, with federal government support, in improving match rates. We point ONC to 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 ONC. We especially 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.

Conclusions

We thank ONC for providing the opportunity to comment on this proposed rule. The Sequoia Project is eager to assist ONC in advancing our national interoperability agenda.

Most respectfully,
Mariann Yeager
CEO, The Sequoia Project

Appendix 1: Specific Recommendations and Comments

IV.B. Revised and New 2015 Edition Criteria
1. The United States Core Data for Interoperability Standard (USCDI) (p. 7440)
ONC proposes to remove the Common Clinical Data Set (CCDS) from the 2015 Edition of certification criteria and replace it with the United States Core Data for Interoperability (USCDI) Version 1. To achieve the goals set forth in the Cures Act, ONC intends to establish and follow a predictable, transparent, and collaborative process to expand the USCDI as well as flexibility for developers to certify to newer versions of standards that have been approved by the National Coordinator through the Standards Version Advancement Process for use in certification.
Comment: We support ONC’s proposal for the USCDI Version 1, the process for its updating over time, as well as the proposed Standards Version Advancement Process. We also support ONC’s proposal that required USCDI development and implementation will be a specified multi-month period after the effective date of the final rule as well as the ability for earlier implementation of the USCDI by developers and providers when they are able to do so. At the same time, we urge ONC to be mindful and explicit that its proposed 24-month period is inclusive of both development and provider implementation, as are other instances of 24-month implementation timing for changes to the 2015 certification criteria. We urge ONC to take seriously and make any needed adjustments to this aggressive proposed timeframe in response to comments from providers and developers on its implications.
In general, we agree with the specific elements of Version 1, 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 ONC’s attention to a 2018 joint Carequality/CommonWell document “Concise Consolidated CDA: Deploying Encounter Summary CDA Documents with Clinical NotesThis white paper
defines a path to improve the content in C-CDA® exchange, including recommendations for including notes in C-CDA®s.

4. Electronic Health Information Export (p. 7446)
ONC proposes a new 2015 Edition certification criterion for “electronic health information (EHI) export” that would replace the 2015 Edition “data export” certification criterion. This criterion would: (1) enable the export of EHI for a single patient upon a valid request from that patient or a user on the patient’s behalf, and (2) support the export of EHI when a health care provider chooses to transition or migrate information to another health IT system.
Comment: We agree with ONC’s stated flexibility in seeking to allow developers to have the ability to create “innovative export capabilities according to their systems and data practices” and that ONC does not propose to require use of a specific export standard, but the data export must be accompanied by the data format used, including structure and syntax, to facilitate interpretation. We do, however, caution ONC to be realistic in its expectations and those it conveys to stakeholders regarding the goal to “provide patients and health IT users, including providers, a means to efficiently export the entire electronic health
record for a single patient or all patients in a computable, electronic format”. Based on our experience, we have concerns that the nature of the exports available, given disparate EHR system architectures, will often fall short of this laudable goal and that the work required to implement this revised export criterion will divert from other priority interoperability goals that may be more achievable. We further note that HL7® interfaces and other interoperability tools are often used as conversion mechanisms. The more we improve the breadth and standardization of FHIR®-based APIs focused on the USCDI as it expands, the more reasonable they will be as future conversion mechanisms, reducing perceived need for separate export tools.

5. Application Programming Interfaces (APIs) (p. 7449)
ONC proposes to adopt a new API criterion to replace the “application access – data category request” certification criterion and become part of the 2015 Edition Base EHR definition. This new “standardized API for patient and population services” certification criterion would require the use of Health Level 7 (HL7®) Fast Healthcare Interoperability Resources (FHIR®) standards and several implementation specifications. The new criterion would focus on supporting two types of API-enabled services: (1) services for which a single patient’s data is the focus and (2) services for which multiple patients’ data are the focus. ONC proposes that certified health IT would need to be updated/implemented to this new criterion within 24 months of the effective date of the final rule.
Comment: We support this provision, and as addressed below, believe that of the four HL7® FHIR® standards options presented in VII.B.4, ONC should select Option #4—designation of FHIR® Release 4 (or the latest balloted version of FHIR®) in the final rule.
We also support ONC’s proposal that required USCDI development and implementation will be a specified multi-month period after the effective date of the final rule as well as the ability for earlier implementation of the USCDI be developers and providers when they are able to do so. At the same time, we urge ONC to be mindful and explicit that this 24-month period is inclusive of both development and provider implementation, as are other instances of 24-month implementations timing for changes to the 2015 certification criteria. We urge ONC to take seriously and make any needed adjustments to this aggressive proposed timeframe in response to comments from providers and developers on its implications.

7. Data Segmentation for Privacy and Consent Management Criteria
In the 2015 Edition, ONC adopted two “data segmentation for privacy” (DS4P) certification criteria, one for creating a summary record according to the DS4P standard and one for receiving a summary record according to this standard. Certification to the 2015 Edition DS4P criteria focus on data segmentation at the document level and is not required to meet the Certified EHR Technology definition (CEHRT) or required by any other HHS program. ONC proposes to remove the current 2015 Edition DS4P criteria and replace these two criteria with three new 2015 Edition “DS4P” certification criteria (two for C-CDA® and one for a FHIR®-based API) that would support a more granular approach to privacy tagging data consent management for health information exchange supported by either the C-CDA®- or FHIR®-based exchange
standards.
Comment: Although we agree with and support ONC’s intentions, we have some concerns about the
practicality of these criteria, in part due to the burden for providers and developers, and the extent to which they will be used by developers and providers. We note that ONC ISA shows a low adoption level of the current HL7® implementation guide published in May 2014 and the Consent2Share FHIR® Consent Profile Design is a new emerging standard in pilot with feedback requested. We also understand that Consent2Share does not appear to have a clear owner moving forward and is not a standard nor implementation guide that has gone through an SDO process.
We also highlight the likely increased complexity involved in trying to enable certain data in the record to be carved out from sharing; for example, when information to be excluded may be in both structured data and notes. We also urge ONC to be mindful of setting realistic patient expectations for what such a standard and capability can achieve. For example, without fundamental rearchitecting of existing EHR systems, clinicians who review the remainder of the record usually will be able to ascertain that something has been redacted, and often will be able to ascertain what it was.

VI. Health IT for the Care Continuum
B. Health IT and Opioid Use Disorder Prevention and Treatment—Request for Information (p.
7461)
ONC requests public comment on how existing program requirements and the proposals in this rulemaking may support use cases related to Opioid Use Disorder (OUD) prevention and treatment and if there are additional areas that ONC should consider for effective implementation of health IT to help address OUD prevention and treatment.
Comment: Prescription Drug Monitoring Programs (PDMPs), when integrated with EHRs, can play an important role in OUD prevention and treatment. We believe that the value of PDMPs and vendor and public sector cross-PDMP connections would be enhanced if:

  • State rules regarding use of this data could be harmonized and normalized:
    • States vary on whether only physicians can retrieve and use the data versus also allowing social workers, nurse practitioners, physician assistants, nurses, unit clerks, etc. to do so;
    • States vary on whether data can only be used during prescribing as opposed to allowing use of PDMP data during diagnosis/assessment; and
    • States vary regarding if/when discrete PDMP data can be propagated and further disclosed beyond view only of a report.
  • All PDMPs were connected to the U.S. Department of Justice RxCheck Interstate Hub.
  • Drugs were shared using RxNorm codes versus free-text which EHRs struggle to ingest; many prescription drug monitoring programs (PDMPs) do not provide medication data using RxNorm, hindering interoperability, usability and deeper clinical decision support.
  • Toxicology lab results and risk scores (codified with LOINC/SNOMED) were also shared, since both values are stored in most state PDMP repositories.

Finally, we highlight the importance of ongoing Department considerations of the HIPAA Privacy Rule, its relationship to state privacy laws (which can be more stringent than what HIPAA requires), and the interaction with 42 CFR Part 2. Rationalizing these varied federal and state privacy requirements will be important to effective use of interoperable health IT to address OUD prevention and treatment.

VII. Conditions and Maintenance of Certification
ONC proposes to establish Conditions and Maintenance of Certification requirements for health IT developers based on the conditions and maintenance of certification requirements outlined in section 4002 of the Cures Act.

B.4. Application Programming Interfaces (APIs)
The Cures Act’s API Condition of Certification include new standards, new implementation specifications, a new certification criterion, as well as detailed Conditions and Maintenance of Certification requirements.
Comment: The Sequoia Project generally supports this provision and the proposed specification of several standards, including HL7® FHIR®. Of the options ONC outlines for the version of FHIR® and associated  standards that should be specified in the final rule, we strongly support, for the reasons articulated by ONC, Option #4—designation of FHIR® Release 4 (or the latest balloted version of FHIR®) in the final rule.
In addition, to provide greater flexibility for ONC and to encourage and enable use of updated SDO-developed implementation specifications, we suggest that such implementation specifications be designated in ONC guidance rather than in the final regulation. It is our understanding that ONC’s position is that implementation guides must be referenced in regulation in order to be included in certification criteria, but we believe that ONC should modify its conformity assessment methods to accommodate
updates to implementation guidance without rule-making. We strongly encourage ONC to examine whether they have any flexibility on that question and/or consider other ways to address the concerns that motivate our request. Note that, for FHIR® Release 4, the applicable implementation guide would be US Core STU 3.1.0, which is expected to be published late 2019.
We also support ONC establishment of the proposed initial set of FHIR® resources to be used for the proposed APIs, the “API Resource Collection in Health” (ARCH), which would align with the proposed USCDI. Although we believe that, in general, health IT standards should be developed by standards developing organizations (SDOs), we recognize the considerations that lead ONC to publish the ARCH. We ask ONC to emphasize that the ARCH is bounded by the scope of the USCDI, that the USCDI will only include data classes and data elements that have SDO-developed implementation guides, that the ARCH will only reference HL7® FHIR® resources, and, moving forward, is transitioned as rapidly as possible to a private sector, SDO-developed implementation specification, such as the HL7® US Core.

B.5. Real World Testing
The Cures Act adds a new Condition and Maintenance of Certification requirement that health IT developers successfully test the real-world use of the technology for interoperability in the type
of setting in which such technology would be marketed. In this proposed rule, ONC outlines what successful “real world testing” means for the purpose of this Condition of Certification, as well as proposed Maintenance requirements—including standards updates for widespread and continued interoperability.
Comment: We strongly support the requirement for real-world testing as mandated by the Cures Act and generally as proposed by ONC. We agree with ONC that such required testing should be limited to health IT developers with Health IT Modules certified to one or more 2015 Edition certification criteria focused on interoperability and data exchange.
We also support the Standards Version Advancement Process (SVAP) as enabling needed industry flexibility. We view the ONC certification program as providing a floor that all certified technology will need to support, while the SVAP provides permissible progressions (that later can become the new floor in the next rule). To maintain compatibility, support for the floor is critical to avoid adoption of only the SVAP allowed version and not being able to fully communicate with the floor version. With respect to the SVAP’s ability to assert conformance in the absence of the test tools, there is a need to test once those tools do become available.
We strongly support ONC’s proposal that “developers should consider existing testing tools and approaches that may be used to assess real world interoperability. For example, we encourage health IT developers to consider metrics of use and exchange from existing networks, communities, and tools including, but not limited to, Surescripts, Carequality, CommonWell Health Alliance, the C–CDA One-Click Scorecard, and DirectTrust.” We suggest adding to this list of examples, in the final rule, the Sequoia
Interoperability Testing Platform (ITP) and the related RSNA Image Exchange Testing requirements already in place. These programs facilitate “real world” testing programs today to test for transport, security, and data quality of clinical content exchanged.

D. Enforcement
ONC proposes a general enforcement approach to encourage consistent compliance with the requirements.
Comment: In general, we agree with the enforcement approach taken for the conditions of certification and the relative roles of ONC and the ONC-ACBs, including building on processes previously established for ONC direct review of certified health IT. We strongly agree with ONC’s proposed approach to focus on a corrective action process as the first priority in its enforcement engagement with developers. We also emphasize the need for clarity on the interaction of enforcement for these provisions as reflected in
Table 3 (p. 7507) and for information blocking more generally as well as the relative roles of the OIG and ONC. We appreciate the discussion of OIG and ONC roles on p. 7507 and emphasize the critical need for both clarity and coordination in roles.

V.III. Information Blocking
Section 4004 of the Cures Act establishes stringent requirements around the prohibition of information blocking. The statutory language adds some clarity but also requires ONC to define key terms and concepts in this regulation as well as to identify “reasonable and necessary [activities that interfere with the access, exchange, or use of EHI and] that do not constitute information blocking”. ONC’s regulatory actions in the proposed definitions as well as its regulatory and sub-regulatory discussions and provisions regarding information blocking practices and definitions are also of great importance. ONC also proposes a complaint and enforcement process that could, but need not, coordinate with the OIG and Federal Trade
Commission and that would supersede certification bodies in some cases.
Comment: Although much of the focus of the proposed rule is on the Secretary’s required identification of “reasonable and necessary [activities that interfere with the access, exchange, or use of EHI and] that do not constitute information blocking,” we emphasize that ONC’s regulatory actions in proposed definitions, as well as its regulatory and subregulatory discussions and provisions regarding information blocking and definitions, are also of great importance. In the sections below, we provide focused comments from the perspective of The Sequoia Project. In addition, we offer to ONC the attached outputs from the information Blocking Workgroup of Interoperability Matters (see Appendix 2).

C. Relevant Statutory Terms and Provisions (p. 7509)
Comment: ONC defines several terms used in the Cures Act. Although we do not have specific suggestions for changes for most of these terms, we emphasize that the definitions of “access,” “exchange,” “use,” and “electronic health information” (EHI) are very broad. As they interact with each other, with the definitions of the four types of actors, with the ONC descriptions and examples of information blocking practices, and
with the seven exceptions, the result is an extensive and heterogeneous set of scenarios and use cases that will be subject to complex compliance and enforcement processes. We are concerned that the impact, foreseen and unforeseen, may exceed and even be inconsistent with Congress’ intent to define and limit information blocking.
We are especially concerned with the implications of the very broad definition of EHI and the likely impracticality of applying the information blocking provisions to this extensive, highly situational and largely non-standardized data set We suggest that enforcement be primarily focused on access to the USCDI (including API access), which will evolve over time to include more and more EHI. We pledge to work closely with the community and ONC to achieve this goal.
One area of great concern is the definition of “Health Information Exchanges” and “Health Information Networks”. We believe that the distinctions between these two categories are unclear. More generally, it is very important that these definitions align with congressional intent as well as common industry understanding of what these terms mean.
Getting these definitions right is critical for several reasons, including the prospect of sweeping in organizations (e.g., provider organizations) that would otherwise not have liability for the very high maximum fines applicable to HIEs and HINs. These definitions would also subject a broad array of organizations to the very stringent requirements associated with these exceptions, for example, permissible contracting practices and terms, down-time for maintenance, and establishment of fees.
For HINs, we believe that the definition is too broadly defined and does not accord with the commonly accepted definition of a network. ONC states that: Health Information Network or HIN means an individual or entity that satisfies one or both of the following—
(1) Determines, oversees, administers, controls, or substantially influences policies or agreements that define business, operational, technical, or other conditions or requirements for enabling or facilitating access, exchange, or use of electronic health information between or among two or more unaffiliated individuals or entities
(2) Provides, manages, controls, or substantially influences any technology or service that enables or facilitates the access, exchange, or use of electronic health information between or among two or more unaffiliated individuals or entities.
The examples of HINs in the preamble go well beyond the reasonable definition of a “network,” a term that is not defined in the proposed rule. ONC provides as examples of an HIN:

  1. Entity established in a state to improve movement of EHI between providers operating in state; identifies standards for security and offers terms and conditions for providers wishing to participate in the network.
  2.  Entity offering (and overseeing and administering) terms and conditions for network participation.
  3. Health system administers agreements to facilitate exchange of EHI for use by unaffiliated family practices and specialist clinicians to streamline referrals.
  4. Individual or entity that does not directly enable, facilitate, or control movement of information, but exercises control or substantial influence over policies, technology, or services of a network.
  5. A large provider may decide to lead an effort to establish a network that facilitates movement of EHI between group of smaller providers (and the large provider) and through technology of health IT developers; large provider, with some participants, creates a new entity that administers network’s policies and technology.

We are especially concerned about the fourth example, which follows from the first part of the definition and focuses on policies. We strongly encourage ONC to revise the definition of a HIN for this rule to be (a) be an actual network or a formalized component of an actual network and (b) have an actual operational role and responsibility for the network. Organizations that develop voluntary standards and policies that may be used by one or more HIN (e.g. standards development organizations—SDOs), should not be
considered HINs. Nor should organizations that provide administrative or operational support for an HIN but that do not have governance responsibility or operational control.
We also believe that ONC should not define hospitals or other healthcare organizations with limited exchange capabilities, such as interfaces for ADT messages or lab results, as an HIN for purposes of these regulations.
We also ask ONC to clarify the extent of the responsibility of a network with respect to its constituent organizations and their own policies and actions that may implicate information blocking. For example, if an HIN knows or should have known that a member engaged in practices that could implicate information blocking, what is the HIN’s responsibility to apply the exceptions and other considerations to determine
whether a violation occurs, or is the HIN only responsible for its own actions? We believe that the latter should be the case. In addition, to what extent must a HIN ensure that its policies specifically prohibit information blocking by its members or is it enough to ensure that its policies do not require or encourage information blocking?
Finally, we tend to see HIEs as an organizational type (versus the use of “HIE” as a verb) and as a subset of HINs. We do not have significant concerns with the proposed definition of an HIE other than that, as indicated, we believe that the distinctions between HIEs and HINs are unclear. For example, ONC states that an HIE that facilitates access, exchange, or use for more than a narrowly defined set of purposes, may be an HIE and an HIN. Given that the information blocking definitions and penalties are the same for
both HINs and HIEs, we suggest that ONC consider combining these in a single category—”HIE and HIN”.

c. Examples of Practices Likely to Interfere with Access, Exchange, or Use of EHI (p. 7518)
ONC provides examples of practices that may implicate information blocking, indicating that these practices can be mitigated by application of one or more of the “reasonable and necessary” exceptions included in the proposed rule. (Quoted language below comes from this section.)
Comment: We find these examples very helpful and they should provide a useful basis for sub-regulatory guidance that can assist the industry in achieving more cost-effective compliance. At the same time, some of the examples raise issues that point to potential needs for revisions in both ONC regulatory provisions and agency interpretations.

i. Restrictions on Access, Exchange, or Use
“One means by which actors may restrict access, exchange, or use of EHI is through formal restrictions. These may be expressed in contract or license terms, EHI sharing policies, organizational policies or procedures, or other instruments or documents that set forth requirements related to EHI or health IT.”

  • “A HIN’s participation agreement prohibits entities that receive EHI through the HIN from transmitting that EHI to entities who are not participants of the HIN.”

Comment: We are concerned that this example could be interpreted as preventing an HIN from restricting participation in the HIN to those who have signed its participation agreement and agreed to abide by reasonable and necessary policies. The distinction between such an action, and the action of preventing, by policy, information from being shared with non-participants through means unrelated to the HIN, should be clarified. It should also be clear that an HIN can restrict exchange within the HIN to entities that signon to the HIN’s participation agreement. More generally, we believe that HINs should be expected to connect with other HINs for applicable use cases through network to network trust agreement or the TEFCA. In addition, an HIN should be able to require that EHI received through the HIN be protected consistent with state and federal law.

“Access, exchange, or use of EHI can also be restricted in less formal ways. The information blocking provision would be implicated, for example, where an actor simply refuses to exchange or to facilitate the access or use of EHI, either as a general practice or in isolated instances. The refusal may be expressly stated, or it may be implied from the actor’s conduct, as where the actor ignores requests to share EHI or provide interoperability elements; gives implausible reasons for not doing so; or insists on terms or conditions that are so objectively unreasonable that they amount to a refusal to provide access, exchange, or use of the EHI”
Comment: An HIN or HIE should be able to choose not to exchange data with another party that has not agreed to the terms of a reasonable governance and trust framework. We recognize that a given policy that is consistent with the information blocking provisions may not be the only way to achieve compliant exchange, but it should be acceptable to limit exchange to parties that agree to a reasonably arrived at compliant framework.

iv. Rent-seeking and Other Opportunistic Pricing Practices
“Certain practices that artificially increase the cost and expense associated with accessing, exchanging, and using EHI will implicate the information blocking provision. Such practices are plainly contrary to the information blocking provision and the concerns that motivated its enactment . . . An actor may seek to extract profits or capture revenue streams that would be unobtainable without control of a technology or other interoperability elements that are necessary to enable or facilitate access, exchange, or use of EHI”.
Comment: In general, we are very concerned with the complexity and broad reach resulting from the interaction of the pricing provisions of the proposed rule, in both information blocking practices and exception, with the very expansive definitions of actors and of EHI. Although the heading of this section refers to “rent-seeking and other opportunistic pricing practices,” ONC is clear in the proposed rule preamble that its definition of the types of fees that could implicate as information blocking is not limited to such behaviors, whose identification is likely to be very subjective. For example, ONC implies that “value-based pricing,” an approach commonly used in industry and indeed one increasingly used in healthcare to pay for drugs and health plans is “opportunistic” and would not be mitigated by any of the proposed exceptions. ONC goes on to emphasize that

“[T]he reach of the information blocking provision is not limited to these types of practices. We interpret the definition of information blocking to encompass any fee that materially discourages or otherwise imposes a material impediment to access, exchange, or use of EHI. We use the term “fee” in the broadest possible sense to refer to any present or future obligation to pay money or provide any other thing of value . . . We believe this scope may be broader than necessary to address genuine information blocking concerns and could unnecessarily diminish investment and innovation in interoperable technologies and services. Therefore, . . . we propose to create an exception that, subject to certain conditions, would permit the recovery of costs that are reasonably incurred to provide access, exchange, and use of EHI.”

It appears that ONC would view any fee as imposing a “material impediment” and therefore requiring use of the exception focused on recovering costs. ONC acknowledges that the definition of any fee as a practice that implicates information blocking “may be broader than necessary to address genuine information blocking concerns and could unnecessarily diminish investment and innovation in interoperable technologies and services”. We agree with ONC on this latter point but are not convinced that simply providing an exception, which is itself very limiting, is a sufficient counter to the issues raised by the provision. In addition, the documentation required by these exceptions could be quite extensive and onerous.
Certainly, where fees are established by market-based business models, especially for actors that are not actually networks or HIEs as these terms are commonly understood, it seems undesirable that these organizations would be subject to the detailed fee regulation established through the combination of the practice and the exception. For example, we do not believe that a mutually agreeable decision to share in revenue should be prohibited for every actor for any interoperability element. We suggest that there be a narrower definition and associated interpretation of HIE and especially HIN.

v. Non-Standard Implementation Practices
“Even where no standards exist for a particular purpose, actors should not design or implement
health IT in non-standard ways that unnecessarily increase the costs, complexity, and other
burden of accessing, exchanging, or using EHI.”

  • An EHR developer of certified health IT implements the C-CDA® for receiving transitions of care summaries but only sends transitions of care summaries in a proprietary or outmoded format.
  • A health IT developer of certified health IT adheres to the “required” portions of a widely adopted industry standard but chooses to implement proprietary approaches for “optional” parts of the standard when other interoperable means are readily available.

Comment: We agree with the importance of standardized implementations; achieving such standardization, including further standardization of SDO implementation specifications, has been essential to the success for large-scale health data sharing to date. At the same time, certain types of optionality, especially for specialized use cases, can be very important. For example, specialized data fields that lack a widely accepted terminology standard may need to be collected and shared to accommodate specialty workflows, such as multidisciplinary tumor boards in oncology. Actors could reasonably develop and enforce a new terminology standard for these specialized fields that, by definition, will not be widely adopted initially, without implicating information blocking. Their behavior would cross the line into information blocking, however, if they insist that the specialized data be transmitted in a way that is not aligned with widely adopted communications formats, for example, where both FHIR® and CDA® could accommodate the information. Careful and flexible application of this information blocking practice will be essential given the complexities of health IT implementation.

6. Applicability of Exceptions
a. Reasonable and Necessary Activities (p. 7522)
ONC describes three overarching policy considerations that guided development of these seven exceptions. First, the exceptions would be limited to certain activities that clearly advance the aims of the information blocking provision; promoting public confidence in health IT infrastructure by supporting the privacy and security of EHI and protecting patient safety; and promoting competition and innovation in health IT and its use to provide health care services to consumers. Second, each exception is intended to address a significant risk that regulated individuals and entities will not engage in these reasonable and necessary activities because of potential uncertainty regarding whether they would be considered information blocking. Third, and last, each exception is intended to be tailored, through appropriate conditions, so that it is limited to the reasonable and necessary activities that it is designed to exempt. To qualify for any of these exceptions, an individual or entity would, for each relevant practice and at all relevant times, must satisfy all applicable conditions of the exception.
Comment: These are appropriate policy considerations. Overall, we believe that the seven categories of exceptions are the right ones and indeed, are essential to implementation of the information blocking prohibition. We do have overall concerns as well as questions about specific elements. We especially highlight our concern with the proposed requirement that “[t]o qualify for any of these exceptions, an individual or entity would, for each relevant practice and at all relevant times, must satisfy all applicable conditions of the exception”. Such a strict compliance standard may add clarity, but it is at odds with the complexity that underlies healthcare operations. We also have general concerns with the costs and complexity that will be the result of organizations needing to manage these complex policies and to document their actions and associated rationale.
Below, we comment selectively on the proposed exceptions. Additional comments and recommendations on the exceptions are included in the attached report (Appendix 2) from the Information Blocking Workgroup of the Interoperability Matters Cooperative.

1. Preventing Harm—§171.201
Comment: We have a few specific points to make:

  • We are concerned that ONC’s expectations for the ability to carve out 42 CFR Part 2 covered data may far exceed current industry capabilities in terms of technology and operational capacity. In particular, carving out such data from notes for exchange and data export will be very challenging.
  • We suggest that the focus on physical harm in the determination by a licensed health care professional that disclosure of EHI is reasonably likely to endanger the life or physical safety of a patient or another person is too narrow and should be expanded to include psychological and other forms of non-physical harm.

2. Promoting the Privacy of EHI—§171.202
Comment: For 202(b)(2)(i), we are concerned that the requirement that the actor “[d]id all things reasonably necessary within its control to provide the individual with a meaningful opportunity to provide the consent or authorization” is too rigid a requirement. If even one possible action was not done, the exception would not apply. Moreover, for an HIN that does not have operational control over or visibility into the detailed decision-making of its participants, it would not be possible to apply or validate this test. We ask ONC to explicitly indicate that an actor such as an HIN does not have the obligation to review or confirm that the actions of its participants meet this or other exception tests that do not involve direct decisions by the HIN. A key issue for a nationwide HIN, for example, is that the terms of its trust agreement, may (out of necessity) provide reasonable discretion for the network participants. One such example is enabling participants to accommodate variations in privacy laws across states as necessary. Doing so could also be potentially construed as enabling decisions that implicate information blocking. It is essential, therefore that ONC focus on direct HIN decisions rather than the actions of its participants, which may or may not have been enabled by the HIN’s trust agreement.

3. Promoting the Security of EHI—§171.203
Comment:

  • We ask that ONC confirm that an HIN or HIE requiring the use of digital certificates that meet federal agency standards in order to meet the needs of its participants will be consistent with this exception when it imposes such requirements.
  • In addition, we offer the scenario of an organization that launches an IHE XCPD query that is otherwise compliant with an HIN’s specifications but is rejected because the query is not secured with an HIN certificate. We ask that ONC clarify that such a request for data access can be rejected, without violating this exception, as not compliant with an organization’s reasonably adopted security policies, including those involving certificates, and the need to validate the identity of the requester and the requester’s valid right to access the data.
  • ONC should address the extent to which actions by an actor to address legal liability not mitigated by HHS Office of Civil Right (OCR) HIPAA-related policies can support use of this exception, including potential liability that can come with exchange that is not covered by OCR guidance relating to the HIPAA patient right of access. Such liability could arise from such sources as state laws, FTC regulations, or contractual obligations.
  • We ask the Department to ensure that OCR issues guidance that conforms, as necessary, to final ONC information blocking regulations.
  • We are concerned with a lack of standards and definitions of such terms as “directly related” and “tailored” and the burden on the industry (including providers, developers, HIEs and HINs) to perform analyses of their policies and practices against such complex and incompletely defined terms and tests,
    especially with the requirement to meet “all requirements at all times”.
  • We note that this exception has a provision for cases where there is no written policy (171.203(e)). In practice, it seems most likely that the absence of a policy means that one is dealing with an unexpected and evolving situation as best one can (e.g. a sustained and sophisticated attack). The exception calls for not only a determination that the practice is necessary, but that effectively there is no other way of having protected your security that might have been less likely to interfere with information access. In our view, such a requirement is asking too much of those dealing with urgent threats, often after hours and under considerable uncertainty. We suggest that 171.203(e)(2) have a further “safety valve” for short-lived actions that are taken in good faith while a situation is being evaluated and understood.
  • We ask that ONC clarify that proactive and preventive security-focused activities that are a condition of exchange are permitted so long as they meet the applicable criteria for security-related practices in this exception.

 4. Recovering Costs Reasonably Incurred—§171-204.
Comment:

  • We do not believe that all mutually agreeable decisions to share in revenue should be prohibited for every actor for any interoperability element.
  • We are concerned that requirements for very granular costs and fee accounting will significantly increase the cost of doing business and of data exchange. We are concerned that the exception can be read to require that an actor retain extensive records to document all of the costs that the actor incurred to develop an interoperability element so that it can prove that its fees only recover those
    costs plus a “reasonable” profit. Cost accounting is challenging for even very large and well-resourced organizations and we are concerned that this exception will result in unintended negative consequences for many actors. We request that ONC clarify that this outcome is not the intent of this exception and to take steps to mitigate the risks of such an outcome.
  • We ask that ONC recognize that for many organizations, especially non-profits, it is common and  appropriate for fees to scale with the size of a member/participant organization. We suggest that such an approach, which does not focus on the revenue or profits for exchange that is facilitated by the organization establishing the fees, is appropriate and that basing fees on member size is a reasonable proxy for basing fees in relation to current costs as well as the need to invest in future capabilities. Such organizations would, in general, be able to demonstrate that aggregate fees collected are related to and grounded in costs but not that a specific fee is directly related to specific costs.
  • We ask ONC to clarify that the policy by an organization (e.g., an HIE or HIN) that a participant cannot condition its provision of information on the recipient having paid a fee for certain use cases or permitted purposes (e.g., treatment) is not information blocking.
  • We agree that ONC should prioritize exchange, access, and use of “observational health information”  i.e., EHI that is created or maintained during the practice of medicine or the delivery of health care services to patients). In addition, we believe that ONC should also prioritize certain purposes or use cases for data exchange/access/use, specifically, the HIPAA categories of treatment, payment,
    and operations, relative to access (other than that needed to support a patient’s HIPAA right of access) that is intended to serve primarily commercial objectives of the party seeking data.
  • We ask ONC to clarify if the fees established by an IT vendor supporting an HIE or an HIN are subject to this provision and if such an action by the HIE or HIN implicates information blocking if it passes on third-party fees as a cost when it has no direct control over such fees? In this scenario, we do not think that the actions of the HIE or HIN should implicate information blocking and that their
    fees should be able to meet this exception.

5. Responding to Requests for Access, Exchange, and Use that are Infeasible—§171-205
Comment:

  • Requests for data that would use non-standard implementation specifications should be able to be refused as “infeasible”
  • Actors should be able to focus on specific use cases and refuse requests to expand access, exchange, or use to support additional use cases as “infeasible.” At the same time, we believe that there should be a floor of the minimum set of use cases with associated interoperability standards that must be supported by a specific type of actor; perhaps the TEFCA provides a basis for such a floor.
  • Requests to participants of an HIE or HIN that maintains a trust agreement/framework should be able to be refused if the requester does not participate in the applicable trust framework or act consistently with its provisions, even if the HIE or HIN has a dominant market position, so long as the terms of the trust agreement are not discriminatory or deliberately anticompetitive.

In addition, ONC asks if it should propose, in a future rulemaking, a narrow exception to the information blocking provision for practices necessary to comply with the requirements of the Common Agreement (TEFCA).

Comment: We believe that such an exception should be created and suggest that ONC broaden this exception to include compliance with the terms of private sector trust frameworks whose aim is to enhance interoperability. We urge that ONC explicitly indicate that such trusted exchange frameworks can design and implement agreements that impose specific obligations on participants, for example, that certain permitted purposes must be included in exchange at no cost, and also that they can employ specific provisions intended to gain participation and hence, to enable greater flow of EHI. We also ask ONC to be clear that such frameworks can choose, and HINs more generally can choose, to focus on specific EHI-exchange use cases and not to address others.

Patient Matching Request for Information (p. 7554)
General Comments: In our detailed comments below, we address the questions that ONC poses
in its request for information (RFI) and agree with ONC on the importance of this issue and of the role of the private sector, with federal government support, in improving match rates. We point ONC to 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 ONC and point to ongoing work in this area by the Sequoia Project Patient Identity Management Work Group. We especially emphasize that much of the focus in accurate patient matching has been intra-organizational but that true interoperability and data liquidity will require accuratecross-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.
ONC asks several questions in this RFI, which we address below.
1. It is a common misconception that technology alone can solve the problem of poor data quality, but even the most advanced, innovative technical approaches are unable to overcome data quality issues. Thus, we seek input on the potential effect that data collection standards may have on the quality of health data that is captured and stored and the impact that such standards may have on accurate patient matching. We also seek input on other solutions that may increase the likelihood of accurate data capture,
including the implementation of technology that supports the verification and authentication of certain demographic data elements such as mailing address, as well as other efforts that support ongoing data quality improvement efforts.
Comment: We agree with ONC that data collection standards and their consistent application by 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 crossorganizational 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. 
2. In concert with the GAO study referenced above, we seek input on what additional data elements could be defined to assist in patient matching as well as input on a required minimum set of elements that need to be collected and exchanged. We encourage stakeholders to review the Patient Demographic Record Matching section of the Interoperability Standards Advisory (ISA) and comment on the standards and
implementation specifications outlined.
Comment: Additional data elements to improve patient matching efforts may include: Maiden Name, Multiple Birth Indicator, Birth Order, Telephone Number types, and Email Address(es). In addition, 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. High data quality of this identifier at the point of capture is essential for acceptable patient match rates. Finally, we also believe that IHE-PDQ and IHE-PIX are very important standards, as identified in the ISA, as tools that can assist with the matching process when used in a process flow with registrar and patient.
3. Also, in alignment with the GAO study, we seek input on whether and what requirements for electronic health records could be established to assure data used for patient matching is collected accurately and completely for every patient. For instance, the adopted 2015 Edition “transitions of care” certification criterion (§ 170.315(b)(1)) currently includes patient matching requirements for first name, last name, previous name, middle name, suffix, date of birth, address, phone number, and sex. These requirements also include format constraints for some of the data.
Comment: As discussed above, other potential data elements of value 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). We also highlight the importance of consistently defined and used format constraints.
4. There are unique matching issues related to pediatrics and we seek comment on innovative and effective technical or non-technical approaches that could support accurate pediatric record matching.
Comment: We agree there are special challenges for pediatric populations, with matching for newborns being especially problematic. Issues unique to pediatrics include

  • No national naming convention for newborns, specifically, patients who have not yet received their legal name and have a temporary name; and
  • Multiple births present challenges with same date of birth, address, mother’s maiden name and potentially very similar names and identifiers, often only differing by a single digit.

Specific approaches to enhance patient matching accuracy for pediatrics include:

  • Following the Children’s Hospital Association’s temporary demographic conventions for newborns;
  • Standards adoption (e.g., for naming, demographics and gender identification);
  • Information governance, process, and technology (e.g., ensuring the health IT and its use enables complete and accurate medical records both for the mother and fetus);
  • Vendor capture of multiple birth indicator, birth order, and mother’s maiden name; and
  • Creation of the medical record prior to birth event

5. Recent research suggests that involving patients in patient matching may be a viable and effective solution to increase the accuracy of matching, and giving patients access to their own clinical information empowers engagements and improved health outcomes. We seek comment on potential solutions that include patients through a variety of methods and technical platforms in the capture, update and maintenance of their own demographic and health data, including privacy criteria and the role of providers as educators and advocates.
Comment: We believe that 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 (and training staff on the value of doing so) 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 “patient inherent” rather than simply “patient-generated”.
6. In addition, we seek input on standardized metrics for the performance evaluation of available patient matching algorithms. Health IT developers are each relying on a number of patient matching algorithms, however, without the adoption of agreed upon metrics for the evaluation of algorithm performance across the industry, existing matching approaches cannot be accurately evaluated or compared across systems or over time.
Comment: We suggest a focus on sensitivity, specificity, and precision. Sensitivity is a measure of the capability of the matching algorithm to correctly classify two records that refer to the same patient as true matches. Specificity is a measure of the capability of the matching algorithm to correctly classify two records that refer to two different patients as nonmatches. Precision is a measure of the fraction of pairs that the matching algorithm classified accurately as matches. This latter metric can be used along with the sensitivity to jointly evaluate the performance of a matching algorithm. It is important that two metrics are used in the analysis because the metrics evaluate the performance of the matching algorithms from different and conflicting viewpoints, resulting in a more balanced assessment as opposed to using just a single metric.
Precision is preferred as a metric over specificity. Specificity is calculated using the counts of True Negatives and False Positives. In most cases most record pairs under consideration are true negatives whereas only a relatively small number of record pairs are False Positives. This difference in the scale between the two numbers involved in the calculation causes false negatives to overwhelm the calculation and reduce the value of specificity as a metric.
7. At the same time, we seek input on transparent patient matching indicators such as database duplicate rate, duplicate creation rate, and true match rate, for example, that are necessary for assessment and reporting. The current lack of consensus, adoption, and transparency of such indicators makes communication, reporting, and cross-provider or cross-organizational comparisons impossible, impedes a full and accurate assessment of the extent of the problem, prohibits informed decision making, limits research on complementary matching methods, and inhibits progress and innovation in this area.
Comment: We agree on the value of such transparent indicators, and emphasize the importance of gold standard data sets to use in evaluating algorithms.
8. There are a number of emerging private-sector led approaches in patient matching that may prove to be effective, and we seek input on these approaches, in general. A number of matching services that leverage referential matching technology have emerged in the market recently, yet evaluations of this type of approach has either not been conducted or has not been made public. Other innovative technical approaches such as biometrics, machine learning and artificial intelligence, or locally developed unique identifier efforts, when used in combination with non-technical approaches such as patient engagement, supportive policies, data governance, and ongoing data quality improvement efforts may enhance capacity for matching.
Comment: In the future, biometrics will likely play a significant role in patient matching and identity proofing and may change the fundamental paradigm for patient identification. Examples of biometrics include fingerprint, palm veins, face recognition, DNA, palm print, hand geometry, iris recognition, and retinal scanning. Biometric devices are used to capture these metrics in a systematic and reliable way. Biometrics are considered immutable attributes, in that they are innate, entrenched, and would take significant effort to change. As such, biometric attributes are ideal for patient matching and identity proofing and we encourage ONC to facilitate and identify standards in this area that can encourage interoperability of biometric data.9. Finally, ONC seeks input on new data that could be added to the United States Core Data for Interoperability (USCDI) or further constrained within it in order to support patient matching.
Comment: Additional data elements for consideration include: Maiden Name, Multiple Birth Indicator, Birth Order, Telephone Number types, and Email Address(es) and types.

 

Appendix 2: Recommendations of the Information Blocking Workgroup of the Interoperability Matters Forum