The document discusses the Draft Trusted Exchange Framework, which was developed in response to a requirement by Congress in the 21st Century Cures Act. The framework establishes principles and terms to facilitate nationwide exchange of electronic health information. It defines the roles of various stakeholders, including Qualified Health Information Networks that would directly connect to enable exchange across networks. The framework is intended to simplify data sharing, reduce costs, and improve care coordination by establishing a common set of rules and standards for trusted exchange.

1. TheDraft Trusted ExchangeFramework
AUser’s Guide to Understanding
VISIT HTTPS://WWW.HEALTHIT.GOV/SITES/DEFAULT/FILES/DRAFT-TRUSTED-EXCHANGE-FRAMEWORK.PDFTOVIEWTHECOMPLETETRUSTEDEXCHANGEFRAMEWORKDOCUMENT.
Whatis the TrustedExchange
Framework?
Whydid Congressrequire the
Trusted ExchangeFramework?
Whocan usetheTrusted
ExchangeFramework?
Whatare the benefits of the
Trusted ExchangeFramework?
How will the Trusted
ExchangeFrameworkwork?
Whatusecasesare coveredunder
the Trusted ExchangeFramework?
Whatfeescan be charged
under the TrustedExchange
Framework?
Whatprivacy and
security protectionsdoes
the Trusted Exchange
Frameworkguarantee?
Whenwill itbe implemented?

2. What is the Draft Trusted ExchangeFramework?
Format of the Draft Trusted ExchangeFramework
Part A—Principles for TrustedExchange
Generalprinciples that provideguardrails to engender trust
between Health Information Networks (HINs). Six(6)categories:
»Principle1 - Standardization: Adhere to industry and federally
recognized standards,policies, best practices,and procedures.
»Principle 2 - Transparency: Conduct all exchangeopenly
and transparently.
»Principle 3 - Cooperation and Non-Discrimination:Collaborate
with stakeholders across the continuum of care to exchange
electronic health information, even when astakeholder maybe a
businesscompetitor.
»Principle 4 - Security and Patient Safety: Exchangeelectronic
health information securely and in amanner that promotes patient
safetyand ensures data integrity.
»Principle5 - Access:Ensure that patients and their caregivershave
easyaccessto their electronic health information.
»Principle 6 - Data-driven Accountability: Exchangemultiple
records at onetime to enable identification and trending of data to
lower the costof careand improve the health of the population.
Part B—MinimumRequired
Termsand Conditions for
TrustedExchange
Aminimum set of terms and conditions for the
purpose of ensuring that commonpracticesare
in place and required of all participants who
participate in the Trusted Exchange
Framework,including:
»Common authentication processesoftrusted
health information network participants;
»Acommon setof rules for trustedexchange;
»Aminimum core set of organizational and
operational policies to enable the exchangeof
electronic health information amongnetworks.
TrustedExchange
Framework
PART A
PART B
6 PRINCIPLES
TERMS AND
CONDITIONS
2

3. Whydid Congressrequire the Trusted ExchangeFramework?
Needfor the Trusted ExchangeFramework –Complexity
Current Proliferation ofAgreements
Eachline color onthe map represents a different network.
Therearewell over100networksin the U.S.
Many organizations have to join multiple Health
Information Networks (HINs),and the HINsdo not
share data witheach other.
Trustedexchangemustbesimplifiedin orderto scale.
3

4. Whydid Congressrequire the Trusted ExchangeFramework?
Needfor the Trusted ExchangeFramework –Costs
Coststo healthcare providers
due to lack of a TrustedExchange
Framework
Healthcareorganizations are currently burdened with creating many costly,
point-to-pointinterfaces between organizations.
The Trusted ExchangeFramework will significantly reduce the need for
individual interfaces,which arecostly, complexto createand maintain, and an
inefficient useof provider and health ITdeveloper resources.
Proliferation of
InteroperabilityMethods
Basedona pilot surveyof roughly 70hospitals:
Fewhospitals usedonlyone
interoperabilitymethod.
»Amajority of hospitals required
three ormore methods
»About three in 10usedfive or more methods
Rated their own Interoperabilityas…
63%Not or a little bit interoperable
17%Somewhatinteroperable
19%Largely or Fully interoperable
4

5. Whydid Congressrequire the TrustedExchangeFramework?
Trusted ExchangeFramework and CommonAgreement
21st CenturyCuresAct - Section4003(b)
“Not later than 6monthsafter the date of enactment of the 21stCentury CuresAct,the National Coordinatorshall conveneappropriate public
and private stakeholdersto developor support a trusted exchangeframework for trust policiesand practices and for a common agreementfor
exchangebetweenhealth informationnetworks.Thecommon agreementmay include—
“(I) a common method for authenticatingtrusted health information network participants;
“(II) a common setof rules for trusted exchange;
“(III) organizational and operational policies to enable the exchange of health information among networks, including minimum conditionsfor suchexchange to occur; and
“(IV) a processfor filing andadjudicatingnoncompliance with the terms of the common agreement.”
21st CenturyCuresAct - Section4003(c)
“Not later than 1year after conveningstakeholders…theNational Coordinatorshall publish on its public Internet website,and in the Federal
register, the trusted exchangeframework and common agreementdevelopedor supportedunderparagraph B…”
5

6. Whydid Congressrequire the TrustedExchangeFramework?
Goalsof the Draft Trusted ExchangeFramework
Buildonandextend
theindustry
TheDraftTrustedExchange
Frameworkrecognizesand builds
upon the significant work done by
the industry over the last fewyears
to broaden the exchangeof data,
buildtrustframeworks,anddevelop
participation agreementsthat
enable providers toexchange data
acrossorganizationalboundaries.
Provideasingle
existingworkdoneby“on-ramp”to
interoperabilityforall
TheDraft Trusted Exchange
Framework providesa single
“on-ramp”toallowalltypesof
healthcarestakeholderstojoinany
health information network they
chooseand be able to participate
in nationwide exchangeregardless
of what health ITdeveloper they
use,healthinformationexchangeor
networktheycontractwith,orwhere
thepatients’recordsarelocated.
Bescalabletosupport
the entirenation
TheDraftTrustedExchange
Frameworkaims to scale
interoperability nationwide both
technologicallyand procedurally,
bydefiningafloor,whichwillenable
stakeholdersto access,exchange,
and userelevantelectronichealth
informationacrossdisparate
networksandsharingarrangements.
Buildacompetitive
marketallowing
alltocompeteon
dataservices
Easingtheflowofdatawillallownew
andinnovativetechnologiestoenter
the market and build competitive,
invaluableservicesthat makeuseof
thedata.
Achievelong-term
sustainability
Byprovidingasingle“on-ramp”to
nationwideinteroperability while
also allowingfor variation around
abroadersetofusecases,theDraft
TrustedExchangeFramework
ensuresthelong-termsustainability
ofitsparticipantsandend-users.
6

7. Whocan use theTrusted ExchangeFramework?
Stakeholderswho can usethe Trusted ExchangeFramework
FEDERALAGENCIES
Federal,state, tribal, and local
governments
PUBLICHEALTH
Publicand private organizations and agenciesworking
collectively to prevent, promote and protect the health of
communities by supporting efforts around essentialpublic
health services
HEALTHINFORMATION NETWORKS
INDIVIDUALS
Patients, caregivers, authorized representatives,and
family members serving in a non-professional role
PAYERS
Private payers,employers,and public payersthat pay for
programslike Medicare, Medicaid, and TRICARE
PROVIDERS
Professional care providers who deliver careacrossthe continuum, not
limited to but including ambulatory, inpatient, long-term and post-acute
care (LTPAC),emergency medical services (EMS),behavioral health,and
home and communitybased services
TECHNOLOGYDEVELOPERS
Organizations that provide health ITcapabilities,including but not
limited to electronic health records, health information exchange
(HIE) technology, analytics products,laboratory information systems,
personal health records, QualifiedClinical DataRegistries(QCDRs),
registries,pharmacy systems,mobile technology, and other technology
that provides health ITcapabilitiesand services
TrustedExchange
Framework
PART A
PART B
7

8. Whocan use the TrustedExchangeFramework?
Defining Terms:Whois the Trusted ExchangeFramework applicable to?
The Trusted Exchange Frameworkaims
to create a technical and governance
infrastructure that connects
Health InformationNetworks
together through a coreof
Qualified Health InformationNetworks.
QHIN
HIN
8

9. Whocan use the TrustedExchangeFramework?
What is a Health InformationNetwork?
Health Information Networks (HINs) are an Individual or Entity that:
1. Determines, oversees, or administers policies or agreements that define
business, operational, technical, or other conditions or requirements for
enabling or facilitating access,exchange, or useof electronic health information
between or among two or more unaffiliated individuals or entities;
2. Provides, manages, or controls any technology or service that enables or
facilitates the exchangeof electronic health information between or among two
or more unaffiliated individuals or entities; or
3. Exercises substantialinfluence or control with respect to the access,exchange, or
useof electronic health information between or among two or more unaffiliated
individuals orentities.
9

10. Whocan use the TrustedExchangeFramework?
Whatis a Qualified Health Information Network?
AQualified Health Information Network (Qualified HIN) must
meet ALLof the requirements of a HIN. In addition, it must also:
»Beable to locate and transmit ePHIbetween multiple personsand/or entities
electronically;
»Have mechanisms in place to impose Minimum Core Obligations and to audit
Participants’compliance;
»Have controls and utilize a Connectivity Broker service;
» Beparticipant neutral;and
»HaveParticipants that are actively exchanging the data included in the USCDIin
a live clinicalenvironment.
10

11. What are the benefits of the Trusted ExchangeFramework?
Trusted ExchangeFrameworkBenefits for HINs
ForQualified HINsand HINstheTrusted Exchange Framework will:
Give HINs and their participants accessto more data onthe patients they
currently serve.
»This will enhance care coordination and care delivery use cases.
The TrustedExchangeFramework ensuresthat there isnolimitation to
the aggregation of data that isexchangedamong Participants.
»This will allow organizations, including Health ITDevelopers,HINs, QCDRs,and other registries to
usethe TrustedExchangeFrameworkto obtain clinical data from providers and provide analytics
services. (Note that appropriate BAsmust be in place between the healthcare provider and
analytics provider.)
11

12. What are the benefits of the Trusted ExchangeFramework?
Trusted ExchangeFrameworkBenefits for Providers
ForHealth Systemsand Ambulatory Providers theTrusted
ExchangeFrameworkwill:
Enablethem to join one network and have accessto data on the patients
they serve regardlessof where the patient went for care.
»This enables safer, more effective care, and better care coordination.
Enablethem to eliminate one off and point-to –point interfaces
»This will allow providers and health systems to more easily work with third parties, such as
analytics products, care coordination services, HINs, Qualified Clinical Data Registries(QCDRs),
and other registries. (Note that appropriate BAsmust be in place between the healthcare
provider and analyticsprovider.)
12

13. What are the benefits of the Trusted ExchangeFramework?
Trusted ExchangeFrameworkBenefits for Patients
ForPatients and Their Caregivers, theTrusted Exchange
Frameworkwill:
Enablethem to find all of their health information from across
the carecontinuum, even if they don’t remember the name of the
provider they saw.
»This enablespatients and their caregivers to participate in their care and manage their
health information.
13

14. Howwill the Trusted ExchangeFramework work?
RecognizedCoordinating Entity(RCE)
RecognizedCoordinating Entity
TheRCEis the entity selectedby ONCthat will enter into agreementswith HINsthat
qualify and elect to become Qualified HINsin order to impose, at a minimum, the
requirements of the CommonAgreementset forth herein on the Qualified HINsand
administer suchrequirements on an ongoing basisasdescribed herein.
The RCEwill act asa governance body that will operationalize the Trusted Exchange
Framework by incorporating it into a single, all-encompassing Common Agreement to
which Qualified HINswill agree to abide. In its capacity asagovernancebody, the RCE
will be expected to monitor Qualified HINs compliance with the final TEFCAand take
actions to remediate non-conformity and non-compliance by Qualified HINs,up to and
including the removal of aQualified HIN from the final TEFCAand subsequentreporting
of its removal to ONC.
TheRCEwill also be expected to work collaboratively with stakeholdersfrom across
the industry to build and implement newusecasesthat canusethe final TEFCAas
their foundation, andappropriately update the TEFCAover time to account for new
technologies, policies, and usecases.
RCE
14

15. Howwill the Trusted ExchangeFramework work?
RecognizedCoordinating Entity(RCE)
Processfor RecognizingEntity
ONCwill release an open, competitive FundingOpportunity Announcement(FOA)in
spring 2018to award a single multi-year CooperativeAgreement to a private sector
organization or entity. The RCEwill need to have experience with building multi-
stakeholder collaborations and implementing governance principles in order to be
eligible to apply for the CooperativeAgreement.
Expectationsfor Entity
ONCwill work with the RCEto incorporate the Trusted ExchangeFramework into a
single CommonAgreementto which Qualified HINsand their participants voluntarily
agree to adhere.
TheRCEwill have oversight, enforcement,and governanceresponsibilities for eachof
the Qualified HINswho voluntarily adopt the final TEFCA.
2018
Selection
RCE
READMORE:How will itWork?
15

16. AQualified HIN (QHIN) is a network of organizations working
together to share data. QHINswill connect directly to eachother to
ensure interoperability between the networks they represent.
AConnectivity Broker is a service provided by a Qualified HINthat
provides all of the following functions with respect to all Permitted
Purposes: master patient index (federated or centralized); Record
LocatorService;Broadcastand Directed Queries,and eHIreturn to an
authorized requesting QualifiedHIN.
AParticipant is a person or entity that participates in the QHIN.
Participants connect to eachother through the QHIN,and they access
organizations not included in their QHINthrough QHIN-to-QHIN
connectivity. Participants can be HINs,EHRvendors, and other types
of organizations.
AnEndUseris an individual or organization using the servicesof a
Participantto send and/or receive electronic health info.
Howwill the Trusted ExchangeFramework work?
Structure of a Qualified Health Information Network
CONNECTIVITYBROKERQHIN
PARTICIPANTS
ENDUSERS
READMORE:QHINsin Part B, Section2
READMORE:ConnectivityBroker Capabilities in Part B,Section3
16

17. How will the Trusted ExchangeFramework Work?
PARTI CI PANTS
ENDUSERS
QHIN
QHIN
RCE
QHIN
QHIN
QHIN
QHIN
QHIN
RCEprovides oversight and governance
for QualifiedHINs.
Qualified HINs connect directly to each
other to serve asthe core for nationwide
interoperability.
QHINsconnect via connectivitybrokers.
EachQualified HIN represents a variety of
networks and participants that they connect
together, serving a wide range of end users.
READMORE:QHINs
in PartB,Section2
READMORE:
ConnectivityBroker
Capabilities in Part
B, Section3
17

18. Howwill the Trusted ExchangeFramework work?
Qualified HINRequirementsClarifications
Included Not Included
TR USTE D
EXC HANGE
FRAMEWOR K
CONTENTS
»Aminimum floor in the areas where there is
currently variation between HINsthat causesa lack
of interoperability.
»Obligation to respond to Broadcast or Directed
Queriesfor all the PermittedPurposesoutlined in
the Trusted ExchangeFramework.
»Qualified HINsmust exchange all of the data
specifiedin the USCDIto the extent such data is
then available and has beenrequested.
»Baseset of expectations for how Qualified Health
Information Networks connect with eachother.
»Afull end-to-end agreement that would be a net
new agreement.
»No expectation that every HINwill serve same
constituents or use cases.(i.e. no requirement
that Qualified HINsinitiate Broadcast or Directed
Queriesfor all of the PermittedPurposesoutlined
inthe Trusted ExchangeFramework)
»Not dictating internal technology or infrastructure
requirements.
»No limitation on additional agreements to
support usescasesother than Broadcast Query
and Directed Query for the Trusted Exchange
Framework specified permittedpurposes.
18

19. What usecasesare covered under the Trusted ExchangeFramework?
Permitted Purposes
PUBLIC
HEALTH
INDIVIDUAL
ACCESS
BENEFITS
DETERMINATION
TREATMENT
HEALTHCARE
OPERATIONS
PAYMENT
Permitted
Purposes
READMORE:Part B, Section 1
19

20. What usecasesare covered under the Trusted ExchangeFramework?
UseCases
BroadcastQuery
Sendinga request for a patient’s Electronic Health Information (EHI) to all Qualified HINsto
havedata returnedfrom all organizations who haveit.
Supports situations where it is unknown who mayhaveElectronic Health Information about
apatient.
Directed Query
Sendinga targeted request for a patient’s Electronic Health Information to a specific organization(s).
Supports situations where you want specific Electronic Health Information about a patient, for example
data from aparticular specialist.
Population LevelData
Querying and retrieving Electronic Health Information about multiple patients in a single query.
Supports population health services, suchasquality measurement,risk analysis, and other analytics.
READMORE:Population
level data- Part B,
Section8
READMORE:Broadcast
and Directed Queries-
Part B, Section 5.4 and
Section3
20

21. TheUSCDI(https://www.healthit.gov/sites/default/files/draft-
uscdi.pdf) establishesa minimum setof data classesthat
are required to be interoperable nationwide and is designed
to be expanded in an iterative and predictable way over
time. Data classeslisted in the USCDIare represented in a
technically agnosticmanner.
1. USCDIv1—Required—CCDSplus Clinical Notes andProvenance
2. Candidate Data Classes—Under consideration forUSCDIv2
3. Emerging Data Classes–Begin evaluating for candidate status
What usecasesare covered under the Trusted ExchangeFramework?
USCoreData for Interoperability (USCDI)GlidePath
U.S. COREDATAFORINTEROPERABILITY
USCDIv1
Required
Candidate
DataClasses
UnderConsideration
Emerging
DataClasses
BeginEvaluation
21

22. What usecasesare covered under the TrustedExchangeFramework?
Expansion of USCoreDatafor Interoperability (USCDI)
Asthe USCDIexpands, Qualified HINs
and their Participants will be required
to upgrade their technology to support
the data specified in the USCDI.
Some Candidates willbe Accepted to USCDI
Some Candidates Require FurtherWork
Some Emerging Elements BecomeCandidates
Some Require Further Work
2021 USCDI
*NEW
*NEW
*NEW
*NEW
*NEW
*NEW
*NEW
*NEW
*NEW
*NEW
*NEW
*NEW
2020 USCDI
*NEW
*NEW
*NEW
*NEW
*NEW
*NEW
*NEW
2019USCDI
*NEW
*NEW
*NEW
*NEW
2018USCDI
Supported DataElements
Candidate DataElements
Emerging DataElements
https://www.healthit.gov/sites/default/files/draft-uscdi.pdf
22

23. What fees can be charged under the Trusted ExchangeFramework?
Attributable Costs andServices
ReasonableAllowable Costs:arecoststhat wereactuallyincurred; areadirect cost or areasonableallocation of indirect costsfor the attributable
servicesbelow; arebasedon objective andverifiablecriteria; andarenot variable dependingon which QualifiedHINis beingcharged
Qualified HINsmay, though they are not required to, charge attributable service costs to other Qualified HINs,
provided they are reasonable and non-discriminatory.
Attributable Services mayinclude:
DDeveloping or modifying interfaces orAPIsto be able to exchange data in the USCDI;
DDeveloping or revising the Connectivity Broker required in the Trusted Exchange Framework; and
DEmploying legal services necessary to review the Trusted Exchange Framework and amend participation and BusinessAssociate
agreements to meet the requirements of the Trusted Exchange Framework.
READMORE:Fees-Part B, Section 5.3
23

24. What privacy and security protections does the Trusted ExchangeFramework guarantee?
Definitions
Participant
Apersonor entity that participates in aQualified HIN
EndUser
Anindividual or organization using the services of a
Participant to send and/or receive electronic health info
Individual
Apatient or their authorized representative
READMORE:Individuals-
PartB,Section6.1.1and 7.2
READMORE:Participant
obligations-PartB,Section9
24
READMORE:End User
obligations-PartB,Section10

25. What privacy and security protections does the Trusted ExchangeFramework guarantee?
Privacy/Security: IdentityProofing
Individuals
EachQualified HINshall require its EndUsersand Participants to proof
the identity for Individuals at a minimum of IAL2prior to issuanceof
credentials. Individuals must provide strong evidence of their identity.
EndUsersandParticipants
Each Qualified HINshall require proof of identity for Participants
and participating End Usersat a minimum of IAL2prior to issuance
of credentials.
IAL 2 REQUIREMENT DESCRIPTION
Evidence
»One(1) piece of SUPERIORor STRONGevidence;OR
»Two (2) pieces of STRONGevidence;OR
»One(1) piece of STRONGevidence plus two (2)pieces of ADEQUATEevidence
Validation
»Eachpiece of evidence must be validated with a process able to achieve the samestrength asthe evidence presented.
»Validation against athird-party data serviceSHALLonly be usedfor onepiece of presentedidentity evidence.
AddressConfirmation
»TheCredential Service Provider (CSP)SHALLconfirm addressof record through validation of the addresscontained on any
supplied, valid piece of identity evidence.
Identity proofing isthe processof verifying a personiswho they claim to be. The Trusted Exchange
Frameworkrequiresidentity proofing (referred to asthe Identity AssuranceLevel(IAL) in SP800-63A).
READMORE:
Part B, Section6.2.4
25

26. What privacy and security protections does the Trusted ExchangeFramework guarantee?
Privacy/Security: Identity Proofing - EXCEPTIONS
Trusted Referee andAuthoritativeSource
In instances where the individual enrolling cannot meet the identity evidence
requirements specified, organization staff mayact asa trusted referee, allowing
them to use personal knowledge of the identity of patients when enrolling
patients assubscribersto assist in identity proofing the enrollee.
Antecedent Event
Staff mayalso act asauthoritative sourcesby using knowledge of the identity of
the individuals (e.g., physical comparison to legal photographic identification
cards suchasdriver’s licensesor passports,or employee or school identification
badges) collected during an antecedent,in-person registration event.
Qualified HINs,Participants,or EndUsersare responsible for proofing Individuals at the
IAL2level, HOWEVER:
Forexample,IAL2identity proofing for an Individualcan
beaccomplishedbytwoofthe following:
1. Physical comparison to legal photographic identification
cards such as driver’s licenses or passports, or employee
or school identificationbadges,
2. Comparison to information from an insurance card that
hasbeen validated with the issuer, e.g.,in an eligibility
check within two days of the proofing event, and
3. Comparison to information from an electronic health
record (EHR)containing information entered from
prior encounters.
PREFERRED
Individualpresents
for treatment
End Users and Participants must
collect and validate Evidenceof Identity
Alternative Acceptable Forms of IdentityValidation
Personal Knowledge Previous Treatment
Sucessful
Identity
ProofREADMORE:
Part B,Section
6.2.4
26

27. What privacy and security protections does the Trusted ExchangeFramework guarantee?
Privacy/Security: Authentication
Each Qualified HIN shall authenticate End Users,Participants,
and Individuals at aminimum of AAL2,and provide support for at
least FAL2or, alternatively,FAL3.
Connecting to a Qualified HINor one of its Participantwill require
two-factor authentication. Alist of acceptable second factors
(in addition to a username and password) can be found at
https://pages.nist.gov/800-63-3/sp800-63b/sec4_aal.html.
QHIN
End Usersand Participants
AAL2
Authentication
Supportfor FAL2
or FAL3
Individuals
Digital authentication isthe processof establishingconfidence in a remote useridentity communicating
electronically to an information system. NISTdraft SP800-63Brefersto the level of assurancein
authentication asthe Authenticator AssuranceLevel (AAL). FederalAssuranceLevel(FAL)refersto the
strength of an assertionin a federated environment, usedto communicateauthentication and attribute
information(if applicable) to a relying party (RP).
READMORE:Part B, Section6.2.5
27

28. What privacy and security protections does the Trusted ExchangeFramework guarantee?
Privacy/Security-Breach Notifications andCUI
“The Qualified HIN shall complywith all applicable
Breachnotification requirementspursuantto 45CFR
§164.402 of the HIPAARegulations whichaddresses
Breachnotification. The Qualified HIN further shall
notify, in writing, the RecognizedCoordinatingEntity
without unreasonabledelay,but nolater than fifteen
(15) calendardays, after Discoveryof the Breachin
order to allow other affected parties to satisfytheir
reportingobligations.Uponreceiptofsuchnotice,the
RecognizedCoordinating Entity shall be responsible
for notifying, in writing, other Qualified HINsaffected
bytheBreachwithinseven(7)calendardays.”
“Information the Governmentcreatesorpossesses,
or that an entity createsor possessesfor or on
behalf of the Government, that a law, regulation,
or Government-wide policy requiresor permits
an agencyto handle usingsafeguarding or
dissemination controls” (32 C.F.R.§2002.4(h)).”
BreachNotification
Regulations
Controlled
Unclassified
Information(CUI)
!
READMORE:Breach Notification-Part B, Section 6.1.3 and 6.1.5
28

29. 29
Whenwill the Trusted ExchangeFramework be implemented?
Timeline
AUGUST
2017
SEPTEMBER
2017
NOVEMBER
JANUARY
2018
LATE
2018
1st ListeningSession
30 daypublic
commentperiod
2nd ListeningSession
2017
3rd Listening Session
Draft TrustedExchange
Framework released
for publiccomment
Release
FinalTEFCA
JANUARY-
FEBRUARY
2018
MID
2018
45 day public
commentperiod
Selection ofa Recognized
Coordinating Entity