Difference between revisions of "TEFCA"

Latest revision as of 22:48, 18 March 2020

Full Title or Meme

Trusted Exchange Framework and Common Agreement (TEFCA)^[1]

Context

The context of TEFCA connection is an FHIR interaction with the transfer of PHI between Secure Nodes, although other transactions could travel on the same connection.

The Trusted Exchange Framework (Draft two) is intended to enable Health Information Networks (HINs) to securely exchange electronic health information with each other to support a wide range of stakeholders. The draft Trusted Exchange Framework sets up an ecosystem wherein Qualified HINs connect to each other to support the use case of broadcast and directed query for treatment, payment, operations, individual access, public health, and benefits determination purposes. To enable the broadest set of use cases, Qualified HINs and their participants are required to be able to exchange the USCDI when such data is available (i.e. if a participant or Qualified HIN does not capture or have access to a specific data class, they are not expected to be able to exchange that data class). By requiring Qualified HINs and their Participants to be capable of exchanging the USCDI, the Trusted Exchange Framework will, over time, be able to support the Cures Act requirement of all electronic health information from a patient’s record being available.

In an effort to develop and support a trusted exchange framework for trusted policies and practices and for a common agreement for the exchange between HINs, the proposed Trusted Exchange Framework supports four important outcomes:

1. providers can access health information about their patients, regardless of where the patient received care;
2. patients can access their health information electronically without any special effort;
3. providers and payer organizations accountable for managing benefits and the health of populations can receive necessary and appropriate information on a group of individuals without having to access one record at a time (Population Level Data), which would allow them to analyze population health trends, outcomes, and costs; identify at-risk populations; and track progress on quality improvement initiatives;
4. the health IT community has open and accessible application programming interfaces (APIs) to encourage entrepreneurial, user-focused innovation to make health information more accessible and to improve electronic health record (EHR) usability.

Problems

• FHIR is focused on the data access methods and encoding leveraging existing Security solutions. Security in FHIR needs to focus on the set of considerations required to ensure that data can be discovered, accessed, or altered only in accordance with expectations and policies.
• Privacy in FHIR is focused on the data access methods and encoding leveraging existing Security solutions. Security in FHIR needs to focus on the set of considerations required to ensure that data can be discovered, accessed, or altered only in accordance with expectations and policies.
• TEFCA itself only references the requirement for a PKI certificate and the ability to encrypt transmissions with HPPTS.

  Certificate Policy - Public key infrastructure (PKI) often serves as the basis for securing electronic communications over the internet. PKI involves the use of digital certificates to assert and authenticate identities, encrypt data, and sign communications.

Solutions

• The government is looking for demonstration servers and suggestions on improvements. https://www.hhs.gov/about/news/2018/05/17/secure-api-server-showdown-winner-announced.html
  • Including a Recognized Coordinating Entity (RCE)^[2]
  • This The Draft Trusted Exchange Framework could be made generic and apply to a broader range of industries.^[3]
• The page on Federation Trust Registry describes some generic solutions to Trust in a Federated Ecosystem,

QTF - QHIN Technical Framework

TEFCA has pushed some of the technical details in issues like Security and Privacy to the QTF draft 2 - which is (2019-12) to forms the basis for draft 2. The following notes were taken from the annual meeting of Carequality, which is the contractor of the ONC for the QTF.

• TEFCA requires compliance with the QTF which is included in contracts by reference.
• QTF 1 (aka Appendix 3 of TEFCA) was based on SOAP queries as it is in other document exchange by Carequality and other sites. There seems be no drive to move to more modern protocols. Presentation by Dave Cassel Carequality and David Pike.
• IAT protocols might be updated from a very old version, rather then move to HTML and FHIR.
• MHTS was proposed as an interim step.
• FHIR is inevitable, but that seems like too much for version 2. The moderator, Dave Cassel or Carequality, predicted 10 years.
• Push people to IHA & XTF for hop-hop as well as direct queries.
• Seems to be some idea that the patient ID would be the same across QHINs.
• Sites can ask for any document that they want.
• MRTC = minimum required terms and conditions is for qhin-qhin exchange.

References

1. ↑ HealthIT.gov, Trusted Exchange Framework and Common Agreement. https://www.healthit.gov/topic/interoperability/trusted-exchange-framework-and-common-agreement
2. ↑ The Office of the National Coordinator (ONC) for Health Information Technology, Draft Trusted Exchange Framework. (2018) Section 2 - How Will it Work p. 9ff https://www.healthit.gov/sites/default/files/draft-trusted-exchange-framework.pdf
3. ↑ The Office of the National Coordinator (ONC) for Health Information Technology, A User’s Guide to Understanding The Draft Trusted Exchange Framework (2017) https://www.healthit.gov/sites/default/files/draft-guide.pdf

Other sources

• Trusted Exchange Framework and Common Agreement (TEFCA) Draft 2 (2019-04-19)
• A User’s Guide to Understanding to TEFCA Draft 2 A slide deck that introduces some erroneous simplifications. (like credential)
• Trusted Exchange Framework and Common Agreement: A Common Sense Approach to Achieving Health Information Interoperability (2018-01-05)
• FHIR STU3 version of the Security and Privacy Module has a good overview of protection of health information(PHI).
• SMART Health IT is an open, standards based technology platform that enables innovators to create apps that seamlessly and securely run across the healthcare system.
• Argonaut Project is a private sector initiative to advance industry adoption of modern, open interoperability standards. The purpose of the Argonaut Project is to rapidly develop a first-generation FHIR-based API and Core Data Services specification.
• SMART Backend Services: Authorization Guide, Use this OAuth 2.0 profile when the following conditions apply: (1)the service runs automatically, without user interaction, and (2)the service is able to protect a private key
• Appendix I – Sources of Security Standards and Security Patterns