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

August 28, 2018 Security Conference Call

From HL7Wiki
Revision as of 19:34, 28 August 2018 by Suzannegw (talk | contribs)
Jump to navigation Jump to search

Back to Security Main Page

Attendees

x Member Name x Member Name x Member Name x Member Name
x 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 . Johnathan Coleman . Francisco Jauregui x Joe Lamy
. Rhonna Clark . Greg Linden . Grahame Grieve x Dave Silver
. Mohammed Jafari . Jim Kretz . Peter Bachman . [mailto: ]
. Beth Pumo . Bo Dagnall . [mailto: ] . [mailto: ]

Back to Security Main Page

Agenda

Meeting Recording: (temporary)

  1. (2 min) Roll Call, Agenda Approval
  2. (5 min) Review and Approval of Minutes for August 21, 2018 Security Conference Call
  3. (5 min) GDPR whitepaper on FHIR update - Alex, John, Kathleen
  4. (5 min) TF4FA Normative Ballot reconciliation (formerly PSAF) - Mike, Chris
  5. (10 min) PASS Audit document update - Mike
  6. (05 min) TF4FA Trust Framework Volume 3 - Mike, Chris
  7. (10 min) Review of the Proposed Restructuring and Additions to FHIR Implementer’s Safety Check List developed in FHIR Security calls. - John and Kathleen
  8. (05 min) Security Working Group - upcoming HL7 Working Group Meeting, Baltimore Maryland

Meeting Minutes DRAFT

Chair, Kathleen Connor

Suzanne, Kathleen, Dave silver, mike, chrisS, diana, Francisco, david stagg

Meeting Minutes

  • Approve Meeting Minutes from August 21, 2018 (Suzanne / ChrisS)
  • Vote: approve 8; no abstentions, no opposed
  • Suzanne to update comment ballot spreadsheet


GDPR Baltimore GDPR chat-a-thon sometime during the WGM (] Comments 52-57

  • Sunday -


TF4FA

  • Met this AM to review; link sent out earlier
  • Motion made to approve comments as shown; comments 52-57
  • Vote: approve 8; no abstentions, no opposed

Trust Framework, Volume 3

  • Chris does not have much to say about the update
  • continue to work on the figures/diagrams (completed--shared on clal previously)
  • attempting to complete the descriptions and remaining content of the doc
    • some volunteers may be assisting

PASS Audit

  • tF4FA has beenthe priority
  • not much happening with the document update

Review of the Poporsed Restructuring and Additions to FHIr Impement Safety Check List

  • the FHIR spec has a couple of different informational pages, security page is one that we own (signatures we owne, etc)
  • ther eis a safety page that hasn't received a lto of visibility until now; if you knew the propoer incantation you were able to get ther
    • its starting to mature and gain more visibility
    • it was devoid of security items that should rise to the occasion
    • Kathleen brought this into a document format inorder to do updates/mark-up
  • not made to be 100% complete, education--its a checkless for someone who already understands and wants to make sure they didn't miss anything
    • needs reminders of BIG things (in the security realm)
      • see 20 security 'top important things' - shouldn't be exhaustive
    • what is shown is the word document - for editing sake they are numbered
  • PROPOSAL from FHIR -Security WG
    • break this checklist down into big buckets
  • PRIVACY, SECURITY, etc and other sub-cateorires in security (authentication, audit, etc)
  • and the #NEW as a proposed new checklist item distinct i.e #9 (9 is already there but new information added)
  • our hopes are that the NEW items add value; ultimately left many descriptions open--because the SAFETY page is owend by FHIR-I (not by security); you change the concenuse group you change the concensus
  • some items may no longer appear (not part of the 80%)

Break down and re-sort under headers: time-keeping, communctions and the like

  • the wording of the new items, the sentence papern in the safety checklist, is to write it as a 'security-checklist'
  • LINK: in agenda
    • for review; as a proposal to FHIR-I, we can vote on it next week or today; enhancements/review/comments are welcome

Baltimore Agenda John approached by PA that thought the person resource might benefit by having a security considerations section - hey reader who is going to use person resource...here are some security considerations with that thought--if eVERY group brought this question forward---everyone---POINT everyone to the security page...

  • the first way to get there is to take an assessment of everything in FHIR i.e. capabilities statement (which si what a server capability is... parameters, etc) some of these resources are inherently intended to be public--certainly if they are marked sensisty, they can be marked that way. potentially pulic but can be ….(21:40)
  • things that are purely business sensitive, provider sensisty and/or paitnet sensitive, etc
  • doesn't take away from the need to have tagging and roles, compartments , etc... etc. just allows ther eader to start with the assumption that quite possibly the resource is indeed logical and not protected by any provider oruser authentication.
    • one other item - there are people who when approach fhir security and look at our security apges come to the conclusion that absolutely everyhitng in FHIR (including test script) must have consent level control...e ven thought the item has no PII, patient reference, or the like. its putting a softer feel to inform the reader.
  • if we have broader categories and we can explain what they mean--then each resource will have a security consideration if significatlny different in its category.
  • we can reach out to PA and financial management and gather use cases (tasked to kathleen) to see if proposed will work
    • this will help to see if this works and/or if additional buckets are needed for consideration. these are hot topics for us--risk around certain items; these are visually broad enough to cover most of the scenarios--if we can try out between now and the WGM we can provide comments
  • that in mind: WGM AGenda, this item will fit:
  • Mike - havenet' looked at the list - issue we have was data quality (DQ) of codes used in the system; the codes can be incorrect and the system may not work right. need to connect DQ with this and the labeling. not sure howmuch hou have in system testing but the idea is to have it as automated as possible
  • john - i'm going a step back from system/system testing - this is at a broad brush to help distinguish the items that really should be public and why arent' they--vs patient sensistive and why aren't thye protected. in touch with folk with folks who had no idea of our security considerations. this is not intended to be documented enough.... further refine
  • further refine in Seucirty and CBCP/Privacy... cthis is currently our crib notes
    • the point brought up aking this system lvel automated, that type of system conformance testing for privacy and security SHULD happen (Kathleen) this may be a wy to flag which of the items in the checklist should be had … marked patient sensitive