Draft QHIN Technical Framework Feedback Comments

View Submission File (PDF)

Comments:

• In the RLS definition, it would be helpful to include the level of “authoritativeness.”  It is my understanding that each  QHIN must have an RLS that can respond to demographic queries for all of its participants or flow-down XCPD queries to each of the QHIN nodes each time (and not limit the scope to a region or specific geographies of its participants).
• “Push” is import to include as an exchange modality to support many use cases including sending alerts or sending data to public health.
• Regarding the Instance Access Consent, I suggest removing the “Manual Review” concept and adding details on an approach for one specific access control scenario: a HIPAA Release of Information. This could be used as a detailed model for how to implement Instance Access Consent end-to-end, and is truly uniform across all of the states. Then, more complex Instance Access Consent models could evolve with time for handling sensitive data or any state-specific laws.
• Yes, the QTF should include “Push” / Message delivery as an exchange modality to support many use cases including sending alerts or sending data to public health. Choosing XCDR also makes sense for QHIN-to-QHIN (and optionally QHIN-to-QHIN_Participant for end-to-end acknowledgements (even if the intra-QHIN exchanges traverse into a DIRECT spec).

View Submission File (PDF)

Comments:

• I have commented expecting that Page 5, paragraph 4, stated the goal of the specification. This paragraph expressly states the goal is QHIN-to-QHIN and clearly states as out of scope what happens inside the QHINs.
  I have learned, at deadline, that this was not the goal of the paper. I have learned that the goal is explicitly not this goal. That the goal was to express how a this interaction was supported with a depth of 2+. This very much changes the perspective. As a depth of 2+ is explicitly not scoped by IHE, as the problem involves solving for a much harder problem of “routing”. This was recognized by IHE and explicitly left unresolved to enable the communities to experiment. The solution that simple networks of networks could be addressed with simple static routing tables, much like the internet was in the first decades.
  The expectation was that when the problem became important, that a new-work-item would be brought to IHE, and that the IHE body could create a consensus specification. The lack of this routing consensus specification is not a failure to exist, it is a failure of those in need from bringing their need to IHE.
• “Today there are two viable solutions that are both not optimal. The Direct-Project, and IHE-XDR. Both of these should be encouraged within the communities and use-cases for which they are used. New use-cases can choose which of these best fits their need, likely based on their existing infrastructure. Those that already support Direct-Project will likely choose to expand use of Direct-Project. Those that have XCA/XDR capability will likely choose to expand use of XDR. The only conflict is the recipients of these messages will need to either guide THEIR community on the solution to use, or support both.Given that both of these are not optimal; the move to use FHIR RESTful push seems like a good place to focus first on the use of FHIR REST. There are solutions for FHIR RESTful push defind in the IHE-MHD implementation guide, and the model there is aligned with the XDS/XCA/XDR/XDM model. Use of this in a Point-to-Point push should be seen as a simple alternative over the two alternatives currently available.Given the QTF identified directory to enable endpoint discovery, and the more simple model provided by IHE-MHD push (using FHIR), there should be no need for Intermediaries. Where there is consideration of intermediaries, one needs to question the value being provided by the intermediary vs the complexity in routing, security, authenticity, provenance, integrity, and availably they bring forward. The fundimentals of http REST are built upon the Internet and http protocols that are world-wide, and the security of TLS that is proven.”
• “Three distinct points on this question1. The current TEFCA solution can carry FHIR-Documents with zero modification of the existing infrastructure. Not just FHIR-Documents, but any kind of content. The metadat model defined in IHE is content agnostic, focusing on use of mime-type, format-code, and fundimentals of byte-stream. The metadata focuses on enabling Privacy, Discoverability, Integrity, Provenance, and Identity. The metadat model invisioned many kinds of documents, and this is why FHIR-Documents are supported by the foundation. Further the metadata model enables relationships between different encodings of the same content so that a Query Initiator can determine that multiple entries are covering the same content with different formats. In this way a Medical Summary could be published in both C-CDA and FHIR-Document; giving the document consuming system the flexibility to choose their preferred format. — https://healthcaresecprivacy.blogspot.com/2021/08/fhir-data-in-existing-nationwide-health.html2. The IHE-MHD implementation guide provides for a FHIR based API to the technology foundation usied in TEFCA. The use of the IHE-MHD implementation guide would enable new participants to join the nationwide network fully while they use the more modern FHIR technology stack for discovery, query, and retrieve. This solution does not affect the privacy, authentication, provenance, integrity, or availability of the content; as the solutions are all focused on making patient and metadata accessible, while preserving and being agnostic to the document content.Combined use of 1 and 2 would enable the document consumer actor to not only use FHIR as the API, but also retrieve FHIR as the document content.3. The IHE has also defined an access methodology that breaks down the documents into FHIR Resource level entities. The IHE mXDE and QEDm offer this solution to make the document consumer even more easy. The solution makes sure to give provenance recognition to any documents that were used as source for the FHIR Resource level entities. Where multiple documents contained the entity, multiple Provenance records would exist pointing at the document. The Provenance can be used to retrieve the original document so that the context of the entity information can be understood within the document published.For further details on ALL of these points, see the IHE whitepaper https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html”
•  

Comments:

Directory services must be public information. It should not be required to agree to anything to get this information. This is critical for epidemiological research and for healthcare outcomes research. The FHIR directory services, should resolve to both FHIR and Direct Address endpoints and your document should require Direct Address endpoints explicitly.

Both FHIR and Direct were designed to work as open Internet protocols. Without seeing the directory information publicly it is not possible for newcomers to the network to understand what the benefit of the network is. Nor is it possible for watch-dog data journalists (like myself) to use the public access to find fundamental flaws in the directory services, including the fact that many providers are still reluctant to publish these results. In order for “name and shame” to work to ensure that the network is healthy, we must be able to see clearly into Directory Services.

NPPES will be hosting FHIR and Direct endpoints, and this *will* become the authoritative directory for this information. If the directory services are publicly available, then it will be possible to ensure that addresses stay in sync. Without this, there will be an irreconcilable out-of-sync that will be ongoing.

Please do not dismiss this suggestion as “insecure” The Direct protocol and FHIR protocols are MORE secure to share publicly than physical addresses, fax numbers and phone numbers. If we ever want to see Fax replaced for health information exchange then it must be as easy to find a doctors digital endpoint as it is to find their fax number. The people who are arguing for privacy and our cybersecurity concerns here are mis-informed about the design of the underlying protocols.

Please get this right. This is what makes the health information exchange network ultimately accessible for patients in the end. To do otherwise is to create a secrecy “tax” that will only apply to patient provider communications in the end.

You should not need to be a participant or subparticipant to get access to certain information: i.e. directory services.

Comments:

• I note the statement on Page 24 of the overview presentation
  OAuth not designed for multi-hop.
  • Originating user unknown to responder.

  I wish to draw your attention to RFC 8693 (https://datatracker.ietf.org/doc/html/rfc8693) that provides a standard for recording multi-hop security transactions with either delegation or impersonation semantics. This standard is not fully supported by all vendors, but support is improving.

  The following, from the RFC, shows the mechanism for indicating that the token has been “exchanged” and the previous subject is recorded.

  {
  “aud”:”https://service26.example.com”,
  “iss”:”https://issuer.example.com”,
  “exp”:1443904100,
  “nbf”:1443904000,
  “sub”:”user@example.com”,
  “act”:
  {
  “sub”:”https://service16.example.com”,
  “act”:
  {
  “sub”:”https://service77.example.com”
  }
  }
  }

View Submission File (PDF)

Comments:

• In the Nominal Flow, there seems to be an indication that a QHIN itself is not consolidating XCPD queries and responding back to the Requesting QHIN. We recommend the QTF be clear in their expectations of a QHIN, in that a QHIN is expected to consolidate XCPD queries and provide a response back to the Requesting QHIN regardless of whether or not it maintains an eMPI/RLS.
• Assumption 1b states: “The ability to provide information in each transaction that identifies security and permission details about the request such as: who is requesting, what their role is, and what their purpose is”. 
  • This assumption seems to be a carryover from the Exchange Scenarios section.  For message delivery, no one is requesting the message as this is an unsolicited push transaction. Therefore, the transaction cannot include an identification of the “who” that is requesting, since there is no requester.  The QTF should clarify that the transaction identifies exactly who is sending the message and what their role is. Additionally, the QTF should clarify if the purpose identified should be aligned with the HIPAA purpose (treatment, payment, operations) via use of a coded value or if the purpose should be used to communicate the context of the pushed message (i.e., referral, care coordination, prior authorization, etc.)
• One of the Preconditions states: “The RCE Directory includes the organization name(s), and Home CommunityID(s) for all current Participant and Subparticipants who have chosen to participate as a Responding Source of QHIN Message Delivery. Each Participant and Subparticipant is matched to the appropriate QHIN. Each QHIN maintains an up-to-date copy of the RCE Directory”.
  • This seems to indicate that organizations can choose whether or not to accept unsolicited messages, which is a scenario we support. However, the current QTF does not specify whether this is to be a global opt-out from message delivery, or if there are options for panel rosters or identification of specific sites from whom they do wish to receive messages. If additional details about this scenario will be specified in the forthcoming RCE Directory specification, this fact should be noted in the QTF.
  • We ask that the RCE clarify for message delivery if the intention is for subscribers to publish their panel rosters to the RCE Directory, or a subscription list, or if the sender would need to publish their panel roster?  
• We ask for clarification as to if the topic of message delivery is agnostic as to the purpose of use, or if a receiver could choose which purpose of use they wish to receive messages for ( i.e., for treatment only versus TPO).
• Connectivity and Remediation
  o We ask for clarification as to whether there will be a connection validation, and/or certification, and /or attestation? Will this be part of the onboarding process?  Will certification/validation be periodic or triggered by a connectivity failure? 
  • QTF-029 If the Query Source does not indicate specific providers or facilities to be queried, all QHINs SHOULD be queried using provided demographics. 
  o We recommend changing this statement to a “MUST”.  If the query source did not indicate specific providers or facilities to be queried (directed query) it is an indication that they do not know where the data exists.  With no RLS between QHINs, the only way to return the data would be if all QHINs are queried.  Modifying this to a MUST statement ensures broadcast query functionality to ensure data is returned when the data holder is unknown to the query source.
  • QTF-039 If a Document Retrieve response is not in C-CDA 2.1 format, QHINs MUST convert the response to C-CDA 2.1 format except where consistent with QTF-043 and QTF-040. 
  o We are supportive of the C-CDA 2.1 format being the expected exchange format. However, we recommend that QTF-039 be changed from a MUST to a SHOULD statement. Many of the organizations who will be QHINs do not currently touch nor have plans to touch the clinical data itself, rather, they provide services that appropriately route that data to the right places.  Making this statement a MUST would require QHINs to do significant work to turn data formats (sometimes pdfs) into C-CDAs.  The two exceptions for the requested format or legal requirements is not sufficient and therefore the statement should be changed to a SHOULD.  QHINs who have the tools in place and wish to provide a data translation service could do so, but QHINs would not be required to fix the data format issues of their participants and sub-participants.
  • QTF-042 All C-CDA 2.1 format documents adhering to the Continuity of Care Document template SHOULD include all appropriate data classes and elements from The United States Core Data for Interoperability (USCDI) V1 prior to January 1, 2023, and MUST include all appropriate data classes and elements from USCDI V1 after January 1, 2023.22 The RCE will determine ongoing requirements of using newer versions of the USCDI as they are released. 
  o We recommend that this requirement be modified to a MUST for use of USCDI v1 prior to January 1, 2023.  The USCDI is already the required data set under the ONC Information Blocking regulation and is available in the C-CDA 2.1 templates.  We have seen many EHR vendors fail to update their summary of care documents within network structures (some vendors are still sending C32s) and allowing this to be a SHOULD instead of a MUST will only allow that to continue.  There is not an apparent technical reason why the USCDI v1 cannot be required at “go-live”.
  o Additionally, while the CCD template is mentioned, the QTF does not identify which template IDs must be supported.  We recommend adding a statement that indicates if a QHIN MUST or SHOULD support all of the template IDs in the C-CDA 2.1 structure.
  Message Delivery
  o The Message Delivery section does not indicate any particular payloads that QHINs MUST or SHOULD support.  We recommend that the RCE clarify whether Message Delivery is payload agnostic, or if QHINs are expected to transform any of the payloads to the C-CDA 2.1 structure.
   
  Patient Identity Resolution and Record Location
  o We understand and appreciate that the RCE is attempting not to dictate the internal technology structure of QHINs, enabling organizations to participate who otherwise might not.  We also understand the goal is to use SLAs to ensure that response times are met by QHINs that do not have a centralized MPI/RLS service.  However, we are deeply concerned about the ability of the TEFCA to function without accurate patient matching and record location between QHINs.  Currently, we are seeing high failure rates of matching between HINs who are exchanging with each other, particularly when one of the HINs does not have centralized MPI and RLS functions.  If QHINs cannot achieve high match rates when data is requested from another QHIN, the value of TEFCA will be significantly decreased and organizations will be able to realize the benefit of joining only one network.  We offer the following recommendations to address the risks associated with poor patient matching.
   If the QTF does not require centralized MPI/RLS functions, then the SLAs referenced in QTF-067 should specify the following: a response rate of P95 <= 5 seconds measured over a rolling 30 day window and P99.5 <= 10 seconds over the same period; availability of >= 99.9% availability, defined as: 100 * 1 – (seconds down/302,400 (seconds in 30 days) + (errors + timeouts)/total transactions in 30 days). Additionally, the SLAs should specify that a situation where no patient record is located due to internal Participant timeouts (as a response to the Requesting QHIN) is a scenario that would in fact not meet the corresponding SLAs.  Otherwise a QHIN with a decentralized model could continuously reply with no patient found messages and still meet the SLAs.
   The SLAs should set match rates that each QHIN must meet.  We understand that there is a lack of a single national standard for matching accuracy; however, this is an excellent opportunity to set such a standard.
   We recommend that the RCE add two additional requirements to the Patient Identity section from the Sequoia Project’s Framework for Patient Identity Management: 1) Both Responding QHIN and Initiating QHIN MUST use case insensitive matching; and 2) Responding QHIN MUST NOT use exact character-by-character matching.  For item two, the statement could be use case specific, allowing for a tighter match for Individual Access.
  o We recommend that ONC specify a patient match algorithm (define deterministic and probabilistic and specify what is allowed) and state that any algorithm more restrictive than the defined standard is “unreasonable”. This algorithm would become a safe harbor of sorts, particularly for individual access where the risk of a breach for an incorrect match is higher.  We are concerned that without this specificity, individual access may not function between QHINs, limiting the value of TEFCA.  One suggested first approach would be to define “deterministic” and require that no one can match with a logic more restrictive than this version of deterministic across any use case.
• QTF-082 A Responding Source SHALL send only one identifier for a patient in response to a patient discovery query. 
  o We recommend modifying this requirement.  For treatment, payment, operations, and even public health use cases, returning more than one identifier when more than one match is within the matching threshold can be valuable for resolving identities. If more than one identifier is returned, the query initiator can review the returned data and determine if one or more than one of the returned identities are in fact the individual.  This can enable systems to remove duplicates that may exist in their data.  For Individual Access, returning more than one identifier can be problematic.  Consequently, we recommend this statement be modified to apply to specific Purposes of Use, (e.g., Individual Access at a minimum).  For other Purposes of Use, Responding Sources should be encouraged to return more than one identifier if more than one identity falls within the matching thresholds.
  • Since the QTF allows QHINs to delegate the patient identity resolution function to Participant(s), we recommend adding the following requirement: “A Responding Source with a delegated patient identity resolution function MUST be able to respond to a QHIN Query within any service-level agreement (SLA) requirements adopted by the RCE”.
  o We recommend the SLAs for Responding Sources be set to the same level as the QHIN SLAs for this function, which we have noted above.  We also recommend the SLAs specify that timeouts as a response to the Requesting QHIN do not meet the SLAs, unless experiencing a downtime event or regular maintenance. 
  • While the QTF includes timing requirements for QHINs to update the RCE Directory, there is no corresponding flow down to a QHIN’s Participants and Subparticipants that require them to update the QHIN directory, so the RCE Directory can be maintained.  If the QHIN’s Participants have no requirements to update them, then the QHIN will be unable to update the RCE Directory with any “fresh” information.  We recommend adding flow down clauses to this section requiring Participants to update their QHIN on a set schedule.
• The RCE proposed three options for QHIN Message Delivery and asked for feedback on which option should be chosen: Option 1: Require “QHIN Message Delivery” modality in QTF using the Integrating the Health Care Enterprise (IHE) Cross-Community Document Reliable Interchange (XCDR) profile with a future transition to FHIR; or Option 2: Defer “QHIN Message Delivery” from QTF until a FHIR-based solution is readily available; or Option 3: Include “QHIN Message Delivery” using XCDR as optional in QTF until a FHIR-based solution is readily available.
  • With the current timeline of QHINs onboarding at the beginning of calendar year 2022, we recommend Option 2 as the best path forward.  While a small number of organizations who may be QHINs are currently able to support XCDR for message delivery, the majority of organizations do not support this today and would need significant time to build such delivery.  Since a number of other options exist for message delivery (Direct, CMS required ADT notifications, etc.) there is not a significant gap in the market that must be addressed quickly with an older standard, rather than waiting for the new standard to be available.

View Submission File (PDF)

View Submission File (PDF)

Comments:

I am specifically providing feedback on the question of including message delivery in the QTF. It should NOT at this time. Wait for the FHIR based solution to arrive. REASON: adopting, then migrating from one technology to another is a troublesome and costly approach. Better to implement ONCE on the FHIR environment. The Amish have a saying: “Three moves is as good as a fire!”. Do not be ignorant of this wisdom.

Comments:

Comments:

• As an alternative to broadcast and RLS options, the QTF should permit geospatial queries. It’s well known that most healthcare is provided locally to the patient. Queries have a point of diminishing returns outside of a 50 mile radius of the patient’s primary residence. The QTF should allow organizations the ability to query a geographical region containing the patient’s primary address as an alternative to broadcast or RLS queries. This could, perhaps, be augmented by a QTF policy indicating that periodically a QHIN should broadcast a query to all Participants in that QHIN to detect care provided outside the patients’ home region.Additional mandatory behaviors are needed in the QTF to ensure patient access. At this time, consumer-facing applications are proving to be near-impossible to deploy for the very common scenario where a single patient needs to access multiple EMRs. EMR vendors and their customers rightly fear impermissible disclosures and hence require each consumer to have an account at each EMR and require an interactive login challenge for each session. This has the chilling effect of making multi-EMR consumer portals unusable since data disclosers require one login, per EMR, connected to the portal, each time the portal is accessed. The consumer experience is that each time they attempt to access their multi-EMR portal, they are faced with multiple logins (one per data discloser).Instead, the QTF should mandate that all data disclosers a) require a confirmed account, with an OAuth2 end-user challenge, ONCE for initial access; b) use an OAuth2 refresh token for the next 12 months which does not involve a direct end-user authentication request; c) only allow the data discloser to challenge the consumer for authentication if something significant has changed such as a new device or a new portal vendor; and d) require an data discloser end-user facing authentication challenge once after 12 months have elapsed since the last end-user facing challenge.
• The QTF needs additional specificity regarding exception handling approaches. In order for the overall QTF to be robust and reliable, each component of the QTF needs to be robust which includes the ability for the component to detect and communicate precise errors and exceptions. This is critically important so that automated corrective actions, manual diagnostic actions, and high-precision operational logs, can be implemented in response to such exceptions. However, if the error is obscured or imprecise, then the QHIN won’t know what actions to take to recover from the exception. The QTF should solicit feedback from prospective QHINs and created an enumerated list of exceptions to be conveyed between QHINs, and such exceptions should have a unique programmatically processable code and a corresponding unique human-readable text component.
• The QTF should mandate support for the Access Consent Policies (ACP) capability as a roadmap capability that QHINs and their Participants can deploy after 24 months. This capability, which is used in the eHealth Exchange network by the Social Security Administration, may not be mature enough or interoperable for use by other initiating organizations at this time. If the QTF mandates support for this issue, it might contradict the QTF’s stated goal of using mature technologies, and might result in interoperability problems until support for ACP matures. While we do see value in ACP, there are contradictory approaches that need to be reconciled (eg perhaps eHealth Exchange ACP v Carequality) and then time for the reconciled approaches to be developed by vendors and deployed by customers.The QTF overall needs more specificity to be implementable and should be revised accordingly. When the base standard cited by the QTF is insufficiently constrained, the QTF should enumerate all attributes being profiled with the XPATH of each attribute, its allowable values and code system, and its optionality, cardinality and/or conditional nature. For example, the QTF statement “QTF-023 All XUA and SAML metadata must be consistent. Where discrepancies exist, they must be resolved prior to the next step in the workflow.” is unimplementable as written due to ambiguity and leaves a number of questions for implementers to resolve on their own, likely leading to different interpretations and hence gaps in interoperability. Questions arise such as “what is the definition of the word ‘consistent’?” and “how are those undefined inconstancies identified and ‘resolved’?”. Another example is that in many places the QTF inserts tables, such as QTF-087 without citing the source, or the body that will be curating the table after initial adoption of QTF.Test cases should be specified in the QTF as conformance statements. Consistent with our recommendation that the QTF needs more precision to be implementable, the QTF should have embedded conformance statements which are programmatically implementable. In addition the QTF should define the operations, content, security, test cases, methods of interaction, and more related to the “RCE Test Instance”.The QTF should consistently specify the use of IHE ATNA logging for all transactions between organizational boundaries. Currently, the logging requirements of the QTF are inconsistent and should be clarified (and simplified) to require implementation of the mature and widely-supported IHE ATNA logging profile. The IHE ATNA logging design was informed by current USA federal regulatory requirements, including an accounting of disclosures. The QTF should clarify that all transaction logs between organizational boundaries should not log clinical data. Logging clinical data is generally unneeded for operations and introduces massive risk to the QTF.The QTF should reference the ONC Project US@ instead of USPS Publication 28. USPS Publication 28 was intended, as per USPS staff, to meet the requirements of then-current USPS postal service data processing equipment. It is lossy (for example, it requires ‘folding’ of special characters) and yet it is under constrained in other areas. Publication 28 was not intended to be an interoperability standard for healthcare and it should not be used. Instead, the ONC “US Address” project, abbreviated as “US@” should be normatively referenced by the QTF instead, as it is intended as a lossless healthcare interoperability standard and is hence much more consistent with the purposes of the QTF.The QTF should recognize allow older and newer content standards instead of requiring a single version of C-CDA. This should be negotiable between the orgs. C-CDA 2.1 is about to become obsolete (version 2.2 is now being developed) and will likely be ready for adoption in several months. Also, not all valuable documents are in C-CDA format, such as a scanned cardiogram, or a scanned patient consent. The C-CDA 2.1 requirement may have the unintended effect of disallowing valuable data that was already created in other formats from be exchanged via the QTF such as HITSP C32 documents created years ago.Aggregated responses are not implemented or implementable as defined in the QTF. As previously commented by the eHealth Exchange, neither XCPD aggregated responses are supported by the vast majority of technologies (such as EMRs or HIEs) available today. This requirement will require significant development work. The eHealth Exchange already supports XCPD aggregated response for its “Hub” product, but has found that no other organizations support it today in production. As currently specified in the QTF, XCA aggregated responses are not supported by the base IHE standards and hence are unimplementable at this time. Note that aggregation of XCPD and XCA should consider: a) complete successful aggregated responses, b) partially successful aggregated responses, and c) unsuccessful aggregated responses.The QTF should change the push transaction from ITI-80 to ITI-41. ITI-80 is immature and not commonly supported, whereas ITI-41 is both mature and widely supported. The QTF states its objective is to use mature technologies, and ITI-80’s adoption contracts that QTF objective. The IHE committee, including the authors of ITI-80, are considering dropping ITI-80 as being duplicative of ITI-41. ITI-41 with profiling of the intended recipient apex can express the same values as ITI-80. ITI-80 is widely regarded as a mistake and should not be further considered by the QTF.The QTF should include a funding model for the QHINs to operate very expensive MPI/RLS systems. The current draft of the QTF requires broadcast or support of an MPI/RLS. Operating a large scale MPI/RLS is costly from both the initial technology deployment perspective as well as from an on-going operational perspective. The QTF should provide a financial incentive for QHINs to deploy and operate these capabilities.The QTF should roadmap a standard library of test patients to be loaded into all systems. Currently identifying test patients in Participant systems is an expensive and manual process. The QTF should create a library of 5 to 10 test patients that are required to be available in all Participant systems. Some Participants may have policies preventing deployment of test patients, so the QTF should instruct CMS and payors to automatically detect these test patients and allow Participants to host them with no risk of potential penalty. Given that it will take time for test patient policies to be changed, the QTF should allow an adequate amount of time for adoption such as 24 months. The library of test patients should use standard names that leverage test patient name best practices, and are required to be available for queries (opted-in), and have a standardized C-CDA document associated with the test patient.The QTF should allow for the fact that some QHINs do not have patient data repositories, such as the eHealth Exchange, and only act as proxies for their associated Participants.The QTF should relax reporting requirements which are currently onerous. The QTF currently mandates highly burdensome reporting requirements which will require significant development activities. The QTF should convene an industry-wide reporting workgroup to refine and define a less-burdensome approach which still provides the RCE and the ONC with sufficient operational insight into the QTF. For example, the reports could be made quarterly instead of monthly.
• The RCE should explicitly state that it assumes the responsibility of keeping the RCE directory up-to-date and quality-assured. As currently defined in the QTF draft 2, QHINs will have a heavy dependency on the RCE directory. But if the RCE directory becomes inaccurate, out-of-date, or stale, then it will cause a QHINs to be unable to achieve their mandates under the QTF. Maintaining a national-scale directory is a significant undertaking. One benefit of the QTF approach is that we, as a country, can leverage the RCE directory, provided that such a directory is maintained to high standards.The RCE maintains their directory in such a way that QHINs only need to synchronize with the RCE directory; restating another way QHINs don’t need to obtain any additional information from other directories like NPES, or VHD. This includes the RCE keeping the directory up-to-date, populated with NPIs, current and historical organization names, and organizational relationships. The RCE-maintained directory should use globally unique identifiers for each organization to avoid the need for imprecise “fuzzy” matching of organizational entries. This approach should take into account tracking organizations as they merge, are devested, and otherwise change over time.The RCE should also deploy an efficient means for QHINs to detect updates to the directory.The current directory state transition model conflicts with the common industry use of the ‘active’ flag. Overloading the meaning of ‘active’ from ‘logically deleted’ to reflect a Participant’s onboarding state is unexpected and will require development work from all directory clients and server technologies. It will also have likely unintended workflow implications.

View Submission File (PDF)

View Submission File (PDF)

View Submission File (PDF)

Comments:

• (ACP): Policies that may influence access control decisions and which can be referenced in queries-This is a generic definition that does not specify enough informationIndividual Access Services needs to be defined and approved. Please ensure it is included in the final Common Agreement.
• Why is the return message “being routed through any intermediary Participant and Subparticipant, as necessary?” The possibility of error increases with each pass through.
• ‘Document presently lists USCDI V1 update to USCDI V2 on page 28 and 35’ATNA- according to the website requires only local user authentication. The profile allows each secure node to use the access control technology of its choice to authenticate users.Add HL7 before FHIR p.36 and 40.
• ‘The FEHRM recognizes that TEFCA adopted existing SOAP-based HIE profile functionality to leverage existing HIE networks, business practices and technical expertise. The FEHRM is concerned by non-existence of a roadmap that leverages HIE C-CDA multi-hop and FHIR resources point-to-point capabilities but also understands that the question of whether TEFCA changes to accommodate FHIR or whether FHIR changes to accommodate TEFCA remains unknown at this time.
   
  Reliable, unique patient matching is required for trusted network efficacy. While views surrounding national patient identifiers are highly debated, uniform patient identity remains a factor in patient matching and optimization. The FEHRM considers no resolution around patient matching standardization and methodology as safety, quality and administrative risks.
   
  Although USCDI advances interoperability, additional work needs to be done to ensure semantic interoperability.
   
  The FEHRM believes that in the interest of semantic interoperability TEFCA and QTF should further: 
  o Apply Interoperability Standards Advisory (ISA) recommendations that ONC provides a common set of terminology definitions to USCDI elements to remove ambiguity regarding its usage.
  o Define value sets, which should remove further ambiguity by providing element examples in-context.
• ‘The QTF defines audit logs and their use, e.g., “After retrieving the relevant documents, the initiating QHIN transmits them back to the HIE that submitted Query Solicitation, which then transmits them to the provider. Each QHIN involved in the query maintains audit logs of all activities and transactions the QHIN performed in the process of resolving the query, according to the IHE Audit Trail and Node Authentication (ATNA) profile.”The QTF should also define the circumstances under which a Participant may request audit logs from the QHIN and the timeframe alloted to the QHIN to respond to audit requests.
• Defense Health Agency (DHA)-Interim Procedures Memo 18-018, Physical Custody and Control of the DOD Health Record designates DOD Health Records as the property of the U.S. Government and not the property of the Service or family member, although the patient has the right to a copy.In addition to ONC’s current consideration of SAMSHA Consent2Share sensitivity value sets and labeling regarding minors, in order to protect of national interests, the FEHRM asks ONC to expand the security labeling to designate the health information of Service members.Please clarify whether the Recognized Coordinating Entity (RCE) will expect each organization operating as part of the Federal EHR (DOD/VA/Coast Guard) to publish a single or separate Notice of Privacy Practices or whether they can publish a single NoPP.The RCE should allow the FEHRM to sign the TEFCA on behalf of all the organizations that use the federal EHR if the organizations decide to do so.If possible, the RCE should explain the relationship of the TEFCA and the DURSA and whether the TEFCA will eventually replace the DURSA. The RCE should also state its view regarding other types of agreements governing HIEs.The FEHRM is concerned that in meeting these response times, QHINs may miss unidentified patient records due to the higher volume of transactions. QHINs will have to provide a service in a national exchange despite TEFCA’s well-designed architecture, which segments QHIN’s traffic to that intended for it and its partners.
• The FEHRM recommends that QHIN Message Delivery not be required by the QTF until a FHIR-based solution is available
• In Overview-‘Name of the President who signs a law is irrelevant.The phrase “Qualified Health Information Network (QHIN)” is undefinedThe terms “Participant” and “Subparticipant” are used as terms of art and should be defined
• Authorization & Exchange Purpose, Table 7 The codes for “Public Health”, “Individual Access Services” and “Benefits Determination” appear to obviate the need for the code “Operations” Eliminate duplicative exchange purpose code
   
  Audting, footnote 25 States that “There will be an SOP about records retention and storage” without providing a projected date for publication of this SOP Insert projected date for publication of records retention SOP
•  

Comments:

• QTF-15 – suggest to make the mandatory and optional SAML attributes more clearly defined by adding (or refencing) a table that defines each XUA SAML attribute, it possible content and optionality. Possible define/suggest (coded) values for Subject-Role and standardized organization names.
  QTF-16 – I am assuming that the Auth-Consent is the way to allow a source to convey the consent policy applicatie to the request. If this is correct the text in the previous chapters may be updated to reflect this. Question: what behaviour of the responding gateway is to be expected when not Auth-Consent is included. Do local consent policy take precedence over any remote policy that are included in the XUA token?
  QTF-21 – suggest to include a coded entry to indicate request in “trauma” situations. This may be helpful for the receiving gateway to decide whether or not to treat such request different from requests made for “normal” treatments. Have you consider sticking to the ISO 14265 defined purpose of use codes?In the XCPD section it is suggested that an initiating QHIN can send a targeted XCPD query to an organization in the responding QHIN. There doesn’t seem to be a corresponding requirement in the QTF-25 to QTF-36 list.QDT-39 – does this requirement mean that plain text and PDF document also must be converted to C-CDA documents?QTF-77 Since IHE ATNA is the preferred audit option it would be good to include a table maps the mandatory audit information to ATNA audit message elementsQTF-087 (also see previous comment with ATF 16). How does this list of consent codes map to XUA? Seems a bit strange to include a code that looks like a formatCode or typeCode instead of referencing a consent policy OID.
• Specific to the Message Delivery Scenario, have you considered only sending a notification of availability to the target responding QHIN and allowing the responding QHIN to determine whether or not to use an XCA transaction to retrieve the patient summary document if it identifies an recipient in its internal network that should receive a copy of the summary document? The benefit of sending the notification only is that less patient sensitive data is shared with responding QHINs that may not be “interested” in the summary. The notification message can be a FHIR notification based message that public FHIR end-point published by the responding QHIN that does not require a mTLS connection to be setup.
• Definitions on how to use the IHE PIXm/PDQm, MDH, QEDm and IUA profiles as alternatives to te XCPD, XCA and XUA profiles. Furthermore a distributed service discovery solution allowing each QHIN to publish its IHE profile endpoints such other QHINs can query/retrieve such information withou having to rely on an RCE provided service.

Comments:

• Option 2 – “Defer “QHIN Message Delivery” from QTF until a FHIR based solution is readily available”. Or better yet eliminate QHIN Message Delivery as the current network of Direct Secure Messaging has been proven during the pandemic to serve the needs of public health and a QHIN is not required for public health to take full advantage of Direct Secure Messaging. If it is not broke, don’t fix it. The comments from public health likely precede the use of Direct for public health during the pandemic.
• Of the suggested choices: Option 2 – “Defer “QHIN Message Delivery” from QTF until a FHIR based solution is readily available”.In response to the question posed above: The QTF should NOT include QHIN Message Delivery. If it is not broke, don’t fix it. The current network of Direct Secure Messaging has been proven during the pandemic to serve the needs of public health and a QHIN is not required for public health to take full advantage of Direct Secure Messaging. If a QHIN wishes to participate as HISP (which many if not all candidates for QHINs do) they may optionally do so following the standards and regulations that are currently in place.
• Just as payers and provider are being required to expose patient data via FHIR, the same should be true for HIE/HIOs and QHINs.. This is a similar approach to that used in banking and finance where sources of data and aggregators of data coexist in the same eco-system.
• While I applaud making message delivery a test only requirement, I fail to understand why a robust, established, secure, ANSI standard such as Direct was not chosen over the poorly defined IHE XCDR technical profile. My supporting arguments are as follows:
  – Direct is more broadly deployed and in daily use with millions of messages currently flowing between providers and other end points across HIE/HIOs and HISPs.
  – eCR reporting to the CDC was enabled within a matter of days vs. the far more technically complex XCDR profile.
  – Context management similar to XCDR is now enabled in both Direct protocols (SMTP and XDM) as a result of work to support ADT Notifications.
  – Direct supports end points without EMR or other HIT systems such as community provider organizations enabling better health equity.
  – Requiring a QHIN to create a cross connection between Direct and XCDR adds unnecessary cost and complexity to the pragmatic use of Message Delivery.

View Submission File (PDF)

View Submission File (PDF)

View Submission File (PDF)

Comments:

• Page 8 states that “Each QHIN has either a Record Locator Service (RLS) OR Enterprise Master Patient Index (eMPI) OR the ability to query all of its Participants for a patient lookup within the timeout limitation as specified in the QHIN Service Level Requirements Policy”. The service level requirements policy referenced is not yet available. We want to underscore the importance that, regardless of method chosen by the QHIN, not only the timeout limitations are acceptable and consistent to support the end user workflows impacted, but also overall performance, quality, and completeness of responses are consistent to ensure end-user experience across QHINs is acceptable.We note the absence of patient matching performance thresholds necessary to provide consistent minimum matching performance across QHINs. We strongly urge the RCE to collaborate with QHINs and their participants to establish basic performance expectations for patient matching, to drive consistent quality and completeness of matches across QHINs and their participants. This could include designation of an expanded minimum set of demographic data elements (including available unique identifiers and/or formatting standards) that must be exchanged to facilitate patient matching across organizations and across the network of QHINs.The QTF contains the following excerpt: “IHE does not define a document beyond ‘a collection of bytes, including proprietary and textual formats.’ Therefore an XCA document may be any form of information including C-CDA 2.1, FHIR® resources, PDF, or other formats. For purposes of Document Query and Retrieve, C-CDA 2.1 is the expected format for all patient information. If a Responding Source is unable to return a C-CDA 2.1 document, the data is converted to the C-CDA 2.1 format by a Responding QHIN, Participant, or Subparticipant prior to transmission to the Initiating QHIN.”Further, QTF-039 requires “If a Document Retrieve response is not in C-CDA 2.1 format, QHINs MUST convert the response to C-CDA 2.1 format except where consistent with QTF-043 and QTF-040”.We are opposed to any requirement that the QHIN convert any document to any other format, whether HL7 CDA C-CDA R2.1 in accordance with the standards/versions referenced in ONC’s certification criteria, or any other current or future standard, e.g., an HL7 FHIR Document. Requiring a QHIN to perform such conversions creates major concerns as outlined below:i. Privacy and Security: The QHIN should not be expected to access message payloads. Such access unnecessarily expands the number of touchpoints where patient data is exposed and at risk. The source of the information should be expected to produce information in any required manner.
  ii. Incompatibility: Older or different data formats may not have sufficient or appropriate data to properly create an HL7 CDA C-CDA 2.1 document, thus requiring not only format changes but also content mapping. Next generation documents based on FHIR that are likely to emerge as this framework rolls out would have to be converted “back to” C-CDA 2.1 format, dampening standards advancement.
  iii. Loss of information: A lossy conversion to C-CDA 2.1 might inadvertently withhold original/relevant data from the information requester.
  iv. Change of information: Certain documents such as Referral Notes and Discharge Summaries are considered legal attestations to the facts contained therein. For these documents in particular, it is important they contain only what the author intended to be conveyed and retain their full original format and content. Any change by any intermediate is not appropriate and should not be required.
  v. Non-brokered exchange: As FHIR-based access and exchange in the future may contain documents as well and the FHIR-based exchange may not be brokered by the QHIN, documents would not be managed consistently.Rather than recommend the QHIN be responsible for normalizing document formats to C-CDA 2.1, we instead recommend ONC require sources to generate new documents in accordance with the then-current format as required in ONC’s CEHRT program, regardless of whether the source is CEHRT or not. Similarly, receivers should be required to enable viewing of any document obtained using that standard as well as standards used in prior standards (e.g., CCR, CCD, C-CDA R1.1) or generally used formats (e.g., .pdf). Any conversions to other formats should be left with either the source to maintain fidelity to the original document or the receiver in context of the intended purpose. This should not preclude a QHIN from providing this capability to their participants to aid in any desired conversion as indicated by the source to maintain the necessary fidelity to the original source.
• The EHRA recognizes the need for message delivery to be a capability that the trusted exchange framework and QTF supports. We note the value demonstrated by recent efforts by Carequality, eHealthExchange, APHL, and CommonWell to enable message delivery for COVID case reporting. However, we do not support the introduction of XCDR for this purpose between QHINs for the following reasons:i. XCDR is not widely adopted. Although XCDR would only be required QHIN to QHIN, we would expect requirements would be likely to trickle down to participants.
  ii. XCDR is not fit to purpose. A message delivery capability needs to be able to support addressing messages to specific users, not only organizations/home communities.
  iii. Other and newer alternatives are available or on the horizon.We therefore do not support options to require or optionally support XCDR.However, we do offer an alternative to waiting for FHIR. FHIR has the promise, but not yet the maturity, to address message delivery through a variety of mechanisms: RESTful writes, messaging paradigm, and subscription/notification models. Rather than waiting for these models to mature and be deployed, we suggest to encourage and enable QHINs to follow the Carequality model used for case reporting: use Direct or XDR with applicable payloads for the use case at hand. With record locator services and endpoint directories, a variety of notification and other push messaging use cases can be scaled under a common trust framework. We note that under this approach QHINs would not be required to broker the messages. Generally we recommend that brokering actual payload transactions should not be a requirement across all use cases. While reasonable and appropriate for document queries, this is not necessary for message delivery as already demonstrated in other settings where the legal framework and trust framework are the critical element to scale. We realize that un-brokered messaging complicates certain interoperability measures, but those measures should not drive how to best communicate data. Function, utility, efficiency should drive the level for brokering that QHINs support.As FHIR matures for the relevant use cases, it can expand, improve upon, or replace message delivery use cases. In the meantime a proven, widely adopted message delivery approach can be consistently deployed within, across, and outside of QHINs.
• We suggest aligning the TEF QTF FHIR Roadmap with similar efforts under development by the FHIR at Scale Task Force (FAST), Carequality, CommonWell, and eHealth Exchange. They focus on establishing the fundamentals of a FHIR based trust, authorization, authentication, and registration foundation using FHIR US Core queries. Subsequent use cases would be expanded based on industry priorities, such as those developed by the Da Vinci Project, the Argonaut Project, the Gravity Project, and other HL7 FHIR Accelerators. This approach does not currently require brokered FHIR transactions (although the need for them may emerge over time as the technology matures and use cases demonstrate benefiting from brokered exchange). Neither the QTF nor the CA should have blanket brokering requirements across use cases and technologies. Instead, if a specific use case or technology adopted by QHINs and Participants requires the use of brokered transactions, the QTF should reflect that need specific to that use case. For example, Carequality does not require brokered FHIR transactions. Similarly, CommonWell is initially focusing on unbrokered FHIR based queries within the CommonWell trust framework for patient matching, record location services and endpoint discovery.Finally, while the RCE and ONC should continue to participate in advancing the development and maturation of new standards, we recommend relying on the existing framework for developing industry-wide, consensus-based standards to do so, instead of attempting to use TEFCA Participants as an accelerator for standards development and adoption. Following existing initiatives would prevent diluting those existing efforts, as the same resources would be required to progress any RCE-led initiatives.

View Submission File (PDF)

Comments:

• HL7 Comments
  Patient Matching
  • HL7 notes that there are no defined matching criteria and/or algorithms defined for QHIN-to-QHIN interactions.  We strongly urge that appropriate minimum criteria and standards are established to enable consistent and predictable expectations to find all of a patient’s data across QHINs.
   
  Document Reformatting Requirement
   
  The QTF Draft 2 specifies that QHINs implement the IHE XCA profile to enable query-based network-to network document exchange. HL7 has the following comments:
   
  The Draft QTF states that “If a Document Retrieve response is not in C-CDA 2.1 format, QHINs MUST convert the response to C-CDA 2.1 format except where consistent with QTF-043 and QTF-040.”  For reference:
  • QTF-040 – Responding QHINs SHOULD transmit any specific document format requests (provided by the Initiating QHIN via the IHE XDSDocumentEntryFormatCode XCA parameter) to Responding Sources. 
  • QTF-043 – Responding QHINs MAY provide patient information in other document formats if required by Applicable Law, if an alternative format is requested by the Initiating QHIN via the IHE XDSDocumentEntryFormatCode XCA parameter, or where C-CDA 2.1 format documents are inappropriate for the content (e.g., Public Health submissions or Payer claim/coverage documents). 
   
  While HL7 understands the desire to share consistent document formats across participants, we are concerned that this requirement creates undue burden implementing conversion capabilities where it is reasonable to expect that receivers can manage (view, process) older formats, if not newer formats (e.g., HL7 FHIR Documents).  Conversion of older versions may be challenging, as there may not be enough data to yield a properly conformant CDA C-CDA 2.1 document.  Merely wrapping it as an unstructured document would not yield additional value either.  Rather HL7 suggests that TEF focuses on promoting and driving that any newly generated documents adhere to the most current standard adopted for certification, which currently is CDA C-CDA 2.1, plus referenced companion guidance and may in the near future start to include an  HL7 FHIR Document format.  This approach has added benefits of better enabling other future standards version advancement.
• HL7 Comments
  • HL7 recognizes the value of enabling message delivery under TEF.  We note that adoption of XCDR is extremely limited, adding an additional standard to the stack would significantly increase complexity, that there is wide support for Direct as an alternative, and that use of XCDR would be temporary because HL7 FHIR adoption and implementation is progressing rapidly in multiple scenarios. Therefore, it is prudent not to require XCDR.  The RCE should consider that Direct could be used already where QHINs can provide substantial value in directory services to find and address organizations and individuals alike within, across, and outside networks.  
   
  • HL7 notes that for the Public Health use case of case reporting, the Carequality framework has already enabled such an approach where the eCR Now on FHIR method –using an HL7 FHIR based SMART App to trigger data collection using FHIR based APIs, then generating a CDA eICR document that is delivered directly to APHL using either XDR or Direct– primarily takes advantage of the Carequality trust framework.  
   
  • Similar to our feedback on the FHIR Roadmap, HL7 suggests that message delivery need not require a brokering approach, as the Direct or HL7 FHIR based methods do not require such additional overhead.  Optional adoption of Direct that focuses on directory services may be a reasonable progression as HL7 FHIR matures, and/or use of XDR for certain use cases as demonstrated by the case reporting example.
• HL7 Comments
  HL7 has a series of foundational questions regarding constraints for participants and sub-participants.  These include: 
  • Is TEFCA, and specifically are the QHINs, required or expected to support HL7 FHIR-based API exchanges?  If so, when and in what sequence for different functions or use cases?
  • Would participants and sub-participants WITHIN a QHIN be able to conduct health information exchanges/controlled access to health information via HL7 FHIR-based APIs?
  • Would a participant/sub-participant in one QHIN be able to conduct exchanges with a participant/sub-participant from ANOTHER QHIN using HL7 FHIR-based APIs?
  o Using QHIN trust framework, directory, and RLS only;
  o Using QHIN(s) as a message broker in the middle.
  • What are the use cases when QHINs may be expected to support QHIN-to-QHIN FHIR-based exchanges?
• HL7 Comments
  • Regarding the question of if the QTF should include QHIN Message Delivery, HL7 observes that since Message Delivery is a part of the current landscape, we do not see how it could not be supported at all.  The critical question is how QHIN Message Delivery could be supported.
  • HL7 inquires what the reasons are for not considering integration of Direct Messaging in the initial QTF.
  • HL7 also asks how the risks and costs versus the benefits are viewed of introducing a new set of standards in XCDR that will be only temporary by design?
• HL7 Comments
  Overarching FHIR Roadmap Comments
  • Regarding what elements should be included in a TEFCA FHIR Roadmap and for enabling FHIR date to be used by Health IT systems for the purposes outlined here, HL7 stands ready to practically and meaningfully contribute to and facilitate help with feedback on the TEFCA FHIR roadmap.  This includes insight about the various ways that HL7 FHIR can be used in the TEFCA context. 
   
  Detailed FHIR Roadmap Comments
   
  HL7 appreciates the inclusion of a FHIR Roadmap in the Draft QTF, while the initial focus is on IHE based Document Exchange.  Two key issues that can be considered in the Roadmap include:
   
  • Use of FHIR based document exchange to migrate document exchange from IHE profile based to FHIR based. 
  HL7 FHIR Implementation Guides (IGs) and profiles are already available to enable this inclusion earlier on a Roadmap, particularly considering these capabilities already have been deployed. HL7 stands ready to gather a master list of relevant and user-ready IGs and profiles for this purpose.
   
  • Use of FHIR based data exchange such as queries to USCDI/EHI using FHIR US Core.
  TEF provides a valuable opportunity to scale national level trust, access, and exchange based on FHIR.  Many of the HL7 FHIR accelerator use cases lend themselves to be adopted at some point under TEF.  HL7 offers the following considerations to incorporate those into a Roadmap:
   
  o The current QTF is exclusively based on a brokering model where all transactions flow through a QHIN.  HL7 suggests that for many FHIR based use cases this is not necessarily required or beneficial and therefore should not be an a priori, cross-use case requirement.  The value of the TEF for many of these use cases is in the trust fabric that TEF provides, the record locator (RLS), master patient index (MPI), and endpoint discovery processes.  HL7 recommends that the FHIR Roadmap should recognize this need and not require brokered-only FHIR based use cases. It is important that the QTF can be used for trust, record location, end point discovery, authorization, authentication and registration (as currently being pursued by the Carequality FHIR implementation Guide) while letting individual QHINs determine when and how much to broker beyond that.  As implementation experiences mature, appropriate use of brokered approaches will emerge.
  o From a use case deployment perspective, HL7 suggests that the initial focus should be on FHIR US Core to establish the foundational elements, and grow the use cases based on initial deployment experiences and priority.

Comments:

• Overall, the definitions are clear and concise.  Given the diverse backgrounds of those reviewing and using the document, Humana recommends adding definitions for technical components such the IHE, IHE profiles, XCPD, XCA, ATNA, etc. 
  We commend the RCE for planning for a TEFCA FHIR roadmap.  In the paragraph that speaks to the roadmap, we advocate for adding narrative around the promise and opportunities that FHIR provides moving forward such as:
  1. Reduced interaction complexity
  2. Contemporary API ease of use and implementation
  3. Complementary technologies such as CDS hooks and SMART on FHIR apps
• Overall, the scenarios as described with the existing protocols are well documented. We do note that requiring protocols, such as IHE, limits the ability of actors (including intermediaries) and new actors who do not currently support those protocols to integrate. Actors who need to invest in the IHE and associated protocols may need to defer investment in other interoperability technologies such as FHIR.
  We support the mutual TLS approach. We understand the SAML proposal given the protocols proposed but we do ask that the RCE consider contemporary models such as Open ID Connect and UDAP moving forward.
  The document query and retrieve narratives are well documented. Given that XCA is content agnostic and supports many standards, it does provide flexibility.
  We do wonder if having the protocols mentioned in the proposal be considered a floor such that actors who want to go beyond IHE and mutually agree to use approaches such as FHIR are permitted to do so.
• We commend the RCE for recognizing the need for push data models. Moving forward, we recommend that the RCE consider industry initiatives such as the ONC FHIR at Scale Task Force (FAST) for identity, directory, security, and intermediary routing. FHIR messaging is also a consideration for the roadmap.
  The error handling, auditing, and constraints are well documented and appreciated.
• Comments regarding the functions and technology have been intertwined throughout our response. Overall, we recognize that the QTF is advocating for established technology and protocols such as IHE. We are encouraged that a roadmap for using FHIR and other technologies at scale will be created to ensure a path to contemporary scale. As an industry, we need to be sure that near term approaches do not constrain contemporary API models moving forward.
• Regarding QTF-096, we recognize the value of having one test patient in production but there will need to be cross QHIN testing standards to ensure there is no opportunity for confusion in any part of the ecosystem.
• We thank the RCE for the opportunity to comment on the proposed framework. We support interoperability initiatives that move our industry toward integrated care delivery for the benefit of all stakeholders, especially better outcomes for members and patients.
  We understand the perspective of using established protocols such as IHE profiles and we look forward to working the industry to progress this model to include contemporary approaches to achieve even greater and sustainable interoperability. HL7 as an organization, with is re-envisioning initiative, is placing the future of interoperability on FHIR with maintenance only for previous versions. The RCE should continue to recognize and follow that path.
• Yes, message delivery should be optional using XCDR until a FHIR based solution is readily available. Option 3 is recommended.
• FHIR and associated approaches provide a contemporary model for health care interoperability at scale. The FHIR community, including the HL7 FHIR accelerators and the FHIR at Scale Task Force, are providing solutions for wide-scale FHIR adoption in a value add, less complex, and easier to implement model than previous approaches.Specifically, the roadmap should include:
  1) A path for adopting true FHIR interoperability as foundation of TEFCA/QTF, not simply FHIR as a format moved over XCA.
  2) Integration for FHIR only actors into the TEFCA/QTF ecosystem without having to refactor FHIR enabled systems backwards to previous models such as IHE. This could include in-flight movement between FHIR and approaches defined in QTF and by supporting FHIR as a distinct feature of the QTF model.
  3) Consideration of the existing proposal as a floor but not a ceiling. Innovative actors, with agreement, could run with new approaches such as FHIR.
  4) Use of the emerging standards in HL7 FHIR including intermediary routing, UDAP security, identify management, provider endpoint directory, and others.
  5) Support for FHIR messaging and movement between FHIR and QHIN messaging.
  6) FHIR to QHIN and QHIN to FHIR dynamic processing.
  7) Adoption of FHIR as the underlying approach for QTF in the future with legacy support for previous approaches.
  8) Considering of FHIR event processing across ecosystem.

Comments:

• The QTF should defer “QHIN Message Delivery” from QTF until a FHIR based solution is readily available – reasons include:
  There is a widely deployed Direct Secure Messaging push network that already provides the essential capabilities that XCDR might offer a QHIN, including XDR-based message delivery. 
   
  Providers requiring CMS Certified EHR Technology certification already must meet the ONC Health IT Certification criteria for either the §170.315(h)(1) Direct Project or §170.315(h)(2) Direct Project, Edge Protocol, and XDR/XDM that are included in the Base EHR definition.
   
  Hundreds of millions of XDR messages were delivered over a nationwide Direct Secure Messaging network in the last year—the Direct XDR/XDM protocol is widely supported by healthcare providers, EHR systems and Direct network service providers.
   
  Direct Secure Messaging supports: 
  • both larger providers that use XDR/XDM as well as providers that rely on SMTP or webmail.
  • reliable messaging for XDR endpoints
  • integral mapping of Direct addresses to XDR endpoints
  • both real-time and store-and-forward message delivery
   
  Nothing would preclude a QHIN from providing ONC certified Direct XDR services for QHIN-to-QHIN or QHIN-to-final recipient messaging.
   
  FHIR Messaging services that use Direct secure messaging for backbone transport are already delivering tens of millions of patient event notifications to XDR, SMTP or FHIR endpoints.

Comments:

IHE’s family of Document Sharing health information exchange integration profiles act as the foundation of health information exchange activities enabled by current national networks utilized in the United States, such as Carequality, CommonWell, DirectTrust, and eHealth Exchange. The Document Sharing HIE integration profile family addresses the problem of exchanging clinical documents (for example, discharge summaries, lab reports, pathology reports, etc.) between information systems in different enterprises. See the appendix at the end of this comment for more information on IHE’s Document Sharing HIE integration profile family.

IHE USA agrees with the use of this widely implemented family of document sharing integration profiles to support the current and future vision for the nation’s health data interoperability represented within the Trusted Exchange Framework and Common Agreement (TEFCA). We believe that a use case-based approach to the integration of FHIR into QHIN-to-QHIN data exchange will allow the industry to utilize an outcomes-based vs. timeline-driven change management paradigm. A use case-driven approach will also allow stakeholders across the industry to better co-collaborate on use cases that meet current and emerging health data priorities and will facilitate a smoother transition to support FHIR Document-based exchange in production environments by appropriately extending the capabilities of existing technology architectures. We encourage the establishment of use case-driven pilot studies at provider organizations such as those who have received the HIMSS Davies Award of Excellence or EMRAM Stage 7 recognition to help establish FHIR Document-based exchange best practices that the broader industry can look to as best practices in order to support their own transition from CDA to a FHIR-based data exchange architecture.

Additionally, IHE’s Cross-Community Document Sharing integration profiles recommended for QHIN-to-QHIN data exchange can help the nation manage the transition to RESTful data exchange as these profiles are content agnostic. While currently leveraging HL7’s clinical document architecture (CDA) exchange standard, these profiles can also leverage HL7’s FHIR as discussed in the example below. Additionally, the existing nationwide networks have leveraged CDA-based IHE profiles to resolve many current exchange issues, such as those around privacy, security, discovery, routing, vocabulary alignment, quality, and patient Identity. While FAST workgroups are making good progress to address with http RESTful exchange, work remains to be done to achieve the same functionality currently enabled through CDA-based IHE profiles.

Should QTF include QHIN Message Delivery?
Option 1: Require “QHIN Message Delivery” modality in QTF using the Integrating the Health Care Enterprise (IHE) Cross-Community Document Reliable Interchange (XCDR) profile with a future transition to FHIR is the path I recommend. Given that the Q/R QHIN exchanges are utilizing IHE published profiles due to there broad deployment in the industry, the fundamental underpinnings for XCDR are already required for QHINs. Active work to identify and address technical issues with using a FHIR-based exchange for message delivery (and Q/R) should however be continued and expedited.

Comments:

View Submission File (PDF)

Comments:

• On behalf of Kno2, I am pleased to submit comments on the Office of the National Coordinator’s QHIN Technical Framework Draft v1 as published in July 2021. We have supported the QTF, and are excited to participate in its implementation in 2022.
• Kno2 applauds the forward-thinking of the ONC and Sequoia Project to allow for innovation by adding the ability to exchange outside of an eMPI or RLS, given their infancy in the interoperability framework.From page 11:Each QHIN has either a Record Locator Service (RLS) OR Enterprise Master Patient Index (eMPI) OR the ability to query all of its Participants for a patient lookup within the timeout limitation as specified in the QHIN Service Level Requirements Policy.Kno2 fully supports this provision, but we would suggest the QHIN service level requirements policy is necessary for all QHINs, not just those who query their participants directly. Also, we believe an eMPI and RLS should validate completeness of information, since many today don’t have all patients’ data registered.
• Kno2 has exchanged “push” messages or “message delivery” for several years. The biggest lesson we’ve learned is the importance of an accurate directory, rather than semantics about what transmission method is best.However, opening up those transmission methods for future use cases is incredibly important to patient care, such as event notifications. We are concerned about not putting message delivery into the initial specifications, as that would duplicate exchange frameworks that are in place today. In addition, provider and others’ workflows has been poor through the history of message delivery, and we would welcome ONC and Sequoia taking this on as a subject to be solved.
• We at Kno2 applaud the ONC and Sequoia for using the technical framework for query and response that is in use at scale today. This allows for a floor of exchange that’s achievable, and something to build on as TEFCA scales to the entire country.
• We at Kno2 fully support message delivery via TEFCA, and would support its inclusion being a “should” rather than a “shall” in the initial specifications.

Comments:

• The Draft QTF Includes patient requests as one of the exchanges required to be supported, however little in the document speaks to the extent to which this will be handled any differently or recognized as an equally important enabled transaction. This could be vastly improved with an explicit scenario breaking down the patient request/individual access services.It would also be very reassuring to patients and families if the QHINs were required to support patient requests directly if a patient or authorized patient representative did not have an authorized Actor able to act on their behalf, staled more plainly if the individual did not have a Provider, Health plan or HIE/HIN readily willing to act broadly on a patient request. Perhaps stated another way, how will the common agreement and Technical framework support facilitating individual access such that consumers are not required to submit inquiries to every provider’s portal or system. this continued fragmentation of the individual requires runs contrary to the non-blocking rules.
• Could aggregation across HIEs, participants and sub participants in response to individual access requests be a stated requirement for functions and technology.
• With respect to the QTF and TEF, I strongly recommend the development of plain language overviews and consumer guides on how individual access will be enabled and how individuals can engage with their providers, plans, local HIEs and QHINs.
• Since the non-blocking implementation is depending upon the FHIR implementation, I would ask that 2 explicit scenarios be detailed in the exchange:
  1) A participant submitting a request pursuant to an individual access query to help aggregate across other participants and subparticipants; and,
  2) A scenario in which the QHIN acts in this capacity ( or at least describe the extent to which this scenario would differ)I would also ask that there be a parallels of requirements for these scenarios or a clear subsections delineating how the requirement would apply under these scenarios.

Comments:

• Please clarify whether the Access Consent Policy (p. 6) definition includes Substance Use Disorder information exchange.
• For the document query scenario (page 8), the Responding QHIN “resolves the patient’s identity and returns an XCPD response with the resolved identity (including a local patient identifier, demographic information about the patient, etc.).” For non-federated QHINs, is a local identifier expected to be assigned by the Responding QHIN’s eMPI?The pre-conditions of document query scenarios implies that record lookup is required which is contradicted by the specified standards in Table 1. Is the 0…* cardinality for the actor Record Locator Service correct or should it be 1…* with a note that record location may be accomplished by querying an eMPI or the QHIN participants?
  The QHIN Service Level Requirements Policy needs to be finalized and the timeout limitation clarified. The link provided for the QHIN Service Level Requirements Policy does not work.Regarding Document Retrieve Alternate Flow 1: Error Flow (p. 16), we recommend providing more robust error response message examples that include the reason for a failure and type of failure. We recommend including the reason for patient matching failure. For example, “patient discovery at Participant X was unsuccessful due to insufficient demographics to achieve a patient match in X’s system.”Regarding Document Retrieve, Alternate Flow 2: Retrieve returns partial success (p.16), the QTF should provide an example of a more robust error message (Item 2): for example, “Successful patient identity match at Participant X, but no documents found or some documents are unavailable.”Regarding Item 3, IHE Cross Gateway Retrieve (ITI-39) only shows a single RetrieveDocumentSetRequest entry and should be expanded to show an example of a consolidated response.Regarding Item 4, we agree that the Initiating QHIN should combine all IHE Cross Gateway Retrieve [ITI-39] responses into a single response and choose to execute one of the following subflows but assume it would be a new entry that “loses” the history in the separate entries that it was constructed from.Regarding Post-conditions Item 5, we recommend adding “except in the case of errors” to the statement “Query Source has obtained all retrieved documents as known by each Responding Source.”
• Regarding the Message Delivery Scenario (p. 17), explicit information about how a patient in an emergency department identified the intended recipient of the message would be useful (i.e., patient provided PCP’s Organization name).Please clarify the expected information about the intended recipient(s) of the message in the Message Delivery Solicitation (e.g., name, practice name, individual, organization, or NPI). We also recommend including specific information a QHIN needs to identify in its directory to determine the appropriate Responding QHIN(s) and whether this information is explicitly required.If a single care summary is intended to be delivered to two recipients (e.g., primary care provider and a specialist), are multiple Message Delivery Solicitations expected or required to be generated by the Message Source? For example, when an emergency room provider intends to send a care summary to a patient’s primary care provider and cardiologist, should the provider expect to experience one or two ‘Care Summary Message Send’ workflows?If a single originating message is expected to be targeted to more than 1 recipients, is the Initiating QHIN expected to consolidate all responses into a single response to the Source Participant (ED provider in this scenario, and aligned with Query workflow)?If a single originating message is not expected to be targeted to multiple recipients, then the use of the optional plural QHIN throughout this scenario is confusing; please clarify when a single message with a single intended recipient would be sent from a single Initiating Gateway to multiple Recipient Gateways.Regarding the Message Delivery pre-conditions (p.19), can an unsolicited message delivery be sent for an entire Organization and all the providers within that Organization? Or is an individual target provider required? Additionally, we recommend clarifying the pre-condition that each QHIN maintains an up-to-date copy of the RCE Directory to define the phrase “Up to date.”Regarding Nominal Flow, Item 2 (p. 20), when sending a message, we recommend revising the sentence to: “The initiating QHIN creates an IHE Cross-Gateway Document Provide (ITI-80) transaction per intended recipient and sends each transaction via the Initiating Gateway to each Responding QHIN’s Responding Gateway.Regarding Message Send, Alternate Flow 1: Error Flow, Item 2, when the responding QHIN returns a ResponseStatusType:Failure, the error message should include a reason why the message cannot be delivered so that this information can be relayed back to the Message Source for triage. If the message is addressed to more than 1 provider, then RespondingGateway should return one error message with the reason it failed to all recipients.
• Regarding QTF-015 – the SAML Assertion User Authentication (p. 24), we recommend including the “assigning authority” as the term to describe the identifier in the User Authentication functions.Regarding QTF-021 Exchange Purpose Accepted Codes (Table 7), “TREAT” is not the correct NHIN PurposeOfUse code. Is a new code system being used? Please clarify the table further.
  Regarding Directory Services (p. 33), please define the criteria (i.e., number of years between updates) for a maintained RCE Directory Service (and the associated link in the guide).
• Regarding Performance Measures QTF-105 (p. 37), please clarify the downtime requirement. Is total downtime data required for each QHIN gateway actor or is the summary only a total of all downtime, regardless of the number of actors? Additionally, should the data include planned or unplanned downtime?Regarding the “Average response time for each inter-QHIN transaction,” consider including the average response time for each QHIN-Participant transaction by HCID and adding total number of messages successfully delivered to Participants (i.e., positive ACKs) for validation/comparison.For QTF-106, we recommend including “QHINs are also encouraged to attest to the validity of standards-based clinical documents (when possible) which persist within the QHIN environment (i.e., non-transient clinical documents).” Additionally, please define “clinics” (e.g., HCID, geographic location, postal address, etc.).Regarding Onboarding and Testing Requirements (p. 39), please define the format the RCE expects test cases and results: write up, attested, unaltered server audit logs, gateway or network transactions, or some other option.
  Regarding Patient Discovery Item 2 (p. 40), we suggest you include, “(3) an error including the error message(s).”Regarding Document Query and Retrieve Item 1 (p.40), please define “successful” outcome of patient discovery transaction (i.e., return of patient data rather than no response or technical error.
• Messaging is a fundamental use case in healthcare interoperability. Through TEFCA, QHINs are well-positioned to bridge technology gaps between IHE and FHIR and, therefore, should be required to support standards-based Message Delivery as outlined in the scenario and encouraged to support multiple (IHE and FHIR) messaging modalities. 
   
  Two wording options:
  a) Consider requiring the use of IHE XCDR profile in all cases except where both actors/systems (mutually) agree use of FHIR messaging will be used instead of IHE.
   
  b) Require “QHIN Message Delivery” modality in QTF using the IHE XCDR profile except in cases where both actors/systems (mutually) agree FHIR messaging will be used instead of IHE.
• Through TEFCA’s FHIR Roadmap, QHINs and TEFCA participants should be encouraged to support mandatory search parameters and search parameter combinations as defined in the current or most recent US Core Implementation Guide Profiles. The RCE should also plan to expand its functionality to include a directory of Participants’ FHIR resources, profiles, and search parameters. With this directory, high-volume and efficient transactions of both unsolicited messaging (push) as well as query can be performed using FHIR. To maintain the RCE FHIR Resource directory, QHINs and their participants (EHR systems) should each publish and maintain their own FHIR Implemention Guides containing their systems-supported FHIR capabilities.We recommend considering the work being done by the HL7 FHIR at Scale Taskforce (FAST) as part of the FHIR Roadmap. FAST uses the concept of floor and ceiling to define a base set of standards all must implement (the floor), but that the experimental use of FHIR by negotiation and agreement would allow for a high ceiling, provided that all parties also implement the base requirements (IHE XD* specs in this case).

MaxMD is an Interoperability Service Provider that leverages IHE, HL7, FHIR and Direct Secure Messaging standards to create solutions that provide clinical data liquidity and healthcare interoperability for thousands of Healthcare and Healthcare related clients. We are responding to the request for comments to the current draft of QHIN Technical Framework and more specifically to the question; “Should the QTF include QHIN Message Delivery? If you believe QHIN Message Delivery should be included, how should it be technically specified?”
Before responding I would comment that while I can understand the need to focus the responses as a process management technique, I think the options provided miss an obvious and pragmatic choice. The DirectTrust Network is an established Trust Network infrastructure that already exists and provides a secure push modality that is easily integrates with virtually any edge system or application. Today, Direct Secure Messaging is an used by over 260,000 organizations exchanging over 100 million transactions monthly and over 2 Billion transactions to date. Perhaps most importantly, the DirectTrust Network is not a separate network; the very organizations considering use of xCDR as a push modality likely are already using Direct Secure Messaging.

XCDR would be a duplicative effort that would increase cost for no apparent benefit or increase in capability. The Direct Protocol is versatile and still evolving with improvements such as Message Context IG, Distributing ADTs and already has an improving National Directory of end points that will serve to increase the usability and value of the existing network. Direct Secure Messaging and the FHIR Community are already working together to leverage the best of both modalities. Adding another push option like XCDR would likely confuse the market, add burden, limit growth, and likely create no additional functionality.
Given the choice of the three suggested responses we would recommend that Sequoia “ Defer “QHIN Message delivery from the QTF until a FHIR Base Solution is readily available”. However, the smarter path would be to continue to develop on the foundation of Direct Secure Messaging that has been firmly established over the past 10 years. We appreciate that Sequoia may view XCDR as a familiar push modality for many current active members, but given the diverse capabilities of the overall healthcare market creating an additional “push modality” with no apparent advantage over Direct Secure Messaging seems counterproductive.

Comments:

• We look forward to the workgroups where more detailed questions and conditions can be discussed.
  QTF 039 is a MUST with some vague exceptions. I suggest it be more clear.
  QTF 072 requires 48 hours for onboarding. That seems like a long time. What is anticipated that would cause the delay?
  QTF 072 Where is validation defined?
• We look forward to the workgroups where more detailed questions and conditions can be discussed. The scenarios seem well thought out.
• MedAllies supports the choice of XCDR for QHIN to QHIN push. Use of Direct might require QHINs to also be HISPs, which could complicate matters. Direct is certainly a network that a QHIN may offer to its subscribers.
• Is there a requirement to support TLS 1.3 or is it optional. TLS 1.3 presents some enterprise challenges as it restricts the ability of IDS and DLP systems to inspect packets in transit.
  I assume that SAML 2.0 is specified so that the originating subscriber can be identified after multiple hops.
• I look forward to the workgroups where more detailed questions and conditions can be discussed. The QTF takes a good pass at providing enough information to determine authorization of a query.The test procedure looks reasonable. What protection or procedure is being considered to keep test instances separated from interoperating with production instances?
• Will the metrics collected be aggregated prior to distribution? Will anyone outside of the RCE have access to the individual QHIN metrics?
• I look forward to the workgroups where more detailed questions and conditions can be discussed.
• MedAllies supports option 1 requiring QHIN to QHIN push via XCDR. The IHE protocols are a mature standard and XD* is widely adopted in production. XCDR is a reasonable requirement for QHIN to QHIN push delivery. The interface between the subscriber and the QHIN is not the subject here. It can be anything that the QHIN negotiates with its subscribers. FHIR, XDR, Direct, and other protocols are all possible subscriber to QHIN interfaces.
• FHIR is a data structure and FHIR bundles can certainly be delivered over an XD* network. I think that the FHIR schema should be actively considered for FHIR bundle delivery via XCA or XCDR. The FHIR restful interface can be left to the QHIN/Subscriber interface.

View Submission File (PDF)

According to an ONC data brief from February of 2019: “HISPs that enables messaging via DIRECT protocol were the most common electronic method used by hospitals for sending and receiving summary of care records in 2019.”

Your question “Should the QTF include QHIN Message Delivery? If you believe QHIN Message Delivery should be included, how should it be technically specified?” the recommendation based upon the market place right now and support by the ONC data brief is Direct Secure Messaging as a good starting place for push messaging in TEFCA, since Direct is broadly deployed. A selection from the options outlined by the RCE does not provide one that addresses market place concerns. If absolutely required to select from required options it would be:
Option 2 – “Defer “QHIN Message Delivery” from QTF until a FHIR based solution is readily available”.

View Submission File (PDF)

Comments:

• We propose an alternative solution that the initiator of the message is required to validate the patient ID before sending (e.g. using XCPD) so the receiver can rely on the provided patient ID. The receiver should be responsible for matching what they ingest.
• Onboarding should consist of a standard set of use case tests performed against test environment to ensure that each participant can meet the minimum requirements consistently.
• Image Exchange:
  We suggest including imaging exchange as optional in the initial version so image exchange QHIN’s are able to exchange images from the start of TEFCA. XCA-I image exchange is perfectly aligned with the other exchange standards (XC* IHE profiles). It would be a setback for standardized national image exchange if TECFA does not include image exchange.Multiple QHINs for one health care organization:
  In the current philosophy of TEFCA every health care organization will join TEFCA via one QHIN (whereas lot of participants currently join multiple networks for multiple purposes, e.g. HIE and eHX). It might be very well possible that for different data types different QHINs will be established, e.g. for EHR an EHR-vendor can provide its customers a QHIN, but for DICOM images a PACS-vendor or image exchange vendor might be the connection to TEFCA.
• Option 1: Require “QHIN Message Delivery” modality in QTF using the Integrating the Health Care Enterprise (IHE) Cross-Community Document Reliable Interchange (XCDR) profile with a future transition to FHIR.

Comments:

• I participated in the group formed by ONC to define a scalable approach to message delivery. In general, it is best if we have peer-to-peer exchange, not requiring QHIN or QIO. There are multiple challenges with choosing an approach other than the one we call Direct Secure Messaging: Some of these include:
  1.) End point discovery and routing. If A wants to send a message to B – who keeps track of which network is attached to B.
  2.) Message content definitions – the hub-to-hub approach ends up with content limitations – imagine pushing an MRI from one point to another.
  3.) Trust relationships – how does one really set up trust?
  4.) Adoption – most organizations do not participate in HIE’s – or QHIN – we have not solved the financial issues with doing so.
• I do not believe that QTF should include QHIN Message Delivery. QHIN should only be for query…
• A TEFCA roadmap should start with per-individual and per-organization X.509 digital certificates for signing, encryption and connections. FHIR could sit on top of this, along with SMTP to provide scalable peer-to-peer network. FHIR should define the content of the message, not the transport.

I believe that it is important that the TEFCA framework include message delivery from the outset. Interoperability is a dynamic process that must support multiple use cases and methods of information flow. Two fundamental needs that clinicians have are the ability to push and to query for clinical data to support patient transitions and care coordination. If the TEFCA is to fulfil its promise of a single onramp to nationwide interoperability, support for unsolicited push messaging must be included. There are a number of technical methods that could be used to support this capability. Our industry currently successfully utilizes both Direct and XCDR messaging in support of push messaging and will eventually support FHIR-based messaging. I believe that the QTF should begin with a requirement to support push via either of the currently available technical standards with a plan to include FHIR when feasible. In the future, it would be ideal to standardize on a single technical solution for push, but requiring such standardization before the industry is ready to support it risks the success of the TEFCA.

Comments:

• 2. Patient identify management with centralized Master Person Index (MPI):
  – Successful exchange of  information between QHINs depends on accurate identification of persons between core QHIN to QHIN exchange, and by extension, between one QHIN’s members to another QHIN’s members  
  – Would a centralized MPI that jointly serves all QHINs be a better solution and be more efficient than this model since the same ‘index’ will be shared by all the QHINS and the data will be reconciled on a real time basis rather than after an exchange is done with another organization and doing a look up and matching with each one from a federated model?
  – For example, what if a query to find a patient record do not match with any of the persons because of an exception that took place in one of the MPIs?
• Consent management while exchanging only relevant patient’s details with another stakeholder within a QHIN or across QHINs
  – Consent management would a challenge when it comes to exchanging only relevant patient information between member organizations across  QHINs
  – It would be beneficial to have a consent management modality established by QHINs in coordination with the member organizations and individuals. Could QHINs have a role in consent management between organizations in coordination with the patient? For example, organization ABC in a particular QHIN needs specific information (e.g. only information related with a notifiable condition to one organization and health insurance submitted to another organization) of a patient from another organization XYZ from another QHIN.
• Include “QHIN message delivery” in QTF using IHE XCDR (Cross community document reliable interchange) profile as required with a future transition to FHIR

View Submission File (PDF)