1. A little about NATE… Policies, practices and technologies…
…that enable and promote trusted exchange…
…within and across state lines...
…among unaffiliated organizations…
…and the consumers they serve.

2. Who Is NATE?
The National Association for Trusted Exchange (NATE) is a not-for-profit membership association focused on enabling trusted exchange among organizations and individuals with differing regulatory environments and exchange preferences
Incorporated on May 1, 2013
From and including: Wednesday, May 1, 2013 To and including: Wednesday, January 18, 2017
Result: 1359 days
It is 1359 days from the start date to the end date, end date included
Or 3 years, 8 months, 18 days including the end date
Alternative time units
1359 days can be converted to one of these units:
117,417,600 seconds
1,956,960 minutes
32,616 hours
1359 days
194 weeks and 1 day
372.33% of a common year (365 days)
NATE is a 501(c)(3) Mission Driven Organization Focused on Enabling Trusted Exchange that Includes the Patient
NATE’s Membership is Open to Government Entities, Non-Government Organizations, Associations and Individuals

3. NATE Members Include… CONSUMER CONTROLLED APPS
STATES, NATIONAL ASSOCIATIONS AND INTERNATIONAL PEERS

4. Our First Federal Agency Member
“Participating in NATE allows VA to continue to be a national leader in enabling our Veteran patients to take control over their health information and become informed and active partners in their overall healthcare.”
-- Dr. David Shulkin
U.S. Secretary of Veterans Affairs
Those That Take Consumer Engagement Seriously Join NATE

5. A little about what we do…

6. What is the NBB4C?
The NATE Blue Button for Consumers (NBB4C) Trust Bundle is a trust mechanism that provides, to HIPAA covered entities that use Direct, a facile method of exchange with Consumer Facing Applications that must meet or exceed a specific set of regulatory criteria and user experience requirements in order to become a NATE-QE
History of how we developed the Trust bundle evaluation criteria.
NATE Makes It Easier for Providers to Share Health Information With Their Patients So That Their Patients Can Do What They Want With It

7. NATE’s Blue Button Trajectory Analysis to Establish NBB4C2
Dec
2013
Jun
2014
Oct
March
2015
VA - NATE Begins
Analysis to Establish NBB4C2
NBB4C
Goes Live
PHR Ignite
Phase 2 Begins
Call for Comment
on NBB4C Policies
August
2016
NATE Takes
Over BB+
NATE awarded PHR Ignite Grant -
10/14 Call for public comment
11/15 – BB+ depricated
August 2016: VA reaches out to NATE to discuss creation of bundle that meets federal requirements for sharing with consumers.
HIMSS 17
Demonstrate
NATE
Blue
Button
Directory
PHR Ignite Pilot Award By ONC
BB+
Deprecated
Nov
2015

8. NATE Blue Button for Consumers (NBB4C) Consumer Controlled App Members

9. Refining our 2017 priorities based on advances made in 2016
Blue Button Directory for Consumers
TrustHarbor
BLUE BUTTON DIRECTORY
FOR CONSUMERS

10. Blue Button Directory For Consumers
An out of the box solution to a persistently wicked problem
Rather than trying to overload the purpose of existing P2P4Tx Trust Bundles
What if we tried to bring the consumer’s “Individual Right of Access” request to the part of the health enterprise responsible for responding to these requests today?
Would that result in a win-win for consumers and providers alike?

11. Find us at the HIMSS17 INTEROPERABILITY SHOWCASE
Consumers are requesting their medical records and providers want to share them but there is often a workflow disconnect between the two.  NATE and demo participants demonstrated how a simple enabling infrastructure can alleviate this problem.  The NATE Blue Button Directory allows patients to discover how best to submit their request for health information and establishes a secure end-point for the covered entity’s staff responsible for managing these requests. NATE demonstrated the registration of the organization by the appropriate staff (e.g., medical records department) in a FHIR-based directory, and showed how the provisioning of a Direct address enables bi-directional exchange with those consumer-controlled apps recognized by NATE’s trust community.

12. Secondary Market of App Endorsers Consumer Apps
Trust
Harbor
Secondary Market of App
Endorsers
Consumer
Apps
Provider’s Consumer Facing APIs
Consumer apps register to TrustHarbor
Verified endorsers apply signed software statements
Access TrustHarbor via APIs to verify endorsements
Enable dynamic registration of consumer apps that meet criteria
Endorsers register to TrustHarbor
Apply endorsements in a verifiable way
TrustHarbor will facilitate trustworthy exchange at the intersection of consumer apps, provider’s APIs and validated endorsers.

14. July 2016 Proposal Trust Harbor: A Win-Win-Win Solution
Data Holders
Need to validate applications requesting API access
Common checks
App Developers
Need to be approved by each data holder
Common responses to checks
Consumers
Need a framework to help them decide whether to trust an app with their data

15. The TrustHarbor is a public registry and API of:
Consumer controlled apps
Endorsing bodies
Application endorsements
It supports registration of two actors and one action
To get the conversations started I thought it would help to talk about the different kinds of entities that interact via the TrustHarbor and the resulting relationships. To make this as accessible as possible I thought it might help to walk you through the process from the perspective of the different parties that would be engaged by the TrustHarbor.

16. Two actors, one action; many relying parties and supported use cases
Register as an Endorser
Endorser – an organization that provides a certification, accreditation, “seal-of-approval” or otherwise endorses consumer applications
Could include entities that provide technical certification such as those related to IdM (SAFE-BioPharma; Kantara)
Or accredit for operational compliance to a set of evaluation criteria that include non-technical policy requirements (EHNAC; NATE)
Or align with qualitative preferences such as usability for different populations (VSO Association for Vet Friendly Apps; NPWF’s ‘Top 10 Family Friendly Consumer Apps’).
To get the conversations started I thought it would help to talk about the different kinds of entities that interact via the TrustHarbor and the resulting relationships. To make this as accessible as possible I thought it might help to walk you through the process from the perspective of the different parties that would be engaged by the TrustHarbor.
We Make It Easier for Providers and Consumers to Trust Consumer Applications and Easier for Consumers to Use Them

17. Register as an Endorser
What information should be collected about an endorser?
What qualifies an organization to be recognized as an endorser?
How do we govern the removal of endorsers?
Legal agreement?
An endorser may have more than one type of endorsement that they provide

18. Meaning of an Endorsement
For each endorsement that an endorser provides, what information do we need to make available to relying parties in order to determine if they trust them as a 3rd party?
Do we define levels of endorsement? Each higher level endorsement comes with more validation requirements

19. Register as an Application
What information should be collected about a consumer app?
What qualifies a vendor to be recognized as a consumer controlled app? NBB4C criteria sufficient?
Legal agreement?
How do we govern the approval or removal of appropriate vendor’s offerings?
A vendor may have more than one offering that may support different endorsements based on target market and use case
Update the evaluation criteria for the NBB4C?
What should we require consumer apps to publish about how they do business?

20. Apply Endorsement to Registered Application
What guidance do we provide to relying parties about frequency of TrustHarbor verification?
Should they verify status of an endorsement for each transaction? Can they cache verifications?
How do we notify relying parties about endorsement revocation?

21. How Does it Work for a Data Holder?
Developer brings web token(s) from endorser(s)
Validated token(s) enables consumer app to skip some/all data holder registration requirements
Validated token(s) may raise throttling limits for vendor’s use of an API
Relying party queries TrustHarbor central registry to determine token(s) is still valid
Relying party performs regular, out-of-band queries to registry to identify token(s) revocation or expiry
On the web it is not unusual for APIs to limit the number of requests they handle from a given endpoint. eg requests/hr. Major web properties use this to generate revenue. ie. Pay for fatter bandwidth.
In the CMS situation we are looking to balance a number of issues. One of those is to allow unvalidated apps to gain access.
The CMS API might require the beneficiary to go through extra steps to confirm that they want to use an unvalidated app. We have to allow for this otherwise we could be at odds with OCR pronouncements regarding consumer access to their data.
The CMS API may also choose to place restrictions on unvalidated apps for example limiting the number of inquiries to the API in a given period, or limiting the number of accounts that can connect to the app. This would allow developers to innovate (eg at Hackathons, or to produce an app for their family) but would encourage them to get validated if they want to make serious use of the app.
Validated apps would be exempted from those restrictions.

22. Defining Safe Harbors using TrustHarbor – hypothetical
What endorsements would be required to establish a safe-harbor for consumers to share data collected by the consumer from another provider?
i.e., consumer directed exchange
Updates provider organization’s medical record with new clinical information
Endorsements (valid tokens) from recognized endorsers that cover following:
App is consumer controlled (NATE/CARIN)
High confidence in identity of consumer (Kantara|SAFE-BioPharma)
Provenance of data from original provider is such that receiving provider is confident it hasn’t been modified before receipt (SDO)
Security certification that data sent by vendor does not introduce security risks (EHNAC|HITRUST)

23. Defining Safe Harbors using TrustHarbor – hypothetical
Endorsements (valid tokens) from recognized endorsers that cover following:
App is consumer controlled (NATE/CARIN)
High confidence in identity of consumer (Kantara|SAFE-BioPharma)
Provenance of data from original provider is such that receiving provider is confident it hasn’t been modified before receipt (SDO)
Security certification that data sent by vendor does not introduce security risks (EHNAC|HITRUST)

24. Sign Up on NATE’s Website to Stay Informed:
NATE-trust.org