QHIN Onboarding and Designation SOP Feedback

Section I: Eligibility Requirements

The RCE should explain how it will grant QHINs access and to which market(s), as well as how the RCE will be prioritizing QHINs based on geographic availability. The SOP does not explain whether a QHIN will need to set a geographic area or disclose other constraints on participation. We believe QHINs should make publicly available via a disclosure process or website posting who is eligible as a Participant, their geographical reach if not national, and what services they offer. We also urge the RCE to make available a directory of QHINs. By listing the QHINs and their Participants it will be well-known who has access to what information and where they are operating.

Section III: Pre-Production Testing Process

The SOP should clarify whether a public utility will be used for testing processes so that involved entities can avail themselves of the existing infrastructure.

Section IV: Designation & Post-Production Testing

The SOP should clarify whether a public utility will be used for testing processes so that involved entities can avail themselves of the existing infrastructure.

Additional Feedback and Considerations

For the QHIN construct to be most effective, QHINs should be national. However, as noted earlier, there has been mention of HIEs being QHIN. This raises the potential for QHIN coverage that is not national. Our members have had a variety of experiences to date with HIEs. In order for TEFCA to function effectively, the RCE should explain its vision for what will happen if a QHIN becomes unsuccessful. For example, some HIEs ceased operations whereas others flourished. Entities that want to become involved with TEFCA will need to understand the RCE’s plan if a specific QHIN is not successful (e.g., a State-based QHIN fails to flourish) or if the RCE does not garner QHIN participation for an area (e.g., a rural area, a State). At this stage, we can envision potential “QHIN Deserts,” which is a term we use to describe a geographic area that is not covered by a QHIN. Entities can benefit from understanding how the RCE will proceed if a QHIN Desert occurs. The SOP provides detail in the “Eligibility” section for how a QHIN can begin the application and operational processes but fails to address situations where a QHIN voluntarily or involuntarily ceases operations or is suspended. For example, if a QHIN retires, moves, or is acquired by or merges with another entity, what will happen to the Participants and Subparticipants contracted with the QHIN? What will happen to the data in these situations? Will consumers receive notice of such changes? What process, if any, will the RCE initiate to ensure a smooth transition for consumers, Participants, and Subparticipants? The SOP could benefit from clarifying these issues which are fundamental for managing data exchange and governing contracts. The SOP should align with the suspension and termination parameters as stated in the Common Agreement but should address the practical outcomes and expected processes in more detail in the SOP. We also ask that the RCE clarify how data will be secured and contingencies made to support continued exchanges if a QHIN ceases operations. Our members noted concerns that data could be put at risk if a QHIN ceases operations suddenly or is sold to another party. Similarly, if a QHIN ceases operations without notice, vital exchanges could be delayed. Such delays could risk patient care or healthcare operations that are essential to support patient care. It is unclear if a health plan or insurer is currently participating in multiple HIEs, how does this transition if those HIEs apply to become QHIN’s? Will each local QHIN set the exchange rates for exchanging QHIN to QHIN? How will each Participant understand this cost information? Answering these questions will be important for TEFCA to move forward from our perspective. We thank you for the opportunity to comment in response to these important issues.

Section I: Eligibility Requirements

General Summary: Common Agreement Criterion: “Signatory can exchange Required Information, as defined in this Common Agreement. The specific, required means to demonstrate this are set forth in an SOP.”

Comments and Feedback: This statement is unclear on the required means for exchanging data. We recognize that FHIR implementation is a future timeline item for TEFCA, and this may create inconsistencies with FHIR-ready entities that wish to participate if some QHINs are not using FHIR and others are. That said, we propose to take advantage of the opportunity to accelerate FHIR adoption through TEFCA in alignment with the Roadmap for TEFCA Exchange by encouraging FHIR-ready entities to participate as a QHIN without concern for supporting older technology standards.

Likewise, the current QTF is predicated on the use of existing IHE Framework and related technology and doesn’t allow for innovation and application of new and/or breakthrough technologies for connectivity, and secure, trusted information exchange. Therefore, such technologies and innovative frameworks [beyond “traditional” IHE] should also be given consideration in an SOP.

The SOP should be clear on how participants and QHINs should communicate.

Under stage 1 for TEFCA, additional information and a potential infographic is needed to show the mechanisms of exchange between QHINs and participants. While this new network may be valuable to providers not yet connected to larger EHR and exchange systems, there are providers, health plans, and other stakeholder with existing connections. The SOP and related documents should clarify the advantages of TEFCA participation to these entities, as well, which will help foster involvement of entities across different levels of exchange.

Section II: QHIN Application Process

General Summary: Common Agreement Criterion: “Signatory must demonstrate that it has the ability to perform all of the required functions of a QHIN in the manner required by this Common Agreement, the SOPs, the QTF, and all other applicable guidance from the RCE…”

Comments and Feedback: Additionally, it is known that that not all versions of FHIR are backwards compatible. Blockchain technologies can address this gap, and will serve not only as an intermediary, but also as a long-term option to efficiently synchronize between networks on differing versions and updates. We note that certain security requirements in the previously finalized QTF will require blockchain developers to implement procedures not necessary for blockchain. We suggest enabling opportunities to leverage blockchain technology so networks can more succinctly coordinate FHIR and API data exchange and be able to support innovative methods that can advance the goals of interoperability.

Blockchain could become an enabling technology mechanism of choice for healthcare data exchange and the catalyst for making true interoperability in healthcare possible. It can address the major root causes of problems that the Federal government has prioritized. Specifically, as defined by the ONC in a Shared Nationwide Interoperability Roadmap, the critical components needed for nationwide interoperability include (i) Ubiquitous, Secure Network Infrastructure, (ii) Verifiable Identity and Authentication of All Participants, and (iii) Consistent Representation of Authorization to Access Electronic Health Information.

General Summary: The Provisional Status is a 12-month period in which a QHIN can demonstrate the ability to perform all the required functions of a QHIN in the manner required by the Common Agreement, QTF, and applicable SOPs.

Comments and Feedback: Allow the RCE to shorten the time of the 12-month Provisional Status period if the required QHIN criteria are met earlier. This would incentivize Signatories to develop/adopt required capabilities earlier and, at the same time, significantly reduce administrative burden on both Signatory and RCE from additional monitoring and reporting.
General Summary: Criterion: “Signatory must have the requisite financial and personnel resources to support its obligations as a QHIN. This includes but is not limited to the following…”

Comments and Feedback: We support this criterion. Financial sustainability is key to the long-term success of QHINs and TEFCA-related data exchange.

Section II: QHIN Application Process

General Summary: Beginning the process RCE review of applications for completeness

Comments and Feedback: The QHIN application process must be transparent and open. Entities looking to join QHINs will want to know what potential QHINs are going through the process so they can plan accordingly. We advise clear transparency on applicants and where they are in the process throughout the RCE’s review and decisions.

General Summary: RCE review of complete applications
– 1. Re-application: If an application is denied, the applicant can reapply six (6) calendar months after the date shown on the notice of denial with a new application that includes all required information and that specifically addresses the deficiencies noted as the basis for denial of the applicant’s previous application.
– Appeal of denial: An applicant may appeal the denial of its application only for specific reasons (see page 11)

Comments and Feedback: The timeline delay for re-application may deter innovation and new entries from participating as QHINs. It may also inhibit participants from joining a QHIN, or severely limit options. We recommend a shorter timeframe, as determined by stakeholder feedback.

General Summary: Assertion of Compliance: By applying to be Designated as a QHIN and beginning the technical testing process outlined in the next section, the applicant asserts that the system or systems used are compliant with the technical specifications outlined in the QTF

Comments and Feedback: Avoid restricting current QTF to the use of existing IHE Framework and related technologies. Instead, allow QHINs to accommodate the next generation of technologies (such as Blockchain) and Frameworks (such as Zero Trust for security) to foster innovation beyond “traditional” HIE technology.

Additional Feedback and Considerations

We appreciate the opportunity to share our feedback on the Draft QHIN Onboarding & Designation SOP and hope that our comments are helpful for shaping ONC’s vision of interoperability. Our comments also reflect a strategy to accelerate ONC’s FHIR Roadmap and to realize the full potential of blockchain in the healthcare industry.

Read Email Submission Here

Section IV: Designation & Post-Production Testing

4bi. Please clarify the minimum level of governance that is required, if any, for technical framework? 4cdii. Please clarify “executive level” responsibility?

Section I: Eligibility Requirements

For Section 1.e.:
The eHealth Exchange wishes to note, for consideration, that the RCE is collecting Stakeholder feedback on the Onboarding & Designation SOP and this Application until June 15, 2022, and the SOP Release Schedule that was published on May 16, 2022, indicates an additional release of these documents in August 2022. The Release Schedule also indicates that the Means to Demonstrate U.S. Ownership and Control of a QHIN SOP will be released in August 2022, and the schedule does not indicate that this U.S. Ownership/Control SOP will be released in final form. Finally, the ONC blog post in which the Release Schedule was shared states, “The SOP schedule is designed to make a set of SOPs available by August 2022. These SOPs will inform the application process for QHINs, which is set to begin in late summer/early fall. This is aligned with our goal of QHINs beginning to onboard as early as fall of this year.” In light of the above, we wish to note that making a determination as to what constitutes “control” by “any non-U.S. person(s)” could be a complex and fact-specific analysis. We request that ONC and the RCE be mindful of these complexities with respect to the timing of the release of the final U.S. Ownership/Control SOP relative to when the RCE begins accepting applications that must include the attestation in Question 9. Footnote 2 on page 5:
The eHealth Exchange suggests revising the first sentence of Footnote 2 as follows:
“[F]unctionally comparable exchange method” means executing all of the functions specified in Table 1 of the QTF using standards (including proprietary standards) that are not identified in Table 1. If the standard for the specified function is identified in Table 1, then it would not be “functionally comparable” to the query functionality outlined in the QTF; rather, executing the functions specified in Table 1 using the standards identified in Table 1 is “query functionality as outlined in the QTF.” Therefore, the reference to standards that “may … be identified in Table 1” seems inaccurate.

Section II: QHIN Application Process

Section 3.2, Appeal of denial, last sentence:
The eHealth Exchange suggests rewording this statement, as it seems in conflict with the statement above that the denial of an application on one basis does not mean that the application is free from other disqualifiers that were not yet identified when the RCE ceased review of the application. Resuming review of the application would not be “proceed[ing] to the next step in the Onboarding process”; rather, it would be picking back up at the same step. Section 3.4. 2nd paragraph:
This statement seems to be in conflict with several statements in the Pre-Production Testing and QHIN Onboarding Process outlined in Section III. We recommend striking this sentence, as further explained in our comment to Section III.1 on the following page.

Section III: Pre-Production Testing Process

Number 1, QHIN Onboarding:
In the final sentence of Section II.4 (above), it states that an applicant MUST register for the testing platform prior to submitting an application and SHOULD successfully pass all testing via that platform prior to submitting an application. If Onboarding begins once the RCE has approved the prospective QHIN’s application, how does the testing platform fit within the Onboarding process? If an organization heeds the recommendation above and successfully passes testing via the testing platform prior to applying, will that organization be required to repeat the same testing during the “official” Onboarding process? The eHealth Exchange suggests striking the final sentence of Section II.4, as noted above, and revising this Section III.1 as follows:
Onboarding begins when a prospective QHIN has signed the CA, received approval of its QHIN Application, and registered for the testing platform identified in Section III.5 of this SOP. Number 4. 1st sentence, Pre-production Testing Timeline: In the final sentence of Section II.4 (above), it states that an applicant MUST register for the testing platform prior to submitting an application and SHOULD successfully pass all testing via that platform prior to submitting an application. If Onboarding begins once the RCE has approved the prospective QHIN’s application, how does the testing platform fit within the Onboarding process? If an organization heeds the recommendation above and successfully passes testing via the testing platform prior to applying, will that organization be required to repeat the same testing during the “official” Onboarding process? The eHealth Exchange suggests striking the final sentence of Section II.4, as noted above, and revising this Section III.1 as follows:
Onboarding begins when a prospective QHIN has signed the CA, received approval of its QHIN Application, and registered for the testing platform identified in Section III.5 of this SOP. Number 5. first sentence of paragraph 1 and first sentence of paragraph 2: The QHIN Testing Process documents are not addressed in the Release Schedule that was published on May 16, 2022. If applicants are required to register for the testing platform and encouraged to complete this testing prior to applying, these documents (and instructions for registering for the testing platform) would need to be made available a reasonable amount of time in advance of the application period opening. Number 5. last sentence of paragraph 2: In the final sentence of Section II.4 (above), it states that an applicant MUST register for the testing platform prior to submitting an application and SHOULD successfully pass all testing via that platform prior to submitting an application. If Onboarding begins once the RCE has approved the prospective QHIN’s application, how does the testing platform fit within the Onboarding process? If an organization heeds the recommendation above and successfully passes testing via the testing platform prior to applying, will that organization be required to repeat the same testing during the “official” Onboarding process? The eHealth Exchange suggests striking the final sentence of Section II.4, as noted above, and revising this Section III.1 as follows:
Onboarding begins when a prospective QHIN has signed the CA, received approval of its QHIN Application, and registered for the testing platform identified in Section III.5 of this SOP.

Section III: Pre-Production Testing Process

Testing and Onboarding Process
QHINs that are onboarding participants from their existing networks into a parallel TEFCA network might not be able to complete testing in the manner/sequence described in the onboarding SOP. Specifically, if Participants have not yet onboarded to the QHIN’s parallel TEFCA network, they may not be able to complete the full set of non-production or production tests. This could be the case for the initial group of QHINs, since prospective Participants may be hesitant to engage in testing for a network that is not yet live. Additionally, participants may be hesitant to complete tests in production environments with mock patient data. QHINs that are able to complete a sufficient number of connectivity and exchange transaction tests with other QHINs before they onboard Participants should be permitted to join TEFCA as a provisional QHIN. Post-production reporting of transaction volumes can be used to verify that a QHIN’s participants are live and engaging in exchange as expected. The SOP should also be revised to not require participants to store mock patient data in production environments.

Section IV: Designation & Post-Production Testing

Testing and Onboarding Process
QHINs that are onboarding participants from their existing networks into a parallel TEFCA network might not be able to complete testing in the manner/sequence described in the onboarding SOP. Specifically, if Participants have not yet onboarded to the QHIN’s parallel TEFCA network, they may not be able to complete the full set of non-production or production tests. This could be the case for the initial group of QHINs, since prospective Participants may be hesitant to engage in testing for a network that is not yet live. Additionally, participants may be hesitant to complete tests in production environments with mock patient data. QHINs that are able to complete a sufficient number of connectivity and exchange transaction tests with other QHINs before they onboard Participants should be permitted to join TEFCA as a provisional QHIN. Post-production reporting of transaction volumes can be used to verify that a QHIN’s participants are live and engaging in exchange as expected. The SOP should also be revised to not require participants to store mock patient data in production environments.

Additional Feedback and Considerations

Appeal of Denial
For the first cohort of applicants, the transitional council and QHIN council will not have been established. The SOP should clarify how the appeal process will work for applicants denied before those councils are established.

Read Email Submission Here

Section II: QHIN Application Process

Procedure, Section II, Paragraph 1, Page 9:
Recommend moving the contents of Paragraph 4 Assertion of Compliance (Page 12) which indicates the applicant must successfully pass testing via the testing platform prior to submitting their application into Paragraph 1 Beginning the Application Process to consolidate the application requirements. Procedure, Section II, Paragraph 3, Pages 10-12:
This section provides time periods in which the RCE will operate to review an application. This section also provides the ability for the RCE to extend the time periods but without any indication of when an extension should be granted to themselves and any limitations on the length of the extension. Recommend the SOP provide clarity as to the expected reasons for, and length of, extensions to increase applicants’ understanding of the application process.

Additional Feedback and Considerations

Communication of Onboarding & Designation Status by Applicant, Page 2
The applicant must agree that it will only communicate the status of the application in accordance with RCE’s written protocols. The QHIN application requires the applicant to provide three background references and that the applicant must ensure the references are aware that the RCE will be contacting them. Are there other written protocols concerning communicating information about the application? Where are those located? General Comment:
The SOP and the application process will provide the RCE with a wealth of information concerning the applicant’s current status and capabilities. Recommend the applicant be required to provide a high level plan of action to identify the changes in organizational and governance structure, technical components, capacity or exchange capabilities, etc. necessary to become a QHIN. This additional requirement would provide the RCE critical insight into the applicant’s ability to successfully transition to a QHIN.