Stay Connected
Complete the form below and join our mailing list.
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
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
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.
Certificates
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.
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
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?
Complete the form below and join our mailing list.