Difference between revisions of "August 07, 2018 Security Conference Call"
Line 112: | Line 112: | ||
* audit log … using the same machine because they are close | * audit log … using the same machine because they are close | ||
** provenance log collects data that corresponds to lifecycle events that the community interest want sto store in their electronic leger (25 events defined, 18 of which are create/up--which is what FHIR is most interested in) | ** provenance log collects data that corresponds to lifecycle events that the community interest want sto store in their electronic leger (25 events defined, 18 of which are create/up--which is what FHIR is most interested in) | ||
+ | ** configure as on/off - when that event happened it tirggers the provenance trail; or audit train (each use the same machine but report different paths); in the case of ht provenance, it typically, there is an interest that connects it tot he e-leger, usually local kept.. provenance different wherein you can have local rules 1-5; | ||
+ | community interests only cares about 2,3,4 | ||
+ | |||
+ | jim - how does the actor get recorded? i.e. national provider ID? name | ||
+ | mike - this is cocnpetual model th eprovance record has the agent involved in terms of provenance. we're staying at this level and ot specifying conceptual model... just trying to get the big chunks in place | ||
+ | the actiit is associated with that agent. we ould have Jim as actor (14706), | ||
+ | tryingto tyie together the conceptual figures | ||
+ | |||
+ | |||
+ | Federated Provenance Domain (figure showed) | ||
+ | * has for all the memebers in the domain, there is a provenance policy (agreed to by the members, implement in the indiciuatl mreains) which is then pused to the digital leger as they occure. Policy gellls members what to coll and pushed down the left path | ||
+ | |||
+ | * federated user have their own thing whereinthey carn request provenance data from the ledger (nothing to do with pushing infor there) provenance service returns | ||
+ | ** this is mechanism to search in the digital leger | ||
+ | ** its possible in thae exchange of inforaiton itself that th eprovance goes ith it...tht's a differetrocessl The data itsel | ||
+ | * there esre discussion of dta moving around (JIM)...WITH QUEESTIONS 'who recorded this...?' it would somhow say dr. bob at facility: XYZ | ||
+ | * md |
Revision as of 19:32, 7 August 2018
Attendees
x | Member Name | x | Member Name | x | Member Name | x | Member Name | |||
---|---|---|---|---|---|---|---|---|---|---|
. | John Moehrke Security Co-chair | x | Kathleen Connor Security Co-chair | . | Alexander Mense Security Co-chair | . | Trish Williams Security Co-chair | |||
x | Christopher Shawn Security Co-chair | x | Suzanne Gonzales-Webb | x | Mike Davis | . | David Staggs | |||
x | Diana Proud-Madruga | x | Francisco Jauregui | . | Joe Lamy | . | Greg Linden | |||
. | Rhonna Clark | . | Grahame Grieve | . | Johnathan Coleman | . | [mailto: Matt Blackman, Sequoia] | |||
. | Mohammed Jafari | x | Jim Kretz | . | Peter Bachman | x | Dave Silver | |||
. | Beth Pumo | . | Bo Dagnall | . | Riki Merrick | . | [mailto: Julie Maas] |
Agenda
- (2 min) Roll Call, Agenda Approval
- (5 min) Review and Approval of:
- http://wiki.hl7.org/index.php?title=Jul_31,_2018_Security_Conference_Call
- Meeting Minutes (in process) July 17, 2018 Security Call
- (5 min) GDPR whitepaper on FHIR update - Alex, John, Kathleen
- (5 min) TF4FA Normative Ballot reconciliation (formerly PSAF) - Mike, Chris
- Meetings: Tuesdays, 11:00 AM Eastern; freeconference.com same as Security call
- TF4FA Ballot Reconciliation (wiki)
- Ballot Reconciliation Sheet_v20180724 for review offline
- Comments 11-24 up for vote
- Comments 25-41 dispositions posted for review (vote next week)
- (10 min) PASS Audit post ballot reconciliation document update - Mike
- (05 min) TF4FA Trust Framework Volume 3 (placeholder) - Mike, Chris
- Is Privacy Obsolete - Mike
- (05 min) Placeholder: HL7 WGM Baltimore planning
Meeting Minutes (DRAFT)
Chair: Chris Shawn
Roll taken, No updates to the agenda
July 17 - meeting minutes approval motion: (Mike / Suzanne)
Objections: none; abstentions: none; approve: Minutes approved
July 31 - meeting minutes approval, motion: (Suzanne / Mike)
objections: none; abstentions: none; approve: 11
GDPR whitepaper on FHIR update
- no update
TF4FA Ballot Reconciliation Suzanne or Chris to send out ballot reconciliation spreadsheet for review by Security WG attendees
- motion made to approve 11-25 block of dispositions (Kathleen / Mike)
Objections: none; Abstentions none, approval 11
- please review dispositions 25-41 for next week vote
- also, attach ballot reconciliation attach documents to meeting invite
- no additional comments/questions
PASS Audit
- reconciliation completed, need to complete dispositions to the document
- Diana indicated completion of most of the 'easy' comments
- no additional comments/questions
TF4FA Volume 3
- Dave Silver -
- we have had osme further clairification of the ocmponents of provenance; we are usisng the features of the PASS Audit services to implement provenance to implenetn capablitys of lifecycle events; using
using aligning r... the needs are to ollet the audit, bu tht euadiot of colelcion is fromt he xxx policy. each of the ose might hae ther own policy of information to be collected and report back to the provenance repository or chain
- focused on
- conceptual model showl : leveraging audit service (provenance Model)
- must be configures to record lifecycle events; goes to the audit disposition service, this is now both audit and provenance. provisioned for provenance. iin process A all the lifecycle events are taken (coded into application) the dispositions servie basedon the xx whdetermine which events need to e configured at a certain time. then goes to delivery service; then to
- action service probably intermally
- alarm - wanted to make sure WG understands; there may be provnanc events... some occure wherein we send th eprovenance event and notify participants in that block chain that something has happened. it may be ethat some inforaiton in the chain has been determined to be invalid i.e. … or may... we want to notify participants that even should be ignored; i.e. its harmful to patient if accepted, we found that it was invlad..maybe we have an alarm for that particil… doesn't hurt to keep or remove; just imagining scenarios for keeping it in. ; the ability tos support alam
- thorught the export service, is extracted from the local provenance reposity then pushed to the community wide
staying away from 'block chain' saying / leaning more toward electronic leger.
<<link to volume 3>>
s there any specific data being recorded?
- audit log … using the same machine because they are close
- provenance log collects data that corresponds to lifecycle events that the community interest want sto store in their electronic leger (25 events defined, 18 of which are create/up--which is what FHIR is most interested in)
- configure as on/off - when that event happened it tirggers the provenance trail; or audit train (each use the same machine but report different paths); in the case of ht provenance, it typically, there is an interest that connects it tot he e-leger, usually local kept.. provenance different wherein you can have local rules 1-5;
community interests only cares about 2,3,4
jim - how does the actor get recorded? i.e. national provider ID? name mike - this is cocnpetual model th eprovance record has the agent involved in terms of provenance. we're staying at this level and ot specifying conceptual model... just trying to get the big chunks in place the actiit is associated with that agent. we ould have Jim as actor (14706), tryingto tyie together the conceptual figures
Federated Provenance Domain (figure showed)
- has for all the memebers in the domain, there is a provenance policy (agreed to by the members, implement in the indiciuatl mreains) which is then pused to the digital leger as they occure. Policy gellls members what to coll and pushed down the left path
- federated user have their own thing whereinthey carn request provenance data from the ledger (nothing to do with pushing infor there) provenance service returns
- this is mechanism to search in the digital leger
- its possible in thae exchange of inforaiton itself that th eprovance goes ith it...tht's a differetrocessl The data itsel
- there esre discussion of dta moving around (JIM)...WITH QUEESTIONS 'who recorded this...?' it would somhow say dr. bob at facility: XYZ
- md