|
|
| Line 50: |
Line 50: |
| | | | |
| | #''(15 min)'' '''[http://wiki.hl7.org/index.php?title=HL7_May_2018_WGM_AGENDA_-_Cologne,_Germany Security Cologne May WGM Agenda]''' Review Revisions and start adding Q agenda information - Kathleen | | #''(15 min)'' '''[http://wiki.hl7.org/index.php?title=HL7_May_2018_WGM_AGENDA_-_Cologne,_Germany Security Cologne May WGM Agenda]''' Review Revisions and start adding Q agenda information - Kathleen |
| − |
| |
| − | ==Meeting Minutes DRAFT==
| |
| − |
| |
| − | 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
| |
