November 7, 2017 Security Conference Call

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 group

• no issues with technical descriptions
• new sensitivity codes (2)introduced
  • Over time, it became clear that v2 that carried over to v3, psych/ETOH does 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)
• Security Harmonization 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 is an old code, an abuse; ETH substance abuse information sensitivity

• ETOH is 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 As noted 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

Security and Privacy Domain analysis model - Mike Davis

• on the PSAF call today; additional clarification added to the drafts of the model; taking into accounts that there were lots of question on what a domain is.
  • clarification provided more elegant description of domains and recognizing that we need to move from definitions that are high level / ethereal and atomic in nature but do not work with real world objects. at a very core level; we have definitions 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 definition at high-level principal definitions but hey apply to 'sensitivity of the domain is consistent'; but when using real world model--where the user is perceiving the model as presented to them... the sensitivity as define in the
  • the single sensitivity is a function of the classification and the HL7 HCS sensitivity term (is redundant), integrity and compartment; this should still follow the basic definition of the domains is uniquely defined but is taken from a higher level of abstraction.
  • attempting to get from the core definition where it doesn't work with the world definition... you can transition from the atomic def to the real-world definition and you haven't broken any of the core definitions... just the way you are applying them
  • series of slices across the information objects; where each slide describes different federated authorization 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 describe 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 between domain AB, data-is what it is, policy (domain has these three characteristics); policy combines the users with the data
  • let’s say we have HIV data (for security labeled as HIV) and we have some users; the policies define the relationship between 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 sensitivity value policy binds the federated domain sensitivity to federated domain 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 sensitivity data--then the policy for that kind of user but may be overruled by individual sensitivity access. You can have two federated domains where different policy crosses between them

Shown: Care Team ABAC Provisioning 2 - xls

CCDE - how cascading OAuth can give patients Right of Access (RoA) Remaining agenda items: Deferred to next week Meeting recording: (temporary link) https://fccdl.in/RU3LHbKpV

Meeting Material

See PSAF Wiki for history, links, and references

See "Is Privacy Obsolete" for new material

ISTPA

International Security, Trust and Privacy Alliance

• ISTPA Privacy Tools & Technology FAQ January 20, 2003
• ISTPA Privacy Framework FAQ
• Managing Information Privacy Developing a Context for Security and Privacy Standards Convergence(ISTPA Privacy Framework ISO 20886)Robbins & Sabo
• Analysis of Privacy Principles: Making Privacy Operational v.2 2007
• ISTPA Privacy Framework v.1.1 2002
• [https://gforge.hl7.org/gf/project/security/docman/Security%20White%20Papers/Is%20Privacy%20Obsolete%20Study%20Group%20Library/ISTPA/Managing%20Privacy%20and%20Information-Sabo.pdf