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.
|Q1 TUE||Alex Mense (Chair)|
|Agenda Approval||Agenda approved 13:0:0|
|30||Security FHIR Tutorial||Andrew 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:
SRs in Progress:
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
|5||PSAF Vol 4 Ballot Report (Audit)||Kathleen (Mike Shawn)|
Audit ballot passed with no negative votes
|15||PSAF Vol 3 Provenance||MIke 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….
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.
|30||FHIR Security Report out||John 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….
e.g., (1) HIPAA, (2) INFORMED CONSENT
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 report||Mohammad Jafari||Privacy Aware Bulk Data Transfer API use case used. by VA. The Bulk Export Use Case: Privacy Aware Bulk Data Access|
|-||Basic Provenance||Brett Marquard, Russ Ott||Deferred to Q3|
|FHIR Data Expert IG||Adam 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)
|PROPOSED AGENDA ITEM|
See slide deck FHIRcast slide deck
SMART app launched from the EHR.
“Sidecare” or external
App context synchronization
FHIRcast: simple app conext sync
Process. After handshake exchange OATH token
Hub verifies callback url (see slide)
Workflow event occurs, and subscriber is notified (see slide)
Balloting HL7 FHIRcast (see Get Involved slide)
KC Q: re JSON security labeling
Steve Posnack ONC re. options for more testing
|Basic Provenance IG||Russ Ott|
Brett Marquard (on the phone)
See Slide deck. Basic Data Provenance BasicProvenance_20190422_v2
SCENARIO #1: Receipt of a transmission from another site.
Example of AGGREGATED VIEW of test data from JLV. Provenance ID is linked to the ORGANIZATION that provided the information.
SCENARIO # 2 :
SCENARIO #:3 HIE transformation
SCENARIO #4: Clinical information reconciliation and incorporation (CIRI)
EPIC: we consider that once information has been reconciled, then it becomes the product of the reconciler and the provenance begins anew.
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.)
BARE MINIMUM PROVENANCE
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
OUT OF SCOPE ITEMS - See Slide 12
REPORT OUTLIME: Informative Implementation Guide. (see slide)
PRIOR DATA PROVENANCE EFFORTS - See slide 13
Next visit to Patient Care to discuss the level of detail 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 Kathleen||John and Kathleen discussed questions raised in FHIR Security call about use cases for Provenance Relevant History. See https://www.hl7.org/fhir/provenance-relevant-history.html|