1. Saturday, January 27 & Sunday, January 28
HL7 FHIR Connectathon
Saturday, January 27 & Sunday, January 28

2. Connectathon Overview
FHIR Connectathon Objectives
Track Selection
Timeline of Activities
Participant Opportunities
Location of Support Materials
How to get your questions answered

3. What’s to be gained by attending a FHIR Connectathon?
Join a community of FHIR users
Develop and test your system and use of the standard
Demonstrate what’s possible
Refine the FHIR Specification

4. Track Selection Review track details to find your focus
Select your track in the Pre-Connectathon Survey
Connect with your track lead in advance
We recommend participating fully in only one track

5. Timeline of Activities
Registration
On-Site
Saturday
Breakouts: Orientations on FHIR and Test Tools
Working, Testing
Sunday
Working, Testing, Wrap Up

6. Participant Opportunities
Join in the community
Bring Questions and share your challenges
Help others by sharing your knowledge
Bring your development system ready to go
Have your application installed
Have you environment configured
Raise questions that identify hot topics
Record your Results
What happens at Connectathon stays at Connectathon.
It’s OK to fail.

7. Location of Support Materials
FHIR Specifications:
R4 ballot:
R3 final:
R2 final:
Track Definition
Tracking Results
(see CCDE tab)
Gforge:
FHIR Chat:

8. How to Get your Questions Answered
FHIR Chat:
Track Lead: Aaron Seib
Track Lead: John Moehrke
On Site Issues: Sandy Vance )

9. Intro to the CCDE Track Introduction to Track Lead (Aaron & John)
Track Definition
List of participating systems in the track (& contacts?)
References to the servers & clients for the track
Goals for this track

10. CCDE Track Definition
Consumer Centered Data Exchange is any exchange of health information where the consumer’s involved in the transaction. This involvement can take many forms, including:
As part of an interactive authorization such as Oauth
As part of an asynchronous authorization process such as an eConsent.
FHIR specifications are being used by implementers of these approaches across the country and beyond. The objective of the track is to learn more about how the specs are being used and learn more about changes to the spec that are warranted or would increase clarity for the FHIR community and other stakeholders.

11. CCDE Track – Consumer Centric Definition
As a consumer I want to be able to:
Authorize a Data Holder (EMR, Payer Systemto share my data with the Consumer Controlled App of my Choice. (CMS BB-API)
Set my privacy preferences in a Consent Capture tool (MiHIN) so that:
A) A distribution system can share my data with authorized 3rd
parties on my behalf. (MiHIN)
B) A disclosing system can constrain what is shared at a
fine level of granularity with authorized end users.
(HL7 Security WG team)

12. Three Anchor Systems
CMS API Team – represents an “interactive authorization” – referred to as Architecture 1 on the HL7 Wiki
MiHIN – represents both the Consent Capture tool and a Distribution System
HL7 Security WG team – Represents a disclosing system able to handle fine grained consent preferences.

13. Client and Server References
We will be using the new Connectathon Management Tool to publish information about how to connect to the various servers and systems that are going to be available for participants.
This is the first time we’ll be using this tool so please let us know if there is any confusion.

14. Track Goals -
Continue to develop an understanding of what the main specification of the US core IG should say about enabling consumer-centric use cases. Specifically we want to learn more about how the specifications are used today in these three architectures and examine gaps that may need to be addressed to enable the Consumer-Centric Use cases described with an emphasis on:
Developing a better understanding of how the Authorization\Consent language is related to the Scopes supported by 3rd party systems and how the FHIR Specifications can best be used to ensure stakeholder’s understanding of what is being authorized to share\disclose.
Consideration by the community regarding how a consent can be used as inputs to multiple steps across a transaction that transverses more then one architecture (see Arch_3 diagram where Consent informs distributions server and disclosure process independently).
The use of security labels in supporting fine grained access control.

15. Track Goals – Consumer Centric View
As a user, when I am interactively sharing data with the app of my choice or authorizing the sharing of my data on my behalf by a third party, I want to trust that I understand what is being disclosed and to whom. There needs to be a correlation between what is indicated as authorized in Consumer facing interfaces and what the scopes are able to enforce. There is the trivial case where I am willing to share all and the non-trivial case where I want to constrain what is disclosed. How do we ensure that the scopes and the consumer facing information that describes what those scopes are capable of doing are appropriately aligned?

16. High level Architectures - interactive
Anchor Participant: CMS BB API Team

17. High level Architectures use eConsent to manage fine grain disclosure to end user
Anchor Participant: HL7 Security WG Team

18. High level Architectures – distribution to end points that handle fine grain disclosures.
Anchor Participant: MiHIN

19. Thank you
sandra Connectathons are like a marriage. You get out of it what you put into it.