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

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

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

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

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

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.

Location of Support Materials FHIR Specifications: R4 ballot: http://hl7.org/fhir/2018Jan/index.html R3 final: http://hl7.org/fhir/STU3/index.html R2 final: http://hl7.org/fhir/DSTU2/index.html Track Definition http://wiki.hl7.org/index.php?title=201801_Consumer_Centered_Data_Exchange Tracking Results https://docs.google.com/spreadsheets/d/11QbX8iB49s_-YMP6GmEej41uT58ir4f6W2EvMEe4cUg/edit#gid=1775022935 (see CCDE tab) Gforge: https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemBrowse&tracker_id=677 FHIR Chat: https://chat.fhir.org/

How to Get your Questions Answered FHIR Chat: https://chat.fhir.org/#narrow/stream/consumer-apps Track Lead: Aaron Seib (aaron.seib@nate-trust.org) Track Lead: John Moehrke (john.moehrke@gmail.com) On Site Issues: Sandy Vance (sandra.vance@aegis.net )

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

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.

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)

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.

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.

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.

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?

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

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

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

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