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 01:21, 5 September 2018 by Suzannegw (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
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
. Diana Proud-Madruga . Johnathan Coleman . Francisco Jauregui . 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


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 Whitepaper on FHIR Baltimore GDPR chat-a-thon sometime during the WGM on Sunday

TF4FA Ballot Reconciliation

  • Met this AM to review; link sent out earlier to Security listserve
  • Motion made to approve comments as shown (Suzanne / MikeD); Comments 51-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 call previously)
  • Attempting to complete the descriptions and remaining content of the doc
    • Some volunteers may be assisting

PASS Audit Document update

  • TF4FA has been the priority
  • not much happening with the document update

Review of the Proposed Restructuring and Additions to FHIR Implementer Safety Check List

  • The FHIR spec has a couple of different informational pages, security page is one that we own (signatures we own, etc.)
  • There is a safety page that hasn't received a lot of visibility until now; if you knew the proper incantation you were able to get there
    • It’s 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 in order to do updates/mark-up
  • Not made to be 100% complete, education--it’s a check list 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-categories 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 owned by FHIR-I (not by security); you change the consensus group you change the consensus
  • some items may no longer appear (not part of the 80%)

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

  • the wording of the new items, the sentence papers 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 WGM 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 is what a server capability is... parameters, etc.) some of these resources are inherently intended to be public--certainly if they are marked sensitivity, they can be marked that way.
  • things that are purely business sensitive, provider sensitivity and/or patient sensitive, etc.
  • doesn't take away from the need to have tagging and roles, compartments , etc... etc. just allows the reader to start with the assumption that quite possibly the resource is indeed logical and not protected by any provider or user authentication.
    • One other item - there are people who when approach FHIR security and look at our security pages concluded that absolutely everything in FHIR (including test script) must have consent level control...even though 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 significantly 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) I haven’t' 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 how much you 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 aren’t' they--vs patient sensitive and why aren't they 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 in Security and CBCP/Privacy... this is currently in our notes
    • the point brought up asking this system level automated, that type of system conformance testing for privacy and security SHULD happen (Kathleen) this may be a way to flag which of the items in the checklist should be had … marked patient sensitive

Baltimore Agenda

  • Need to find a home for the topic JohnM just brought up
  • Privacy Obsolete - final report out - will have PPT, document as deliverables; go through the findings
    • reviewed in CBCP; recent activities this year that affected Privacy/CBCP
    • need to shut the project down because its taking too much time, will present at minimum those three items
      • cover in Monday Q3/Q4
      • during regular Security Agenda

JohnM topic


At the WGM before the meeting in Germany - we had discussed to formally publish the IM, take on the project work to update that model which my proposal--have we published it? or do we even have a project to update it?

  • asked Trish; Alex is moving the publication forward.
    • Mike - how long will it take; this was not favorite solution to IM; in addition to publishing to also add discussion of updating
  • add: WED Q4 Restarting the PSAF work; (FHIM/Galen) that had several iterations of models... PSS in place, it’s a matter of negotiating resources and time again
    • the FHIM has modified the model as well--need to take fresh look at it; revise and update. in Mike's view the current is stale
  • Break out session during Connectathon - to discuss the GDPR work (Alex/John); requested a breakout room for Sunday AM for a chat-a-thon on GDPR and FHIR
    • interesting - California is considering implementing GDPR
    • Diana – actually, there is a proposal that is supposed to show up in the November ballot (Kathleen says its sidelined, wealthy person sponsored, but went through legislature and a compromise is in place.
    • moved to a flavor of regulation moved into the court language wherein it is less hard and fast. It will be similar to GDPR and sets its goals similarly to GDPR. It was redirected nefariously into a type of regulation/law
  • Kathleen has put a lot of links out - has caused a ripple effect. The same folks (that JohnM described) have worked with Trump to develop federal law so that the states do the same thing)

Note: no objections to a national level initiative, so long as it protects privacy (what Kathleen is talking about will mostly likely not protect privacy)

  • During the ONC interoperability forum a few weeks ago - John m led a panel discussion with 'our friends' at mayo (Walker Suarez, Ken-Mayo, etc.) pre-discussion there is concern that a lot of wasted energy trying to understand 12-20 levels of privacy policy on top of each other. If there is one national 'good' privacy policy that would simplify a lot of work. These people were very clear that they not wanting to erode privacy but to make it clearer.
    • An example of this: An emancipated minor the transition is at different time is different across state boundaries. In situations such as large organizations, they must cross state boundaries ... that use case is a nightmare to figure out what is it that they have to enforce. Is it where the person requesting the data lives? Where is it the person data where they live? Where the data lives...? request resides, etc.? What is the right application to do? especially when the patient says ‘’please do…’’. What of the state location or the requester location? There is wasted energy because in US we have no unification of regulation on privacy.
  • This is a strength of GDPR its the entire UE, the entire country. Diana suggests adopting GDPR and being done with it

Baltimore Agenda

  • add TUES Q2 PSAF Refresh -

Motion to adjourn (Mike); meeting adjourned at 12:53 Arizona Time --Suzannegw (talk) 15:54, 28 August 2018 (EDT)

Retrieved from "https://wiki.hl7.org/w/index.php?title=August_28,_2018_Security_Conference_Call&oldid=160675"