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

November 7, 2017 Security Conference Call

From HL7Wiki
Revision as of 21:00, 7 November 2017 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
. John Moehrke Security Co-chair x Kathleen Connor Security Co-chair x Alexander Mense Security Co-chair . Trish Williams Security Co-chair
x Christopher Shawn] Security Co-chair . Suzanne Gonzales-Webb x Mike Davis x David Staggs
x Mohammed Jafari . Beth Pumo . Ioana Singureanu . Rob Horn
x Diana Proud-Madruga . Serafina Versaggi x Joe Lamy . Galen Mulrooney
. Paul Knapp . Grahame Grieve . Johnathan Coleman . Aaron Seib
. Ken Salyards . Jim Kretz . Gary Dickinson x Dave Silver
. Oliver Lawless . Lisa Nelson . David Tao . Nathan Botts

Back to Security Main Page

Agenda

  1. (2 min) Roll Call, Agenda Approval
  2. (3 min) Review and Approval of October 24, 2017 minutes and October 31, 2017 minutes.
  3. (15 min) 2017Nov HARM INTIALPROPOSAL SECURITY Sensitivity Codes.doc passed initial Harmonization approval. Need WG approval for final submission. - Kathleen
  4. (15 min) HL7 Security and Privacy Domain Model - Mike Davis
  5. (10 min) Consumer Centered Data Exchange (CCDE) Track for Jan Connectathon- Should Security and CBCP WGs collaborate on the development of CCDE scenarios? - John and Kathleen
  6. (5 min) PSAF PSS Report out from PSAF call discussion on need to re-review HL7 Privacy and Security Framework PSS 3 v2 approved Oct. 31 PSAF call based on initial draft revisions to HL7 Privacy and Security Framework PSS 3. Discussed during the earlier PSAF call. If the deliverables are only a subset, then have to rewrite entire first part, which describes a much larger project. Then rather than simple deliverable dates changes, we will need to have the entire PSS go through the FTSD and TSC approval process. Also, this change means we have much less flexibility about topics we can work on under the previous PSS. - Mike and Kathleen
  7. (3 min) Is Privacy Obsolete? Study Group wiki page has the "Is Privacy Obsolete?" Listserve link. Update on project - Mike Davis and Chris Shawn
  8. (2 min) FHIR Security Call later? - John Moehrke

Minutes

  • Chris Shawn chaired. Agenda approved.
  • Meeting Minutes for 10/24/2017 Motion(Kathleen/Suzanne) objections: none; abstentions: none; approved: 8
  • Note:
    • PMRM
      • ISTP links added to 10/24 minutes
  • Meeting Minutes for 10/31/2017 Motion(Kathleen/Suzanne) objections: none; abstentions: none; approved: 8
  • Note:

ACTION ITEM: Do we want to follow up on a survey?

  • Accounting of disclosures - see note from John Moehrke

Harmonization Proposal Security Recommendation for HL7 RIM Change

  • proposal accepted by the harmonization people
    • no issues with technical descriptions
    • new sensitivity codes (2); over time it became clear that v2 that carried over to v3, psych/ETOH are antiquated and narrow; Kathleen wrote out the broad concepts as part of concerns access control
      • VIO (violence information sensitivity)
      • MST (military sexual trauma information sensitivity)
    • proposal calls out trauma (non-person), and trauma called out for non-related person as well as military trauma (not specific to the US)
    • as described, decreases confusion in the current codes, MST is internationally scoped

interoperability use: may be used outside the military health systems

ETOH - an old code, an abuse; ETH substance abuse information sensitivity

    • viewed as a character flaw--not as a mental health problem
    • added as substance use disorder information sensitivity(SUD) (this is about the vulnerability of the information you'll need to look at the content and confirm that this is in the bucket for this sensitivity
      • there is granular use outside of abuse per Mike; it might be more efficient if looking for codes related to alcohol / useful to separate alcohol use from substance abuse such as opiods and other drug abuse.

ACTION ITEM: this is something that should be brought up to SAMHSA (Jim Kretz, Ken S as alcohol and drugs are combined together in 42CFR - Question: should be separate?)

typically this is a discrimination for job application etc., vs psych issue

PSY - psychiatry information sensitivity; too specific to the psychiatry discipline separated out MH (mental health information sensitivity) and BH (behavioral health information sensitivity)

Reviewed in more detail for use of ActInformationSensitivyPolicy for VIO, MST, SUD, MH, BH, SPI (specially protected information) specially is the terminology used in ONC papers as well as consent directives which ask about disclosure on MH, sexual assault, etc., when used in combination with state law for special condition according to these policy that will cue the recipient of someone receiving SPI

ETH 'first sight' is Ethanol

ACTION ITEM: check with Jim on other differentiating items for BH and MH

---END Harmonization Proposal discussion Motion to approve (Kathleen/Suzanne) opposed: none; abstain: none; approval: 8 with the caveat that answers are provided from Jim Kretz and/or Ken Salyards on the two action items described above

Seurity and Privacy Domain analysis model

  • on the PSAF call today; additional clarification drafts on the model; taking into acconts that there were lots of question on what a domain is.
    • providing more elegant descriptiosn of domains and recognizing that we need to move from defintions that are high level / ethereal and atomic in nature but do not work with real world objects. at a very core level; we have defintiosn but as we rise into complexity on what domains are and the information in them, we run into multi-domain objects which the core information does not deal with but still need to be described differently than the base definition.
  • the very core deifntion at high level principal defintions but hey apply to 'sensitivity of the domain is consisitent'; but when using real world model--where the user is percieivnt he model as presented to them... the sensisty as define in the
    • the single sensisty is a function of the classification and the HL7 HCS sensisity term (is reduntant), integrity and comparty; this should still follow the basic definition of the domains is uniquely defined but is taken from a higher level ob abstraction.
    • attempting to get from the core definition where it doesn't work with the world deifntion... youc an transition from the atomic def to the real world definition and you haven't broken any of the core defintions... just the way you are applying them
    • series of slices across the the informati objects; wehre each slide describes different federated uathization domain
  • highest level is compartment
    • other code sets, integrity codes or compartment codes are defined within the domain i.e. different compartment codes for research/within the research domain these are individual slices.
    • work in progress; incorporating items together, by next week we hope to have a version presentable for the security WG

question: appears you are using a vector instead of a scaler (implying a direction)

    • the vector represents a sensitivity vector in this 3-D space; the number of possible vectors in this space; the overall sensitivity as defined is the intersection of the classification with multiple possible values of Sensitivity-Integrity and Compartment. one way to look at his: this domain sensitivity for these information object is a function of a classification with the attributes of sensitive of Sensitivity-Integrity-Compartment as the arguments of the compartment (so they become scaler values); I can descriabe this space as 3D axis that define it..not intended to be anything more than a conceptual thing
    • the domain (atomic level)is defined to have three elements; it has users-intersections beween domain AB, data-is what it is, policy (domain has these three chracteristics); policy combines the users with the data
      • lets say we have HIV data (for security labeled as HIV) and we have some users; the policies defines the relationship bet the data and user; varying what the users bring to the table based on the policy. we don't want you to give this information unless you have clearance zz in addition handling instructions which are not computed in this sensisty value policy binds the fed dom sensistivey to fed dom users ;
  • need to know WHO, DATA, POLICY (rule); how to get to those critical data based on the rules

The care team is being handled as a user--user has rights as being part of a care team; and that is how policy is defined. if a care team member lacks permission for some sensitivy data--then the policy for that kind of user but may be overruled by individual sensisty access.

you can have two federated domains where differtn policy crosses between them; 

Shown: Care Team ABAC Provisioning 2 - xls

CCDE - how cascading OAAUTH can give patients Right of Access (RoA) Remaining agenda items: Deferred to next week

Meeting Material

See PSAF Wiki for history, links, and references

See "Is Privacy Obsolete" for new material

ISTPA

International Security, Trust and Privacy Alliance