Elements of the Common Agreement
Feedback

The RCE sought feedback on the Elements of the Common Agreement released September 20, 2021. In addition to engaging the RCE through the public, virtual events, you may have chosen to submit written feedback.

All feedback submitted to the RCE is publicly available below.

RCE Directory Service

Please clarify if the Directory Service only be directory of QHINs, QHIN Participants or subparticipants themselves and will not contain or provide direct access to content within QHINs, QHIN Participants or subparticipants.

Further, how will the RCE Directory Service align/complement the FHIR IGs under development in the new National Directory Project which is part of FAST and hosted by the HL7 Patient Administration Work Group? If this is still a process in motion, please make mention that the RCE will coordinate with the National Directory Project.

Privacy and Security

Please clarify that an industry-recognized cybersecurity framework and security assessment process will be established by the Cybersecurity Council. If that is not the expectation, please identify which framework the RCE is considering and what the security assessment process will look like.

Additionally, the Cybersecurity Council should be comprised of more than representatives of the QHINs. Participants and Subparticipants should also have representation on the Council. For instance, cybersecurity requirements and considerations are vastly different for small/solo medical practices than those of large health systems which are different than those of QHINs. QHINs cannot be expected to represent the needs of all their participants/subparticipants given the wide variability of those entities. We urge Sequoia to include representation from a wider range of entities including medical practices (or those that represent medical practices) and small/solo physician practices (or those that represent small/solo physician practices).

Exchange Purposes

Amazon Web Services (AWS) fully supports inclusion of Individual Access Services and Public Health as permitted uses under the Common Agreement. Prompt patient access to records can help individuals better guide their care and make informed decisions based on up-to-date data on disease progression and their unique medical state. In parallel, the COVID-19 pandemic has highlighted the limitations of public health authorities to obtain the data they need to track and respond to threats in their communities, including for syndromic surveillance and case investigation. Including these uses in the Common Agreement will help patients and public health officials alike obtain the data they need to improve outcomes.

However, the Common Agreement is missing two critical permitted exchange purposes that should be in the final document.

First, while patients should be able to access their own records, patients should also be able to authorize or direct the sharing of their data with third-parties. In fact, the Office of the Civil Rights has proposed regulations that would advance this capability when patients direct this type of exchange from a healthcare provider. Qualified Health Information Networks should also enable this patient-directed exchange capability.

Relatedly, the Common Agreement should permit patients to authorize or direct the sharing of their data for research purposes. Many patients, including those with rare diseases, seek to share their data to help spur innovation and identify the next generation of cures. Several government efforts–including the All of Us program–seek to enable greater data sharing for research. While the current Common Agreement indicates that biomedical research may be included in future versions, patient-directed sharing of their data for research should be included in this version of the framework.

Participants and Subparticipants

The definitions of Participants, Subparticipants, and Downstream Subparticipants should clearly indicate that they apply to only those organizations that authorize access to and sharing of health information. Those definitions should not apply to organizations–such as technology developers or cloud service providers–that provide the necessary technical capabilities for data exchange.

Required Flow-Down Provisions

We recommend that “no-view” cloud service providers (“CSPs”; for more on this concept, see HHS’s Guidance on HIPAA & Cloud Computing) be excluded from any requirement to include flow-downs or enter into any Framework Agreement (e.g. Participant-Subparticipant Agreement or Downstream Subparticipant Agreement). This can be achieved by exempting CSPs from the definition of “Participant”, “Subparticipant,” and “Downstream Subparticipant,” or by including an express exemption for CSPs from the flow-down/Framework Agreement requirements. “No-view” CSPs are not in a position to know what data is in their services at any given time, nor what the use cases for that data are, and therefore cannot feasibly operationalize the flow-down terms, which assume that the downstream entity knows what the data is and can act on it.

Cooperation and Nondiscrimination

As mentioned in the “Required flow-down provisions” section, no-view CSPs should be exempt from the specific flow-down terms that are described in this section.

Individual Access Services

“The Common Agreement should clarify that Individual Access Services must be enabled via the app of the patient’s choice—just like patients can use an app of their choice to gain access to data directly from a provider. Some Qualified Health Information Networks may not enable a user-friendly interface or adopt best practices to support patient access; supporting the use of third-party apps maintains the ability for patients to have access via their preferred approach. While the Technical Framework did not enable use of the FHIR standard, specifying alignment with FHIR-based APIs for Individual Access Services will better meet the goals of this permitted use. Without specifying alignment with FHIR (and the implementation specifications required under health information technology certification), many of the third-party apps used by patients would not be able to easily integrate the individual’s data via the Trusted Exchange Framework—which would set back both this intended “on ramp” to interoperability and result in a loss of momentum in patients’ ability to access their records.

Finally, the Common Agreement defines Individual Access Services as those “optional services provided” for patient access. Participation in the TEFCA framework should require the availability of Individual Access Services; we recommend you delete the term “”optional”” from this definition for clarity.”

Privacy and Security

As mentioned in the “Required flow-down provisions” section, no-view CSPs should be exempt from additional privacy and security requirements as long as the no-view CSP complies with applicable HIPAA requirements.

Definitions

The American Hospital Association (AHA) appreciates the opportunity to provide feedback on the “Elements of the Common Agreement (ECA).” We support the goals of the Common Agreement, including to establish a floor for universal interoperability and create simplified connectivity that would enable hospitals and health systems to join one Qualified Health Information Network (QHIN) that could facilitate information sharing with other QHINs nationwide.

The definition of “TEFCA Information” is defined broadly to include any information exchanged by QHINs for one or more exchange purposes. The definition would include de-identified information for which the HIPAA Privacy Rule Protections would not apply. “Required Information” in contrast is electronic protected health information (ePHI) that must be provided in response to a request (barring an exception) and is defined consistent with HIPAA. The Recognized Coordinating Entity (RCE) should clarify the rationale for including de-identified information as part of TEFCA Information and elaborate on the distinction between the two categories of data.

We further encourage, to the extent possible, alignment of definitions across the Common Agreement rather than application of different definitions for data in different elements of the Common Agreement. This will reduce complexity and confusion for entities engaging in exchange under the Common Agreement.

Exchange Purposes

The AHA supports the establishment of a focused set of six initial exchange purposes and the RCE’s acknowledgement that the scope of exchange purposes is likely to expand over time. We further support the alignment of the definitions of treatment, payment and operations with HIPAA. We do encourage the RCE to consider including appropriate boundaries (such as those currently established in regulation) for each exchange purpose that could serve to ensure excess patient data is not shared unnecessarily.

The ECA states that uses and disclosures would adhere to the Common Agreement privacy and security requirements and any “applicable privacy notices.” The Common Agreement should be clear that uses and disclosures must adhere to applicable law and regulation rather than “privacy notices.”

Comments related to additional exchange purposes are included below.

Participants and Subparticipants

The AHA urges the RCE to provide further details and clarification on the distinction between Participants and Subparticipants, particularly as it relates to health systems and hospitals. It should be made clear that if a health system owns multiple hospitals, those individual hospitals would not be required to sign Subparticipant agreements to participate in exchange through a QHIN.

Required Flow-Down Provisions

The Common Agreement will specify certain provisions QHINs would be required to include in their Framework Agreements with Participants. In turn, Participants would be expected to include these provisions in their agreements with Subparticipants. Given that health systems and hospitals are expected largely to participate under these Framework Agreements it is critical that the required elements be informed by robust health care provider input. The AHA looks forward to the release of additional details regarding the flow-down provisions and the opportunity to review and provide feedback.

TEFCA Information and Required Information

See comments above in “definitions” section.

Governing Approach to Exchange Activities Under the Common Agreement

The approach to governance appears fairly complex as a series of “governing bodies” is envisioned that will serve as a resource to the RCE and as a forum for discussions of issues affecting exchange activities under the Common Agreement. The AHA encourages the RCE to establish a detailed governance framework that clearly lays out the roles, responsibilities, timelines and participants for the bodies that will govern the TEFCA.

RCE Directory Service

The ECA lays out a broad expectation that the RCE would maintain a Directory Service to support exchange of information between and among QHINs, Participants and Subparticipants. The Common Agreement would identify the rights and limits on use of the RCE Directory Service. In addition to simply identifying the rights and limits on use, the Common Agreement should provide detailed information regarding the sources of the data, how it will be maintained, access requirements and approach to patient and provider matching.

Individual Access Services

See comments below under “privacy and security” section.

Privacy and Security

The AHA strongly supports that the Common Agreement would require non-HIPAA entities to protect TEFCA information that is individually identifiable in “substantially the same manner” as HIPAA Covered Entities protect PHI. We agree that this alignment is critical to promoting the trust necessary to achieve the goals of the TEFCA. With regard to the “Individual Access Services” Exchange Purpose, the Common Agreement would specify the privacy and security requirements that a QHIN, Participant or Subparticipant would be required to adhere to as an IAS Provider. We strongly encourage the RCE to apply robust, HIPAA-equivalent privacy requirements for IAS Providers rather than creating a separate standard.

Fees

The Common Agreement is expected to include a prohibition on QHINs charging fees to other QHINs yet fees could be charged to Participants. In practice, this could lead to a complex fee structure for hospitals and health systems that could include per-transaction fees rather than a flat fee for all exchanges. Proliferation of complex fee structures could serve to reduce health care provider participation. The AHA urges that guardrails be placed around the fee structure for Participants to ensure it does not become a barrier to entry and exchange.

These comments submitted by Ryan Harrison, and do not necessarily reflect the views of Amida.

 

Definitions

Full comment in blog format.

Using “Definitions” for Preamble.
TEFCA must support individual HIPAA rights, including the individual right of access. A right is hollow if it does not evolve with technology, and TEFCA is the likely future of networked exchange. Unfortunately, the Common Agreement draft, makes individual access an optional second-class citizen.

First, I commend the progress that the TEFCA RCE has made on the Common Agreement. Interoperability in Health IT is cat herding, and in some respects more art than science.

Second, I recognize, as an axom of policy, that concentrated interest almost always defeat diffuse interest. Even if, as is the case with health, those diffuse interest are orders or magnitude greater than concentrated interest. Feedback mechanism, though valuable, are yet another way for concentrated interests to bend the regulatory agenda to their will.

I implore the TEFCA RCE to examine every comment from concentrated interest through the lens of “what does this mean for patients?” Let the patient be your north star, and you will find that your individual access provisions are left wanting.

 

Exchange Purposes

Clarification: Do the six exemptions to TEFCA mandatory TEFCA responses (Elements of the Common Agreement, September 20 2021, pg 4) apply to all Actors (QHINs, Participants, Sub-participants) or just Participants and Sub-participants [4]? For example, could a Public Health QHIN use its exemption to treat all requests as optional, or only respond to requests with Public Health exchange purposes?

Opinion: I think that only Participants should be allowed exception. QHINs should be general purpose, supporting all six exchange purposes without exception (at the QHIN level).

 

TEFCA Information and Required Information

Requiring non-HIPAA Participants and Sub-participants to abide by HIPAA using TEFCA contractual language instead of HIPAA language (for which TEFCA and the RCE doesn’t have authority) is clever. A network in which some actors (e.g. non-HIPAA Sub-Participants) can skirt the privacy and security rule, while other cannot, is asking for an unreported breach. Indeed, the “thou shall follow HIPAA” should be inclusive of breach notification to HHS OCR.

 

RCE Directory Service

Clarification: What portion of the RCE Directory Service will be public? The names, registered business address, business and technical contact? The allowed (request) exchange categories for each Actor?

Opinion: The litmus for public disclosure of the RCE Direcory Service should be default to public. This means name, registered business address, business and technical contact, and allowed (request) exchange categories for each QHIN, Participant AND Sub-Participant. The ethos of QHIN-to-QHIN exchange is transparency in exchange; this should extend to the RCE Directory Service.

Individual Access Services

I am not a fan of the cart blanch exemption to servicing Individual Access requests. I question the need for a separate IAS Provider category because IAS should be a first-class citizen of TEFCA.

The HIPAA right of access should i) have “teeth”, and ii) include updates in technology to remain meaningful. Faxes yesterday; TEFCA tomorrow. As written, individuals will have to pay Non-HIPAA Entity providers of Individual Access Services to exercise their HIPAA rights. Further, the payments and fees by individuals don’t appear to be restricted, like they are under a non-TEFCA request.

The HIPAA right of access should extend to TEFCA. Patients, especially those seeing many different providers (e.g. childhood rare diseases), already experience an enormous undue burden in retrieving and if necessary correcting, their medical records. TEFCA should move the ball forwards, not backwards. Put bluntly, allowing Actors to opt-in to IAS is a cop-out. IAS should be required. Any waivers to IAS should be opt-out and temporary.

The CMS rule (Patient Access API) is a step in the right direction towards allowing individuals to delegate their HIPAA right of access to a third party, which acts on their behalf. Third-party apps which meet Actor requirements should be able to make requests on behalf of an individual, and those requests should be services subject to non-discrimination, i.e. no QoS (quality of service) for either direct individual access request or third-party mediated individual access requests.

 

Privacy and Security

Clarification: Will individuals be able to opt-out of TEFCA exchanges that do not expressly override individual opt-out by law (e.g. certain Federal Opiod reporting mandates)?

Opinion: In practice, most TEFCA requests will be for B2B administration between Covered Entities. HIPAA already enumerates permitted uses for Health Care Operations and Exchanges for Treatment. Therefore, I believe only requiring an express patient consent for Individual Access Requests is justifiable (by definition, the patient must have initiated the request). However, a permitted use by a covered entity is a privilege, not a right. In the same way that Individuals can opt-out of most (but not all) permitted uses, TEFCA should provide a patient opt-out mechanism. The opt-out will bar all exchanges not expressly overridden by law (e.g. certain Federal Opiod reporting). Further, Actors should be prohibited from discriminating against individuals who choose to opt-out of TEFCA exchange.

 

Special Requirements (including Consent)

The Common Agreement would require IAS Providers to obtain express consent from Individuals for, among other things, how the Individual’s information may be accessed, exchanged, Used, and/or Disclosed, including whether that information may be sold

Actors, including IAS Providers, should be barred from selling or reselling patient data. To quote Okun, “Everyone but an economist knows without asking why money shouldn’t be able to buy some things.” A patients most sensitive information, a digitization of their very bodily autonomy, should not be for sale. Privacy should not be a feature attainable only by the wealthy, and be extension the the poor or unsuspecting should not have to pay for TEFCA access with their private health information.

 

Fees

I would prefer if QHINs, Participants and Sub-Participants were barred from charging for individual right of access request. This includes both individuals requesting directly, and individuals requesting (with express consent) via a third-party. At a bare minimum, fees should not exceed allowable papers fees (at cost). Fees to individuals and third-party designees of individuals shold be temporary, subject to phase-out or sunset, such that individual access request are ultimately available at no cost to individuals.

Definitions

The Blue Cross Blue Shield Association (BCBSA) appreciates the opportunity to provide comments on the Elements of the Common Agreement draft. BCBSA is a national federation of 35 independent, community-based and locally operated Blue Cross and Blue Shield (BCBS) companies (Plans) that collectively provide healthcare coverage for one in three Americans. For more than 90 years, BCBS Plans have offered quality healthcare coverage in all markets across America – serving those who purchase coverage on their own as well as those who obtain coverage through an employer, Medicare and Medicaid.

BCBSA has extensive experience with data exchanges and interoperability as the operator of the BlueCard® program, one of the largest health claims processing and reimbursement programs in the nation, providing BCBS Plans seamless national access to 95 percent of physicians and 96 percent of hospitals that participate in BCBS healthcare networks.

Informed by our experience, BCBSA believes actionable, secure, reliable and interoperable data that are shared through a trusted exchange will enable a higher quality, more efficient and effective healthcare delivery system. Upon review of Elements of the Common Agreement draft, BCBSA comments are general in nature:

  • BCBSA applauds the RCE for its efforts to align the Elements of the Common Agreement (ECA) with HIPAA requirements.
  • We are particularly pleased to see the ECA’s extension of privacy and security protections to non-HIPAA obligated providers. However, it would be important for the ECA to further clarify and require HIPAA alignment by non-HIPAA entities like tech service providers or IAS. Continued expansion and innovation around the methods by which consumers can access their health information have led to troubling gaps in HIPAA protections.

Exchange Purposes:

  • BCBSA supports the six initial exchange purposes and the incremental approach to adding more over time as outlined in the ECA. However, we would recommend strengthening the language around social service agencies to be more inclusive. In order to reduce health disparities and improve health equity, other entities such as Community Based Organizations, Home Health, and other health care professionals/para-professionals should be referenced in the ECA to clarify their need for access to information for care coordination.

Participants and Sub-Participants:

  • BCBSA fully supports the flexible participant and sub-participant structure noted in the ECA. This type of flexibility will allow for expansion and innovation in the unknown future.

Individual Access Services (IAS):

  • BCBSA applauds the call on in the ECA on Individual Access Service obligations. In the cases when a HIPAA-covered entity may also fall under the scope of the IAS obligations, we suggest a clarification in language making clear that such entities’ privacy and security obligations are governed by HIPAA, and that those meeting HIPAA requirements are not subject to additional privacy and security requirements applicable to consumer-facing applications and other non-HIPAA IAS providers.

Privacy and Security:

  • BCBSA is pleased with the well-evidenced commitment to privacy and security in the ECA. Specifically we applaud the requirement for non-HIPAA covered entities to meet all HIPAA covered entity requirements and the role QHINs will have in maintaining third party certification to an industry-recognized cybersecurity framework. The ECA notes all such provisions will be designed to avoid conflict with applicable law and duplicative requirements. In combination with the Trust Framework proposed recently by TEFCA, these efforts should serve consumer information protection needs well. However, we are asking for clarification that HIPAA covered entities and their business associates will not be subject to the additional third-party certifications, annual security assessments or security incident notifications referred to in the ECA. HIPAA covered entities are already subject to the HIPAA Security Rule, as well as the HIPAA breach notification Rule, upon which the ECA’s definition of a TEFCA Security Incident is based.

Definitions

Individual Access Services. Clarify that the contractual obligation to respond to IAS requests is not optional, but that the ability to deliver IAS is optional. Also clarify that when the QHIN, Participant, or Sub-Participant maintains TI in a PHR or to support PHR functionality, they may not respond to requests from other QHIN, Participants or Sub-Participants for any Exchange Purpose without the individual’s affirmative, informed consent.

Non-HIPAA Entity. Consider narrowing the purpose of this definition, or replacing it with a different concept when defining the exclusion applicable to IAS providers that are Non-HIPAA Entities. Covered entities and business associates that provide IAS services should not be required to respond to requests for permitted Exchange Purposes with information for an individual’s PHR. 

Required Information. Required Information should not include information that is maintained by covered entities or business associates in systems that support PHR functionality, if these systems are not part of a covered entity’s “”designated record set”” in CEHRT. These entities may have the ability to ingest C-CDA data, but not the ability to maintain C-CDA in a system of record. Also, covered entities may have more than one business associate that are Participants or Sub-Participants. The only business associates required by the information blocking rule to respond to requests for permitted Exchange Purposes are HIE/HINs and developers of certified HIT.

Exchange Purposes

We agree that Individual Access Services should be a required exchange purpose for QHINs, Participants, and Sub-participants.

Participants and Subparticipants

We agree that non-HIPAA Entities that are IAS providers should be permitted to participate as Participants or Sub-participants.

Required Flow-Down Provisions

We endorse the use of flow down provisions to enforce Common Agreement requirement to Participants and Sub-participants.

TEFCA Information and Required Information

We strongly support a broad description of required information that must be exchanged by TEF participants for the Exchange Purposes. For IAS, the information required to be shared in response to a query should be any electronic protected health information that meets the definition of “designated record set” under the HIPAA Privacy Rule.

Governing Approach to Exchange Activities Under the Common Agreement

1. Representatives of patients and Individual Access Services providers should be included in the various governing bodies. At present, most representation and input from patients and IAS providers has been accomplished through listening sessions and public comment opportunities. We believe that it is critical for the patient, caregiver, and consumer voice to be present in all RCE considerations and the ongoing development of the TEF and iteration of the CA. Additionally, as flow-down provisions for IAS providers exist, it is critical that their perspective is also represented.

2. It is critically important that the provisions of the Common Agreement align with HIPAA and other regulatory requirements. Therefore, it will be critical to the success of TEFCA for ONC and OCR to clarify the role of Business Associates (BAs) who are “actors” under the information blocking rule regarding information sharing (i.e., the BAA should not be used to limit information sharing otherwise permitted or required by HIPAA).

Cooperation and Nondiscrimination

1. As the RCE moves forward in implementing both the Trust Exchange Framework and the Common Agreement, it is critical that the Agreement not set ID proofing or matching requirements in a way that discriminates against Individual Access Services providers. Similarly, the TEF should not require IAS providers to do more for ID proofing than other network participants. We would recommend the RCE move to adopt the NIST 800-63-3 IAL2 standard for all participants.

2. It is critically important that the provisions of the Common Agreement align with HIPAA and other regulatory requirements. Therefore, it will be critical to the success of TEFCA for ONC and OCR to clarify the role of Business Associates (BAs) who are “actors” under the information blocking rule regarding information sharing (i.e., the BAA should not be used to limit information sharing otherwise permitted or required by HIPAA).

3. ONC should also move quickly to enhance the value of participating in TEFCA by tying robust participation to the information blocking rules (i.e., presumption is that an actor is appropriately sharing EHI if participating in the TEFCA).

4. We are grateful that the RCE recognizes the value of consumer-facing applications and the utility of standards-based application programming interfaces (APIs), including the FHIR standard. We support the eventual transition to the use of standards-based APIs, specifically FHIR resources. We appreciate that this transition is on the technical roadmap for the RCE.

Individual Access Services

1. We agree that Individual Access Services should be a required exchange purpose for QHINs, Participants, and Sub-participants. We endorse the use of flow down provisions to enforce this requirement in the QHIN CA to Participants and Sub-participants.

2. We believe the concept of Individual Access Services should be clarified, to make clear that the act of responding to an Individual Access Services request is not Individual Access Services.

3. We endorse the privacy and security standards that would be imposed on any provider of Individual Access Services as a condition of participation in the Common Agreement.

4. While we agree that Non-HIPAA Entities offering Individual Access Services should not be required to respond to Exchange Purposes, we also believe this carve out should apply equally to HIPAA Covered Entities and Business Associates that provide Individual Access Services. We’d like to draw the RCE’s attention to the fact that information created, received, or shared as part of Individual Access Services must be managed, shared, and controlled by individuals, consistent with the HITECH definition of a “personal health record”. CARIN Alliance can point to examples of HIPAA covered entities and business associates that offer PHR functionality for patients and plan members.

5. Moreover, the data maintained by HIPAA covered entities or their business associates to support PHR functionality should not be considered “designated record sets” that require interoperability in response to requests for required exchange purposes. When considering this comment, we draw your attention to the fact that not all business associates are covered actors under the Information Blocking Rule. Moreover, HIPAA covered entities participating in the TEF may choose to respond to required requests through one or more designated business associates, rather than by each business associates that also participates in the TEF as a QHIN, Participant or Sub-Participant.

6. We support the proposal that a QHIN, Participant, or Sub-participant can voluntarily offer individual access services to persons with whom they have a direct relationship. As QHINs, Participants, and Sub-participants become more sophisticated and experienced in providing Individual Access Services, these direct relationships will allow for greater information sharing with consumers, including sharing through standards-based APIs.

7. We believe the diligent adoption of FHIR-based exchange under the TEF is important for the ultimate success of the Individual Access Services element. The importance of FHIR-based exchange is evident by the way in which FHIR APIs and standardization occurring at FHIR patient access API endpoints is already advancing consumer-directed exchange. FHIR patient access APIs through the TEF will advance consumer-directed exchange by eliminating the need for consumers to create portal credentials will not only remove friction from the consumer experience but advance the healthcare sector’s adoption of a common IAL-2 digital identity proofing standard.

Privacy and Security

1. As QHINs, Participants, and Sub-participants share information for Individual Access Services, it is critical to maintain clarity around who can query for individual services and how consumer-facing applications can facilitate that activity. Additionally, it is critical to ensure that Individual Access Service providers should offer protections like those outlined in the CARIN Alliance Code of Conduct. However, we also believe that IAS provider privacy and security requirements should only apply when providing those IAS services (as opposed to other use cases that the provider may support).

2. Regarding the requirement of all entities, including non-HIPAA covered Individual Access Services providers, to abide by most of the HIPAA Privacy Rule and the HIPAA Security Rule, we disagree with the framing that “most of the Privacy Rule” provisions should apply to consumer-facing apps. Individuals using apps should have stronger rights to control their data (vs. having that data subject only to HIPAA’s permissions like TPO). Additionally, security incident notifications should be consistent with existing breach notification obligations (whether HIPAA or HITECH) and should focus on threats to the network (existing definition of security incident aligns more with the HIPAA breach notification definition than those for personal health records under HITECH). As noted above, however, we do support privacy and security requirements for IAS services. We encourage the RCE to consider the CARIN Code of Conduct as the model for IAS providers to provide privacy and security, including by requiring proactive individual consent for additional data sharing activity.

Special Requirements (including Consent)

1. We recommend that the elements of Common Agreement make clear that a patient consent can be collected via an E-SIGN Act compliant means. As currently written, the Common Agreement requires that consent should follow HIPAA, but HIPAA doesn’t require the acceptance of a digital signature.

 

Definitions

TEFCA Information (TI) and Required Information
The CA proposes two new definitions, TEFCA Information and Required Information. We are a bit perplexed by these new definitions when the definition of EHI and USCDI already exist, as previously created by federal rulemaking. The EHI definition encompasses nearly all data that could be exchanged. We recommend the RCE utilize EHI rather than creating new definitions of the data that would be exchanged by QHINs.”

 

Exchange Purposes

We strongly support the inclusion of all the Exchange Purposes listed in the proposal in the final Common Agreement, and the corresponding requirement for Participants and Sub participants to respond, in accordance with applicable law. While networks have done a great job of ensuring data can be exchanged for Treatment purposes, very few have expanded to Payment and Operations or Individual Access, requiring organizations to do one off data use agreements and connections. Inclusion of these Exchange Purposes in the final Common Agreement, coupled with the flow down clauses requiring a response (when in accordance with applicable law) will enable significant efficiencies across the healthcare ecosystem and quickly expand data access.

In the Common Agreement, there is a proposal that “Only certain QHINs, Participants, or Sub participants could make requests for each Exchange Purpose. Specifically, a QHIN, Participant, or Sub participant may only request, use, or disclose TEFCA Information for a specific Exchange Purpose if the QHIN, Participant, or Sub participant is the type of person or entity that is described in the definition of the applicable Exchange Purpose.”

Generally, we agree with this limitation to ensure entities are only requesting data for purposes they are legally allowed to request for. However, this could be interpreted to exclude Business Associates acting on behalf of the type of person or entity in the definition of the Exchange Purpose since the HIPAA definitions do not reference Business Associates but do reference Covered Entities.

We recommend the RCE clarify in the Common Agreement that Participants and Sub participants who are Business Associates acting on behalf of an entity described in the definition of the Exchange Purpose may request data for such Exchange Purpose.

 

Fees

The request for comment indicates: “The Common Agreement is expected to include a provision that prohibits a QHIN from charging fees to other QHINs with respect to activities under the Common Agreement. QHINs would not be prohibited from charging fees to Participants.”

  • We understand the restriction on fees between QHINs for the Exchange Purposes of Treatment, Public Health, and Individual Access. We believe this fee restriction follows what most networks currently do. However, we do not completely understand why QHINs would not be allowed to charge reasonable fees to other QHINs for the remaining Exchange Purposes, particularly when a response is required. This restriction may limit the attractiveness of being a QHIN or a technology provider to a QHIN, thus putting the TEFCA at risk. We recommend the RCE revert to the last instantiation of the Common Agreement, which allowed for fees for these other Exchange Purposes, but required non-discrimination in charging of the fees.
  • Additionally, we ask the RCE to clarify if a Participant or Sub-participant would be allowed to charge a Requesting QHIN for EHI. The language in the Common Agreement is unclear on whether fee restrictions apply only to QHINs or to their Participants and Sub-participants as well.

Definitions

Collective Medical, a PointClickCare company, appreciates the opportunity to submit comments on proposed elements of the Common Agreement. We are supportive of the goals and objectives of the Trusted Exchange Framework and Common Agreement (TEFCA) and we applaud The Sequoia Project and the Office of the National Coordinator for putting forward this draft to solicit and incorporate stakeholder input.

As the nation’s leading real-time care notification, activation, and collaboration platform, Collective Medical’s comments stem from more than a decade of sharing information for care coordination, working with hospitals and care team members to ensure that they have the critical patient information they need to provide whole-person care. Together with PointClickCare, the healthcare IT market leader for the senior care industry, we form the largest combined acute and post-acute care network in North America, with more than 22,000 skilled nursing facilities and 1,300+ hospitals, ambulatory care centers, health plans, and ACOs.

With regards to Definitions, we recommend aligning as closely as possible with federal terms and definitions to ensure consistency and reduce complexity. We appreciate that the draft elements adopt this approach by pointing to definitions found in federal regulations.

Exchange Purposes

Collective Medical supports allowing participants to query for a broad range of purposes, provided that those purposes are not prohibited by Applicable Law.

We’d recommend that definitions and categories of Exchange Purposes align as closely as possible to existing exchange purposes and privacy laws that are outlined in federal laws such as HIPAA and 42 CFR Part 2. Healthcare providers must already comply with federal and state-specific data sharing laws. Adding new layers of exchange criteria can be administratively and technically burdensome and difficult to navigate. Therefore, we greatly appreciate the consistency with HIPAA and its “Treatment,” “Payment,” and “Health Care Operations” definitions throughout this section.

Similarly, it will be beneficial for response requirements to align with new Information Blocking requirements and exceptions so that entities requesting and receiving requests for health information can be held to the same standards, regardless of whether they participate in TEFCA.

Finally, although we do not find it necessary to be prescriptive about how this should be addressed within the terms of the Common Agreement, we do think it is important to acknowledge that some state laws include additional protections and requirements for health information Exchange Purposes that QHINs will need to be able to accommodate.

Participants and Subparticipants

Collective Medical is supportive of the proposed framework of Participants and Subparticipants and we agree with the construct of allowing stakeholders to connect at the point that is most appropriate for them.

Structuring the Common Agreement “Participant and Subparticipant” requirements to enable participation by a wide variety of provider types – spanning the large hospitals and health systems as well as smaller community-based providers – will be beneficial to ensure a comprehensive, holistic view of an individual’s health care journey.

There are several categories of providers and unique population groups—e.g., 42 CFR Part 2-covered programs, correctional health care, the Veterans Administration, and the Indian Health Service—whose health information is often siloed from the rest of the health care system for a variety of reasons. Receiving input from these groups on how their health information sharing needs could be met and structuring the Common Agreement to facilitate their participation could be hugely beneficial in connecting individuals’ health information across these disparate systems. We would also encourage consideration of how Subparticipants that play a role in an individual’s social determinants of health may participate in TEFCA, where applicable.

With this multi-layered approach, providing technical assistance and/or funding may be especially valuable for Participants and Subparticipants that need support making connections or navigating where and how they should connect.

Required Flow-Down Provisions

Collective Medical recognizes the importance of incorporating appropriate flow-down provisions into contracts and subcontracts. Given that many entities will need to go through the process of amending existing contracts, we recommend allowing a reasonable timeframe for incorporating flow-down provisions.

TEFCA Information and Required Information

Collective Medical supports allowing a broad range of health information to be exchanged as long as the exchange is in alignment with HIPAA and other Applicable Law. We would, however, request clarification on the statement that “Required Information would generally be the ePHI (as defined by HIPAA) that is created, received, transmitted, or retained by any QHIN, Participant, or Subparticipant […].” It is unclear whether Required Information could be retained by the QHIN. Given the large amount of ePHI that could be exchanged through the QHIN, retaining all data that flows through the QHIN could be a privacy and security concern unless there is a defined reason or Exchange Purpose for which the QHIN needs to retain the information. If QHINs are permitted to retain ePHI that flows through them, we would recommend considering limitations or restrictions on what can be retained, for how long, and for what purposes. This would also maintain consistency with the minimum necessary standard of the HIPAA Privacy Rule.

Governing Approach to Exchange Activities Under the Common Agreement

The governing approach to exchange activities under the Common Agreement will be critical to the success of this initiative. We are supportive of the proposed governing structure, and we look forward to learning more specifics about the transitional and governing councils, including how the members of these councils will be selected.

QHIN Designation and Eligibility Criteria

Collective Medical is generally supportive of the QHIN Designation and Eligibility Criteria. We would underscore the importance of the privacy, security, and technical criteria. This will be critical infrastructure for QHINs to have in place to demonstrate value and build trust.

Cooperation and Nondiscrimination

Collective Medical is generally supportive of the Cooperation and Nondiscrimination elements. It will be beneficial to put parameters on what will be considered a timely response and what will be considered limiting interoperability. We would again recommend close alignment with federal Information Blocking laws.

RCE Directory Service

The RCE Directory Service will be an essential resource for QHINs, Participants, and Subparticipants, and we commend the RCE for including this element. We recommend incorporating requirements to ensure that the Directory Service is as exhaustive and up-to-date as possible. Each Participant should be required to provide the following information for itself and all of its Subparticipants for inclusion in the directory: organization name, applicable identifiers such as an OID, contact information, address, organization type, parent company, date that the organization began participation, and associated QHIN. It will also be beneficial to define how frequently this information is expected to be updated to ensure that the list is current and to provide a way to retrieve a parsable version of the list from a well-known internet location.

Individual Access Services

Collective Medical agrees it is important for Individuals to have access to their health information and we appreciate that this element places an emphasis on an Individual’s rights related to their own ePHI. It will be important to develop a consent process and privacy notice that makes it transparent to Individuals what they are agreeing to when they are giving consent for access, exchange, use, or disclosure. Additionally, we recommend a high level of accountability and robust security requirements and processes for vetting IAS Providers. Any vulnerability, including from IAS Providers, can expose the rest of the network to security risks.

Privacy and Security

We applaud the focus on privacy and security and we echo comments from the RCE and stakeholders in acknowledging that this will be essential for protecting data and promoting trust across all layers of the TEFCA network. We suggest that QHINs be required to be HITRUST certified and, additionally, we recommend that Participants and Subparticipants be held to more robust security standards than the HIPAA Security Rule. There should be an accountability framework to thoroughly vet each Participant and Subparticipant from a security perspective to minimize the risk of a breach, which could occur at any level and could compromise the entire network. We recommend that the TEFCA security council develop a prescriptive, detailed security questionnaire. Participating organizations should be required to meet a certain threshold on that questionnaire annually. We recommend that QHINs be accountable for detecting and mitigating what appears to be intentional or malicious rogue behavior on their networks or security concerns, which would be defined by the security council.

Special Requirements (including Consent)

Collective Medical recognizes the complexity of consent issues and we appreciate the thoughtfulness with which the RCE has tackled this challenging topic. It will be important for QHINs to have a standard set of consent policies and technical controls that ensure appropriate access to and disclosure of health information and takes into account federal, state, and local regulations. The TEFCA approach should acknowledge that the requirements will vary when it comes to the type of information being shared and/or where the information originates. To the extent possible, we would recommend a consistent consent approach between QHINs and in their flowdown provisions. This will facilitate QHIN-to-QHIN information sharing and minimize complexity for Participants, Subparticipants, and Individuals.

Fees

Collective Medical does not have comments on the high-level fee elements proposed other than to acknowledge the challenge of covering the costs associated with building and maintaining a robust network such as TEFCA while ensuring that participation is not hindered based on prohibitive participation costs. We would be happy to participate in additional feedback sessions on this topic to discuss specific strategies or approaches.

 

Exchange Purposes

We request more clarity on the obligation to respond for all specified exchange purposes. There appears to be a conflict, or at best ambiguity, around Applicable Law and being capable of exchanging for All Purposes:

“Responses would not be required by the Common Agreement if providing the information is prohibited by Applicable Law or the Common Agreement.” (pg. 4)

While we interpret this to mean the QHINs, Participants and/or Subparticipants do not need to respond if it is prohibited. However, what about situations where it is permitted to deny the exchange of data? Specifically, the Information Blocking rule allows a party to deny a data request if it meets an exception. Does participation in TEFCA eliminate any of those exceptions?

For example, a security exception. Say a data holder decides TEFCA, as defined, does not sufficiently address security risks. By pointing to Applicable Law, it would seem the data holder could participate in TEFCA but regularly deny requests from data. We believe this will happen less for Treatment exchanges but is of particular concern for Individual Access Services (IAS). There is legitimate concern a responding party could have or could create a security requirement that relies on technology that is unavailable or unspecified in the QTF.

With the above said, for IAS and the security exception, we recommend specifying a high security bar by TEFCA itself. First, require a level of identification of the individual (IAL2 or in person equivalent). Second, specify a set of required demographics based patient matching logic for responding to IAS.

These together could make it infeasible to claim the security exception and still participate within TEFCA. On the Oct. 19 information session call (see time stamp 55:16-56:36 of session recording), someone asked about this exact scenario (a provider not responding to IAS requests under the security exception under info blocking), and the RCE representative cautioned that entities should be careful to set a “default deny” policy for IAS given the spirit of the Information Blocking rule. While this is sound advice, it seems to ignore the realities of how often data holders respond to IAS queries over existing large scale, query-based document exchange frameworks, which is very small today.

The use of this exception is likely amplified by the fact that info blocking specified FHIR APIs and user-provided OAUTH2 credentials as a documented technical requirement, while query-based exchange uses demographic matching with no standard requirement for an identity proofing process. Fixing this gap could accelerate adoption.

Regarding benefits determination, there is a technical obstruction here that likely requires a very simple technical fix. TEFCA was founded on IHE standards and their existing application at scale in the United States. This includes a standard set of codes included in transactions to represent Purposes of Use (PoU). TREATMENT, for example, is the code used for provider-to-provider exchange, while REQUEST is used for patient access requests (i.e., IAS). COVERAGE is the PoU used for benefits determination; however, the PoU code is not specific nor solely centric to governmental agencies. Rather, it includes commercial benefits companies such as life insurance and supplemental disability.

Rather than redefining Benefits Determination to reflect this is for government agencies only, the Common Agreement and/or the QTF should consider specifying a new PoU to indicate the benefits determinations query is specifically from a government association. Otherwise, responders will need to maintain their own whitelist and blacklists to specify when the COVERAGE PoU should be cleared by default. Finally, the Elements document makes mention of the six purposes being the ONLY exchange purposes ALLOWED (pg.5). We recommend allowing other PoUs to be used, but not requiring QHINs to support them yet. To help clarify, below we have leveraged the current Elements language and provided a suggestion how it could be worded and expressed in the Common Agreement:

Original Language (pg. 5-6):

At this time, only the six Exchange Purposes described above would be allowed under the Common Agreement; the RCE plans to work with stakeholders to identify additional Exchange Purposes over time, as appropriate. For example, requesting or sending information to support biomedical research could be identified as an Exchange Purpose in a future version of the Common Agreement, if amendments with appropriate requirements and protections are adopted in the Common Agreement.

Suggested New Language:

At this time, only the six Exchange Purposes described above would be specified under the Common Agreement; the RCE plans to work with stakeholders to identify additional Exchange Purposes over time, as appropriate. For example, requesting or sending information to support biomedical research could be identified as a specified Exchange Purpose in a future version of the Common Agreement, if amendments with appropriate requirements and protections are adopted in the Common Agreement. In addition, TEFCA entities may acceleration innovation to other areas of health interoperability by using the framework for other purposes of use that are in not in conflict with the Common Agreement, the QTF and their associated SOPs and policies.

The recommended addition acknowledges there may be other exchange purposes that could benefit from trust, policy and technical components of the TEF but are not yet ready for mandatory adoption at TEFCA scale. This would facilitate innovation within and between QHINs. It also would help TEFCA construct pilots of new Use Cases by avoiding the need for wholly new agreements from the RCE down through QHINs to Participants/Subparticipants.

 

Required Flow-Down Provisions

We have no comment on this section of the Elements document. We look forward to the publishing of the substantive details, at which time we will likely provide comments

 

TEFCA Information and Required Information

The addition of “TEFCA Information” (TI) as a newly defined health information data type is causing confusion. Likewise, while not articulated in the Elements document, it has been noted in other forums that there is consideration to segregate and/or track TI in a manner differently than current approaches. If at all possible, we recommend removal of this new data type and leverage current Applicable Law to define required information (PHI, EHI, etc.).

 

Cooperation and Nondiscrimination

We request more clarity on the term “discriminatory” used in the following context:

“In addition, QHINs, Participants, and Subparticipants would be prohibited from limiting interoperability with any other QHIN, Participant, Subparticipant, or Individual in a discriminatory manner.” (pg. 8)

The term “discriminatory” has been interpreted in similar frameworks in different ways by different entities. While it may not have been of extreme importance previously, when combined with the required support for all Purposes of Use, this definition may need some special attention and clarity to understand the intended scope of this concept. For example, in Carequality a lack of clarity has led to confusion on fees allowed for purposes of use beyond Treatment, which, in turn, has led to very low adoption of purposes such as Payment and Operations.

 

Individual Access Services

The privacy and security requirements listed for IAS make sense for protection of the individuals, but there is a notable exception of requirements that would facilitate data holders’ adoption as responders to this PoU. As mentioned in comments above, we encourage specification on patient identity and patient record matching. We recognize it may be beyond the authority of the ONC to create a safe harbor whereby a participant following the standard has immunity from legal action caused by wrongful disclosure caused by patient mismatches even when following the standard. Still, setting a standard for use in TEFCA may serve to create a defensible position without it providing full immunity.

 

Privacy and Security

Aligned with our comments on PoU and use of Exceptions allowed under Information Blocking, we have concern regarding the use of the privacy exception and the interpretation of state and local laws, which may be inconsistent with the bi-directional nature of exchange expected within TEFCA. Some states with opt-in regulations for exchange of health data have not responded to requests from providers outside their state unless the party on the other side of the exchange asserts consent in a manner that is perfectly in line with the state’s chosen model.

To be clear, this is not a concern about opt-in versus opt-out to DISCLOSE; this concern is more targeted at states that have opt-in methods for ACCESSING data. While we appreciate that states can implement their own privacy rules, where such a rule would allow them to be a one-sided exchange participant in TEFCA (requesting data but never responding), we should consider a mechanism to decide whether the participant should be disallowed from plugging in to the Trusted Exchange Framework (TEF) as it does not meet the spirit of the framework. Having such a mechanism may encourage states to modify their consent regulation to embrace a connected health care ecosystem knowing that a lot of care crosses state line.

Consent processes are necessary for patient privacy and security; however, safe exchange is generally better for patient care than no exchange at all. One suggestion could be leverage a governing committee of TEF to oversee addressing applicability of the standard and the granting of exceptions.

 

Special Requirements (including Consent)

This section speaks of Consent to Disclose. As explained in the section above, there also is consent to ACCESS regulations, which can make exchange across some state lines improbable to impossible. We think these consent rules create an unfair exchange playing field which is worthy of being specifically addressed in TEFCA.

 

Fees

We note that “QHINs would not be prohibited from charging fees to Participants” (pg. 10) does not say “QHINs would not be prohibited from charging fees to its Participants.” The absence of the word “its” implies QHINs may charge any Participant (and likely implied to mean Subparticipant) fees. Is this intentional? And is this intended to be constrained to specific Use Cases or for All Use Cases?

Another point of clarification: if Applicable Law allows a fee to be charged from one Participant (or Subparticipants) to another Participants/Sub for a specific record exchange, does this fee exception obviate the ability for QHINs to provide TEFCA billing services for its Participants? To facilitate the transactions, QHINs may want to track fees for its participants and pass an aggregated bill through to another QHIN, who would handle distribution of billing of its individual Participants and Subparticipants.

We presume this financial clearinghouse function is not intended to be considered a QHIN-to-QHIN fee but would appreciate clarification.

Exchange Purposes

The final common agreement should specifically address the ability of HIEs and similar organizations to persist data in their own data repositories that is requested and received by a Subparticipant or Downstream Subparticipant. Once data is requested for an Exchange Purpose, a Participant or Subparticipant that is an HIE or similarly situated organization that requested data on behalf of a Subparticipant or Downstream Subparticipant should be able to persist the data in its data repositories for use in accordance with Applicable Law – which may include use cases beyond the defined Exchange Purposes. The final version of the Common Agreement should specifically address this potential situation, to avoid the confusion that may arise if the subject is left silent.

Individual Access Services

The draft materials suggest that a QHIN, Participant, or a Subparticipant can choose to become an IAS Provider. In order to do so, such organizations will have to agree to certain additional protections, including specifically a requirement that IAS Providers permit Individuals to have deleted all of their individually identifiable information maintained by an IAS Provider. Depending on the nature of the organization serving as an IAS Provider, binding legal requirements associated with the maintenance of audit logs and electronic medical records may apply that would conflict with the obligation to delete all individually identifiable information upon request. The final version of the Common Agreement should specifically address that potential tension, and to avoid precluding a large segment of healthcare-related organizations from becoming IAS Providers, it should include a provision relaxing this requirement when deleting the information would violate Applicable Law.

 

Fees

The draft materials make clear that QHINs will not be prohibited from charging fees to Participants, but there is no language addressing Participants charging fees to other Participants or Subparticipants, and the implication of the materials is that data must be provided to requestors without the data providing organization assessing an associated fee. Have the drafters given consideration to the business models of HIEs, many of which rely upon participation fees collected from data sending and data receiving organizations to support their infrastructure and offset the costs associated with the services those HIEs provide? HIE Participants or Subparticipants may be adversely affected if the financial partners in local and regional HIEs could avoid financially supporting those HIEs by submitting requests for data held by an HIE through the national framework, rather than engaging in direct data exchange with the HIE.

Definitions

This isn’t really a definition, but I am unsure where else to put this:
– I am guessing this is a little early, but I would like to see TEFCA be a requirement, at least for some types of healthcare organizations, in the future. There are some organizations that are not part of any data sharing program currently, and I don’t see them joining TEFCA with it being a voluntary program. I would love it if the government found a way to subsidize TECFA for the greater good of the American people, with the goals of lowering healthcare costs in the US and providing better care with better outcomes.

TEFCA Information and Required Information

HIPAA Minimum Necessary – While having very good intentions, in some scenarios, HIPAA minimum necessary seems to complicate the exchange of data. I really liked where FHIR was going, because 3rd parties could request pieces of data that they need, rather than requesting the full chart. This especially comes into play for the exchange purposes of Public Health and Benefits Determination. I would like to see something in the SOP that requires requestors to only request info that they need, and for QHIN’s to support releasing pieces of a patient’s medical record rather than the whole CCD. 

RCE Directory Service

If these directories contain direct address, QHIN’s should be required to share direct addresses of all their participants with all other QHIN’s, and other organizations (such as HISP’s) at no charge. The recent interoperability rule requires that providers share their direct addresses on NPPES, but that is not being done, nor if that a reasonable way for other sites to ingest this data.

Individual Access Services

Individual Access Services (IAS) – There seems to be a lot of discussion about how to ensure that the person accessing data via IAS is accessing data for themselves, or that they are legally allowed to access data on the patient’s behalf. This reminds me of a lot of issues we have been having here with verifying that the person setting up a patient portal is in fact the patient. In our system, to set up a patient portal you go through an identity verification from a third party (Experian).

However, in many cases, someone close to the patient (a parent or a spouse) could gain access to the patient’s portal by knowing answers to these questions. There is little that we can proactively do to prevent this from happening. 20 years ago, when someone needed their health records, they physically went to HIM with their ID to prove their identification, which lowered the risk of healthcare data ending up in the wrong hands. With the internet today, we can put safeguards in place, but under some circumstances, it is very difficult prevent someone with knowledge of a patient’s personal data to not gain access to the patients’ healthcare information. At some point, there needs to be guidance or regulation that if healthcare organizations have safeguards in place to confirm identity, but we share data with someone who has fraudulently identified themselves as the patient, that we can not be held liable for a breach of HIPAA. Until then, I think HIPAA covered entities will continue to be concerned about this issue. Information blocking further complicates this issue because by not sharing data, a health care organization could face fines. I don’t have any real recommendations for you, but just know that this issue is happening outside of TEFCA.

  • Many patient portals can now use FHIR to pull data from other EHR’s. Our patient portal can even query public health registries, so patients have access to a lot more than just our data. With this in mind, I think there needs to be clarification of if these patient portals would be concerned an IAS or not.
  • “In addition, the Common Agreement would specify Individual rights that IAS Providers would need to provide, such as the Individual’s right to have deleted all of their individually identifiable information maintained by an Individual Access Service Provider and the right to obtain an export of their data in a computable format.”
    • There needs to be clarification for individuals who request their data be removed. If their data has been shared with a participant, that data will not be deleted retroactively, it will only be deleted to prevent further sharing. Also, how would this request by an individual be communicated back to any organizations that house data for this individual? Or would that not be in scope of this?

 

Fees

The Common Agreement is expected to include a provision that prohibits a QHIN from charging fees to other QHINs with respect to activities under the Common Agreement. QHINs would not be prohibited from charging fees to Participants.

  • On one of the webinars someone asked if it would be prohibited for QHIN A to charge QHIN B’s participants for data. I hope the common agreement goes into more detail about this topic and clarify who can charge whom.

View Submission File (PDF)

Exchange Purposes

EHNAC urges the RCE to move forward in its planning, but also to promote a coordinated approach to implement voluntary requirements and assure a successful implementation, rather than to accelerate the timeline. The infrastructure, policies, and agreed upon standards need to be in place to capture and transmit the data. Lastly, and most importantly, it has to work for all stakeholders, from the individual patient to the clinician, the payers and the business associates along the way.

Recent recommendations to NCVHS are repeated below as core to the success of the implementation of Interoperability:

A. Continued development and promotion of standards especially in the area of the use of new technology, with emphasis on the emerging FHIR standards.
B. Promoting trust through the encouragement and/or requirement of accreditation/certification will build a greater belief in the reliability of all actors across the healthcare spectrum that basic privacy, security and cyber security can be met.
C. Continued work to assure regulations and authoritative requirements are integrated and consistent further promotes ease of adoption of such standards.

Overall EHNAC supports the requirement for third party certification/accreditation of a recognized cybersecurity framework and related security assessments for QHINs, and all other flow-down participants (as appropriate) because this will promote industry wide third-party stakeholder, clinician and consumer trust. Should an unfortunate cyber-attack or breach to data occur, the entire facilitation of interoperability may be impeded. Once the trust in a third-party relationship is destroyed, it may never be restored.

Required Flow-Down Provisions

Recommendations are not yet provided for “flow down” participants as each may vary significantly and it is suggested the most appropriate “level” of privacy/security trust should be set with input from the QHINs themselves. EHNAC is available to assist in these recommendations when timing is impending.
Overall EHNAC supports the requirement for third party certification/accreditation of a recognized cybersecurity framework and related security assessments for QHINs, and all other flow-down participants (as appropriate) because this will promote industry wide third-party stakeholder, clinician and consumer trust. Should an unfortunate cyber-attack or breach to data occur, the entire facilitation of interoperability may be impeded. Once the trust in a third-party relationship is destroyed, it may never be restored.

Cooperation and Nondiscrimination

While EHNAC is appreciative of the “go-forward speed” with which the Elements of the Common Agreement have been processed along with other more broadly based interoperability related initiatives (ONC FAST, HL7 work; FHIR; DaVinci; Connect-a-thons, the promotion of Unified Data Access Profiles (UDAP), the Industry Glide Path for Dynamic Registration and Authentication and others), there is a concern that overall coordination could be improved upon.

In summary, there are currently many public and private stakeholders operating in somewhat of a silo state (as there is not one entity convening all of the stakeholders to create a unified, integrated and agreed upon common roadmap for overall implementation). The various initiatives noted above have shown that FHIR Use Cases and standards have been prepared and will allow for the secure, efficient and scalable adoption to reach interoperability. This work can be leveraged today. At present the need is for a coordinated implementation effort in order to take advantage of this work as standards will continue to evolve.

Privacy and Security

In order for the nation to achieve true “interoperability” of health data, EHNAC believes that healthcare organizations must be able to “trust” each other to appropriately share patient/individual data. The encouragement and/or requirement for each participant within the healthcare ecosystem to gain an independent third-party privacy/security/cybersecurity accreditation and/or certification is one proven method and trust framework to “raise the bar” with respect to the level of stakeholder-trust across the industry. Through participation in a rigorous accreditation program, our candidates receive multiple and specific reports to “share” their status and demonstrate to their partners that they can be “trusted” from a privacy/security and cyber-security perspective in addition to demonstrating they can provide operational/business stakeholder specific criteria in accordance with their program. By completing this independent review process, organizations also improve their cyber-readiness and preparedness planning to better handle cybersecurity incidents i.e., ransomware etc. and/or breach issues when they occur.

This level of independent review for all QHIN’s provides the necessary independent assessment needed to assure the appropriate level of review necessary to assure stakeholder-trust from all of the actors either exchanging data or accessing information such as patients through portals, smartphones or other electronic means. Additionally, by having an independent third-party review for QHIN’s, they will be best positioned to also be able to obtain cyber insurance from a carrier. Many insurance carriers are requiring independent third-party review before they will consider underwriting cyber insurance policies due to the increased number and size of claims due to the exponential increase in cyber attacks in the healthcare ecosystem. This is another key rationale for requiring an independent third-party review and to assure compliance and alignment with TEFCA requirements.

Specifically, regarding the current draft language, EHNAC suggests the following revisions for consideration (see red font language):

Regarding # 11. (Page 9) entitled “Privacy and Security” –

i. EHNAC applauds the RCE for “raising the bar” to required that non-HIPAA entities protect TEFCA Information to the same level as those subject to HIPAA

ii. EHNAC suggests the following revisions (changes in red font) to the wording in the 2cd paragraph:

1. “QHINs would be expected to meet and maintain third-party certification BY A FORMAL STANDARDS DEVELOPMENT ORGANIZATION (SDO) SUCH AS BUT NOT LIMITED TO EHNAC OR HITRUST to an industry-recognized cybersecurity framework an annual security assessment and PROVEN COMPLIANCE WITH THE ELEMENTS OF THE COMMON AGREEMENT.”

iii. Regarding the “flow down contract language: it is suggested that a “deeming provision” be added by using third party independent accreditation/certification as a way to allow proven standards can be met.

iv. Regarding the CyberSecurity Council – It is suggested that the membership be expanded to include independent members (outside of the QHINs) to assure that varying perspectives are provided, and that neutral feedback and arbitrators of issues are in place. The RCE may consider representation from other industry stakeholders such as “Participants”; “Clinicians”; “Consumers”; Standards Development Organizations and others to assure a non-biased application of policy governance is in place.

 

Definitions 

We note that when referencing “QHIN” it is not always clear whether the reference is solely to the organization that is providing the QHIN services, or is inclusive of all its Participants and Subparticipants. We suggest emphasizing that QHIN solely references the organization that is providing the QHIN services, unless it is specifically expanded to cover all participants. For example, when it is stated in 13. Fees that QHINs cannot charge each other, is that solely the organizations providing the QHIN services, or inclusive of any of its Participants and Subparticipants?

We note that the definition of “available” is unclear in “5. TEFCA Information and Required Information – …A QHIN, Participant, or Subparticipant that receives a request would be obligated to provide all Required Information that is available for the Exchange Purpose asserted…” We agree this is an appropriate concept to establish expectations regarding what data should be shared. We suggest, however, that this be further defined using the context of information blocking rules to align on data sharing requirements. It should address when “available” creates an obligation to share data considering the capabilities of the technology a Participant or Subparticipant has available, and the forms of the data that are available considering the required standards and specifications that are part of trusted exchange. It should also address whether EHI (a subset of the ePHI that makes up Required Information) maintained in a Participant’s system that is “disconnected” from trusted exchange that otherwise would fit within a required purpose of exchange use case should or should not be considered “available” when it would otherwise be considered information blocking.

Exchange Purposes

We appreciate the intent to support a broad set of exchange purposes. Current deployments indicate that the “Treatment” purpose is being widely supported and “Individual Access Services” is advancing, while there is minimal, if any, adoption of the other exchange purposes. This is due to a combination of factors: readiness of stakeholders on both sides of the interoperability use cases that support the relevant standards and technologies, due to conflicting priorities or lack of funding, and absence of sufficient guidance as to what data sets are appropriate to access and exchange, particularly using a query model. The EHRA recommends a phased approach to supporting the exchange purposes, starting with “Treatment” and “Individual Access Services,” and expanding as implementation guides for subsequent exchange purposes are incorporated into the QTF. Such implementation guides would also provide clear understanding of data sets/documents that can be shared to align with minimally necessary and fit for purpose considerations rather than being required to send all data on a patient in all circumstances. We suggest that such guidance, including summary grids on what data is expected to be shared for each use case, is best provided by expanding the QTF and SOPs as appropriate. Once available, QHINs, Participants, and Subparticipants can proceed with the necessary development and wide deployment. We note that based on ONC’s certification program, initializing wide deployment typically takes 18-24 months from the availability of specifications, depending on other regulatory requirements.

“…shared through QHIN-to-QHIN exchange…” and “Requests: TEFCA requests would be transmitted via a QHIN’s Connectivity Services…” appear to imply that the CA only covers brokered exchange. As we noted in our feedback on the TEF QTF, particularly relative to message delivery and FHIR-based access and exchange, not all exchanges need to be brokered. Current efforts to enable FHIR-based access starts with the actual queries, and after establishing trust, patient discovery, and obtaining endpoints from a directory, is all direct between endpoints. Likewise, message delivery need not be brokered as current case reporting use cases under the Carequality umbrella demonstrate. The EHRA strongly recommends that the TEF CA not make assumptions about the level of brokering that may be utilized, and instead leave that to the TEF QTF to address based on the specific needs and opportunities of the use cases at hand. It furthermore enables TEF to be a framework that reduces the number of point-to-point data sharing agreements that otherwise would be necessary.

The bullet on Responses indicates that a number of parties need not respond, beyond reasons of applicable law. We are concerned that the particular stakeholders, such as Public Health Authorities, certain governmental agencies, as well as Individual Access Service providers, would have data relevant and appropriate to others. Examples include public health data on patients individually or in aggregate that would enable a provider to offer better care for a specific patient or population; a provider being granted access to a patient’s data that is maintained by an Individual Access Service; or a consumer/patient obtaining their health data from a governmental agency. We suggest that the basic premise should be that Participants are engaged to enable sharing data with other stakeholders, including patients, who are authorized to access such data unless applicable law prohibits that, or the patient does not consent to such sharing. We suggest the Common Agreement should not add further restrictions, as clarity on how proper authority is asserted and consent is evaluated is defined through the TEF QTF to maximize sharing, reciprocity, and non-discrimination.

Participants and Subparticipants 

We appreciate and support the recognition of Participants and Subparticipants that reflect the potential organizations involved in enabling a national network infrastructure.

Required Flow-Down Provisions 

We support the need for flow-down provisions and look forward to reviewing the language more specifically once made available for public review.

TEFCA Information and Required Information 

We seek clarification as to why ePHI is used to scope Required Information while the Information Blocking rules use EHI. Wherever possible, common scope should be used to define what is minimally required.

Conversely, we must recognize that enabling interoperability not only requires EHI or ePHI, but also other data – including directory data, de-identified data, aggregated data, and other non-health data – which would imply that the Required Information scope should also be larger than ePHI or EHI. This further highlights that caution must be given to defining the scope of Required Information in the TEF CA, rather than through the QTF and SOPs.

In the context of this TEF CA element, we would like to reiterate the importance of not requiring that all information is always exchanged. The use case for each exchange purpose should clarify what constitutes “available” to ensure the intent and spirit of TEF is maintained.

Governing Approach to Exchange Activities Under the Common Agreement 

We support the general approach outlined to govern updates to the TEF CA, QTF, and SOPs and appreciate all stakeholders are involved and able to contribute.

QHIN Designation and Eligibility Criteria 

In our response to the TEF QTF we indicated the importance of reliable performance by the QHIN for the capabilities they provide (e.g., patient discovery). We support addressing this critical element in the TEF CA, in particular the statement: “Demonstrated resources and infrastructure necessary to support a reliable and trusted network.” This is critical for all Participants and Subparticipants to establish the necessary expectations and trust not only within their own QHIN, but across the entire TEF.

We want to reiterate the need for a phased approach toward supporting all exchange purposes and their use cases. Having insight into future exchange purposes (e.g., research) would also enable a QHIN to understand what additional exchange use cases they will need to be prepared to enable.

Cooperation and Nondiscrimination 

We fully support the notion and need for cooperation and non-discrimination, where for the latter the default approach should be to enable bi-directional, reciprocal interoperability unless the use cases are truly only limited to uni-directional interoperability.

RCE Directory Service

We appreciate the inclusion of a singular directory service that reflects all the relevant QHINs, Participants, and Subparticipants with their official endpoints/addresses for the various purposes that can be used in combination with the QHINs patient discovery services to easily and reliably find the correct endpoints/addresses.

Individual Access Services 

We understand that QHINs, Participants, and Subparticipants need not provide IAS for individuals, but must be able to respond to IAS requests from another QHIN, Participant, or Subparticipant that is an IAS Provider. The EHRA supports that approach. We do note that there can be use cases in which another Participant or Subparticipant, while not being an IAS Provider, has an appropriate interest in data for a patient they manage that is available through one or more of that patient’s IAS Providers. The EHRA suggests that the IAS Provider must respond to those requests by non-IAS Providers where the patient has provided such consent, and according to applicable law. While under FTC that app may be able to not share, we suggest that to participate under TEF they must share. We recognize that the relevant specifications to enable sharing would need to be developed before this capability can be deployed, yet the TEF CA should encourage, if not require, adoption of those capabilities at that time.

Privacy and Security

Privacy and security are critical components when creating a truly trusted exchange framework. As TEF is intended to encompass both HIPAA/42 CFR Part 2 covered entities and non-HIPAA entities, all parties must be held to the same level of secure exchange within the privacy policies across the various jurisdictions and a patient’s consent directives, with clear understanding and transparency of how the data is to be used by the connected stakeholders.

Special Requirements (including Consent) 

Consent management at scale remains a challenging but important element to enable access to data without a person needing to curate the authorized data set. Standards have been defined on how to tag data and how to assert presence of consents. Adoption is limited, and essential components necessary to have ubiquitous and computable awareness across a network on what data can be shared in accordance with applicable policies across multiple jurisdictions (federal, state, and local) and the patient’s consent directives are not available. We suggest that much work needs to happen before this becomes a reality. In the meantime, to comply with applicable law and consumer expectations, it remains important to establish consistent consent management and expectations across all actors in TEF. We encourage RCE to give additional guidance in the following areas:

  • Clarify what process will be permitted for capturing and sharing consent. In certain cases, consent may be collected through an intermediary or a third party and presented to the provider or entity holding the patient’s record such as can be the case with community providers and the Veterans Administration (VA) or under 42 CFR Part 2 for an emergency physician dealing with a patient in a medical emergency. In other cases, consent must be collected directly from the patient such as in non-medical emergency situations for a 42 CFR Part 2 patient and the disclosure of records by their 42 CFR Part 2 provider to non-Part 2 treating providers.
  • Clarify how the requestor is to capture consent compliant with all jurisdictions, as many have specific requirements for the scenarios in which consent is required and the language they must contain.
  • Address how consent expiration and revocation by the patient is to be handled.
  • Clarify who will take responsibility and liability when a consent is later found to be deficient. Is it the requestor for failing to capture consent properly, or the responder for disclosing PHI inappropriately? If it is the responder, then Participants and Subparticipants may expect to review consent prior to disclosure, which will hamper real-time data exchange.

 

Fees

We note that where there is bi-directional exchange among parties where both enable an infrastructure to ask and be asked that cost can start to be assumed to be sufficiently distributed to be equitable. However, when access and exchange is unidirectional, there is no such equitable sharing of infrastructure cost. While such a balance would exist in QHIN-QHIN exchanges, that would not necessarily be the case between Participants and Subparticipants within and across QHINs. For example, the benefits determination exchange purpose is mostly uni-directional. We suggest it is clear that appropriate cost-sharing approaches for such use cases remain permitted as currently is allowed by applicable law. If the intent is that all transactions under TEF are free, then other funding methods must be established for data sources to enable the essential infrastructure to support such exchange purposes and use cases.

View Submission File (PDF)

Exchange Purposes

Implementation Guides are Needed to Support Exchange Purposes
We support the aim of expanding health data exchange to use cases beyond Treatment. However, implementation guides (IGs) that adequately address and support the six exchange purposes outlined above have yet to be published and were not included in the QHIN Technical Framework (QTF). Defining IGs for each exchange purpose, including different use cases within a given exchange purpose, is an essential prerequisite to implement additional exchange purposes across a broad network. They include critical guidelines on the set data elements that is appropriate to disclose for each exchange purpose (while complying with HIPAA minimum necessary requirements), which entities can assert specific exchange purposes (and how to express that assertion using OIDs), and confidentiality codes that should be associated with different document types. Other networks like Carequality have published implementation guides for query-based document exchange for the Treatment use case that could be referenced by the QTF.
Without implementation guides for each exchange purpose, healthcare industry stakeholders will be unable to meaningfully participate in the TEF or adopt the TEFCA. Concerns about the infeasibility of ensuring compliance with federal, state, and local privacy rules including HIPAA’s minimum necessary requirements when responding to queries without detailed IGs will lead participants to be hesitant to join the TEF. Significant differences in how healthcare organizations interpret federal, and state regulatory requirements will lead to inconsistent implementation and support for non-Treatment/IAS exchange purposes. Consensus-based IGs would create industry alignment on the minimum scope of data necessary to fulfill the needs of a specific use-case and the expected uses and disclosures of that data for that purpose, streamlining information exchange.

Cost Concerns with Multiple Exchange Purposes
Provider organizations, public health authorities, payers, and other classes of Participants and Subparticipants have also been highly sensitive to the infrastructure investment and ongoing storage and maintenance costs associated with increased health information exchange capacity. Concerns about cost will be a major part of organizations’ consideration of whether to adopt exchange under the Common Agreement.

Treatment, the most widely adopted exchange purpose in use today, results in networks and healthcare organizations processing billions of transactions each year alone. Facilitating exchange on that scale requires investments in IT infrastructure at participating organizations, in order to ensure performant response times, to store the additional outside data received, and to maintain robust privacy, security, and audit logging capabilities. Networks and their participants also retain staff dedicated to managing the software and infrastructure required for exchange. Requiring the immediate adoption of five additional exchange purposes beyond treatment will result in significant increases in the number of exchange transactions that must be processed and will result in significant, unpredictable increases in the costs that participating entities will bear. This would be exacerbated by the current approach of the QTF, which requires all QHIN-QHIN exchange to flow through a central gateway.

We recommend adopting a staged approach to implementing additional exchange purposes via the Common Agreement. During the initial implementation of TEFCA, QHINs and their Participants/Subparticipants should be required to support exchange for the purposes of Treatment and Individual Access Services. The RCE should work with QHINs, Participants, and Subparticipants on a timeline for the development of IGs and rollout of support for additional use cases. The RCE should accept input on the priority of additional exchange purposes, establish timelines for development and testing of IGs, and establish deadlines for entities to implement support for additional exchange purposes as those IGs become available. Such a process could enable an additional exchange purpose to be adopted network-wide every 24-36 months. A standard process provides a clear and predictable roadmap for additional exchange to TEFCA entities, giving them time to plan additional hardware purchases, develop and test software updates, and implement new operational processes that support the additional exchange purpose.

Regarding Requests:
We agree that tailoring permissible exchange purposes based on the type of requestor is an appropriate safeguard against inappropriate use or disclosure of information in the TEFCA ecosystem.

Regarding Responses:
Reciprocity is a core principle for building trust in health information exchange networks. We recommend that the Common Agreement reflect this important principle by requiring all actors (including Individual Access Service providers and public health authorities) to respond to valid requests for health information unless applicable law or patient preference prevents them from doing so.

Extending the requirement to include Individual Access Service providers will promote greater patient choice by improving the portability of their data if they wish to switch between IAS providers and as patients move between providers in the healthcare system. This expectation aligns with the spirit of the policies advanced under ONC’s 21st Century Cures Final Rule and with patient expectations that information they give their care team and in apps that connect to their electronic records will be shared with all their healthcare providers. Because all requesting actors would need to adopt technology that supports the standards for exchange specified in the QTF, requiring actors to respond to requests would not create an unreasonable additional burden.

Required Flow-Down Provisions

We agree that it is appropriate for the Common Agreement to incorporate required flow-down provisions. Requiring QHINs, Participants, and Subparticipants to have common expectations, especially for privacy, security, and exchange reciprocity, will improve trust and accountability within the network.

TEFCA Information and Required Information

The current definitions for TEFCA Information and Required Information encompass a more expansive dataset than can be exchanged using mature standards today. Although we agree with the principle that an actor should respond with all the information it can reasonably provide to fulfill the request under applicable law, we believe it would be appropriate to define the scope of data required for exchange under TEFCA in terms of data classes, elements, and formats supported by standards adopted by the QTF for a given exchange purpose. For example, Required Information for the Treatment exchange purpose could be all of a patient’s USCDI v1 data exchanged via the C-CDA document format (as specified in the QTF). In another example, Required Information for Quality Improvement within the Health Care Operations exchange purpose could require the data classes supported in a properly formatted QRDA I or QRDA III document.

Defining TEFCA Information and Required Information in a way that refers to standards endorsed by ONC and adopted by the QTF would set clear expectations for actors and leave flexibility within the Common Agreement framework for the adoption of exchange purposes or formats that do not use individually identifiable patient information or other non-health related information like provider directories.

 

Governing Approach to Exchange Activities Under the Common Agreement

We support the governance approach described in the Elements of the Common Agreement. Establishing a mechanism for QHINs and Participants/Subparticipants to provide input into TEFCA’s management, operating procedures, and exchange activities will foster collaboration and a greater sense of responsibility for the network’s success.

 

QHIN Designation and Eligibility Criteria

We agree that it is appropriate for the RCE to establish an application process to evaluate prospective QHINs prior to their engagement in exchange via the Common Agreement. However, some of the draft QHIN Eligibility Criteria do not provide clear, objective, and demonstrable criteria that prospective QHINs must meet to achieve designation under the Common Agreement. This will make it more challenging for prospective QHINs navigate the onboarding process and understand the basis for decisions on whether they can achieve designation as a QHIN. Specifically:

  • It is unclear how prospective QHINs will demonstrate they are “capable of the exchange” for all exchange purposes. We are not aware of any network that facilitates exchange for all six exchange purposes according to the QTF’s specifications at scale, which could result in no prospective QHINs achieving designation. The RCE should instead specify that a prospective QHIN must demonstrate that it can facilitate exchange for at least one permitted purpose at scale according to the specifications of the QTF prior to designation.
  • It is unclear whether/how the signatory’s existing data sharing agreements, operating policies and procedures, or other related agreements will be evaluated in the context of QHIN designation, including whether certain terms or provisions of those agreements would disqualify an entity from QHIN designation, or whether the modifications will be required for existing exchange agreements outside of the purview of TEFCA.
  • It is unclear whether transaction volumes need to exceed a certain threshold to achieve designation.
  • It is unclear how contents of audited financial statements will be evaluated in the context of QHIN eligibility, including whether certain positions will be deemed disqualifying if a signatory otherwise meets the requirement to maintain operating reserves.
  • It is unclear how the RCE will evaluate whether the organizational structure and staffing are satisfactory for the operation of a QHIN.

The RCE should provide additional details on the demonstrable thresholds or criteria that signatories need to achieve for each of those requirements to promote transparency in the QHIN onboarding process.

 

RCE Directory Service

We agree that is appropriate to prohibit use of the RCE Directory Service for activities other than to expand or improve connectivity via the Common Agreement.

 

Individual Access Services

The RCE should clarify that offering a patient portal made available through a healthcare organization’s EHR does not constitute providing Individual Access Services under the Common Agreement. As written, it is unclear whether offering a patient portal would constitutes IAS. Today, some patient portals can provide access to data retrieved from outside organizations via FHIR APIs or network-based exchange. However, if a provider offers a patient portal with those capabilities, they may not be able to meet some of the IAS provider requirements, such as the right to data deletion. We do not believe that was the intent of the RCE to define a patient portal as an IAS offering, so we recommend specifying that an IAS Provider is an entity that is not an EHR-based patient portal that enables an individual to submit requests for information to all QHINs via the Common Agreement.

Robust privacy and security requirements should apply to all IAS providers. This approach would unify the data privacy and security expectations that apply to all handling of the sensitive information that IAS providers and other actors will have access to via TEFCA. The Common Agreement should require all IAS providers to comply with relevant provisions of the HIPAA Privacy and Security Rules, including those that prevent the inappropriate sale, use, or disclosure of patient data. Such a requirement would align with patient expectations that their sensitive health information is private and protected, regardless of the type of entity that possesses it.

 

Privacy and Security

We support the privacy and security requirements described in the Elements of the Common Agreement, as well as the expectation that they would flow down to all types of Participants and Subparticipants. Patients expect their health information to be protected regardless of whether a particular entity is subject to HIPAA rules. TEFCA should limit the collection, use, and sharing of private information to what is necessary to provide services requested by the patient, with exceptions only for necessary operational activities, similar to HIPAA. It should also include a broad prohibition on inappropriate secondary uses of data, such as commoditization or sale of private information. Patients should not have to navigate divergent opt-out processes for hundreds of organizations or service providers to prevent their data from being monetized.

 

Special Requirements (including Consent)

We agree with the principle in the Elements of the Common Agreement that consent for exchange should not be needed unless applicable law requires it. The RCE should clarify whether the requestor or discloser of health information is required to collect consent if it is required by applicable law. We believe it the discloser should be responsible, since state or local laws typically restrict the disclosure of health information without consent—not requests for health information. Setting the expectation that the discloser must collect consent (if required) will allow disclosers to ensure that the consent is documented in the form and manner required by applicable law, reducing their risk of liability for impermissible disclosures.

 

Fees

We recommend publishing the fee schedule for QHINs, Participants, Subparticipants, and other TEFCA entities as soon as possible, since it could play a significant role in the decision-making process for prospective TEFCA actors.

View Submission File (PDF)

Exchange Purposes

About Us: Health Utility Network, Inc. d/b/a Avaneer Health (“”Avaneer Health””) is a member-based, secure and open network supporting utilities developed for and by the healthcare industry. Avaneer Health’s mission is to unlock the potential of healthcare to do more for people through enabling new models for secure data exchange and fluidity across the ecosystem. Built using the latest in scalable technologies, including blockchain technology, to ensure privacy and reduce the costs of data exchange, it serves providers of services across the healthcare industry. Avaneer Health improves the care experience by removing administrative barriers and resolving inefficiencies in cross-party transactions that slow down or disrupt delivery of care. Avaneer Health and its partners Aetna, Anthem, Cigna, Cleveland Clinic, HCSC, IBM, The PNC Financial Services Group, Inc. and Sentara Healthcare are committed to improve transparency and interoperability in healthcare. With continuing support from the biggest players in healthcare, Avaneer Health will play a key role in transforming how the industry operates to address consumers’ needs more efficiently and effectively.

We support the proposed set of initial Exchange Purposes as we believe this initial set coverers a variety of existing use cases and offers broad opportunities to create efficiencies and reduce waste across multiple healthcare participants from the start.

That said, we think that this restriction to only use the Exchange Purposes defined could stifle innovation and believe that the Exchange Purposes should be more flexible from the start and allow all healthcare cases supported by the current legal framework. With that we propose to add a category “Other Permitted by Law”.

We also request to include Preventive Services in addition to Treatment Exchange Purposes. Specifically, coordinated activities between extended care teams participants (incl. Social Services and specialty community service providers) for prevention purposes are not clearly called out.

We support Sequoia’s Consumer-centric approach and Consumer use cases being developed in parallel with B2B exchange frameworks, as well as focus on related data security and compliance with HIPAA rules and other regulations .

With that, we would like to comment on the approach to the information exchange between QHINs, Participants, or Subparticipants. Specifically, as indicated on Page 4 of the Elements of Common Agreement, the information exchange between above stakeholders assumes Request-Response approach only. Not including alternative approaches, such as Publish-Subscribe, significantly limits the scope of applicable information exchange architectures and opportunities to innovate on the Network in order to achieve even greater effectiveness and efficiencies. For example, use of Publish-Subscribe model will allow real-time dynamic information updates across all authorized participants without the need for pushing the Requests and pulling the Responses each time information is needed. Therefore we request that information exchange approaches include the Publish-Subscribe models as well.

On the same note, we strongly recommend to explicitly support the employment of new / breakthrough technologies for connectivity and information exchange. These include, but not limited to Blockchain and Distributed Ledger technologies. Such technologies will ensure data provenance, audit trails and trust between participating stakeholders. It will also further foster the innovation on the network while attracting new stakeholders on both supply and demand sides of the ecosystem.

Participants and Subparticipants

We need to consider where regulation begins and where it stops. Given the complexity of network-of-networks organization, we propose that QHINs have the flexibility in defining the roles and corresponding layers in their respective networks as allowed by law.

QHIN Designation and Eligibility Criteria

About Us: Health Utility Network, Inc. d/b/a Avaneer Health (“”Avaneer Health””) is a member-based, secure and open network supporting utilities developed for and by the healthcare industry. Avaneer Health’s mission is to unlock the potential of healthcare to do more for people through enabling new models for secure data exchange and fluidity across the ecosystem. Built using the latest in scalable technologies, including blockchain technology, to ensure privacy and reduce the costs of data exchange, it serves providers of services across the healthcare industry. Avaneer Health improves the care experience by removing administrative barriers and resolving inefficiencies in cross-party transactions that slow down or disrupt delivery of care. Avaneer Health and its partners Aetna, Anthem, Cigna, Cleveland Clinic, HCSC, IBM, The PNC Financial Services Group, Inc. and Sentara Healthcare are committed to improve transparency and interoperability in healthcare. With continuing support from the biggest players in healthcare, Avaneer Health will play a key role in transforming how the industry operates to address consumers’ needs more efficiently and effectively.

Paragraph 2a (iv)
Requirement for Signatory to indicate the length of time that it has experience with Required Information Exchange in 2a (iv) and the time required more broadly in 3 will jointly create a potentially unintended barrier and significant disadvantage for innovative and emerging companies, including those with substantial existing support from major industry participants, extensive processing capability and traction with transactional processing – especially the seemingly arbitrary 12 month requirement articulated in 3. Given the other technical and operational diligence in place, as well as further to be developed SOP called for in 3, the elapsed time of experience and historical volume processing requirements seem stifling of innovation and also unnecessary. Therefore, we propose to exclude these requirements from the consideration.

Paragraph 2b:
“Signatory must submit the number and type of organizations that utilize its exchange services” – We propose to add “or committed to utilize its services” to avoid excluding the emerging innovative market players who already have commitments from their partner organizations, but still in the process of deploying the exchange services with them.

Paragraph 2c:
Might require provision ensuring the confidentiality of data being shared to avoid dissemination of proprietary/sensitive information. The same comment applies to Paragraph 4(iv) in scenarios when Contract Terms are being shared with RCE.

Paragraph 3:
Requirement for being operational and supporting the query functionality for at least 12 months will again discourage new / emerging companies from participations and, as a result, hinder innovation and competition. Therefore we propose to remove this requirement, or, alternatively, reduce time barrier to more reasonable 3 months.

Paragraph 3b: Same comment as above

Paragraph 4c (i):
Requirements to provide audited financials for the prior two years will again put new / emerging companies at disadvantage.”

Cooperation and Nondiscrimination

We strongly believe that Data Provenance and Audit Trails are important elements required for successful cooperation. Therefore we propose including these points in the expectations of QHINs. Accordingly, we propose including in the Agreement that a QHIN needs to have reliable technology to ensure data provenance and audit trail for the data exchange.

RCE Directory Service

We ask for more details on the RCE Directory Service capabilities and associated costs / fees.

Fees

The expected provision prohibiting a QHIN from charging fees to other QHINs with respect to activities under the Common Agreement [while allowing to collect fees from Participants] appears to be both too prescriptive and restrictive given the expected diversity of entities under QHIN definition and variety of Exchange Purposes as indicated in the Common Agreement. There is a certain cost to connect between QHINs and facilitate the information exchange, and such costs need to be covered. Likewise, enabling complex use cases and corresponding Requests might call for access to multitude of data sources, data cleansing, normalization, and extensive processing, that in turn requires use of significant additional resources.

Therefore, to ensure both flexible and sustainable economic structure, we recommend eliminating the above provision that prohibits a QHIN from charging fees to other QHINs from the Agreement. Alternatively, we recommend that inter-QHIN charges can be regulated as a utility fee that may also include ancillary value-add services (such as advanced data cleansing and normalization). In any scenario, we believe that the costs have to be recognized and compensated for.

Governing Approach to Exchange

Activities Under the Common Agreement
Question: Will these deliberative bodies also establish clinical data quality thresholds that must be met to be a QHIN? This goes beyond the certification. This references the clinical usability and the value of exchanging a complete clinical intention.

QHIN Designation and Eligibility Criteria

We have these suggestions for the following sections:

ii. Specify “Be capable of conducting exchange with unaffiliated organizations”. Is the information referred to here clinical information, PHI? Suggest specifying ‘secure information exchange…’ and specifying how secure is defined.

iii. Clarify various types of ‘how’ (e.g. which entity initiates information exchange (ie push messaging, push documents, query/retrieve from EHR, provider web portal lookup, etc.), Direct, on-going in near-real-time vs. scheduled batches (if so daily/weekly/monthly/etc.?)

iv. Regarding “Signatory must submit copies of its data sharing agreements, operating policies and procedures, and other legal agreements and related documents that govern the operation of its health information network” we suggest adding guidance for a ‘Signatory’s requirement to submit updates to all of its data sharing agreements, operating policies and procedures, and other legal agreements and related documents whenever said documents are formally updated by the Signatory’.

b. Provide examples for types of organizations related to “Signatory must submit the number and type of organizations that utilize” to “Signatory must submit the number and type of organizations (e.g. Organization employing providers/deliverers of healthcare services, organization employing case managers, schedulers, healthcare insurance, life insurance, academic researchers, for-profit researchers, etc.) that utilize…”

4.a.i Regarding “Signatory must describe the eligibility criteria for becoming a representative in its network governance, including any criteria related to ensuring the diversity of those participating in Signatory’s network are represented” we suggest “Signatory must describe the eligibility criteria for becoming a clinical data contributor representative and/or a clinical data accessor representative in its network governance, including any criteria related to ensuring the diversity of those participating in Signatory’s network are represented. Also, clarify what ‘diversity’ in this sentence refers to.

4.a.v. Consider explicitly requiring Signatory to ‘describe how the Signatory validates (candidate) organizations on technical security (ie. HIPAA Breach Notification Rule Requirements, presence/strength/types of firewall, encryption, etc.) as well as physical security in order to minimize risk for a breach to the broader WHIN network originating from the (candidate) network.’

Privacy and Security

On Page 9 of the Common Agreements, please consider including flow-down contract provisions for review.

Special Requirements (including Consent)

We suggest mentioning how consent related to Substance Use Disorder (protected under Part 2) applies or does not apply here.

Privacy and Security

Thank you for the opportunity to provide feedback on the Elements of the Common Agreement.

Mass General Brigham appreciates the details and consideration shared in the Common Agreement. We request clarification on the encryption requirements for QHINs as stated in the draft QHIN Technical Framework. Based on the draft, our understanding is that end-to-end encryption between provider organizations is not required, therefore allowing QHINs to access PHI and PII. We would appreciate confirmation of our understanding. If this is true, we would be concerned, we would like to see end-to-end encryption such that QHINs in the middle would not see PHI and PII have end-to-end encryption to reduce security and privacy risk for our patients.

We are very pleased to see this effort continue to move in the right direction. We hope you will consider creating a detailed implementation guide for participants that will support common understanding and consistency across the exchange network. We think providing specified instructions will make it easier for participants and help advance this great work.

Exchange Purposes

On behalf of Mayo Clinic, we want to thank you for the opportunity to share our comments regarding the Elements of the Common Agreement released by the Sequoia Project. We applaud the efforts of this initiative and believe that interoperability and a trusted exchange framework are essential to building the health care delivery system of tomorrow.

For over 150 years, Mayo Clinic has been committed to our mission of putting the needs of the patient first. Today, more than one million people from all 50 states and 130 countries come to Mayo Clinic to receive the highest quality care at sites in Minnesota, Arizona, Florida, and Wisconsin. As the largest integrated, not-for-profit medical group practice in the world, Mayo Clinic is dedicated to finding answers for patients through medical care, research, and education. With more than 3,600 physicians and 65,000 employees, Mayo Clinic brings together teams of specialists with a relentless and unwavering commitment to excellence. In addition, the Mayo Clinic Care Network is an affiliation of more than 40 independent organizations located across the country and world where local providers work with Mayo Clinic through technology and physician-to-physician collaboration to deliver a full spectrum of medical expertise to patients locally. This collaboration continues Mayo Clinic’s rich history of solving the most serious and complex medical challenges – one patient at a time. Mayo Clinic is proud to be top-ranked for quality more often than any other health care organization and has always ranked at or near the top of the “Best Hospitals Honor Roll.” U.S. News & World report named Mayo Clinic Hospital (Rochester, MN) once again as the No. 1 hospital in the nation in 2020-2021.

In our comment submission, we wish to highlight two key concerns regarding the proposed Elements of the Common Agreement. First, we note that the current TEFCA draft outlines six exchange purposes that would be required capabilities, with a requirement to support Treatment, Payment, Health Care Operations, Public Health, Benefits Determination, and Individual Access Services exchange purposes at launch. We note that while these six purposes have been identified, implementation guides are not yet accessible and to our knowledge no entity currently implements all six of these use cases. We urge the Sequoia Project to pause implementation of these specific exchange purposes until implementation guides have been released. These guides should be created by a Standards Development Organization and upon moving forward with implementation, we support a phased-in approach as opposed to an immediate requirement to support all six exchange purposes.

Fees

Second, we wish to respectfully express concern regarding the future funding model for the proposed QHINs. We are concerned that successful operation of a QHIN may entail substantial costs, and that in the absence of an established federal funding mechanism, these costs may be passed on to participating systems and stakeholders. It is specifically stated in the TEFCA Draft 2 that QHINs cannot charge other QHINs. However, there has been no mention of funding for individual QHINs. With added specific QHIN requirements in TEFCA regarding security, including decrypting and encrypting large amounts of data every day, the magnitude of the capital and operating costs for QHINs could become quite substantial. Mayo Clinic is a strong advocate for ensuring strong security infrastructure and privacy standards and appreciates this emphasis in the stated requirements. At the same time, we note that in the absence of more detailed design information, the costs of operating a QHIN are difficult to quantify and could even reach multiple millions per year.

We are concerned about the potential costs associated with participation in a QHIN and are interested in better understanding whether there has been further discussion regarding the funding model for QHINs and the direction this may take. In particular, we are concerned that large healthcare organizations may eventually shoulder many of the costs associated with QHIN operation. This could happen in instances where QHIN participation evolves from a voluntary to mandatory requirement, with associated participation fees based on number of providers or patients served by an organization. In these scenarios, costs passed on to a large healthcare organization could reach hundreds of thousands, or even exceed one million per year. We respectfully request that the Sequoia Project further investigate the financial models currently utilized by several state HIEs, and evaluate and recommend whether there are models in use that could serve as a framework for engaging QHIN stakeholders/participants without introducing significant financial burden

Mayo Clinic is honored to care for more than one million people a year including more than 400,000 Medicare and Medicaid patients. Mayo Clinic has long served as a strong voice for patients in improving America’s health care system, and we applaud your efforts to improve interoperability. For more information, please feel free to reach out to me, Elaine Vita, M.D. at Vita.Eleanor@mayo.edu, or contact Mayo Clinic Government Relations Director of Payment and Care Delivery Policy Sarah Meier at meier.sarah@mayo.edu.

Exchange Purposes

We caution the RCE from requiring a response to all Exchange Purposes from day zero of TEFCA. We believe the goal should be to realize all of the Exchange Purposes introduced, but there should be a timeline for when each purpose should/could be fully live. As some of the Exchange Purposes could require additional coding work, a quick turnaround time might be unrealistic for participants of TEFCA.

Required Flow-Down Provisions

We request further clarification on what the flow-down provisions are.

TEFCA Information and Required Information

Adding these additional terms, which resemble EHI, PHI or ePHI, seems unnecessary and adds confusion and burden. Instead, we recommend using the terms that are already accepted and understood by the industry.

Fees

We ask that the RCE provide clarity on the statement “QHINs would not be prohibited from charging fees to Participants.” The way this is worded implies that QHINs could charge fees to other QHIN’s participants. Please provide clarity on if this was intentional? And is this intended to be constrained to specific Use Cases or for All Use Cases? We would encourage the RCE to change the statement to “QHINs would not be prohibited from charging fees to ‘its’ Participants.” We would discourage the CA from allowing QHINs to charge participants (and likely implied to mean Subparticipant) outside of their network a fee for exchange.

Definitions

To the extent the definitions have an impact on the substantive elements of the Common Agreement, we’ve provided our comments on those definitions in connection with the substantive provisions. In this section, we further note the following:

  • Applicable Law. The current proposed definition would freeze in time the laws in effect at the time of execution. This aspect of the definition will create at least two problems. One, it will prevent the Common Agreement from staying current with the health information privacy and security landscape, which is under constant change. Second, it will create a situation where the applicable laws may differ depending on when a QHIN signs the Common Agreement. We thus respectfully request that this be changed to the “laws and regulations then in effect and as may be amended, from time to time, and applicable to the subject matter herein.”
  • Business Associate and Other HIPAA Terms. Many terms in the Common Agreement are defined by cross-references to the relevant HIPAA definitions. There is currently a notice of proposed rulemaking (NPRM) to change the HIPAA regulations and the HIPAA regulations will continue to change over time, potentially including regulatory citations. Thus, to the extent the Common Agreement will use terms as defined by HIPAA, we suggest simply including a statement in the definitions section that any capitalized terms that are not specifically defined have the meaning assigned to them by HIPAA.
  • Disclosure and Use. Because the vast majority of participants in TEFCA will be HIPAA covered entities and their business associates, we respectfully request that the terms “Disclosure” and “Use”—to the extent it is necessary to treat these as defined terms—have the same meaning assigned to them by HIPAA. We believe that adopting this approach will reduce confusion among participants within the TEFCA ecosystem regarding the meaning of these terms. Alternatively, the RCE should consider whether it is necessary to treat these words as defined terms.
  • HIPAA. HIPAA should be defined to include subsequent amendments. This is particularly important given the pending NPRM to change the HIPAA regulations.

Individual

The RCE’s definition of “Individual” is broader than the definition of this term under HIPAA. For instance, it includes any legal representative who can make healthcare decisions on behalf of person, even if that legal representative is not the person’s personal representative. That’s significant because the RCE defines Individual Access Services (IAS) in relation to this definition of Individual, but without accounting for the fact that the persons covered by the broader definition of Individual may not have the right to access, or to authorize a third party (such as a third-party application) to access, the full scope of TI without a HIPAA authorization. Moreover, as a result of the Ciox Health, LLC v. Azar, No. 18-cv-0040 (D.D.C. January 23, 2020) decision, an Individual’s (as defined by HIPAA) ability to use a third party directive under 45 C.F.R. § 164.524—that is, exercising the Individual right of access to direct in writing that a covered entity give a third party access to health information without a HIPAA authorization—is limited to that ePHI that is maintained in the “electronic health record” (as defined at 42 U.S.C. § 17921(5)). The TI will include ePHI that goes well beyond what is in a provider’s “electronic health record,” such as ePHI that comes from claims data supplied by health plans. Because the Ciox decision limits the scope of third-party directives, that avenue for permitting disclosure to third party applications is not available with respect to all the TI. Yet the IAS Exchange Purpose does not seem to account for this. For these reasons, we suggest that the RCE define “Individual” in accordance with HIPAA and reexamine the IAS Exchange Purpose in accordance with Ciox and the sources of TI.

Exchange Purposes

  • MiHIN supports a contractual framework for exchange purposes that align with HIPAA and gives participants at all levels of the TEFCA ecosystem the ability to opt out of particular exchange purposes for which they cannot support compliance with applicable laws. It is MiHIN’s experience that community health information exchanges (HIEs) today are generally structured to support HIPAA-permitted treatment, payment, and health care operations, as well as some limited public health use cases. However, the industry is less mature with respect to supporting HIPAA-authorization based use cases (such as Benefits Determinations) and Individual Access Services (IAS). Additionally, many states still impose written consent requirements on the disclosure of health information for non-treatment purposes, including disclosures for payment and health care operations activities. The issues that arise with these use cases typically involve who has the responsibility (and liability) for ensuring compliance with HIPAA authorization requirements (and other state or federal consent requirements), as well as individual identity and authority verification. For instance, the RCE contemplates permitting individuals to use consumer-facing applications owned or offered by entities who will verify the individual’s identity and authority. Yet, because many of these applications are not subject to HIPAA, there are not satisfactory assurances that the identity and authority verification measures used will meet HIPAA-required privacy and security standards—the standards for which HIPAA covered entity and business associate participants in the TEFCA framework are required to meet to ensure that the access or disclosure is authorized, and not a breach. Moreover, delegation of these HIPAA obligations—that is, the responsibility for verifying individual identity and authority—is typically a function that triggers a business associate relationship and requires execution of a business associate agreement (BAA). We thus seek clarification from the RCE as to whether and how the Common Agreement will flow down BAA requirements to IAS Providers who will perform these functions, and who within the TEFCA framework will be responsible for auditing and monitoring IAS Provider compliance with BAA obligations as part of routine HIPAA risk analyses.
  • Because of the practical reality and maturity of existing technical systems—and limitations on the ability to adequately allocate responsibility, risk and liability under the Common Agreement—we respectfully request that the RCE consider removing the Benefits Determinations and IAS Exchange Purposes from the list of Exchange Purposes for which QHINs, Participants and Subparticipants are required to respond. Rather, these should be Exchange Purposes for which participants in the TEFCA ecosystem may respond. Mandating exchange for the use cases could be reserved for future iterations of the Common Agreement.
  • MiHIN would also like to note that HIPAA does not permit the exchange of protected health information (PHI) among non-HIPAA covered entities (and their designated Business Associates) for the full range of health care operations activities (as defined by HIPAA), when the entity requesting PHI is doing so for its own its health care operations activities and/or the entity disclosing the PHI is doing it for the receiving entity’s health care operations activities. HIPAA limits such exchanges to exchanges among HIPAA covered entities (and their designated business associates) for the purposes listed in paragraph (1) or (2) of HIPAA’s definition of “health care operations” or for the purpose of health care fraud and abuse detection or compliance. See 45 C.F.R. § 164.506. Yet the current Common Agreement definitions and proposals for limiting Exchange Purposes based on an user’s organizational identity do not seem to account for this. The RCE should also consider whether administrative and technical infrastructures are sufficiently developed to support a TEFCA Exchange Purpose framework that will require Participants and Subparticipants to identify at the user-level organizational and individual status using a role-based access model that may meet TEFCA needs, but might not align with the role-based access permission used internally by these organizations. Accordingly, the RCE might want to consider limiting the Exchange Purposes to what can reasonably be supported by existing infrastructures and role-based access models.
  • MiHIN would ask the RCE to reconsider the structure for Permitted Purposes contemplated under the Common Agreement. Currently, a QHIN must facilitate exchange under Treatment, Payment, Healthcare Operations, Benefits Determination, Public Health, and Individual Access Services. While many Health Information Networks and Health Information Exchanges comply with sharing under the Permitted Purposes, their Legal Agreements are not structured to share health information by purpose for sharing. Instead, sharing may be facilitated through Use Case Agreements or Exhibits, which outline how information is shared as opposed to why the information is shared. A type of sharing could function across multiple Permitted Purposes. For example, MiHIN provides for an encounter notification use case, titled Admissions, Discharge, and Transfer (ADT) Use Case. This Use Case allows for an ADTs to be shared with all members of a patient’s care team regardless of if this information may be used for treatment, payment or both. We suggest the RCE remove these predefined Permitted Purposes and allow QHINs and Participants to share information through their existing workflow. The foreseeable problem with predefined Permitted Purposes is organizations eligible for QHIN status may not be the best entity to accommodate each Permitted Purpose. Further, it would require QHINs and their Participants to restructure their Legal Agreements and explicitly state for which Permitted Purpose each Use Case functions.
  • Finally, MiHIN seeks clarity from the RCE on why signatories that are Non-HIPAA Entity providers of IAS are not subject to mandatory response requirements under the Common Agreement.

Participants and Subparticipants

  • MiHIN supports a TEFCA ecosystem that supports participation by a broad range of stakeholders that are authorized under federal and state health information laws to have access to health information for legally permissible purposes. The core TEFCA Exchange Purposes—treatment, payment and limited health care operations—are all limited by HIPAA to those individuals and organizations that qualify as covered entities and business associates and, in some instances, non-covered entity health care providers (as defined by HIPAA). Yet the RCE proposes to define QHINs, Participants, and Subparticipants as including entities that are not covered entities or business associates, and does not purport to limit these entities to other entity types that may be permitted access under other HIPAA-permitted use cases, such as public health authorities or entities for which an individual has issued a third-party directive that would permit the limited access of health information maintained in electronic health records. Expanding participation beyond those individuals and entities that are permitted access under HIPAA may have the unintended effect of undermining the trust framework because there is a lack of certainty regarding the legal authority of entities and individuals who will have access to highly sensitive health information about individuals.
  • Additionally, the RCE proposes to permit participation by non-U.S. Entities. Non-U.S. Entities may access and store data outside of the United States. This is particularly problematic, as many individuals and entities that exchange health information, including health information of Medicaid and Medicare enrollees, are expressly prohibited from permitting offshore access to the health information. Moreover, the potential introduction of data into the TEFCA ecosystem that comes from jurisdictions outside of the United States may trigger compliance obligations under non-U.S. laws for which other participants in the system may not be equipped to handle. Accordingly, we respectfully request that the RCE reconsider the scope of participation in TEFCA.

TEFCA Information and Required Information

  • MiHIN supports the exchange of electronic health information in compliance with applicable laws. As proposed, the Common Agreement will require participants within the TEFCA ecosystem to respond with all “Required Information” (RI). This is currently defined as essentially all ePHI, except for information compiled in anticipation of or use in civil, criminal or administrative actions/proceedings or psychotherapy notes (as defined HIPAA). However, this contractual requirement does not take into account what data elements can be technically supported through the various exchange networks. For instance, it may be technically infeasible for a participant in the TEFCA ecosystem to exchange all RI if the connection at issue, or implementation guide being used, does not support exchange of that data element. For that reason, we respectfully request that the RCE redefine RI such that it may be limited to those discrete data elements that are supported by the applicable technology being used by that QHIN, Participant or Subparticipant to enable the data exchange.
  • MiHIN also understands that under the Common Agreement QHINs and Participants that facilitate the data exchange network as a service—and as a HIPAA business associate of one another with respect to TI of those individuals for whom a QHIN or Participant might not be functioning as a business associate under its agreements with Subparticipants because those Participants/Subparticipants might not have a relationship with all the individuals for whom they are transacting data across the network—will be permitted to retain and use that TI in accordance with the laws that apply to them. MiHIN seeks clarity from the RCE on how this model will ensure that a QHIN and/or Participant that is retaining TI on behalf of another QHIN will not use or redisclose or that TI in violation of more stringent laws or business associate limitations (such as no permission to support IAS) that might apply to those QHINs/Participants. For example, if due to regional laws QHIN A cannot exchange health information for the full range of HIPAA-permitted health care operations activities without a written authorization, and QHIN A facilitates the push of such information to QHIN C for delivery to QHIN C’s Participants’ Subparticipants through QHIN B (whose Participants and Subparticipants do not have a relationship with those individuals) pursuant to a written authorization that authorizes the disclosure to those Subparticipants of QHIN C, how will the Common Agreement ensure that QHIN B does not use or redisclose the TI in violation of the individual’s written authorization or without the individual’s written authorization? We understand that the RCE intends to require all participants in the TEFCA ecosystem to comply with all applicable laws—including more stringent laws; however, the mechanisms for ensuring this are unclear and may be challenging in situations where the data being retained by pass-through QHINs and Participants is subject to different and inconsistent laws. The RCE may thus want to consider whether pass-through QHINs and Participants should be permitted to retain TI.

Governing Approach to Exchange Activities Under the Common Agreement

  • MiHIN supports a governing approach that not only solicits participation, but places governance in the hands of the stakeholders that will be participating in the TEFCA framework. To that end, MiHIN respectfully requests that the RCE consider giving the Governing Council greater decision making authority over which entities will be qualify for QHIN status.

QHIN Designation and Eligibility Criteria

  • MiHIN supports the development of QHIN eligibility criteria that is designed to create a reliable and trusted technical, legal and administrative framework to support regional and national interoperability in the United States. In particular, we strongly support the RCE’s s requirement that a QHIN applicant demonstrate network governance, and we further suggest that the RCE consider whether that governance model allows for stakeholder input in governance decision at the local and regional levels among Participants and Subparticipants. MiHIN further supports the RCE’s requirement in the Draft QHIN Eligibility Criteria that all QHINs be U.S. Entities. However, MiHIN notes that throughout the RCE’s “Elements of the Common Agreement” draft, the RCE provides that under the Common Agreement a QHIN may be a “non-U.S. Entity,” see, e.g., page 17 (definition of QHIN). We thus seek clarification from the RCE whether, and under what circumstances, a QHIN may be a non-U.S. Entity. Because of the regulatory and legal challenges associated with accessing and storing health information outside of the United States, as well as potential applicability of more stringent non-U.S. laws associated with the exchange of some data from certain jurisdictions, we urge the RCE to limit QHIN eligibility to U.S. Entities.
  • MiHIN further supports criteria used to evaluate technical capabilities to support the exchange of Required Information (RI). However, we seek further clarity on the QHIN eligibility requirement that a QHIN be able “to support” the exchange of Required Information for all Exchange Purposes. Specifically, is this intended to mean technical support for the exchange modalities (e.g., query or push) or something more? MiHIN further requests that the RCE provide guidance on whether it will enter into non-disclosure agreements with applicants to protect the confidentiality of proprietary information required as part of the application process—such as data sharing agreements, operating policies and procedures, financial information, technical infrastructure gaps, and breaches—as well as the extent to which such information may be subject to federal public record requests.
  • MiHIN also understands from the public calls that the RCE is discouraging new market entrants from applying for QHIN status and will require twelve (12) months’ worth of high volume activity on existing networks, in addition to requiring significant financial and administrative disclosures (such as two years of audited financials). Requiring applicants to prove high transaction volumes on a TEFCA network and financial viability for that network going back two years prior to TEFCA implementation poses an interesting challenge, and may have the unintended effect of reducing innovation and competition at the QHIN-level by significantly limiting the pool of applicants to only those existing networks on which the TEFCA model is being based. MiHIN thus suggests that the RCE clarify that QHIN applicants may meet the 12-month requirement by demonstrating activity among its members, affiliates and/or potential Participants and Subparticipants, even if the QHIN entity itself was not incorporated or otherwise formed within that 12-month period. Additionally or alternatively, the RCE should consider permitting applicants to demonstrate, via other means, their ability to support high volume activity on the TEFCA network it is requesting QHIN status in order to build and operate. Similarly, other avenues should be available to assess sufficient financial and personnel resources. In sum, we respectfully request that the RCE consider developing alternative QHIN eligibility criteria that will meet the intended goals—ability to perform, legal structure/governing approach, and resources/infrastructure—while maximizing market participation.
  • MiHIN also seeks clarification from the RCE on whether and why the 12-month requirement is applicable only to query functionality and not push functionality, or other modes of functionality required by the Common Agreement? Emphasizing one form of exchange over another may again have the unintended effect of discouraging innovation and competition at a time when recently finalized and proposed CMS interoperability regulations are placing an increased emphasis on push functionality (such as admission, discharge and transfer alerts).
  • Under the QHIN Eligibility Criteria, organizations applying for QHIN status must submit their monthly and annual metrics. We request the RCE refrain from requiring organizations meet a certain threshold. Further we request the RCE to consider how these numbers will be subject to significant change once an organization begins functioning as a QHIN. As an example, many HINs currently share information through eHealth Exchange today, however, under this new framework, QHINs will share in the responsibility of national health information exchange. This will, in turn, increase QHIN numbers, and decrease eHealth Exchange numbers. To remedy this, we request the RCE refrain from instating thresholds during the QHIN Application process and consider variability is likely to occur during Provisional QHIN status. If a requirement is in place, we request the RCE allow HINs and HIEs to include their eHealth Exchange contributions.

Individual Access Services

  • MiHIN supports efforts to improve individual access and control over their health information within the existing federal and state privacy and security. As currently envisioned, the Common Agreement will require QHINs, Participants and Subparticipants to support individual access to TI data maintained by that entity. Under the HIPAA compliance framework, whether or not a business associate (such as a QHIN or Participant) can support an individual access use case is determined by the permissions given to them in the HIPAA business associate agreement (BAA). HIPAA covered entity providers and health plans may not be willing to permit third parties to provide (or facilitate) individual access services in the BAA because, for example, the electronic health record (EHR) technology is not yet sophisticated enough to segment data that a provider or plan has determined there is a legal compliance or legally cognizable harm that would result from the access. Consequently, and due to data segmentation infeasibility, the only approach for those data suppliers may be to withhold permission to support an individual access use case. Moreover, there are significant security, technical, administrative and cost considerations associated with whether the identity and verification processes associated with IAS meet minimum HIPAA privacy and security requirements. IAS Providers that are not regulated by HIPAA may have processes in place that do not meet HIPAA requirements. It is for these reasons that it may be premature to require support for IAS at this time.

Privacy and Security

  • MiHIN applauds the RCE’s commitment to requiring all participants within the TEFCA ecosystem to comply with basic security requirements, such as encryption and security incident notifications. However, the RCE’s current proposals for the Common Agreement and SOPs are silent on the minimum identity and authority verification procedures that must be in place to support IAS. These security procedures are critical to any exchange framework that will support IAS. The Office for Civil Rights (OCR) often refers covered entities and business associates to the National Institute of Standards and Technology’s (NIST) publications for guidance on the security protocols necessary to meet the HIPAA privacy and security standards. Given the high sensitivity of the health data that will be exchanged through the TEFCA framework, the NIST Digital Identity Guidelines (NIST SP 800-63-3) and subsequent guidance (NIST SP 800-63A and NIST SP 800-63-3) would suggest an Identity Assurance Level of no less than IAL2 be required for IAS Providers.

Fees

  • MiHIN supports establishing a TEFCA framework that is marketplace neutral and will support innovation and competition. To that end, the Common Agreement should permit participants that operate within the TEFCA ecosystem at all levels to seek to recover the costs for their services, including a reasonable profit margin, and to be exempt from required data exchange in those instances where the data requestor has not paid a reasonable fee for services. To promote this innovation and competition, MiHIN respectfully requests that the RCE consider neither prohibiting nor endorsing any particular economic model for cost recovery. Rather, QHINs, QHIN Participants and Subparticipants should have the economic freedom to choose their business models. Prohibiting fees in certain circumstances (where fees would otherwise be permissible under applicable law), and mandating exchange with entities that have not paid for those services, may have the inadvertent consequence of undermining innovation and competition by limiting QHIN- and Participant-level participation among existing marketplace actors whose corporate and financial structures may enable them to offset the true cost of data exchange services under TEFCA through their non-TEFCA, commercial business models.

Definitions

The Washington State Department of Health appreciates public health be specifically a part of the exchange purpose(s) definition. Our mission critical work should be reflected in TEFCA as we hope to leverage it for better ensuring we can respond to public health emergencies. We also appreciate the definitions being added for Public Health and Public Health Authority. Most of our work is not as a covered entity and it is important that we can continue to exchange patient data, without consent, as our laws allow. This is critical for public health to be able to perform our mission critical work.

Exchange Purposes

The Washington State Department of Health is pleased to see that public health remains an exchange purpose for TEFCA. This is very important to ensure Public Health can respond and contain disease outbreaks and other essential work. We applaud having language for a specific exception for public health not having to respond to all queries as some would not make sense or be allowed based on our laws and regulations. We appreciate being able to leverage TEFCA for uses and disclosures by public health authorities that are consistent with HIPPA and other applicable laws.

Participants and Subparticipants

The Washington State Department of Health appreciates calling out Public Health in this section as a potential sub-participant. We agree that this is likely the role that makes the most sense for our agency. We would encourage continued focus on ensuring that any requirements placed on participants and sub-participants consider that public health authorities are not treated as a covered entity or business associate under HIPAA.

Required Flow-Down Provisions

The Washington State Department of Health appreciates the need to have flow-down provisions for governance, security, and privacy concerns. That said we again would reiterate that no provisions should restrict public health authorities from being able to use and disclose patient information as our laws and regulations allow. Nor should they require us to respond to information requests that do not align with our current laws and regulations. Finally, we need to see what security provisions would be required. While we have very robust security policies in place it is hard to know if they align with what TEFCA will be requiring. We need to ensure that no undue burden is put on public health agencies to meet any provisions.

TEFCA Information and Required Information

The Washington State Department of Health agrees with the need to define what information would be included in these exchanges. Our general concerns remain around ensuring nothing here would restrict a public health authority regarding how they collect, use and disclose protected health information or put requirements on public health authorities to provide protected health information that conflicts with our laws and regulations.

Governing Approach to Exchange Activities Under the Common Agreement

The Washington State Department of Health appreciate the need for robust governance for something as impactful as nationwide interoperability for healthcare data. Since public health is a specific exchange purpose for TEFCA we feel public health authorities should be part of any governance body. We request that state public health agencies be specifically including in the Transitional Council, the Permanent Governing Council, the Participant/Sub-participant Caucus, and any advisory group that focuses on work that impacts public health.

QHIN Designation and Eligibility Criteria

The Washington State Department of Health supports the need for designation and eligibility criteria to be established and welcomes the opportunity to provide input on them when they are released. In general, we want to see assurances that the applying HIN can successfully exchange data for public health and ensure that our rights as a public health authority are upheld in how they govern their network. We also support having robust requirements for security, including annual 3rd party audits to ensure compliance. QHINs should also be able to prove they can handle the volume of transactions they will likely have to keep up with, ensuring that response times are efficient.

Cooperation and Nondiscrimination

The Washington State Department of Health supports the need to ensure discrimination does not occur between or within QHINs. As far as timely responses to inquiries and notification of connectivity failures we ask that those be reasonable and enable proper responses that include a state law/rule prohibits a public health authority from responding to a request.

RCE Directory Service

The Washington State Department of Health would be interested to see how the common agreement would ensure the directory is not used for marketing purposes. This could be challenging to address in policy language but is important. If FHIR is not going to be used as part of the initial QTF we would want to know what will be used to standardize entries into such a directory for the start of the TEFCA in 2022.

Individual Access Services

The Washington State Department of Health appreciates the need for the common agreement to address how IAS Providers must operate. That said, we have some concerns about the proposal that the agreement would require IAS Providers to obtain consent from individuals. Again, a public health authority does not need to obtain consent to collect, use or disclose an individual’s information for purposes allowed by law/rule. We encourage the RCE to ensure the CA has this exception specifically called out for IAS. Similarly, we would not want a public health authority to be required to delete an individual’s information we have collected and are using for public health purposes. Certain individual rights like this should not be placed on public health authorities.

Privacy and Security

The Washington State Department of Health takes privacy and security very seriously in our public health duties. We collect, store and disclose large amounts of protected health information every year. We ask that any requirements for privacy and security not be any more onerous then what public health authorities already have in place as we do not have resources for implementing large changes. We also ask that breach notification requirements align with what public health authorities do today. We appreciate the requirement for QHINs to meet and maintain 3rd party certification for cybersecurity and undergo annual security assessments as we need assurances the network is protected.

Special Requirements (including Consent)

The Washington State Department of Health appreciates the special requirements that will be needed for the CA and appreciates that the current language would allow for local variability for different state laws/rules. We would again caution here to ensure no special requirements restrict a public health authority from being able to conduct our mission critical work to protect the public.

Fees

An earlier version of TEFCA provided an exemption for public health transactions so that they would not be subject to any fees. Given the immense importance of public health data exchange, especially during a pandemic, the Washington State Department of Health asks that this exemption is put back into the CA. We need to ensure there are as few barriers as possible to receiving the essential data we need to control disease spread and perform surveillance. By specifically exempting public health reporting from fees (both QHIN to QHIN and within QHINs) the RCE can help ensure timely data is submitted to and from public health authorities. As public health authorities modernize our systems it is important we encourage our partners to submit electronically and not continue to fax which costs us time, money and results in a much slower response.

Privacy and Security

Would like some clarification on why the data going through the QHINs need to be unencrypted. It does not seem necessary/secure to give QHINs access to all this data.

Similarly, we are curious as to the details of the SOP about QHIN securit

Fees

There is concern about the role of QHINs as they work as a middle-man for exchange purposes. There does not seem to be much clarity on what sort of fees they’d be allowed to charge participants or if they would be barred from selling the data to make up the costs

Comments:

  • Suggest beginning with TPO only and expand to Public Health, Benefits Determination and Individual Access Services later. TPO is foundational but still evolving. Let’s improve and learn from it before expanding.
  • The future expansion mention for biomedical research data sharing brings many questions. Will the QHINS be responsible for de-identification of the data? By what means will data be de-identified? Will the QHIN be responsible if the data can later be re-identified? By what mechanisms will approved research for access to particular data sets be verified?
  • What federal agencies will be accessing data that are not among public health agencies and for what purposes?

Stay Connected

Complete the form below and join our mailing list.