Privacy on FHIR
Meeting Agenda and Minutes
Agenda & Meeting Minutes
Purpose of Meeting: Introductions and Review of Use Cases
Date & Time: Tues 30 Sep 2014, 4-5 PM Eastern
Location: United States: +1 (626) 521-0016 United States (toll-free): 1 866
899 4679
Access Code: 782820893
Meeting. https://global.gotomeeting.com/join/782820893
Audio PIN: Shown after joining the meeting
Meeting Password: FHIR
Meeting ID: 782-820-893
POF WIKI:
http://wiki.siframework.org/Privacy+on+FHIR
Facilitator: Mike Davis
Meeting Support:
Attendees: O = Onsite Attendee; P = Phone Attendee; X = Not Attending
o Mark Russell (MITRE)
Adrian Gropper (PPR)
o Mike Davis (VA)
Brynn Mow (Jericho)
Dave Hill (MITRE)
David Staggs (Jericho)
Debbie Bucci (ONC)
Duane DeCouteau (VA)
Mike Dufel (Jericho)
o Mohammad Jafari (VA)
o Nagesh Bashyam (Dragon) (ONC)
o Nate Gould (DoD)
Gerry Gebel (Axiomatics)
Ross Freeman (Jericho)
John Pitale (VA)
Taylor Gill (Jericho)
Johnathan Coleman (ONC)
Terry Luedtke (VA)
Josh Mandel (MIT)
Judy Fincher (VA)
Justin Richer (MITRE/MIT)
Kathleen Connor (VA)
o
o
o
o
o
o
o
o
Thomas Hardjono (MIT)
Tim McGrail (VA)
Tony Mallia (VA)
o
William Israel (Jericho)
Ken Salyard (SAMHSA)
Agenda
Page 1 of 7
Privacy on FHIR
Meeting Agenda
ID Topic
1 Minutes, Agenda
Presenter
Kathleen, Mike
5 min
2
Updated Use Cases/Storyboards (Review comments Friday)
Kathleen
5 min
3
HIE on FHIR Updated UMA Diagram (Finalize today)
Mohammad
5 min
4
HIE on FHIR Sequence Diagram (Finalize today)
David Staggs
10 min
5
MIT Update (Minutes?)
Adrian, Debbie
10 min
6
Resource Discussion (Bill of Lading)
All
7
HL7 Demo/Code Models
Duane
Project Deliverables
HIMSS Deliverables
1. “Wow” powered use cases meant to capture
imagination and win hearts and mind [aka “Elevator
Pitch”]
All
2. Storyboards intended to convey business
requirements and standards landscape to developers
3. Architecture
a) Choreographies and data element exchanged
b) Diagram showing subsystems and connections
between them
c) Flow diagram showing activities and message
movement between subsystems
d) Elements passed in the Tokens or request headers
relevant to access control
4. Reference Model (Open source executable code
to serve as model for developers, models,
requirements and profile)
1. “Wow” Power
 PoF Overview Presentation and HIMSS Slide
(1 per booth)
 Kathleen Use cases
2. Storyboards
 TBD
3. Architecture
a) Dragons Diagrams
b) Mohammad Diagrams
c) Mohammad Sequence Diagrams
d) Project Brief
4. Reference Models
 VA provided SLS/PPS, Test Models.
 SAMHSA Consent2Share open CDMS
Key Discussion Notes
ID Topic
1
HoF Model Diagram and Booth Diagrams will be updated to indicate that the End User is a FHIR Client and that the
ACS on the Requester side is control by the Requester’s RS to enforce access permissions conveyed by Security
Labeled/Privacy Protected disclosure from Custodian RS.
Agenda
Page 2 of 7
Privacy on FHIR
Project Deliverables
2 Wrt to HoF Model Diagram and Booth Diagrams, the senders and receivers could be any of the HIE actors, which are
HIPAA Covered Entities/~Covered Entities (e.g., SSA)/Business Associates (e.g., HIEs).
3 PoF should highlight the distinguishing business/policy requirements among HoF/AoF/CoF that result in differences in
the manner in which each flow is architected. E.g., because HoF custodians may have policies that override the
patient’s preferences (or to which the patient’s preferences must be constrained via policy adjudication), the flows
need to support a redirect from Custodian’s ACS to Custodian’s preferred AS, thereby possibly overriding the Patient’s
AS authorizations, which might block a Requester from accessing resources that the Custodian would otherwise
disclose per applicable policy.
4 Assume that CDMS has digital signature capabilities.
Action Items
ID
Action Items
1
Assigned to
3
Due Date
How do we constrain the
scope of the use cases? We
have seven months to
complete and test Demo.
What resources are available
and what can be provided by
each of us?
Post materials to S&I PoF page
http://wiki.siframework.org/Pr
ivacy+on+FHIR
Status
Comments
0926
Added
Standards
6/2014
All
2
Assign
Date
Mike
9/2014
0912
KC
0908
0819
COMPLETE
Three
identified.
0613 Need
to know
how many
separate
items.
For Review
0923
Complete
Possible multiple
booths or POD.
1. Patient App
scenario
2. Consent
Directives
3. HIE
4. Standards on
FHIR
0829 Bill of Lading in
today’s presentation
0923 Documents
starting to be
uploaded.
0913 Dragon assisted
Mike with uploading
to the ONC PoF Wiki
4
Update the HoF diagram to
include a single trusted AS for
the Happy Path.
Tony and
Mohammad
9/22
9/26
0926
Complete
Accepted by Group
Agenda
Page 3 of 7
Privacy on FHIR
Next Meeting
Date:
3 OCT 2014
Time:
1-2 PM (Eastern)
Location:
Dial-In Line:
Debbies GoToMeeting
September 30 Minutes
Mike covered agenda. Kathleen reviewed Sept. 26 Minutes.
Mohammad walked through the updated HoF Diagram. Discussion ensued to clarify the ACS on the Client/Requester side.
Group came to agreement that both the Requester and the Custodian RS actors in the HoF Model Diagram should be generic
as to types of HIPAA Covered Entities/~Covered Entities (e.g., SSA)/Business Associates (e.g., HIEs).
Mohammad to update.
Mike Davis walked through the HoF Booth Diagram (below) and asked for comments.
Debbie thought this diagram is cleaner showing the AS in a neutral zone. Josh agreed that despite the demo only featuring one
AS, having the AS in the neutral zone “helps tell the story”. However, he voiced “OAuth nerd” reservations about Steps 4
through 8 because there is “No user on the wire.”
Agenda
Page 4 of 7
Privacy on FHIR
Adrian prompted a round of discussion about how the patient’s privacy preferences are consumed/adjudicated by AS/CDMS
given that the patient gives AS Authorization/CDMS that may not be revisited every time these are enforced. Debbie asked if
the diagram would be simpler without the precursor Steps 1 – 3. Mike Davis noted that while the precursor steps are
redundant with CoF, these are important links to precursor booths.
Team came to similar conclusion about the HoF Booth Diagram as for the HoF Model Diagram – the senders and receivers
could be any of the HIE actors.
Mike Davis asked whether to re-label Healthcare provider/Healthcare consumer. Adrian approved, no one objected. So HoF
Booth and model diagrams approved.
David walked through the HoF Sequence diagram. Kathleen asked if a rolled up version of David’s Sequence Diagrams could
illustrate where HoF and AoF are not aligned to highlight how the architecture is differently structured because of different
policy domains.
Adrian stated that he found the HoF Sequence Diagram confusing without Patient GUI.
David stated that CDMS is separate from custodian. Custodian presents a document to patient for authorization/CD that
conforms to the custodian’s pre-approved CD forms. David offered AG to mark up the diagram. David described a workflow
for the CD.
Mike Davis stated that he wasn’t sure that the CDMS is the custodian of the patient’s CD if the custodian needs a signed CD
that the Custodian must maintain and use for enforcement. But patient may update.
AG – GUI should be in Custodian.
Mike Davis stated that CDMS can create a Custodian specific CD. Patient can fill out the Custodian CD preapproved form and
send as FHIR resource to the Custodian.
Mike Davis asked what changes need to be made. He thinks that the Custodian makes decision on what parts of the CD the
Custodian gets to approve, and then the patient must either sign as accepting or decline. Custodian presents a GUI – after the
patient provides privacy preferences
Adrian described how the MA HIE is implementing an electronic signature capability for the CD form GUI. Mike Davis described
the different types of FHIR CD templates that are being developed for FHIR. Not all will need to be adjudicated against a
Custodian’s policies. Mike asks David to add a line indicating that the Custodian adjudicates the patient’s preferences and
sends the “pre-approved CD” to Patient’s CDMS for digital signature.
Adrian wanted the PoF models to show how the CDMS has the GUI with signature capacity. Mike Davis asserted that in order
to keep electronic and avoid manual adjudication, the CDMS, which is trusted by the custodian, provides a patient signed CD
with CDMS notary signature over it.
Mike Dufel asked why does this have to be so complex – why not a lightweight electronic signature? Mike Davis responded
that the VA attorneys wanted something legally accountable for the patient, so the VA needs a consistent electronically
computable digital signature, i.e., not one that requires a person to compare the previous electronic signature with a
subsequent electronic signature. Everybody knows how to process a digital signature. Also, the FHIR CD Resource is designed
to be a signed Resource.
Agenda
Page 5 of 7
Privacy on FHIR
David stated that the Jericho CDMS has an electronic signature service/notary service. His concern is to have a central place
for patient to go to for CD.
Mike Davis asserted that in order to keep electronic and avoid manual adjudication, the CDMS, which is trusted by the
custodian, provides a patient signed CD with CDMS notary signature over it.
Mike Dufel asked why so do signatures have to be so complex – why not a lightweight electronic signature?
Mike Davis responded that the VA attorneys wanted something legally accountable for the patient. However, VA needs a
consistent electronically computable digital signature, i.e., one that does not requires a person to compare the previous
electronic signature with a subsequent electronic signature. Everybody knows how to process a digital signature.
At the top of the hour Mike Davis adjourned the call and asked the team to please take a look at Bill of Lading and minutes for
Friday, October 3rd call.
Agenda
Page 6 of 7
Privacy on FHIR
Agenda
Page 7 of 7