Skip to end of metadata
Go to start of metadata

Date: 7th May 2019

Quarter: Q1 & Q2

Minutes Approved as Presented 2019-06-18 Security WG Agenda/Minutes 


This is to approve minutes via general consent. "You have received the minutes. Are there any corrections to the minutes? (pause) Hearing none, if there are no objections, the minutes are approved as printed."


Set goals, objectives or some context for this meeting.

Discussion items

 Alex Mense (Chair)

15 mins

Agenda Approval
Agenda approved 13:0:0
30Security FHIR TutorialAndrew Marcus (Asymmetrik)

Education tutorial being run by Asymmetrik on FHIR security. It has a focus on pen testing and the point that the security for FHIR is no different to 'normal' security requirements. Being compliant with FHIR does not mean you are secure. Whilst there are best practices associated with FHIR security, there are parts missing (e.g. server security). Main challenge with OAuth is the lack of granularity.  No certification or testing framework around FHIR. How is this different when using FHIR or any other application? The legislation requirements (e.g. HIPAA) mean that the application alone protection is not sufficient and the FHIR client and hardening a server needs a security framework around it. Jonathon suggested that the HIPAA is about the organisational policy and procedures, not specifically about security techniques.  FHIR security pages could have more, specific, guidance. 

Tutorial will look specifically at the narrative and security labels in FHIR. Discussion on certification on FHIR security (Kathleen/Jonathon). Potential for usefulness of a FHIR environment security best practice document - from a systems perspective.

Jonathon suggested a SIG to validate the instance of implementing a FHIR server. HL7 could maintain this.

SEC WG could explore more ways to disseminate the work that HL7 SEC does, particularly how we actively amend our guidance to the regulatory changes globally.


Country report-outs were given at the CBCP meeting Mon Q4 (refer to CBCP minutes).

ISO (Gothenburg, Sweden, April 2019):

Hideyuki Miyohara.  ISO WG4 Update from Gothenburg April 2019.

See slide deck. Discussed work on:

ISO/DTR 22696

ISO/CD 27789

ISO/DIS 17090-4

ISO/AWI 22697

ISO/TS 14441

ISO/SR 17090-3

ISO/SR 17090-1

SRs in Progress:

ISO 20301_2014

ISO 2302:2014

ISO 21549-2:2014

ISO 21549-3:2014

ISO 21549-4:2014

JTCI SC 17 Liaison Report

(Cards and security devices for personal identification)

TC292 Liaison Report

Resolutions (see slide) Covers :

--Info security management for remote maintenance of medical devices and medical info systems.

--Cloud computing considerations for health info systems security and privacy

Health informatics. Principles and data requirements for the consent in the collection, use or disclosure of PHI

Guidelines on data protection to facilitate trans-border flows of personal health data. (CONFIRMED; no changes

Guidance on the Gateway Security use in Personal Health Care Systems


5PSAF Vol 4 Ballot Report (Audit)Kathleen (Mike Shawn)

Audit ballot passed with no negative votes

V3_PSAF_R1_N2_2019MAY Ballot Reconciliation Spreadsheet

15PSAF Vol 3 ProvenanceMIke Davis

Re-doing Provenance as a DAM for ballot in Sept, to become normative in Jan 2020. NIB needs to be submitted promptly. We currently have 4 specifications under Provenance. HL7 Provenance Conceptual Model 20190502

Kathleen suggested we need to refresh HCS  - as we need more information on why there must be only one confidentiality code and that each policy domain should have one default security label to be interoperable. Discussion on whether we need a new PSS for this. Use of PSS so that we can promote what we are doing in the community as well as any WG that wants to contribute to the project.

M:agree that we need to do a REFRESH

More info on why you want only one confidentiality code.

The importance of privacy domain arriving at a discrete /related security label for each

Issue of project scope statement. Q: include refresh of HCS or have a new one. KC: include. M: suggest a new one.

MOTION: Create a new PSS based on the content of the old one to account for the HCS….



Opposed: none

Abstain: none

Approved: 10

Motion to create a new PSS (based on the content of the old PSS) to account for changes to the current HCS.  

Kathleen to draft new HCS PSS to be reviewed prior to Sept WGM, moved to InfraSD at WGM, and submitted after WGM so that initial ballot might go forward in May 2020.

Mike Davis moved/ Theresa Aardal Connor second.  No discussion. Approved 10-0-0.

30FHIR Security Report outJohn Moehrke

Digital Signature. Are leaning on external standards. Have not developed HL7 signature standards.

Need to clean up:

Louie Maas: issues with JSON signature serialization algorithm.

(2) other one: today the only two digital signature XML signature based on :::: and the JSON signature. A third option that is available …not digital signature, but an electronic signature.   New one that is being discussed…an integrity protection ….Shaw 256 hash….but today there is no mind type for a Shaw 256 hash.

ALSO has been discussed re Blockchain based ….

JM doesn’t believe we should push to have signature go to normative in ____(build?) 5. JM thinks there is good reason to keep it in trial use…rather than moving to moving to normative.

M: discussed issue of consumer / provenance re: transfers of bulk data.

JM: Other issues:

(1) PROVENANCE….X header allows a n application creating a resource on a FHIR service…and include provenance…Predominantly used in CREATE…but could be used in an UPDATE:

(2) in connection with GDPR----X header: for CONSENT predominantly for QUERY or RETRIEVE

JM: the Provenance X header is in the spec, but doesn’t believe the Consent X header is.

KC: we have another problem with Security Labels

If you have two policies applying to the resource….


Need further discussion on FHIR Security Call


GDPR: need to have Implementation guide for OPT -IN, ERASURE operation, Non-patient individual (practitioners, other individual)

-FHIR Connectathon reportMohammad JafariPrivacy Aware Bulk Data Transfer API use case used. by VA. The Bulk Export Use Case: Privacy Aware Bulk Data Access
-Basic ProvenanceBrett Marquard, Russ OttDeferred to Q3

FHIR Data Expert IGAdam Culbertson (Boston Children's)

Reported on FHIR Bulk Data Access IG ballot outcomes and proposed dispositions.  Ricky Sadu proposed dropping _typeFilter element because there did not seem to be alot of interest among BDT implementers for using this query parameter to limit client requests.  However, during the BDT Connectathon track, Mohammad Jafari demonstrated use of _typeFilter on the Server side by the Server's proxy Authorization Server to restrict client queries so as to filter the results based on policies governing the request information. 

Mohammad's Discussion Points:

Model: requester goes through an AUTHORIZATION SHIELD and can modify the request

ALSO: there can be modifications on the RESPONSE

(1) JSON Scopes (permits general scope with negative scopes (exceptions to the general export permission), e.g. Patient X could say do not send my info to organization Y.

MIKE: need to have policy tags on bulk data (constraints / obligations) on that data that follows with the data if it gets handed off to another…

(2) When to reject a request vs. when to accept it but redact the results…..(see slide)

(3) Simpler Flows (see slide) (concerns: easier to forge tokens and harder to revoke)

(4) Bulk API as Reverse Proxy

(5) Wildcard typeFilters (see slide)

(6) Experimental


  • FHIRcast - Isaac Vetter
  • Basic Provenance IG - Brett Marquard/Russ Ott
  • Provenance Relevant History Review - John & Kathleen

FHIRcast Isaac Vetter

See slide deck FHIRcast slide deck
Radiology and Imaging Integration

SMART app launched from the EHR.

  •  --iframe or embedded browser
  • --web app

“Sidecare” or external
Browser external to EHR or native app (mobile or desktop)

Multiple machines
--Simultaneous: desktop EHR + mobile ap

App context synchronization

  • widely used in HC
  • typically, proprietary
  • Disparate implementations
  • May only support desktop apps
  • May require apps to be on the same machine.

FHIRcast: simple app conext sync
• Based on http, webhook, json
• extends SMART on FHIR
• Doesn’t require context manager.

Process. After handshake exchange OATH token
App subscribes to session (see slide)

Hub verifies callback url (see slide)

Workflow event occurs, and subscriber is notified (see slide)

Balloting HL7 FHIRcast (see Get Involved slide)
150+ comments. ID’d 151 issues.
Please click on the following to link review any comment resolutions:

KC Q: re JSON security labeling
Consumer user case 8transgendered youth)
Comment from Y re not being bi-directional like -cal

Mike Q:

Steve Posnack ONC re. options for more testing

Basic Provenance IGRuss Ott
Brett Marquard (on the phone)

See Slide deck. Basic Data Provenance BasicProvenance_20190422_v2
intended to support USCDI. Relatively simple, could be implemented relatively quickly
Focusing on data provenance in use of clinical information
Ballot timeframe: Sept2019. Reconciliation by the end of the year.

SCENARIO #1: Receipt of a transmission from another site.
Could be a push or a pull (result of a query).
Information is received by a provider form an HIE.
What information related to the provenance of the information being displayed needs to be displayed to the clinical user to give a full picture of the information they are looking at.

Example of AGGREGATED VIEW of test data from JLV. Provenance ID is linked to the ORGANIZATION that provided the information.

Current DOD & VA Provenance Processing
HIE just distributing info, not changing the information.
Provenance data I extracted from various XPaths in CDAs (document, section, entry), but always from a representedOrganization.
*As this has evolved ORGANIZATION has been the most important factor to display for these systems.

SCENARIO #:3 HIE transformation
Information is received (e.g., v2lab, other CCDs) and transformed by an HIE, stored, and then passed in a new form (CCD). Source data is not manipulated beyond transforming into a new format.

SCENARIO #4: Clinical information reconciliation and incorporation (CIRI)
1. Provider stores information in their system . may have made changes.
2. Provider sends info to another provider. (e.g., DIRECT). Includes automated deduplication / adding translations.

MIKE: Activity/entity chaining. Need to know the process. Be able to ID the event that prompted the transaction.
KC: In the record itself, there needs to be a clear record of where the information came from….in case there is patient error….
KC: need the author of the content AND the author of the assembler (transmitter)
MIKE E.g., content says the patient has an allergy. But need to know HOW that information was gathered…did the patient say they had an allergy or did the provider run a test and determine that the patient had an allergy.

EPIC: we consider that once information has been reconciled, then it becomes the product of the reconciler and the provenance begins anew.

Q: if you have an HIE that gathers information from a variety of sources and aggregates it. Should the provenance say (1) the information is from the HIE….or (2) should the provenance say the information came from the various sources.

VA is almost entirely EPIC installations….DOD is more varied

LOTS OF DISCUSSION RE: TRANSFORMATION OF DATA AND TRACEABILITY OF INFORMATION (source and method used in changing / transforming the data)

RUSS summed up Drew’s assumption: every conveyor has a provenance obligation (KC: and retrievable.)

There is a store, however it is implemented 8blockchain, ledger, etc.)

For each data scope, we need to have at least one:
· Author
· Author’s organization
· Timestamp
· Data Transmitter (?)
For scenarios 1-4:
· Is Author information at document-level sufficient?
· Are there sections that it’s particularly important to have Authoring info?
· Are there Entries that it’s particularly important to have Authoring information.?

DREW: struggled with the question of what belongs on the RESOURCE and what needs to be in PROVENANCE. E.g., Most FHIR resources have author and timestamp on the RESOURE. He examined other resources and gave example of allergy resource…as one that does NOT have an organization….so would need to use Provenance.

KC: that is just stupid….why not make author/org/timestamp to all resources.

Discussion re: ONC MU….

AUTHOR: equals the Location of where the information came from (doesn’t matter whether it is a performer or organization)

KC: in addition of metadata…..emphasized the importance of signing (or retaining the prior signature) to be able to confirm the authenticity


REPORT OUTLIME: Informative Implementation Guide. (see slide)


Next visit to Patient Care to discuss the level of detail needed by clinicians.
Recommendation from (guy against the window behind Russ) to focus on USE CASES when discussing what data is needed by clinicians

ONC priority was making sure that the AUTHOR and TIMESTAMP be transmitted along with the data.

Recommendation made that Basic Provenance should focus on use cases when discussing what data is needed by clinicians. Project should develop use cases describing what people will use provenance for should be used to determine what provenance information should be exchanged, and whether rendering this to the provider end user is really the priority. Not clear that rendering author organization/timestamp to a provider in the context of an encounter for each provider to make their independent confidence appraisal is how providers or their organizations want provenance to be used.

Provenance Relevant History Review John and KathleenJohn and Kathleen discussed questions raised in FHIR Security call about use cases for Provenance Relevant History. See

 TimeItem Who Notes 

Action items


  • No labels