Skip to end of metadata
Go to start of metadata

Chair: @Christopher Shawn

Scribe: @Suzanne Gonzales-Webb 

Weekly calls Tuesdays 3PM ET

FreeConferenceCall Online Meeting Link

Dial-in Number (United States): (515) 604-9567 Access Code: 880898#

Agenda Topics 

 Minutes Approval


2019-07-30 Security WG Agenda/Minutes

Motion to Approve with amendment to update # of approval 7/30 Minutes :   Moved: Kathleen /  Second Suzanne

Objections: 0  Abstentions: 0; Approve: 8

Share with Protections

Mike Davis

Updates to Sender Responsibilities. 

  • SwP Create
  • SwP Send


  1.  For patient changes request (parameters of consent) what happens to the persisted data?
    1. the data that is sent persists, information is provided is after, the information will now follow the updated policy
  2. recipient has jurisdictional latitude to change or impose either own security labels or policies–they have a more restrictive policy–what happens to the 
  • re Patients (applying their own policy); right now, the way this is written, the sender applies their policies to the information.  the recipient is not allowed to change the sender's policy—that is conveyed to the recipient.  we don’t' want recipients to ignore a more restrictive policy.   There has to be trust at the higher security classification conveys the information. 
  • the same information must remain the same and should …. 

This bring up a good point–if the recipient brings up the point with the 

  • we will need to go through every permeation - we will see if amenable to a table to complete (per Mike)

 PSAF Provenance (Volume 3)

Final PSAF Package submitted to HL7 HQ.  Thanks to authors, contributors and commenters.

PSAF Ballot Spreadsheet - also available on Ballot Desktop.  Please Vote!

Reminder that only the PSAF Vol. 3 Provenance DAM is open for comment:

Important Note to September 2019 Ballot Voters

The September 2019 Privacy and Security Framework (PSAF) ballot is a package containing all of the Volumes developed to date under the PSAF Project Scope Statement 914. See the September Ballot Announcement:

The Privacy and Security Architecture Framework (PSAF) is comprised of:

  • Volumes 1 and 2, and the Informative Guidance document for Trust Framework for Federated Authorization conceptual and behavioral models (TF4FA), which passed normative ballot in May 2018. Being normative, it is not in scope for September 2019 ballot comments.
  • Volume 3 Provenance, a conceptual model addressing topics needed for trustworthy information exchange, passed normative ballot in January 2019. It has been significantly restructured as a Domain Analysis Model (DAM) for the September 2019 ballot based on input from commenters and stakeholders. Volume 3 Provenance is in scope for September 2019 ballot comments.
  • Volume 4 Audit, a conceptual model for the audit service interfaces. This document was approved as normative in January 2017 under the title HL7 Version 3 Standard: Privacy, Access and Security Services (PASS) - Healthcare Audit Services Conceptual Model, Release 1 (PI ID: 1264). However, the Security Work Group missed the publication deadline, so this volume was re-balloted and past normative during the May 2019 cycle. Being normative, it is not in scope for September 2019 ballot comments.
  • The Security Work Group decided to combine all volumes into one ballot package to keep them moving in tandem through balloting, publication and potential reaffirmation.

As stated, only Volume 3 Provenance, is in scope for comments for September 2019.

Inclusion of Volumes 1, 2, and the TF4FA Guide, and Volume 4 in the September PSAF ballot package also affords voters an opportunity to review the wider privacy and security context in which the Provenance DAM was developed, and to which it contributes a significant component.

Reed Gelzer: most comments were in scope - can work on offline, rather than generate more scope questions on the WG call.

Basic Provenance

Basic Provenance Ballot Spreadsheet - also available on Ballot Desktop. Please Vote!

FHIR Security

John Moehrke

  • Comment received from an expert in W3C Prov who could not figure out what our target element was supposed to contain 
    • added a clarification to W3C model and FHIR model - wherein the target is the entities are created or update, and entities are the things that are used–adding linkage materials
  • The second comment was a question from someone focused on REST and therefore CRUDE which is in our Audit event model, they were objecting to the use of execute action when the interaction was a query or a search, given that in the purest RESTful environment was using a 'get'.... 
    • the use of execute is historic and do not want to break with the historic model, secondly, even a get as a query has a search parameters where the servers has to execute and the result of the search has to produce the items... which is more close to an execute than a 'get'
    • this improved the text (added) to differentiate and clarify
    • the new verbiage still supports previous xxx
  • approved two additional narratives

Carin Alliance

Suggest that Security and CBCP WGs monitor Carin BlueButton FHIR IG "self-attestation" to privacy and security requirements, and seek collaboration on attestation criteria.   Note that "Consent Federation" is a project on Carin roadmap.  Suggest that we invite the IG author, Amol Vyas, Cambria Health, to WG call. 

See Carin Alliance WEDi.pdf and

"information seems a little loose," recommends Security, Privacy discuss with primary author

Consent federation - CBCP/DPyke may be reaching out to them to find out more information on what their direction is going. 

Carin BlueButton FHIR IG TOC

Carin BlueButton Use Case

Note that the IG Use Case is Individual Right of Access.  IG states that authorization is done with SMART on FHIR.  However, there is no support for a signature described, which is required according to OCR.

Consumer-directed health insurance data exchange Consumer-directed exchange occurs when a consumer or an authorized caregiver invokes their HIPAA Individual Right of Access (45 CFR 164.524) and requests their digital health information from a HIPAA covered entity (CE) via an application or other third-party data steward.

Use Case: Consumer Access to their Claims Data


  • Consumer (aka Beneficiary, Patient, or Authorized Caregiver)
  • Payer (aka Health Plan, Commercial Payer, Covered Entity)
  • Consumer-facing application - A digital third-party application selected by and primarily for the Consumer with a consumer-facing user interface

Normal Flow:

  • Consumer downloads or accesses the application of their choice
  • Consumer authorizes the application to access their digital claims data (thereby invoking their Individual Right of Access under HIPAA) via the SMART on FHIR authorization flow
  • Application connects to a FHIR API to download their digital claims data and requests the health plan send the data to the application
  • Application displays or otherwise uses digital claims data to the benefit of the Consumer

OCR FAQ: Right to Have PHI Sent Directly to a Designated Third Party

Can an individual, through the HIPAA right of access, have his or her health care provider or health plan send the individual’s PHI to a third party?

Yes.  If requested by an individual, a covered entity must transmit an individual’s PHI directly to another person or entity designated by the individual.  The individual’s request must be in writing, signed by the individual, and clearly identify the designated person or entity and where to send the PHI.  See 45 CFR 164.524(c)(3)(ii).  A covered entity may accept an electronic copy of a signed request (e.g., PDF or scanned image), an electronically executed request (e.g., via a secure web portal) that includes an electronic signature, or a faxed or mailed copy of a signed request.

From <>

  • Action: follow up with Amal (primary author) to discuss and BlueButton document security and privacy pieces, concerns with the Security and CBCP working group.  David Pyke (CBCP), Kathleen Connor (Security) will contact for follow up meeting. 
  1. Carin BlueButton FHIR IG TOC link: 

Recent ISA updates

HL7 PAC will be soliciting WG input on Comments.

The annual ISA Review and Comment period is now open, ending on September 23rd at 11:59pm ET. See the latest Health IT Buzz blog post for more details, and don't miss this year's questions for stakeholder feedback

The Interoperability Standards Advisory (ISA) process represents the model by which the Office of the National Coordinator for Health Information Technology (ONC) will coordinate the identification, assessment, and public awareness of interoperability standards and implementation specifications that can be used by the healthcare industry to address specific interoperability needs including, but not limited to, interoperability for clinical, public health, and research purposes. ONC encourages all stakeholders to implement and use the standards and implementation specifications identified in the ISA as applicable to the specific interoperability needs they seek to address. Furthermore, ONC encourages further pilot testing and industry experience to be sought with respect to standards and implementation specifications identified as “emerging” in the ISA. For historical background on the ISA please review prior ISA publications.

The 2019 ISA has been updated to include improvements made based on recommendations received from public comments and subject matter expert feedback.  To learn more about major revisions of the ISA, please review recent ISA updates. Registered users may subscribe to change notifications to be alerted by e-mail of all revisions to individual interoperability needs or for ISA-wide changes. Anyone may become a registered user by submitting an account request. Once logged in, look for the blue “change notification” button at the bottom of the interoperability need page, or at the bottom of the home page to be notified of any changes across the ISA. An RSS Feed was also added in 2018, capturing more granular updates made to the ISA.

Kathleen is coordinating comments (please review document and send to Kathleen) for incorporation/submittal for ISA Review

Data Segmentation of Sensitive Information

Recording Patient Preferences for Electronic Consent to Access and/or Share their Health Information with Other Care Providers

Appendix I – Sources of Security Standards and Security Patterns

Query for Documents Outside a Specific Health Information Exchange Domain

AdjournmentMeeting adjourned at 1243 Arizona Time (JohnM)

Temporary Meeting Recording:



John Moehrke Co-Chair


HL7 Austria

Kathleen Connor  Co-Chair

VA (Book Zurman)

@Trish Williams Co-ChairFlinders University
x@Christopher Shawn, Co-ChairVA

John Davis (Mike)





@Matt BlackmonSequoia

Julie Chan jchan@cwglobalconsult.comHL7 FHIR
xVA (Book Zurman)

VA (Book Zurman)


@Peter VanLiesdonkPhillips

@Adam Wong adam.wong@hhs.govHHS

Wave One

@Ricky Sahu,  

1up Health

EMR Direct


Laura Bright

 PJM Consulting

Jim KamperAltarum
 Ready Computing
 x @David Staggs drs@securityrs.comSRS 
Trustworthy EHR 

  • No labels