Draft TEFCA Facilitated FHIR Implementation Guide

The RCE sought feedback on the draft TEFCA Facilitated FHIR Implementation Guide released October 7, 2022. 

Responses are published below. 

Certificates

The IG sets out an outline of the policy, technical, and process requirements for Qualified Health Information Networks (QHINs), Participants, and Subparticipants to exchange TEFCA Information (TI) using the HL7® FHIR® standard,” under the Common Agreement (CA) and associated standard operating procedures (SOPs). QHINs, Participants, and Subparticipants will be required to exchange TI and can directly connect to query for and provide TI in the FHIR format. The guide is intended to support business-to-business (B2B) facing individual access workflows, and relies on the HL7 Security for Scalable Registration, Authentication, and Authorization FHIR IG v1.0 (hereafter referred to as the HL7 Security IG). The IG contains a new term, “Operator,” and describes “[a]ny Actor that controls a client or server used to exchange TI in FHIR format. The Operator is identified in the x.509 certificate associated with the client or server.”

Overall, in order for TEFCA to be successful, all involved need to find value for their efforts. We request greater transparency related to the TEFCA implementation status and processes (e.g., number of QHIN Applications received to date, timelines for implementation and status of objectives and goals, etc.). While TEFCA is voluntary at this stage, entities that are planning to be part of the process need more information to allocate and assess financial and administrative resources. Additionally, it would be beneficial to have the TEFCA use cases, data standards, and SOPs aligned with existing regulatory mandates, as opposed to having a “separate playbook” for TEFCA. This can enable efficiencies and alignment in implementation and ensure under-resourced providers do not have to build changing standards over time in order to connect with TEFCA and provide individuals with opportunities for the resources.

For the IG specifically, we recommend that its development take place via an open, transparent, voluntary, and consensus-based process and follow all applicable rules and processes for voluntary consensus standards through a national standards development organization (i.e., HL7) consistent with requirements of the Administrative Procedures Act (APA) and other legal processes, including sufficient timing for public posting of comments and comment input. We also request that the RCE work with the FAST Steering Committee, including standards specific to national health directories.

After reading the IG, we are concerned with FHIR enablement and timeframes. The previously released TEFCA FHIR Roadmap does not appear to align with the interoperability initiatives and implementation timelines in place. We request that either the: (1) Roadmap be updated and released; or (2) the IG be revised to correspond with the existing Roadmap.

There are also concerns about the ability of all entities to use FHIR and the potential for non-FHIR and FHIR-based systems to be running concurrently. Such processes create complexities and increased costs, which may exacerbate inequities in the healthcare system. Therefore, we would prefer a FHIR-based approach at the outset to be used by entities in the TEFCA contexts.

We are also concerned that the IG does not address the ability of responding actors to limit access to specific FHIR resources based on the purpose of use indicated by the query initiator. This is very important to understand to ensure that patients have full control over what information is shared and for what purpose(s), and as important for HIPAA minimum necessary compliance. We recommend that the IG consider including a mechanism for the responder to negotiate with the initiator if the FHIR server lacks the functionality necessary or the requester potentially lacks the permission to support the request.

We believe that more clarification is needed for the TEFCA terms used and that references should be incorporated where necessary. For example, QHIN Participants are obligated to respond to requests from other QHIN Participants as required under HIPAA to support clinical and business operations. The IG is not clear on such relationships and exchanges. We believe the IG should be improved by providing clear definitions of abbreviations and terms and more explanation in this area.

In addition, the term “Operator” is based on the certificate associated with the client or server. We would like clarification as to how QHIN participants will validate the Actors that the Operators represent to ensure that the certification process used in vetting the Operator includes the appropriate steps and process. Participating entities will need to investigate and understand the certification process for end points and will need to verify the directory and certificate storage process. We remain concerned about operational complications and inefficiencies associated with managing the large volume of certificates needed to operationalize Facilitated FHIR. Instead, we recommend a brokered approach through QHINs.

With respect to security, the entities and Actors need to ensure that endpoints and third parties that access data have been verified, validated and certified to ensure that data and data exchanges are secure and the endpoints are authorized and maintained by a participating entity. After reviewing the IG, these components appear to be lacking and should be addressed.

The level of technical specifications included in this IG are extremely complex and detailed, with significant FHIR resources inter-dependencies. We recommend providing at least a 60-day review period to ensure reviewers have adequate time.

We also suggest adding visual representations to help readers and implementers understand the described user flows.

Role Requirements 

The IG sets out that the “FHIR Query Initiator” is “an Actor with the declared role of a FHIR Query. The Initiator initiates queries to retrieve information held by an Actor in the Responding Actor role. An Actor with the declared role of a FHIR Query Initiator shall support the technical requirements throughout this Guide that are specifically described as applying to the FHIR Query Initiator role. The FHIR Query Initiator operates one or more client applications.”

A Responding Actor is one “with the declared role of . . . [providing] information in response to queries by an Actor in the FHIR Query Initiator role. An Actor with the declared role of a Responding Actor shall support the technical requirements throughout this Guide that are specifically described as applying to the Responding Actor role. The Responding Actor is associated with one or more FHIR servers. Each FHIR server is associated with an Authorization Server.”

We are unsure whether these are intended as “stand alone” categories or whether existing entities can fit into either or both definitions based on their function and role. The IG could benefit from explaining these roles.

General Requirements

The Provenance section is unclear as to when the IG applies provenance to data the entity generates or imports from other sources and at what level (e.g. document, sub-document, data element). Maintaining metadata can strain operating system resources and negatively impact functionality. We recommend that this section clarify that provenance should be assigned at the detailed element level if data will be disaggregated subsequently – otherwise the provenance will be lost. We also recommend the provenance be limited to first-level creator of data. 
 
For patient matching, the IG explains that “Actors MUST support the FHIR $match operation to allow for full responses to Patient Discovery queries from FHIR Query Initiators. Responding Actors SHOULD have the capability to return more than one potential patient match when a patient search yields more than one match. Responding Actors SHALL NOT return more than one potential match when such action could be a violation of HIPAA or other Applicable Law.” We ask that the following questions be addressed in the next version of the IG:
  • What is the expected process when two records for an individual are located versus record for multiple individuals with similar identifiers (e.g., same names)?
  • How will the authorized token be used by caregivers?
  • How will QHINs verify consent for caregivers?
  • How will the IG address complexities (e.g., an individual has several authorized representatives/caregivers, custodial allowances and limitations, etc.)?
  • How will responding actors confirm the unique match?
  • Can the requirement be amended for responding actors to have the capability to return more than one potential match when a patient search yields more than one match from “should” to “may?” This change allows organizations to execute best matching to guard against inappropriate disclosure of information under HIPAA.
For error responses, the IG sets out that, “Errors resulting from FHIR transactions should use the Operation Outcome resource to return both human readable and machine processable information with sufficient detail for a client to determine if the error can be corrected at the client side.”  We ask that the following questions be addressed in the next version of the IG: 
  • Are security concerns defined as per the specific organization’s security policies, which can differ between entities?
  • Certain protected health information (e.g., substance use disorder or mental health information) cannot be shared without an individual’s consent. What guardrails will be in place to address these limits within TEFCA?
  • How will member data be handled when a patient/member has a protective order or confidential data hold?
In the version compatibility section, the IG states that “Actors SHALL continue to support any capabilities previously supported for TEFCA purposes under a particular FHIR Release, until support for that FHIR Release has been officially sunsetted by the RCE. The RCE will provide advance notice of such sunsetting and will collaborate with the TEFCA community to develop reasonable timelines for such sunsetting.” For this section, we note that currently the USCDI v1 is required by federal interoperability regulations. As these regulations advance to later versions of the USCDI, we recommend TEFCA alignment as well. In addition, FHIR implementation should align with the interoperability regulations. We request advance notice and collaboration on version updates, including working with HL7 and other standards development stakeholders on testing and implementation. We request that feedback timeframes be no shorter than 30 days. We support amending the requirement for Actors to continue supporting capabilities previously used for TEFCA purposes under a particular FHIR release until support for that FHIR release has been officially sunsetted (i.e., the language should be modified from “shall” to “may”). 
 
In the section discussing Access tokens, we are concerned that 60 minutes of access token could be too long for some organizations or applications. We recommend a standard maximum refresh token time to promote uniformity with shorter maximum lifetimes permissible. We also ask that the following questions be addressed in the IG:
  • How will revocation of access or opt-out be implemented? What will be the process and time frames?
  • Can the 60-minute rule be modified to a shorter duration based on an Entity’s policies?
In the section discussing endpoint lifetimes, the IG explains that If an Actor updates its endpoints listed in the QHIN/RCE Directory for any reason other than FHIR Release support, the Actor MUST continue to support transactions received at its previously listed endpoint(s) for a minimum of 48 hours after the QHIN has the RCE Directory. We are concerned about this section and the notice process when an entity changes an endpoint. It is currently unclear how endpoints will be certified and ongoing maintenance will take place to ensure authorized actors are utilizing them.
 
Use Cases/Workflows
 
We recommend the IG be expanded to include information and workflows for when a TEFCA participating group follows the OAuth Flow for a consumer facing application, and then the Responding Actor responds with an ID token and Access token.
We recommend that QHINs provide choices to their Participants or Sub-participants regarding participation and patient lookup. This could include an Enterprise Master Patient Index (eMPI), Record Location Services, or techniques to perform federated queries at the direction of their participants or sub-participants. Tracking QHIN Participant access will be critical to ensure information is adequately protected and accessed only when permitted.

For the Nominal Flow, we are concerned that the proposed workflow assumes implementation of the new FHIR Digital Identity profile. The FHIR Digital Identify profile is new and currently still being implemented. We recommend additional time to test, train and implement. The timeframe for doing so should be discussed with stakeholders more fully before the IG sets a time.

Infrastructure

Dynamic client registration is still in development and testing and will be a significant undertaking for organizations to implement. We recommend changing the requirement from “shall” to “may” for implementers to support dynamic client registration.

In the section for authentication/trust, we would like more information about the process for when/if a QHIN, client server, or other TEFCA actor ceases operations temporarily or permanently. While the CA addresses a high-level process for terminations, these scenarios should be discussed in the IG.

We also note that FAST is working to address endpoints. We recommend that the RCE work to align with FAST as well as other standards development industry initiatives.

Additional Feedback and Considerations

AHIP members have been working to understand and evaluate the Healthcare Payment & Operations proposed use case for risk management / adjustment. At this stage, based on the information shared to date, we recommend that the use case be limited and more clearly defined. It is uncertain at this stage the extent to which data will be involved and leveraged, whether clinical data can be shared for non-treatment functions, and other uncertainties. We are open to discussions to changing the use case or to tailoring it for more clearly defined and usable outcomes.

For the IG, we request additional detail in the IG for clinical data exchanges. We believe TEFCA should have a process and a consistent, expected timeline for alignment with IGs as they are completed and implemented. We recommend a phased-in approach and a use case as a starting point.

In addition, the IG notes that the Da Vinci Payer Data Exchange should be supported, but there appear to be differences between the Pdex IG and this IG when it comes to exchanging the token. Pdex is working towards a multi-token approach, whereas the IG does not define a multi-token approach. We request specifics on whether and what portions of Pdex IG’s are to be followed. We request similar explanations for the “member-match operation” defined in the Pdex IG.

 

Appendix A

In response to “Requirements for the FHIR Query Initiator: Public Health”
 
This section implies that Public Health entities utilizing FHIR would only have the authority to query and receive information within the context of an emergency situation. If Public Health migrates to and adopts FHIR, querying and exchanging information must be a routine capability, not specific to emergency or outbreak scenarios. 
 
In response to this statement within the Public Health Requirements for the FHIR Query Initator: “The specific patient who is the subject of the query must reasonably be associated with the declared emergency”:
– That should be expanded to include “or public health requirement”
– Need to update the example: PH should be able to access the patient data during a case investigation (i.e. in the context of a public health requirement), even before a pubic health emergency is declared.
 
Additional Feedback and Considerations
 
While the querying capabilities of FHIR are well-addressed and understood, there is no mention of push capabilities. Push is a very important modality for public health and it would be ideal for nationwide data sent via push (eCR, Syndromic, Immunization, e.g.) to travel within the context of TEFCA. 

View Additional Feedback

Role Requirements

Regarding the two defined roles of FHIR Query Initiator and Responding Actor, we also request that the role of the QHIN, participantsand subparticipants beclearlydefined and differentiated in this section.

General Requirements

3.1 Provenance: We believe that the Provenance profile should be based on the implementation that the endpoint supports, and not restricted to US Core 4.0.0. A few additional corrections include updating the link to the “US Core v4.0 Provenance profile,”whichlinksto 5.0.1and thatthe correct version is 4.0.0. We believe that we should have some flexibility here, as many vendors’capabilities are going to be aligned with ONC CEHRT, which has the current requirement set at 3.1.1 with 4.0.0 as optional. If there is a baseline to be set, then we’d recommend starting with 3.1.1but then permitting endpoints to also use higher versions, and specifically indicating that within the IG.

3.2 Patient Matching: In this section, our primary concern is the lack of description around the brokering of the location information. The RLS/eMPI should play a major role in the patient discovery and patient matching workflows prior to the authentication and authorization steps. We agree with the inclusion of the (?)$match but do not agree with the need to perform the $match at each organization. We feel very strongly that in order to scale FHIR, the RLS/eMPI must be the place where the patient matching question(s) are asked. The QHIN with the RLS/eMPI should be able to tell each FHIR Query Initiator where the patient data is, and then allow the FHIR Query Initiator to go directly to the Responding Actor’s FHIR server to gain authorization, registerand authenticate to query for resources. With regard to the setting for (?)onlyCertainMatches, we advise that the client be responsible for setting the number instead of limiting itto 100 potential matches. We advise that the IG use _count instead of indicating a specific number. Allow the FHIR Query Initiator to dictate the maximum.

Use Cases/Workflows

4.1 Patient Discovery, Authentication, and Authorization: As we have indicated in our past comments to the RCE, we believe that the use of an RLS/eMPI is central tothe success of QHIN-based exchange and TEFCA as a whole. Therefore, we advise that an initial assumption should be that the QHIN knows the patient identifier and how to utilize that patient ID for subsequent transactions in the flow. It’s imperative that the QHIN knows where the patient is, so that we avoid having every client having to register with every FHIR server, just to ask where the patient is. In today’s environment with XCPD, we only find patients approximately 3% of the time when we do broad-based queries. It’s not scalable to permit exchange to take place in this manner. Instead, we suggest that the Participants and Subparticipants send patient information to the QHIN’s eMPI andregister FHIR clients and servers with the QHIN’s FHIR Directory, and use that information to allow FHIR Query Initiator’s to do a patient search against the QHIN first. From there, the FHIR Query Initiator will receive a list of patient IDs and FHIR server endpoints. A key component that is missing is how we should expect to handle capability statements. In the CommonWell FHIR workgroup, we debated where the capability statements should live–either at the FHIR server or within the RLS associated to the FHIR endpoint. We decided that the source of truth should be the FHIR server with regard to what it’s capable of. Therefore, in the workflow depicted below, once the FHIR Query Initiator has the patient IDs and FHIR endpoints, it then should go directly to the FHIR server to retrieve itscapabilities. This willtell the FHIR Query Initiator how to register. We advise that the RCE review the order of the workflows to ensure that the FHIR Query Initiator is able to retrieve the server capabilities(4.2.2)prior to the registration workflow step(4.1.2). This is animportant process to get right as the capabilities statement will tell the client what registration capabilities the server has. In section 4.1.2, #4, note that the client should send an assertion, not an authorization token, to request access, per theUDAP Security IG.

Infrastructure

5.1 FHIR Endpoints & Endpoint Discovery: We request further definition on what the QHIN’s Capability Statement should include, as we expect that the QHIN’s role is specifically related to patient and endpoint discovery, and thusshould have a limited capability statement.

5.2: Authentication/Trust: We recommend pointing to and citing the UDAP Security IGas much as is feasible without rewriting much of the content held within, and then calling out QHIN-specific or role-specific information, such as metadata,that isconfigurable based on the community. We recommend stating “QHINs, Participantsand Subparticipants SHALL support dynamic registration as specified in the Dynamic Registration profilewith additional constraints and requirements as defined in this guide.” This way it’s clear that the source of truth is the UDAP Security IG and the Facilitated FHIR IG adds community-specific information, rather than the other way around. CommonWell recognizes that we’re going to need to partner with a Certificate Authority to issue, manageand revoke certificates so that we can ensure trusted exchange can take place at this scale. We submitted feedback to Carequality that CommonWell, both as a Carequality implementer and prospective QHIN, would partnerwith a Certificate Authority of our choice and issue certificatesto our Participants and Subparticipants under that CA. However, we will need theCA to work closely with the RCE to ensure that the root of those certificates can be trusted across QHINs. We welcome the opportunity to have future discussions with the RCE and subject matter experts to come up with the best plan to satisfy the needs of handling a significant number of certificates while maintaining trust within TEFCA.

Appendix B

The description of the public health assertion is unclear. It reads as if public health has the authority to collect data only during a public health emergency. Public health routinely collects data from providers without the declaration of an emergency.
Sometimes, some public health agencies deliver clinical services. In that case assertion should follow the pattern for clinical care.

A suggested reading would be:

Requirements for the FHIR : Query Initiator Public Health. The FHIR Query Initiator for a public health authority must be making its request for information in the context of its Public Health authority according to local, state, tribal or territorial law or regulation. The specific patient who is the subject of the query must be reasonably be associated with a case of a reportable condition or a case under investigation. These typical, core, public health scenarios are not associated with clinical care.

Should the public health agency query for the purpose of delivering clinical care (e.g. in a health clinic scenario), those queries would be done with the appropriate care delivery policy assertion.

Additional Feedback and Considerations 

We note the absence of a push design pattern. Many public health scenarios require a provider (hospital, doctor, lab) to send an unsolicited message. The push use case. While not suggesting current push processes be replaced, it would be appropriate to architect for such a design pattern. Note these could be new, native RESTful PUT or POST scenarios to deliver resources to the receiver (public health). There may be implementation reasons for using the FHIR messaging or documents, even using the existing standards with the FHIR “transport” and security frameworks, but we recognize the low return on investment for such a move at this time.

Lastly, we understand “push” support may be further out on the QHIN implementation timeline. But we would like to see it referenced as it is important as a future option and we would prefer to avoid omission.

Certificates

We believe that FHIR-based approaches to information exchange are better aligned with the North Star architecture and strategic vision of the ONC, and are more modern, capable approaches than the current IHE-based use cases. As such, we are likely to leverage both facilitated and brokered approaches to FHIR-exchange standards.

While we have some concerns about the complexity of the certificate management and the scalability of these approaches, the technical challenges will likely scale faster than the governance issues around certificate renewals, missing information on certificates, keeping the certificate information up to date if ned points change, or the required interactions with the RCE directory services. These are the bigger risks, and the question about who maintains the certificates (either through a QHIN or an agreement with a third-party CA) is less important than how the RCE will manage these other governance issues. Whatever approach is chosen should focus on these non-technical issues, since these are more likely to struggle as we scale.

General Requirements

As the use case is defined, it is a “once and done” interaction. However, determining whether there is an appropriate match may require a series of interactions or a “conversation”. For example, with the initial match criteria, it may be possible to identify 40 or 50 potential matches. While it is possible to return all of those as possible matches, it may be more desirable to ask a second, differentiating question that can refine the search. What that question is may be different for different kinds of possible matches. It is not clear in the IG whether these kinds of interactive matching are supported.

Likewise, additional clarity should be provided about how to determine if a HIPAA violation has occurred with either returning one match or returning more than one match. What that “line” is between returning possible matches and a HIPAA violation isn’t clear in the IG, and additional clarifying information about when something is (and isn’t) as HIPAA violation would improve the implementation guide.

Additional Feedback and Considerations

Finally, while the IG is clear about using the RCE directory for the facilitated FHIR use cases, it is not clear how this IG (and the RCE directory) will interact with other directory initiatives from CMS. As these additional directory initiatives go forward, the IG will want to build in flexibility to use the best directory for the specific use case at hand.

General Requirements

3.1 Provenance, pg2, paragraph 1: Transform – internal, backend data-processing activities by the recipient of the data exchanged is not the province of an implementation guide.

3.2 Patient Matching, Pg 2, paragraph: A multiple match query response should not provide more information back to the requester than was supplied in the query. The query information should be echoed back, and the query initiator told to refine their query.

3.3 Error Responses, pg. 3, last line in paragraph:
Recommend – Elaborate on the possible identified security concerns (e.g., IT concern, Saftey concern, Risk to humans).
Rationale – Dependent on the type of identified security concern, THEN Recommend change SHOULD to SHALL. Revised sentence: Any such choices SHALL be linked to identified security concerns. Rationale – Reasons for obsured information must be link for tracking/safety purposes. Example – If details are obscured for security reasons related to a patient’s past or current criminal history and the identified security concern is not linked to the error, then human safety is placed at risk.

General Comment on this section: It would be interesting to see how value from existing (IHE) HIE capabilities (patient search, content identification, source identification) could be adapted for FHIR query. This might support the testing of security and query functionality decoupled from patient and endpoint discovery.

3.2 Patient Matching, Pg 2: EHR vendors may require considerable time to implement the ability to manage multiple potential patient matches returned in response to a query. Suggest mandatory implementation timelines consider this complexity.

Use Cases/Workflows

General Comment on this section: Interaction diagrams would help readers navigate the text.

Appendix A

The Department of Veterans Affairs has adopted an Informed Opt-In Patient Consent Policy. The OIDs provided do not address how to reflect patients who have not explicitly opted out. Suggest this be added.

Additional Feedback and Considerations

It’s challenging, when defining an Implementation Guide, to separate data-exchange specifications from their technical implementation. Grahame Grieve’s goal in architecting Fast Healthcare Interoperability Resources (FHIR) was first and foremost to aid software engineers in fast software development and deployment of standards-based clinical data-exchanges.

My concern in reading through the TEFCA FHIR IG Draft is the blurring of the lines between a data-exchange specification and its technical implementation.

For example: Data Provenance – the specification should say nothing about what transformations are performed after the recipient receives the FHIR Resources. Burdening the receiver with tracking internal transformations of the data has nothing to do with exchanging the data or tracking its source(s).

It’s unfortunate, for example, that the RESTFul messaging framework has been tied to the hip of the FHIR specification(s). REST is not a W3C standard, and does not provide the power and flexibility of one that is (e.g., SOAP). There is no REST Web Service Definition Language (WSDL) file (the WADL file was neither formalized nor widely adopted).

Hardcopy consent forms exponentially increase the overhead burden on both the initiating and receiving systems. This should only be required if/when the Purpose of Use is not Treatment, and compliance is mandated by state or federal law.

BLUF: A national, base FHIR Implementation Guide should concern itself with defining the Message Types for Request and Response Messages generated and consumed by FHIR data-exchange endpoints, not how the Messages get from point A to point B, nor what is done with the data beyond validating it for conformance to the IG FHIR Resource syntactic and semantic requirements for generating Request/Response Message Types.

View Additional Comments

Certificates

Feedback regarding: The RCE is seeking feedback specifically regarding concerns with managing the volume of certificates needed to operationalize Facilitated FHIR at scale. Do you anticipate that your organization will leverage Facilitated FHIR or wait for an approach Brokering FHIR through a single QHIN Gateway?
 
The DirectTrust community is ready to support FHIR in a nationwide and scalable way. Our trust framework is not an exchange Participant in query exchange, but we believe we have an important role to play in supporting technical trust in Facilitated FHIR as well as FHIR brokered through a gateway intermediary. Please see: “Additional Feedback and Considerations’ for background that may be used to contextualize and contrast DirectTrust’s feedback with that of the current Query Based Data Exchange (QBDE) environment.
 
Feedback regarding: Approaches that are being considered would place the management of certificates on each QHIN by either requiring each QHIN maintain their own Certificate Authority (CA), or alternatively have an agreement with one CA from an approved list. What risks/concerns are there with either approach?
 
The policies of technical trust embodied in a Certificate Policy adapted for the healthcare information exchange environment is essential. There have been several examples of CA compromises over the past decades and in every case, the attack occurred due to untrustworthy operational controls employed by the CA that range from improper procedures used for enrollment, to weak cybersecurity controls, to technology stacks that don’t conform to industry standards. Prior history of CA compromises plainly shows that people and processes are consistently the weakest link of running a CA. Cybersecurity experts have also championed the point that humans are the weakest link in any system. The only way to limit exposure to this risk is to ensure carefully crafted processes are followed by the staff who are responsible for adhering to published Policies and carrying out those processes. Ensuring processes are followed is the ultimate purpose and goal of periodically renewed accreditation. This is the foundation on which trust is built and grows. 
 
The value of governance policies and accreditation is exemplified by the risk assessment process undertaken to inform the initial DirectTrust Policies that govern the trust framework. This methodology includes examining risks to PHI, prescribing levels of assurance and certificate distribution methodologies, and evaluating operational controls that are evaluated as part of accredited members’ biannual audit processes. The option of having intermediaries issue their own certificates is explicitly prohibited unless they are accredited as an RA/CA.
 
To support interoperability across CAs, QHINs, and FHIR Servers, a set of certificate profiles that  can be easily adjusted to accommodate new requirements from the RCE would be recommended. Also, it is best practice to establish an authority to oversee the addition and removal of Trust Anchors from a Trust Bundle, inspecting certificates in an automated fashion to ensure that a CA’s certificates conform to the published Certificate Profiles. Such an approach is maintained today within DirectTrust and enables relying parties throughout the network to trust the Trust Framework and accredited CAs by downloading the Trust Bundle while observing interoperability across accredited CAs. It’s worth noting that a Trust Bundle, Root CA, or other trust mechanisms each have differential benefits and drawbacks, however, any approach will require a well-documented process to help the many thousands of actors to trust the infrastructure in a way that is secure, scalable, and easy.
 
Feedback regarding: Are there other approaches that should be considered? 
 
One approach that should be considered would allow QHINs and/or participants to choose to partner with one or more DirectTrust accredited CAs or elect to instantiate a DirectTrust accredited CA themselves. 
 
1) DirectTrust strongly urges the RCE to require any CA serving the TEFCA community be accredited, whether they are QHINs, QHIN participants, or commercial CAs. This enables a predictable and reliable level of trust across the environment.
 
2) Accreditation must include the processes necessary to scale the identity proofing and domain validation components of the certificate onboarding process. As an example, DirectTrust infrastructure scales as well as it does partly because of language in subscriber agreements between CAs and their customers which allow for authorized representatives of an organization to request multiple certificates for itself or its own sub-customers, of which that sponsor is also an authorized representative. Trusted agents take responsibility for verifying the identity of individuals and sometimes organizations. The subject of the certificate must also be able to demonstrate “control” of the domain where the certificate will be installed through a process that is defined within a Certificate Policy and is often automated using standard protocols. Some of the likely participants in the TEFCA ecosystem, such as EHR companies, are among the accredited CAs that issue these certificates for themselves. Others may depend upon the Accredited CAs that offer commercial Certificate issuance services. In DirectTrust, a total of 11 accredited Certificate Authorities serve approximately 300,000 healthcare organizations today.  We anticipate more Certificate Authorities than the two currently issuing certificates to Sequoia Initiatives participants will be required to scale FHIR and that a more “commercial” (and even semi-automated) approach will be required to support the scale. A scalable alternative to Trusted Agents includes advancements in unsupervised remote identity proofing (defined in NIST SP 800-63A) which supports IAL2, a technology currently employed by members of the community.
 
3) A final point to consider for scale is automating or semi-automating authorization. An organization may be legitimately identity proofed at IAL2 with verified control over their domain, but not authorized by a QHIN or Participant to participate in TEFCA. Scaling the authorization of FHIR certificates is outlined in the next section “How would your organization expect to handle certificates, and how can we scale certificate trust chains and issuance of potentially tens of thousands or more certificates across all QHINs, Participants, and Subparticipants?”
 
Observing these three points will enable FHIR to scale while ensuring processes are carefully followed as part of a Trust Framework with Policies that support healthcare. In this approach, the QHINs and Participants would assume a similar role as DirectTrust currently serves for Carequality, as summarized in “Additional Feedback and Considerations.”
 
DirectTrust has proven past performance maintaining multiple trust communication mechanisms including a Trust Bundle, a Root CA, and a Bridge CA. DirectTrust would be pleased to collaborate with the RCE to develop a strategy for managing scalable trust across healthcare FHIR endpoints.
 
Feedback regarding: How would your organization expect to handle certificates, and how can we scale certificate trust chains and issuance of potentially tens of thousands or more certificates across all QHINs, Participants, and Subparticipants? 
 
For an approach to scale trust in identity proofing and domain validation, please see the feedback regarding: “Are there other approaches that should be considered?” 
 
This section contemplates scaling trust in authorization. Since new actors seeking certificates to operate in the ecosystem as a part of onboarding will not yet be in the RCE directory, the directory cannot be used by RAs/CAs as a mechanism to determine whether an actor is authorized, but may be relied upon by initiating and responding actors. 
 
A TEFCA environment that supports FHIR will require at least three hierarchical layers of authorization that CAs must observe. The unique and complex nature of the TEFCA environment is the precise reason a Trust Framework that is purpose-built for healthcare must be employed as opposed to CAs supporting public web-browsers. These layers of authorization should not be conflated with the identity of the actor or ownership of the domain contained in the certificate. It is conceivable that a certificate could be issued to a healthcare organization that is not authorized to participate in TEFCA, unless a trustworthy authorization process that scales is instituted. The CAs currently supporting the Carequality environment are orders of magnitude away from their capacity to issue certificates due to inefficiencies. The principal inefficiency in the Carequality certificate issuance process is a lack of automation surrounding authorization. The recommendation below aims to address the concern of authorization in an automated and scalable manner. 
 
The first layer of authorization communicates which QHINs have been authorized by the RCE. The RCE might elect to publish a list of authorized QHINs that CAs must observe before issuing certificates to, or on behalf of, a QHIN. Another option is for QHINs to provide a document signed by the RCE to an accredited CA during certificate issuance as a means of conveying authorization, among other approaches. Optionally, the RCE could make provisions in its published certificate profile for FHIR certificates to include the URL of the RCE directory or list of QHINs authorized by the RCE in an effort to allow Initiating and Responding Actors the ability to validate that a QHIN was authorized by the RCE.  
 
The second layer of authorization occurs at the QHIN level. At this authorization level, the CA must only issue certificates to Participants that have been authorized by a QHIN. The QHIN would serve as the authority that determines eligibility for a Participant to receive a certificate. CAs would not be allowed to issue certificates to parties that were not directly authorized by a QHIN. As an approach to ensure unauthorized certificates are not issued, the QHIN could be responsible for approving/submitting applications to their contracted RA/CA(s) using a process established between the RA/CA and the QHIN that complies with the Certificate Policy. If a Participant wishes to contract with an accredited CA separately (different from the QHIN’s CA), the Participant’s CA would need to confirm authorization either by documents signed by a recognized QHIN or some other process before issuing the certificate to Participants. The RCE may also require the QHIN to publish a private list of authorized Participants to allow responding actors the ability to validate, in real time, that the subject of the certificate (Participant) was authorized by a legitimate QHIN. Optionally, the RCE could make provisions in its published Certificate Profile for FHIR certificates to include the URL to RCE’s directory. Initiating and Responding Actors could use the directory to validate that the Participant was authorized by a legitimate QHIN recognized by the RCE. 
 
The third layer of authorization occurs at the Participant level. Some Participants will not have Subparticipants, however, others will. One such example of this third layer in action is EHR vendors who wish to credential each of their customers rather than assume responsibility for their FHIR endpoint. As such, CAs will not be allowed to issue certificates to Subparticipants that were not directly authorized by a Participant that has been listed by a recognized QHIN. As an approach to ensure unauthorized certificates are not issued, the QHIN could be responsible for approving/submitting applications sent to their contracted CA(s) on behalf of Participants using an automated process established between the CA, the QHIN, and the QHIN’s Participants that complies with the Certificate Policy. If a Subparticipant wishes to contract with an accredited CA separately (different from the QHIN’s or Participant’s CA), the Subparticipant’s CA would need to confirm authorization either by a documents signed by a recognized Participant or some other process before issuing the certificate to Subparticipants. Optionally, the RCE may also require each Participant that manages Subparticipants to publish a private list of authorized Subparticipants’ domains. Initiating and Responding Actors could use the directory to validate that the Subparticipant was authorized by a legitimate Participant recognized by the RCE. 
 
The RCE’s directory could consume the private lists of QHINs and Participants to maintain up-to-date information in the directory about the authorized actors participating in TEFCA. A simple mechanism for authorized personnel to communicate updates to the directory could also be employed.  
 
Observing these authorization layers ensures certificates are only issued to authorized actors. These authorization layers represent real business relationships and afford the flexibility to allow actors to outsource both the Registration Authority and Certificate Authority functions, or elect to become an accredited RA and/or CA, at their discretion to support scale and demand.

Role Requirements

DirectTrust believes that Credential Service Providers (CSPs) are a concept and a role that is necessary to adequately fulfill the goals of Individual Access Services (IAS). Please see our feedback in the section 5.2.6 Individual Access Services

Infrastructure

DirectTrust’s comments in section 1 of this response are largely reflected in our suggested edits outlined below.

Comments on Section 5.2: Authentication/Trust

Text: “X.509 certificates establish the authenticity of Actors implementing this IG. The RCE will issue one “Intermediate” certificate to each QHIN to seed the QHIN’s Certificate Authority. A QHIN’s Certificate Authority issues certificates to downstream Actors. Certificates used by any Actor SHALL be chained to the RCE “root” certificate.”
DirectTrust’s alternative recommendation: “X.509 certificates establish the authenticity of Actors implementing this IG. QHINs or participants shall engage in a contract agreement with one or more of the accredited CAs listed by the RCE. Alternatively, a QHIN or Participant may elect to instantiate their own accredited CA. A QHIN’s or Participant’s Certificate Authority issues certificates for downstream Actors. Certificates used by any Actor SHALL be bound to a Trust mechanism specified by the RCE.”

For more information, please see feedback regarding: “Are there other approaches that should be considered?” and “How would your organization expect to handle certificates, and how can we scale certificate trust chains and issuance of potentially tens of thousands or more certificates across all QHINs, Participants, and Sub-participants?”

Broken Links Noted
We also note that links in the draft to FHIR Security IG references are broken and cannot be reviewed easily. We presume the references are meant to be to the following IG as the reference numbers align with the structure of the IG at the following link and not the normative FHIR Security IG – https://build.fhir.org/ig/HL7/fhir-udap-security-ig/

Comments on Section 5.2.3 – Client Registration
We agree with the inclusion of Dynamic Client Registration as a scalable and automated approach to scale the FHIR ecosystem, both for Business to Business connections and for the IAS use case.

Comments on Section 5.2.4 – Authorization Code Grant Type (3-leggedOAuth 2.0)
We note that UDAP Tiered OAuth is included in this draft. We applaud the inclusion as we strongly believe reusable consumer credentials will substantially improve the value of IAS to patients and their representatives. For this reason, we strongly encourage the RCE to upgrade support for UDAP Tiered OAuth from an optional/MAY requirement to a MUST (or at least to a SHOULD) requirement with some timeline for mandatory support.

Comments on Section 5.2.6 – Individual Access Services (IAS) Requests
While the User Authorization Extension Object is stipulated and important information about the requestor is present in the Object, we also think it is important to note “ial_vetted” attributes as a part of this structure need to be reliably protected to determine that an accredited IdP/CSP that was the source of such data is signing the assertion. More than policy is required to ensure that the app was not able to make changes to these verified demographic attributes. We believe accreditation/independent certification to ensure the IdP/CSP conforms to the policies of a technical trust framework should be a requirement to issue credentials for use for IAS. As noted in Appendix B below, the NIST definition of a CSP includes not just IAL assurance, but AAL and credential management requirements as well.

Appendix A

The RCE might also consider more human-readable URIs if the OIDs are expected to reside within a JWT data structure.

Additionally, there appears to be a conflation between an assurance level and a means of communicating consent. Many of the OIDs in Appendix A also appear in Appendix B. Consent and assurance levels are often used in combination, however, they are not the same and should be communicated differently. DirectTrust recommends more human-readable means of conveying the types of consent to aid a responder in potential manual processing of a portion of requests.

Appendix B

DirectTrust observes that Authenticator Assurance Levels (AAL) are absent from this list. In scenarios where an IAS app identity proofs a patient at IAL2, DirectTrust strongly believes the app should authenticate the patient at AAL2 or higher as required by NIST SP 800-63B. DirectTrust recommends adding AAL2 and AAL3 to the list of recognized assurance levels.

Additional Feedback and Considerations

Summary

The TEFCA FHIR Implementation Guide proposes a model for technical trust which we feel will not provide adequate security for healthcare data exchange. We suggest an alternate model that both scales securely and enforces best practices by leveraging DirectTrust as an existing Trust Framework that supports both Direct Secure Messaging and query-based data exchange (QBDE) for all healthcare information exchange.

DirectTrust and our community of certified Certificate Authorities (CAs) have been serving Carequality for nearly two years. We’ve proven our community can provide digital certificates for the TEFCA FHIR ecosystem through our accredited Registration and Certificate Authorities utilizing our current Trust Framework. We recognize the scale required by the FHIR ecosystem will require us to refine the current process utilized for QBDE. We recommend the RCE leverage the DirectTrust Trust Framework and governance to support QHINs in their certificate registration and issuance processes, rather than build a new infrastructure with new policies, new governance, and new CAs operated by QHINs.

Background

Historically, Carequality and eHealth Exchange managed much of the process of issuing certificates to implementers and participants internally and ensured that only community members received certificates. A single Certificate Authority played the role of issuing the TLS certificates that secured communication among all parties. Each Participant needing a certificate would be introduced to the CA in a warm hand-off by email.

In 2020, Sequoia and DirectTrust signed an agreement where multiple CAs could service the needs of the Carequality and eHealth Exchange communities with DirectTrust playing a certificate policy enforcement and accreditation role. DirectTrust also coordinated the hand-off process and technical support, which are duties that DirectTrust doesn’t typically take on in other environments due to the propensity of these activities to cause a bottleneck. The rationale underpinning DirectTrust’s current role in support of Carequality was to maintain as similar a process as possible to what was previously being carried out by Carequality. The hand-off process between Sequoia and DirectTrust remains the mechanism by which the subscribing organization’s participation with one of the initiatives is verified. DirectTrust then introduces the subscribing organization’s representative to the CA that then takes the process to its completion. The sub-contracted CAs do most of the typical commercial Registration Authority and Certificate Authority activities for the issuance of certificates, including but not limited to: ensuring the individual identity of the subscriber (at NIST IAL2), ensuring that the organization is licensed to operate in its jurisdiction, ensuring that the subscriber has control of the domain/machine where the certificate will be installed.

In 2021, all the certificates that had been issued by Carequality’s previous CA were transitioned to the new DirectTrust-enabled model.

Since Query Based Data Exchange (QBDE) is secured between IHE Document repository gateways using TLS certificates, the total number of certificates required for this model is relatively small. For example, CommonWell Health Alliance is a Carequality Implementer with many participants and thousands of sub-participants, but only one certificate is used to secure the connection between CommonWell as broker and the other Carequality implementers. Some implementers stand up separate gateways and certificates for all their sub-participants, but most do not. This approach has scaled reasonably well for the number of certificates and participants required.

Within the IHE profiles there is an additional security mechanism beyond TLS certificates. TLS is supplemented by SAML assertions that communicate organizational identity through initiating and responding gateways from the sender to the receiver. These two mechanisms together are thought to establish adequate technical trust in the current environment and this model has had broad adoption.

Serving Business to Business Query Utilizing RESTful Exchange via FHIR

As Carequality, and by extension the RCE and TEFCA deploy FHIR at scale, there will be several substantial changes from the IHE model. First, most FHIR transactions will be communicated without gateways or brokers, thus initiators will need to perform authentication and authorization directly with receivers. The technical means to accomplish this is different under FHIR and these differences change the security and technical trust landscape in a substantial way. Rather than SAML, FHIR transactions will utilize TLS, OpenID Connect (OIDC) and OAuth 2.0 to communicate identity assurance via digital certificates. Rather than relatively few gateway connections needing to be established, these “broker-less” connections will be made between the thousands of FHIR endpoints to communicate trust and information exchange bidirectionally. This ecosystem is not only large, but also dynamic. A Participant of an implementer, or of a QHIN under TEFCA, will be onboarding new Subparticipant healthcare organizations constantly and need the flexibility to onboard these organizations and Users with minimum friction.

It is precisely the scale of this ecosystem that makes reliable credentials for connections so important. Several trust infrastructures have demonstrated such ecosystems at scale successfully, including The International Civil Aviation Organisation (ICAO) supporting international passports, the CA/Browser Forum (CA/B) supporting the internet, the electronic Identification, Authentication and trust Services (eIDAS) supporting trust across EU nation states, and the Federal PKI. All of these groups ensure that organizations who issue end-entity certificates are accredited and impose strict governance policies to ensure interoperability at scale among all participants.

View Additional Feedback

Additional Feedback and Considerations

We recommend pointing to and citing the UDAP Security IGas much as is feasible without rewriting much of the content held within, and then calling out QHIN-specific or role-specific information, such as metadata,that isconfigurable based on the community. We recommend stating “QHINs, Participantsand Subparticipants SHALL support dynamic registration as specified in the Dynamic Registration profilewith additional constraints and requirements as defined in this guide.” This way it’s clear that the source of truth is the UDAP Security IG and the Facilitated FHIR IG adds community-specific information, rather than the other way around. CommonWell recognizes that we’re going to need to partner with a Certificate Authority to issue, manageand revoke certificates so that we can ensure trusted exchange can take place at this scale. We submitted feedback to Carequality that CommonWell, both as a Carequality implementer and prospective QHIN, would partnerwith a Certificate Authority of our choice and issue certificatesto our Participants and Subparticipants under that CA. However, we will need theCA to work closely with the RCE to ensure that the root of those certificates can be trusted across QHINs. We welcome the opportunity to have future discussions with the RCE and subject matter experts to come up with the best plan to satisfy the needs of handling a significant number of certificates while maintaining trust within TEFCA.

Certificates

Developing the infrastructure to maintain a certificate authority and managing the volume of certificates needed to operationalize Facilitated FHIR at scale would require significant R&D and staff investments on the part of QHINs, which could ultimately result in higher costs for Participants and Subparticipants to engage in exchange via TEFCA. QHINs may be reluctant to invest the resources to support the trust framework envisioned by the Facilitated FHIR Implementation Guide if the RCE envisions TEFCA eventually moving toward a requirement to use QHIN Brokered FHIR in the future across all use cases instead of Facilitated FHIR. Much of the work that will need to be completed to implement Facilitated FHIR would not be able to be reused if TEFCA transitioned QHIN Brokered FHIR in the future, and supporting multiple trust models would be costly. The RCE should clarify the roles that it expects QHIN Brokered FHIR, Facilitated FHIR, and IHE Document-based exchange workflows will have in the network (and for which permitted purposes) in the long term. In the interim, the RCE should also prioritize the addition of the FHIR endpoints of Participants to the TEFCA Directory. Doing so will make FHIR endpoint discovery easier within the TEFCA community and ultimately promote greater adoption of FHIR-based exchange—especially for the IAS use case.

Successful management of the volume of certificates needed to operationalize Facilitated FHIR at Scale will require the RCE to establish strict certificate practice statement requirements for QHINs (or their designated Certificate Authorities) to follow. Not defining a set of strict practice statements will degrade trust in the TEFCA ecosystem, since it will inhibit the ability for entities to validate that an actor is entitled to network access and the information it is requesting based on SOPs that define the types of actors that are permitted to request information via TEFCA for a given use case. In Facilitated FHIR, QHINs should have the flexibility to maintain their own Certificate Authority or choose to use the services of an approved CA that meets the same requirements. Allowing this flexible approach will enable QHINs to determine the best technical match for the Participants in their network and make an evaluation between maintaining their own or using another service provider based on costs and benefits for their network. It will also ensure that QHINs and Participants are not beholden to the priorities of the CA service provider if there are a limited number of approved CAs.

Role Requirements

The Provenance requirements in Section 3.1 specifies that actors should adopt US Core v4.0 Provenance Profile. Instead of specifying the version of the Provenance Profile that should be supported in this section, we recommend referring to the version of US Core profiles required by the TEFCA Facilitated FHIR IG in Section 5.3 to ensure consistency.

The role requirements of the Responding Actor appears to assume that Participants would have implemented FHIR R4 APIs conformant to US Core Implementation Guides to support the nominal flows described later in this guide. This is a departure from the approach of TEFCA so far, where technical requirements were not placed directly on Participants.

The RCE should evaluate the downstream impacts of establishing technical requirements for Participants in TEFCA. Specifying standards and capabilities that must be supported by the systems of Participants and Subparticipants could inhibit certain groups from joining the network, especially if they are not stakeholders that have historically adopted certified health IT (e.g., health plans, public health agencies, individual access service providers, other insurers, etc.). In the future, it could also create situations where there are discrepancies between TEFCA’s expectations of Participants, and expectations for the certified health IT used by healthcare provider Participants. The RCE would need to ensure there is constant alignment and compatibility between its technical requirements and those of certification.

General Requirements

Patient Matching
We agree that only requiring “onlyCertainMatches=true” is appropriate when returning multiple matches could result in a violation of HIPAA or other applicable law. We expect that this would most likely be the case in the case of a query being submitted for the IAS use case. The IAS Exchange Purpose Implementation SOP should be correspondingly updated to reflect the approach described in this IG, and state that responders should only return the equivalent of a certain match in IAS queries.

Use Cases/Workflows

We recommend enabling the functionality described in Carequality’s Consumer Facing App Certification Profile for the IAS use case.

Under the Nominal Flow 4.1.2, step 3.b contradicts the requirements in section 5 by assuming there will be a single purpose_of_use. There might be multiple purpose_of_use values at registration time, since the value is an array, and section 5 also allows for the omission of purpose_of_use at registration time, though the Authorization Server may require it.

Under the Nominal Flow 4.1.2 step 4.a.i.1, the FHIR Query Initiator is required to include the TEFCA User Authorization Extension Object, but this is not required for the authorization_code flow. The IG should clarify the cases when the TEFCA User Authorization Extension Object is required.

Step 4a of the Nominal Flow (in support of IAS request) should require the use of a token from the Credential Service Provider (contemplated in the IAS Implementation SOP) that verifies that IAL2 verification took place. Without a token or some other traceable evidence of verification issued by the CSP and included in the query, it will be impossible for responding QHINs or Participants to independently audit that the IAS Provider had actually completed the identity proofing process.

The lack of the use of a token issued by the CSP would allow an unscrupulous IAS Provider connected to TEFCA to circumvent the “required” identity proofing process by merely asserting that it had verified demographic information without having done so. If an IAS Provider did not complete verification steps but asserted it had, the RCE, responding QHINs and Participants would have no method to audit and discover that the IAS Provider was not adhering to the requirements of the IAS SOP—meaning the unscrupulous actor’s behavior would go unnoticed indefinitely. Ultimately, it could lead to the inappropriate use and disclosure of large volumes of individuals’ sensitive health information.

The lack of a token issued by a CSP for use as evidence would also weaken the ability for individuals to control how IAS Providers and other Participants request, access, and disclose their health information. A token-based system allows individuals to easily revoke or time-limit the permissions granted to IAS Providers or others that will process their health information in the TEFCA ecosystem. When the token expires or is revoked, individuals can have confidence that their health information will no longer be accessed or exchanged for the IAS use case.

TEFCA should adopt a token-based system analogous to the OAuth method as the mechanism for providing evidence that the IAS Provider completed verification. The healthcare ecosystem is already familiar with the technology from its use with FHIR apps for patient access (and patients are familiar with it from other high-security industries, like banking).

Infrastructure

The links to Section 1.2 and Section 2 of the HL7 Security IG in 5.2.2 will need to be updated, since they currently result in a 404 error.

Since implementations are not required to support ES256 or ES384 keys, certificates should be required to use an RSA key to ensure interoperability.

Udap_certifications_required should be listed as required since it SHALL be present
Signed_metadata was copied out of the HL7 security IG but still references that IG.

In general, the authorization server metadata should reference HL7 security IG 2.2 and 2.3 and only list differences on top of that.

Purpose_of_use should be required to be a single value during the Oauth 2.0 client_credentials flow

5.2.6 – The Authorization Code Grant Type corresponds to the first workflow, not “workflow 2”.

Validation of demographics as part of supporting the “tefca_user” extension should not be required for the authorization_code flow.

5.2.4 – The reference to UDAP Tiered Oauth for User Authentication should reference the HL7 Security IG rather than udap.org

Clinical Data Exchange:
US Core has an extensive Must Support definition that defines behavior when data is not available. Therefore, the text “where data is available” when referring to supporting US Core is redundant, and may be construed as contradicting the Must Support requirements of US Core itself. We therefore recommend removing the statement “where data is available.”

The Facilitated FHIR IG should focus on the exchange of the USCDI v1 dataset, since that is the requirement from the QTF. A focus on USCDI v1 would help speed adoption of FHIR capabilities within TEFCA, since that is the requirement that aligns with the capabilities of certified health IT adopted by healthcare providers. The IG should refer to adoption of US Core version 3.1.1 instead of Version 4.0.0, since that aligns with requirements in certification.

The RCE should clarify the intended use cases of the Bulk Data Access IG, MHD, and Da Vinci Payer Data Exchange implementation guides. Because Facilitated FHIR is focused on pull-based workflows, the IG should only reference pull-based workflows of the MHD IG. Additionally, since the exchange workflows supported in TEFCA’s current use cases are focused on the exchange of individual patient records for Treatment and IAS, Bulk Data Access, and Da Vinci Payer Data Exchange should only be added once their associated exchange purposes are supported within TEFCA.

Appendix A

The appendices appear duplicative of each other. The RCE should clarify if it intends for them to be used in different ways. The RCE should also ensure the ACP policies are consistent between the Facilitated FHIR IG and the QTF.

Appendix B

The appendices appear duplicative of each other. The RCE should clarify if it intends for them to be used in different ways. The RCE should also ensure the ACP policies are consistent between the Facilitated FHIR IG and the QTF.

Use Cases/Workflows

In Section 3.2 of the FHIR IG, it states that “[q]ueries for information MUST include all demographic parameters that are available and can be sent and are not constrained by applicable law.” These demographics also must be normalized to USCDI standards. This language suggests that for matching purposes, queries could include all demographics available to the FHIR Query Initiator that are part of the USCDI. However, in section 5.2.6, focusing on IAS, it states that the user metadata submitted with the query must correspond to the verified identity attributes (such as those attributes verified by a credentialing service provider consistent with NIST level of assurance 2 for identity proofing. We acknowledge that the demographic attributes verified as part of identity proofing should be the version of those attributes utilized for patient matching in the context of IAS. However, once a patient has been identity proofed to a high standard (IAL2), there is high value in utilizing additional available demographic attributes that may not be able to be validated (and are not typically utilized for achieving NIST level 2 identity proofing) but are part of the USCDI and could be helpful in achieving a unique match. it’s hard to see what the risks are to utilizing these additional attributes to achieve a match once the patient has been strongly identity proofed. Matching specifications should be aimed at achieving matching accuracy; reliably establishing identity is a separate process.

We also have concerns that the IG, as written, allows the Responding Actor to make a determination on its own, without any particular standards, on when a match is successful. This opens the door to differential responses in the TEFCA network and the possibility of bias in returning results, as entities mask their failure to respond for impermissible reasons behind a safe harbor of not meeting match criteria. The purpose of creating a standards-based approach to exchange is to remove the potential for bias, and to achieve a level playing field for exchange to the extent possible. Rather than allowing each Responding Actor to set its own match criteria, the IG should establish a standard that requires response to queries that would return at least one unique match (and only one unique match in the case of IAS). The ability to set one’s own match criteria is likely to significantly frustrate the use of TEFCA for IAS, given the well-known opposition to this use case outside of traditional access through patient portals by a number of key stakeholders. If IAS is to become a real required use case, it will be critical to set match standards vs. allowing each responding actor to establish its own. We have focused our concerns about how the ability of Responding Actors to set their own match criteria will impact IAS – however, it is likely to also impact utility of the TEFCA for other use cases, as it opens the door for subjectivity in determining whether or not to respond to a query.

Additional Feedback and Considerations

Although this is not clearly reflected in the draft IG, it is our understanding that at least initially, a response to IAS will only be required when a patient/individual is accessing their data through a FHIR API from a certified electronic medical record, which means the data being shared with the patient requester is only the data held by the data holder sponsoring the FHIR API. This significantly decreases any value that patients will get from the TEFCA. The promise of TEFCA is a query through a single “on ramp” that enables a query initiator to obtain gets you all of the information that exists among participants in the network. Why should patients have to facilitate multiple connections in order to obtain this data when the promise of TEFCA is one connection and all information can be accessed? There is evidence that this “hyperportalitis” approach is discouraging for patients. TThere are other approaches that could utilize FHIR and Oauth consistent with this IG without a portal connection. Consequently, it is critical that this IG continue to leave the door open for IAS approaches that are consistent with this IG but are not dependent on patients receiving their payload solely through logging onto their portal, which would require patients to log onto and maintain log ins and connections with an app to FHIR APIs to every single healthcare provider where they have received care. We recognize that there are some important issues to resolve before the true promise of the TEFCA for IAS can be realized. We believe this FHIR IG establishes a framework for the realization of TEFCA for IAS, and we urge ONC and Sequoia not to further limit this IG in ways that would frustrate the realization of that goal.

Certificates

In general, and subject to some concerns and suggestions we (MedAllies Network Council) have detailed in our comments below, we believe the Facilitated FHIR IG specifications are headed in the right direction. It is critical that the IG adopt neutral standards for the exchange of information through the TEFCA using FHIR in a way that does not create unfair advantages for particular technologies or technological approaches. For TEFCA to achieve its goals, the IG specifications must be achievable and support a broad range of required use cases. The current IG approach takes significant steps in that direction.

While our (MedAllies Network Council) preference is brokered FHIR through a single QHIN Gateway, we are prepared to leverage Facilitated FHIR as needed. MedAllies, as a current Certificate Authority (CA), handles well over 100,000 active certificates, so scaling to support Facilitated FHIR is not an issue. MedAllies would find a requirement to use a third-party CA for TEFCA certificates not financially viable. To quell security concerns regarding QHINs maintaining intermediate CAs to the TEFCA root, we (MedAllies Network Council) suggest that specific requirements around the Certificate Practice be part of the requirements, and potentially an accreditation process to ensure that certificates are not compromised. Specifically, policy around publication of Certificate Revocation Lists (CRLs), renewal periods, etc. should be well defined.

Another approach that has been successful with Direct Trust for over ten years is to allow each QHIN to maintain its own root certificates, and then manage a trust bundle of approved CAs that would be designated as the authority, instead of requiring QHINs to create and manage an intermediate CA to the TEFCA Root CA. Direct Trust currently manages this process for the Direct Network and could easily be subcontracted to manage the Trust Bundle and RA/CA accreditation process.

General Requirements

1. Version Compatibility – The baseline version should be defined at FHIR 4.0.1 so that facilitated FHIR doesn’t need to consider STU3.

Use Cases/Workflows

1. It is assumed but not clearly stated in the IG Use Cases section that IAS queries must use the same patient demographics used in the access token request for executing the patient search in 4.2.2. As stated, the requirement is placed on the FHIR query initiator to pass the same demographics and to set onlyCertainMatches to TRUE. We request that the Responding Actor utilize the original demographics from the token, as well as set onlyCertainMatches to TRUE for any patient discovery query that utilizes the IAS permitted purpose.
 
2. In Section 3.2 of the FHIR IG, it states that “[q]ueries for information MUST include all demographic parameters that are available and can be sent and are not constrained by applicable law.” These demographics also must be normalized to USCDI standards.  This language suggests that for matching purposes, queries could include all demographics available to the FHIR Query Initiator that are part of the USCDI.  However, in section 5.2.6, it states that the user metadata submitted with the query must correspond to the verified identity attributes (such as those attributes verified by a credentialing service provider consistent with NIST level of assurance 2 for identity proofing. We acknowledge that the demographic attributes verified as part of identity proofing should be the version of those attributes utilized for patient matching in the context of IAS.  However, once a patient has been identity proofed to a high standard (IAL2), there is high value in utilizing additional available demographic attributes that may not be able to be validated (and are not typically utilized for achieving NIST level 2 identity proofing) but are part of the USCDI and could be helpful in achieving a unique match. it’s hard to see what the risks are to utilizing these additional attributes to achieve a match once the patient has been strongly identity proofed. Matching specifications should be aimed at achieving matching accuracy; reliably establishing identity is a separate process.
 
Infrastructure
 
1. 5.2.3.2 states that “When an Operator includes a TEFCA Basic App Certification in its registration request, an Authorization Server MAY reject subsequent access token requests by this app that contain authorization metadata that does not match the corresponding values declared in the certification.” Having this as only a “MAY” reject access will lead to ambiguous errors.  We suggest that Basic App Certification extension either (1) be defined to which values SHALL be present in registration, and which values MUST be included in the subsequent access requests, or (2) Basic App Certification extension values that are included in subsequent access requests SHALL over-ride values submitted in the Basic App Certification extension during registration.
[Gene]
2. 5.2.6 states that the Responding Actor SHALL limit the patient data accessible using the token granted with IAS permitted purpose, but there is no guidance on how to tie the token back to these demographics once the token is granted and used for the patient query.
 
Additional Comments and Considerations
 
1. 5.2.3.2 states that “When an Operator includes a TEFCA Basic App Certification in its registration request, an Authorization Server MAY reject subsequent access token requests by this app that contain authorization metadata that does not match the corresponding values declared in the certification.” Having this as only a “MAY” reject access will lead to ambiguous errors.  We suggest that Basic App Certification extension either (1) be defined to which values SHALL be present in registration, and which values MUST be included in the subsequent access requests, or (2) Basic App Certification extension values that are included in subsequent access requests SHALL over-ride values submitted in the Basic App Certification extension during registration.
[Gene]
2. 5.2.6 states that the Responding Actor SHALL limit the patient data accessible using the token granted with IAS permitted purpose, but there is no guidance on how to tie the token back to these demographics once the token is granted and used for the patient query.
 

Certificates

Leaning towards a facilitated FHIR exchange. We would expect the QHIN to have an agreement with one CA from an approved list.

General Requirements

We would like clarity on why all actors need to support the $match operation. Given that each facility is connected to a QHIN that already maintains a patient directory and/or MPI, which is in turn queried/exchanged with the RCE directory, the query initiator would already know the identifier for the patient when the QHIN provides the FHIR server URL. Is there any expectation that the initiator then again queries the responder for matches? If so, why? And why are potential matches to be expected?

Appendix B

The description of the public health appears to assert that public health only has the authority to collect data during a public health emergency. It should be clear that public health routinely collects data from providers without the declaration of an emergency.
Many public health agencies provide clinical services. In that case assertion should follow the pattern for clinical care.
Suggested edit would be:
Requirements for the FHIR: Query Initiator Public Health. The FHIR Query Initiator for a public health authority must be making its request for information in the context of a its Public Health authority according to local, state, tribal or territorial law or regulation. The specific patient who is the subject of the query must be reasonably be associated with a case of a reportable condition or a case under investigation. These are typical, core, public health scenarios are not associated with clinical care.

Additional Feedback and Considerations

We note the absence of a push design pattern. Many public health scenarios require a provider (hospital, doctor, lab) to send an unsolicited message. The push use case. While not suggesting current push processes be replaced, it would be appropriate to architect for such a design pattern. Note these could be new, native RESTful PUT or POST scenarios to deliver resources to the receiver (public health). There may be implementation reasons for using the FHIR messaging or documents, even using the existing standards with the FHIR “transport” and security frameworks, but we recognize the low return on investment for such a move at this time.

Lastly, we understand “push” support may be further out on the QHIN implementation timeline. But we would like to see it referenced as it would be nice to know it is important as a future option and we would prefer to avoid omission.

Certificates

Our organization, Washington DOH is expecting to be a sub-participant as a Public Health agency. Being a end user that uses the services of a State designated HIE (as a participant) that handles the certificates on DOH’s behalf, the queries received by the Public Health agency will be brokered by the HIE.

Regarding the question of the two approaches under consideration for certificate management, it may be better to have the QHINs maintain their own Certificate Authority. The reason for a preference over an agreement with one CA from an approved list is the accountability the QHIN has with their own Authority and the comparative ease of testing/troubleshooting as compared to dealing with a third part contracted authority.

Use Cases/Workflows

4.2.2. Nominal Flow:
1. Standardizing Capability Statement of the responding server – is it necessary to specify the capabilities of a FHIR server so that it supports all common use cases (Capability Statement as a common denominator of all use cases considered by TEFCA based exchanges)?

The Capability Statement and thus the scopes of the transactions supported are based upon respective clinical services provided by a health facility.

Infrastructure

5.2.1.2 Issuance:
This item mentions about identification of multiple applications by same operator using the same client_id. Is there a mechanism to track this in the log so that the identification could be made without opening/using the payload bundle, if needed?

Table 1: Required Authorization Server Metadata:
“scopes_supported” – It would be good to make it ‘required’ (instead of recommended) and the scopes and capability statement are aligned with the specialty services provided at the health facility (also see above comment in “Use Cases/Workflows”). Would there be a list/directory of health care services provided by a certain specialty center and an algorithm to match the respective scope so that only relevant search results are displayed for example in the FHIR FAST Directories?

Stay Connected

Complete the form below and join our mailing list.