QHIN Application Form Feedback

Part I – Basic Applicant Information

Cybersecurity liability limits

Part II – Exchange Purposes and Capabilities

Service catalog or list of products and services (or use cases). Make this a more technical specifications section to show standards, protocols, capabilities and functions. List infrastructure components and vendors or application names. Direct vendor name and whether they are part of the national direct directory. Structured data exchange or pdf (view only) portal. API catalog – certification of those API’s and utilization. Patient access capabilities – and which protocols and services are available to consumers vs. providers.

Part III – Network Members, Governance, and References

Governance model – copy of policies and procedures, and their board of directors list and minutes from last 3 months. Privacy officer and CISO name and contact and credentials. HITRUST, EHNAC, DirectTrust Certifications – etc.

Part I – Basic Applicant Information

Part III – Network Members, Governance, and References

Part IV – QHIN Responsibilities

Part VI – QHIN Privacy and Security Requirements

Additional Feedback

Part I – Basic Applicant Information

Question 4: The eHealth Exchange suggests that the language in Question 4 (including the “Note” on the following page) be revised to clarify that the information being requested is for informational purposes only unless the Common Agreement and/or an SOP sets forth requirements for a specific type of coverage (e.g., the QHIN Cybersecurity Coverage SOP). We note that cyber risk / technology errors and omissions coverage is the only coverage type in this list that is currently required under the CA and/or an SOP. Question 9: 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.

Part II – Exchange Purposes and Capabilities

Question 12 and 13: eHealth Exchange suggests rewording to ask about the Exchange Purposes that are currently supported. The statement implies only currently used to initiate or respond. An Exchange may support these query types, and just not have any participants utilizing the POU.

Part III – Network Members, Governance, and References

Question 14: “See sample QHIN-Participant terms for additional information”: The eHealth Exchange respectfully requests that ONC and the RCE announce when this document is anticipated to be released. If there are plans to release sample QHIN-Participant terms, it would be helpful to know that before organizations that are interested in being early applicants for QHIN Designation, such as the eHealth Exchange, invest substantial resources on developing their own Participant-QHIN Agreements. Background References, 2nd sentence of first paragraph: The eHealth Exchange suggests noting the general means through which this will be provided. For example: Should applicants anticipate the release of an SOP or a guidance document, or will this be more tailored to the applicant and communicated during the virtual consultation call that is referenced in the QHIN Onboarding & Designation SOP at Section II, 1? If reference must be listed in this Application, the applicable criteria for serving as a reference will need to be released/provided prior to the acceptance of applications.

Part V – QHIN Operations and Organizational Structure

Question 24.iii.: The eHealth Exchange believes this is intended to refer to a “TEFCA Security Incident” versus an “Adverse Security Event.” Assuming the intended reference is to the definition of a TEFCA Security Incident (TSI), we wish to note the following: Part (ii) of the TSI definition requires the reporting of “[o]ther security events (e.g., ransomware attacks), as set forth in an SOP, that prevent the affected QHIN … from responding to requests for information as required under [the] Common Agreement or otherwise adversely affect [the QHIN’s] participation in QHIN-to-QHIN exchange,” (emphasis added). Per the TSI definition, there are no reporting obligations under part (ii) of that definition unless/until there is an SOP setting forth the “[o]ther security events” that would be reportable by a technology vendor pursuant to this application question. The SOP Release Schedule that ONC published on May 16, 2022, indicates that the SOP on Other Security Incidents and Reportable Events is anticipated for released “End of 2022.” Based on the overall timeline communicated by ONC and the RCE, this would likely put the first group of QHIN applicants in the early stages of Onboarding when this Other Security Incidents SOP is released. With that timeline in mind, we urge ONC and the RCE to either: (a) release a final SOP identifying the other security events that would meet part (ii) of the TSI definition prior to the QHIN application period opening and with reasonable lead time to negotiate any necessary amendments to existing vendor agreements; or (b) refrain from releasing any such SOP until the Governing Council and Caucuses are in place and such an SOP is subject to the full change management process described in Section 5.3 of the Common Agreement.

Additional Feedback and Considerations

For clarity, the eHealth Exchange suggests adding this or a similar header that identifies what follows as a separate section of the Application. (Without identify the attestation as a distinct Part, it visually appears as though the attestation only applies to Question 34 or, at most, to Part VI.)

Part I – Basic Applicant Information

Question 1: Points of Contact
It is unclear what type of financial contact applicants should provide (e.g., an executive contact or a point of contact for invoices). The RCE should clarify. Question 3: Financial Disclosures
The QHIN Application requires a significant amount of sensitive financial information to be disclosed to the RCE, purportedly to demonstrate that the applicant is in good financial health. However, the RCE does not specify the specific, objective metrics that will be used to evaluate an applicant’s financial health. Applicants that are private entities value the ability to maintain the confidentiality of their financial information, for a variety of strategic and competitive reasons. Requiring broad financial disclosures increases the potential for the confidential financial information of applicants to be inappropriately used or disclosed. The RCE should specify the metrics that will be used to evaluate an organization’s financial health. Applicants should then be permitted to submit the financial statements described in the draft application, or to supply more narrow documentation or attestations affirming their financial health in line with the metrics identified. Question 4: Insurance
Although the Common Agreement specifies liability limits, the draft application does not specify whether the policy limits of the insurance carried by the applicant should meet those limits or others for each policy or in total. The RCE could simplify the application by specifying the current minimum limits QHINs are expected to meet. Questions 5 and 6: Corporate Documentation and Board Members
Private entities applying for QHIN designation value the ability to maintain the confidentiality of their sensitive business information, including organizing documents (i.e., articles of incorporation and bylaws) and the membership of their board of directors. Further, it is unclear what specific, objective criteria the RCE intends to use to evaluate the fitness of an applicant to become a QHIN based on that information. Requiring extensive disclosure of sensitive business information as part of the application process for QHINs increases the opportunity for Confidential Information to be mishandled or inappropriately redisclosed. The RCE should instead specify the criteria that it will use to evaluate the suitability of an entity to become a QHIN based on its corporate/governance structure and allow applicants to either supply the suggested documentation or attest that they meet the criteria. Questions 7, 8, and 9: Ownership Interests
The draft application should distinguish between ownership and control. Some applicants may have employee stock programs that offer the opportunity to purchase shares of the entity’s stock, but that do not confer voting rights or other control to stock owners. Requiring prospective QHINs to disclose who has a controlling interest in the entity of greater than 5% is appropriate, but ownership interests without meaningful control should not be required to be disclosed.

Part II – Exchange Purposes and Capabilities

Questions 11, 12, and 15: Permit Responses Based on Experience with Parallel Networks
Some entities that apply for QHIN designation will establish a parallel TEFCA network to their existing network(s), enabling their participants to choose to join the TEFCA network at their own pace. However, because that entity’s new “TEFCA QHIN Network” will have just been established, the applicant will have recently established the governance structure and procedures for the network and might not have demonstrated exchange at scale on the new network, despite having extensive experience with governance and exchange at scale with their existing networks. For example, the prospective QHIN’s existing network may facilitate extensive exchange for treatment, but might not have onboarded its customers to its new TEFCA network yet. Similarly, the QHIN might offer other parallel networks for Payment, Operations, Public Health, etc. The application should allow prospective QHINs to submit exhibits from their existing parallel networks in response to questions 11, 12, and 15. They could then also submit documentation/materials specific to the governance and operation of the new network in response to questions 10, 13, 14, 16, and 17.

Part III – Network Members, Governance, and References

Questions 11, 12, and 15: Permit Responses Based on Experience with Parallel Networks
Some entities that apply for QHIN designation will establish a parallel TEFCA network to their existing network(s), enabling their participants to choose to join the TEFCA network at their own pace. However, because that entity’s new “TEFCA QHIN Network” will have just been established, the applicant will have recently established the governance structure and procedures for the network and might not have demonstrated exchange at scale on the new network, despite having extensive experience with governance and exchange at scale with their existing networks. For example, the prospective QHIN’s existing network may facilitate extensive exchange for treatment, but might not have onboarded its customers to its new TEFCA network yet. Similarly, the QHIN might offer other parallel networks for Payment, Operations, Public Health, etc. The application should allow prospective QHINs to submit exhibits from their existing parallel networks in response to questions 11, 12, and 15. They could then also submit documentation/materials specific to the governance and operation of the new network in response to questions 10, 13, 14, 16, and 17.

Part IV – QHIN Responsibilities

Questions 11, 12, and 15: Permit Responses Based on Experience with Parallel Networks
Some entities that apply for QHIN designation will establish a parallel TEFCA network to their existing network(s), enabling their participants to choose to join the TEFCA network at their own pace. However, because that entity’s new “TEFCA QHIN Network” will have just been established, the applicant will have recently established the governance structure and procedures for the network and might not have demonstrated exchange at scale on the new network, despite having extensive experience with governance and exchange at scale with their existing networks. For example, the prospective QHIN’s existing network may facilitate extensive exchange for treatment, but might not have onboarded its customers to its new TEFCA network yet. Similarly, the QHIN might offer other parallel networks for Payment, Operations, Public Health, etc. The application should allow prospective QHINs to submit exhibits from their existing parallel networks in response to questions 11, 12, and 15. They could then also submit documentation/materials specific to the governance and operation of the new network in response to questions 10, 13, 14, 16, and 17.

Part VI – QHIN Privacy and Security Requirements

Question 27: HITRUST Certification
Achieving HITRUST Certification is a significant undertaking. Applicants should be permitted to achieve Provisional QHIN status if they are otherwise capable of meeting the requirements of TEFCA and have a clear plan and timeline to achieve HITRUST Certification. This will allow a representative set of future QHINs to participate in the initial wave of onboarding and governance, contributing to TEFCA’s long term success.

Additional Feedback and Considerations

Confidentiality
Many of the disclosures and information that the Draft QHIN Application would require is sensitive business information, intellectual property, or other Confidential Information. Although the Draft QHIN Application states that the information contained in the application will be treated as Confidential Information as defined in the Common Agreement, the RCE does not provide further information about how it will handle such information, including who it could be disclosed to, for what purposes, and how it will be protected to maintain its confidentiality. It also does not provide information about the applicability of Freedom of Information Act to materials disclosed as part of the application process. The RCE should provide additional assurances that any confidential or otherwise non-public information provided as part of the QHIN application process will be securely handled, accessed only by staff of The Sequoia Project who need the information as part of their responsibilities to make a designation determination, and not further disclosed without the consent of the applicant.

Part II – Exchange Purposes and Capabilities

Recommendation: In question 12, add a clarifying clause to the 6th row to ensure the applicant addresses identity verification: “Individual access services, including the identity verification methods”.

Rationale: Understanding how the applicant verifies identities as a part of their individual access management is critical to knowing how the QHIN applicant prevents fraud from entering and persisting in their network. For example, if an applicant primarily uses Knowledge Based Authentication (KBA) methods, it can be a sign of weak verification controls. KBA was formally deprecated by NIST in 2017 because it has not proven to be a reliable or accessible security control in preventing fraud. NIST took this action because of the number of at-scale data breaches and the fact that answers to these questions are often basic and/or easily found on public social media accounts. GAO reported similar findings in 2019, expressing concern that federal agencies are still relying on KBA methods using data from credit agencies despite the fact that NIST no longer endorses it as a verification method. By contrast, a QHIN applicant that uses modern methods to verify individuals and secure the accounts by which they access information on the network, including NIST IAL2/AAL2, should be looked upon favorably as one with strong fraud controls that will not introduce undue risk to the QHIN.

Part V – QHIN Operations and Organizational Structure

Recommendation: After question 24, include a question that clarifies the level of interoperability the applicant embraces. For example, “What practices, capabilities, and protocols does the QHIN use that will promote secure interoperability within the QHIN and other organizations with which the applicant interacts?”

Rationale: This question would give applicants the opportunity to discuss what practices, capabilities, and protocols they use to ensure interoperability with other members of the QHIN. As an example, if an applicant employs identity and access management, they would ideally demonstrate doing so in a way that promotes interoperability:
Use of open protocols such as Open Identity Connect (OIDC), OAuth 2.0, or Security Assertion Markup Language (SAML) 2.0.
Adoption of government guidelines, as specified in NIST 800-63-3

As further examples of how commitment to interoperability has helped other sectors, consider other sectors for inspiration. In the payments world, Visa pioneered standards and operating procedures that enabled any organization that accepts payments to trust an individual’s credential. ATM networks agreed upon standards to let other banks communicate with their nodes.

Applying NIST credential standards to the QHIN Application would be a logical next step in modernizing the healthcare industry. Applied consistently, standards also enable QHIN’s to trust identities that originated outside of their organization. As tens of millions of NIST credentials already exist in the marketplace today, many healthcare users and providers would arrive with a credential already in-hand. Any NIST credential minted by a CSP that is independently certified against NIST standards can be taken to any organization that accepts NIST credentials. For example, if a doctor verified their identity at a commonly-recognized NIST assurance level with ID.me in order to prescribe medicine, that individual would be able to engage at least eleven federal agencies, 30 states, and hundreds of commercial entities without having to create a new credential.

Part VI – QHIN Privacy and Security Requirements

Recommendation 1: Add four additional questions to understand the fraud controls that the applicant has in place:

Please describe how your organization verifies the identity of individuals seeking access to (1) the network and (2) information within the network, including for both employees and any end-user consumer with whom they interact.

Please describe how your organization selected its identity verification requirements. If you did not utilize the risk framework of the NIST 800-63 Digital Identity Guidelines, please explain how you determined the sufficiency of your identity verification practices.

Please provide evidence of what practices and procedures your organization takes to identify, prevent, and stop fraud within the network.

Please provide evidence of how your organization complies with the QHIN Technical Framework (QTF), Requirements for Functions and Technology to Support Exchange section.

Rationale: These questions would give a QHIN the opportunity to articulate what they are doing to stay ahead of the threat of fraud within their network. Beyond identity theft and third party fraud, it can give them an opportunity to outline what they do to stop first party fraud, social engineering, and other types of fraud specific to healthcare networks (e.g. claims fraud).

From an identity perspective, NIST standards, particularly Identity Assurance Level 2 (IAL2), when paired with Authentication Assurance Level (AAL) 2 and Presentation Attack Detection (PAD), are effective at stopping fraud. In our experience supporting 30 states and 11 federal agencies at a mix of LOA3, IAL2, and IAL2+Liveness levels, we estimate that attempted fraud rates are 10 – 29% higher in state unemployment systems not using IAL2+Liveness. This shows fraudsters are paying attention and are more likely to attack organizations with weaker defenses.

Furthermore, adherence to these standards can be reinforced and audited by independent accreditation bodies like the Kantara Initiative. Kantara is an industry non-profit organization that certifies vendors against NIST SP 800-63 standards that exists today to provide certifications against NIST standards as a means to ensure quality and improve interoperability.

Some organizations continue to apply outdated identity verification procedures that the nation’s leading cybersecurity experts at NIST formally deprecated in 2017, when publishing the NIST 800-63-3 Federal Digital Identity Guidelines. QHIN’s have the opportunity to follow a risk-based framework that evolves to keep up with the threats imposed by increasingly sophisticated cyber-criminals. Further benefits of adding these questions to the application include:

Give a QHIN applicant the opportunity to demonstrate what measures they are taking to increase security while also improving equitable access in a cost-effective way
ID.me’s experience proves that NIST 800-63-3 compliant identity verification would not be unduly burdensome on the regulated community within the healthcare industry. In a recent article, the Washington Post noted that “ID.me nearly doubled” the pass rate at IRS, including “low-income earners and minorities” while simultaneously increasing security policies to IAL2.

Give a QHIN applicant the opportunity to demonstrate the use of NIST controls that are required in certain parts of the healthcare industry today.
For example, providers of software and services that enable providers to perform Electronic Prescription of Controlled Substances (EPCS) must leverage NIST controls and identity verification in order to remain DEA compliant In the latest version of the DEA Interim Final Rule on EPCS: “Since the IFR was published, changes in technology have led to the creation of new, updated NIST guidelines, NIST SP 800-63-3, ‘Digital Identity Guidelines.’ Under NIST SP 800-63-3, the relevant identity proofing assurance level is Identity Assurance Level 2 (IAL2). Identity Assurance Level 2 of NIST SP 800-63-3, like Assurance Level 3 of NIST SP 800-63-1, allows either in-person or remote identity proofing.”

Give the QHIN the opportunity to show that they are versed in and incorporate standards that are established and overseen by the country’s leading cybersecurity experts.
Applicants that demonstrate understanding and incorporation of elements of NIST 800-63-3 Digital Identity, NIST 800-53 Cyber Security, and NIST 800-37 Privacy guidelines show how a QHIN is leveraging the expertise of the nation’s leading cybersecurity specialists and quickly update their security protocols.

Furthermore, it can give the applicant an opportunity to demonstrate strong fraud controls by articulating how they chose best-in-breed vendors from among the existing competitive marketplace. Additionally, the FedRAMP program housed under the General Services Administration issues authorizations for vendors which are listed in the FedRAMP Marketplace. A QHIN that works with organizations with these and other trust marks can make a stronger case for safe interaction with government agencies.

Additional Feedback and Considerations

ID.me has as well submitted feedback via e-mail. We recommend the RCE review that submission, as the formatting is easier to read and includes footnotes.

Part I – Basic Applicant Information

Question 3: We agree that the applicants must have the requisite financial and personnel resources to support their obligations as a QHIN and should demonstrate their organization’s financial health to assure continuity of QHIN operations. We recommend more details on the audited financial statements. More specifically, could the RCE advise if the requirement for the prior two
complete fiscal years be fulfilled by the following:
● Audited financial statements for the recent fiscal year 2021 (Please note that the opening balances for 2021 are based upon the closing balances of the prior period 2020, reflect the effects of transactions and events of the prior periods,
and accounting policies applied in 2020.)
● Opening balances that also include matters requiring the disclosure that existed at the
beginning of the period, such as contingencies and commitments.
● Statement for a third-party accounting firm certifying that the QHIN Applicants financial
statements were prepared in accordance with the Generally Accepted Accounting Principles (GAAP)

Part II – Exchange Purposes and Capabilities

Q12: 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 and support the goal of expanding health data exchange to use cases beyond Treatment. However, question 12’s definition of “responded to” is ambiguous. Since the Implementation Guidelines have yet to be released, the ambiguity will make it more challenging for prospective QHINs to clearly identify their “responded to” transaction volumes which may affect their ability to achieve designation as a QHIN. Please clarify how to measure “responded to” transactions. Specifically, should applicants count all ITI transactions (55,38,39) and should applicants count those
transactions to which they responded successfully even if no patient or document was found?

Part IV – QHIN Responsibilities

Q19: We support the governance approach described in the Onboarding and Designation SOP in demonstrating organizational infrastructure and legal authority to comply with the obligations of the Common Agreement and a functioning system to govern its Health Information Network.
Additionally, establishing mechanisms and operationalizing a formalized Cooperation and Dispute Resolution policy and process documents are key to ensuring each QHIN is a good steward and has stable relationships with their network participants. We are proposing that a smaller time limit meets the intention of the question and that demonstrating a functioning system to govern its Health Information Network can be accomplished from a 12-month look back versus a 24-month lookback

Part IV – QHIN Responsibilities

Q19: We support the governance approach described in the Onboarding and Designation SOP in demonstrating organizational infrastructure and legal authority to comply with the obligations of the Common Agreement and a functioning system to govern its Health Information Network.
Additionally, establishing mechanisms and operationalizing a formalized Cooperation and Dispute Resolution policy and process documents are key to ensuring each QHIN is a good steward and has stable relationships with their network participants. We are proposing that a smaller time limit meets the intention of the question and that demonstrating a functioning system to govern its Health Information Network can be accomplished from a 12-month look back versus a 24-month lookback

Part VI – QHIN Privacy and Security Requirements

Q28: Health Gorilla endorses the idea that QHINs would be expected to meet and maintain third-party certification to an industry-recognized cybersecurity framework and undergo security
assessments. However, with the limited time remaining for applicants until the end of 2022, HG proposes to limit the certification and audit requirements for 2022 and 2023 calendar years to HITRUST R2 Certification only. Based on our experience, any organization that tries to achieve HITRUST certification needs to dedicate significant resources and time (by our estimate not less than 9 months depending on the size of organization, system complexity, security and privacy program maturity). Additionally, Conducting third-party technical audits the same year the HITRUST validated assessments are performed, will result in effort duplication without any tangible benefits as both HITRUST validated assessments and third-party technical audits will be focusing on the same activities/controls (i.e., NIST CSF, NIST 800-171, NIST 800-53). As such, HG proposes to conduct third-party technical audits only every other year, not to coincide with HITRUST validated assessments. I.e., if the organization went through a validated HITRUST assessment and achieved certification in 2023, a third-party technical audit will be conducted in 2024. The next HITRUST validated assessment will take place in 2025, followed by a third-party technical audit in 2026. Heath Gorilla’s recommendation is to have an option to use third-party automated compliance assessment tools instead of “in-person” technical audits, assuming that all
the necessary controls are covered and appropriate reports are generated

Part II – Exchange Purposes and Capabilities

Q12: the instruction states “Please check all of the Exchange Purposes that are currently used to initiate transactions by at least the participants within your network.” The focus of the question should be activity across the applicant’s network, not if a participant happens to initiate a transaction but uses another approach to complete the transaction. For clarity, please revise the text to “Please check all of the Exchange Purposes that are may be initiated and transacted by providers using your network. Please provide the additional information requested regarding each Exchange Purpose.”

Q12 second part: clarify that the response transaction utilizes network services/connections for routing/delivery.

Additional Feedback

1. Are there sufficient options available to support a government entity applying as a QHIN, if that is anticipated (e.g., organizing documents, insurance, etc.).

2. Is there value in collecting information about the numbers of entities of the different possible types of organizations? Or will the automated provider directory service be sufficient (and will non-participants be able to see the listings of the participant directory)?