This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "HL7 FHIR Security 2018-04-17"

From HL7Wiki
Jump to navigation Jump to search
 
Line 99: Line 99:
 
** blockchain
 
** blockchain
 
*** Seems no activity or stream has been created
 
*** Seems no activity or stream has been created
 +
 +
==Alternative Meeting Minutes DRAFT from Suzanne==
 +
 +
FYI - ''Johnathan out sick - there will be no FHIR meeting this afternoon unless others have done homework regarding the access control section''
 +
 +
Kantara-FHIR Launch Framework - there appears to be a lot of interest, unsure how different it is from smart on FHIR
 +
* ther eis an effort to get a CCOW like system inplace for FHIR based application, there is essentially atwo situations
 +
** one is gamibling smart on fhir launch contenst
 +
** building the context resource
 +
*** how consent  .... (discussion)
 +
 +
agenda with focus on zulip chat on GDPR, look at block chain
 +
** looking at application registration including rusted apolicaiton framework an dwhoe area of certificate managemenet.  its a broad topic , touches on last twobullet points
 +
* what is the trustedapplication? 
 +
** unsure if formally approved, carry over of certificate frack from new orleas, related to PIK, xx protocol, realted to FHIR... the app registration framework is based on the dynamice line registration prototal, and signed..  RFC 7591 (I believe) direct/certificates 
 +
* '''201805 Direct/Certificates Track''' wiki.hl7.org/index.php?title=201805_Direct/Certificates_Track
 +
* Review of project;
 +
Discussion:
 +
* Underlying idea is that certificate-ased trust framework from proviers to provider exchange are widely deployed and successful, and the idea Grahame an dothers are (for over a year) are how to bring in the good parts of the PKi network, to jump stat cross organization exchange and get beyond dthe idea of getting dta from only username/passworld, the first partf of the track is the actually moving fhir payload..
 +
in a nutsheet direct metssages are authenticated---similiarto mutual PLS(?) ad that the authentication built into the protocol can be used to authenthia the connection to the FHIR related entity(?)
 +
 +
* transmit ....
 +
** server will upload his bundler an d send response that bundle was uploaded successfully
 +
** instead of sing http... s/mime protocol
 +
** first part of the track
 +
* second part of the
 +
** use of PKI infrastructiore using the http framework wehre most th etransatoin are taking place.  ouruse case ...two flors of PLS, the first space A1 clinet application directly authticates, resource eservie can authenticate/au.. based on client certificate
 +
** extended that to bring in dynamic trust bundle, which is what ONC spearheaded. to scale it... the idea is that a relying party a resource server can only trusted... where it can dynamically find trusted...
 +
 +
use case A2
 +
use case B
 +
 +
Add Louis to Monday Q3/Q4 agenda at WGM
 +
 +
ZULIP - review
 +
* most have been informed on work Alex and John have completed with Rene
 +
* hope to have more useful
 +
* IG produeced a white paper; IHE S&P security profiles, which is no a lot different from our current  201805 GDPR HL7Wiki (listing FHIR capabilities)
 +
* we have these capabilities, they will be supporting x,y,x, GDPR capabilities - we will probably come up with opportunitesi for projects after the connet ta thon is to say articles #13,14,15 require you to provide information tot hepaitent, which will probably come from a an audit.  one of the possible things to do if you're intestret, is in improving soething that satisfies thereporting requirement if they had a hgihg quiliaty set of audit and provenance consent.  writing up which will rpbaly endof as various scnarios on this wiki page
 +
 +
GDPR - request to be delted, how does that work in with the elements.  even proposed provenance items which propose block chain which are essentially in-deletable.  how can you comply in a situation like that... or maybe y ou cant
 +
* there is a lot of emphasis about a responsibility to dotify downstream where the data has gone, permitted pocess... we need use or profile for on eof these elementto audit the fact that you followed up that there was a change in the permission... new thing to keep track of.
 +
* existing audit events and provenance will technically have what's necessary but certainly is
 +
 +
* espects that GDPR will still call upon 43:00
 +
 +
** is audit event fall under the purview of this project? (yes)
 +
** not seeing specificially who disclose is sent to
 +
 +
ZULIP Blockchain
 +
* there is interesting block chan projects going on, but no visability
 +
* (no
 +
 +
Meeting adjourned at 11:58 Arizona Time

Latest revision as of 19:06, 17 April 2018

Call Logistics

Weekly: Tuesday at 02:00 EST 

Web conference desktop and VOIP https://www.freeconferencecall.com/join/security36 
Online Meeting ID: security36
Phone: +1 515-604-9567, Participant Code: 880898
 Please be aware that teleconference meetings are recorded to assist with creating the meeting minutes

Back to HL7 FHIR security topics

Attendees

Member Name Member Name Member Name
x John Moehrke Security Co-Chair x Kathleen Connor Security Co-Chair . Alexander Mense Security Co-chair
x Suzanne Gonzales-Webb CBCC Co-Chair . Johnathan Coleman CBCC co-chair . Chris Shawn Security co-chair
. Ali Massihi . Mike Davis x Nathan Botts Mobile co-chair
x Diana Proud-Madruga x Joe Lamy AEGIS . Beth Pumo
. Irina Connelly x Matt Blackman Sequoia . Mark Underwood NIST
. Peter Bachman . Grahame Greve FHIR Program Director . Kevin Shekleton (Cerner, CDS Hooks)
x Luis Maas EMR Direct . Dave Silver x Francisco Jauregui

Agenda

ACTIONS

references

Minutes

  • John Chaired
  • Minutes not reviewed
  • Johnathan is out sick so will skip ONC work
  • Reviewed FHIR Connectathon tracks
    • 201805 GDPR
      • A bit more discussion has happened on the zulip thread
      • John, Alex, and Rene are working on pre-work details
      • WIll hae cross-walk from FHIR security and privacy capabilities to the GDPR articles they support
      • Will have gaps identified
      • Some gaps will be useful experiments for participants
      • Loui recognizes a need to have an auditEvent that records that one has followed up on a request by a patient that they needed to communicate to downstream partners that they had flowed that patient's data to. For example when the patient requests data be forgotten, this must be communicated to all that had previously received that data. Thus there needs to be an audit event showing that they tried
        • also reviewed the disclosure example for how well it records enough details for the disclosure. It seems so, but the example is too limited
    • 201805 Direct/Certificates Track
      • Loui walked the group through this whole track in very nice details
      • Last (D) scenario does need a bit more discussion. It was also not clear that D relies on C being used after D succeeds.
      • This scenario should see more visibility. Possibly on zulip
    • blockchain
      • Seems no activity or stream has been created

Alternative Meeting Minutes DRAFT from Suzanne

FYI - Johnathan out sick - there will be no FHIR meeting this afternoon unless others have done homework regarding the access control section

Kantara-FHIR Launch Framework - there appears to be a lot of interest, unsure how different it is from smart on FHIR

  • ther eis an effort to get a CCOW like system inplace for FHIR based application, there is essentially atwo situations
    • one is gamibling smart on fhir launch contenst
    • building the context resource
      • how consent .... (discussion)

agenda with focus on zulip chat on GDPR, look at block chain

    • looking at application registration including rusted apolicaiton framework an dwhoe area of certificate managemenet. its a broad topic , touches on last twobullet points
  • what is the trustedapplication?
    • unsure if formally approved, carry over of certificate frack from new orleas, related to PIK, xx protocol, realted to FHIR... the app registration framework is based on the dynamice line registration prototal, and signed.. RFC 7591 (I believe) direct/certificates
  • 201805 Direct/Certificates Track wiki.hl7.org/index.php?title=201805_Direct/Certificates_Track
  • Review of project;

Discussion:

  • Underlying idea is that certificate-ased trust framework from proviers to provider exchange are widely deployed and successful, and the idea Grahame an dothers are (for over a year) are how to bring in the good parts of the PKi network, to jump stat cross organization exchange and get beyond dthe idea of getting dta from only username/passworld, the first partf of the track is the actually moving fhir payload..

in a nutsheet direct metssages are authenticated---similiarto mutual PLS(?) ad that the authentication built into the protocol can be used to authenthia the connection to the FHIR related entity(?)

  • transmit ....
    • server will upload his bundler an d send response that bundle was uploaded successfully
    • instead of sing http... s/mime protocol
    • first part of the track
  • second part of the
    • use of PKI infrastructiore using the http framework wehre most th etransatoin are taking place. ouruse case ...two flors of PLS, the first space A1 clinet application directly authticates, resource eservie can authenticate/au.. based on client certificate
    • extended that to bring in dynamic trust bundle, which is what ONC spearheaded. to scale it... the idea is that a relying party a resource server can only trusted... where it can dynamically find trusted...

use case A2 use case B

Add Louis to Monday Q3/Q4 agenda at WGM

ZULIP - review

  • most have been informed on work Alex and John have completed with Rene
  • hope to have more useful
  • IG produeced a white paper; IHE S&P security profiles, which is no a lot different from our current 201805 GDPR HL7Wiki (listing FHIR capabilities)
  • we have these capabilities, they will be supporting x,y,x, GDPR capabilities - we will probably come up with opportunitesi for projects after the connet ta thon is to say articles #13,14,15 require you to provide information tot hepaitent, which will probably come from a an audit. one of the possible things to do if you're intestret, is in improving soething that satisfies thereporting requirement if they had a hgihg quiliaty set of audit and provenance consent. writing up which will rpbaly endof as various scnarios on this wiki page

GDPR - request to be delted, how does that work in with the elements. even proposed provenance items which propose block chain which are essentially in-deletable. how can you comply in a situation like that... or maybe y ou cant

  • there is a lot of emphasis about a responsibility to dotify downstream where the data has gone, permitted pocess... we need use or profile for on eof these elementto audit the fact that you followed up that there was a change in the permission... new thing to keep track of.
  • existing audit events and provenance will technically have what's necessary but certainly is
  • espects that GDPR will still call upon 43:00
    • is audit event fall under the purview of this project? (yes)
    • not seeing specificially who disclose is sent to

ZULIP Blockchain

  • there is interesting block chan projects going on, but no visability
  • (no

Meeting adjourned at 11:58 Arizona Time

Retrieved from "https://wiki.hl7.org/w/index.php?title=HL7_FHIR_Security_2018-04-17&oldid=156100"