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

Difference between revisions of "October 16, 2012 Security Working Group Conference Call"

From HL7Wiki
Jump to navigation Jump to search
 
(14 intermediate revisions by the same user not shown)
Line 3: Line 3:
 
[[Security|Back to Security Main Page]]
 
[[Security|Back to Security Main Page]]
 
==Attendees==
 
==Attendees==
* [mailto:bill.braithwaite@equifax.com Bill Braithwaite]
+
*[mailto:berrym@hln.com Mike Berry]
 +
*[mailto:jcarter@apelon.com John Carter]
 
* [mailto:Kathleen_Connor@comcast.net Kathleen Connor]
 
* [mailto:Kathleen_Connor@comcast.net Kathleen Connor]
 
* [mailto:mike.davis@va.gov Mike Davis] Security Cochair
 
* [mailto:mike.davis@va.gov Mike Davis] Security Cochair
 +
*[mailto:ddecouteau@edmondsci.com Duane DeCouteau]
 +
*[mailto:rdgelzer@docintegrity.com Reed D. Gelzer]
 
*[mailto:sgonzales-webb@drc.com Suzanne Gonzales-Webb] CBCC Cochair
 
*[mailto:sgonzales-webb@drc.com Suzanne Gonzales-Webb] CBCC Cochair
* [mailto:robert.horn@agfa.com Rob Horn]
+
*[mailto:cgunter@illinois.edu Carl Gunter]
* [mailto:jim.kretz@samhsa.hhs.gov Jim Kretz]
 
* [mailto:ted.lesueur.com Ted Lesueur]
 
 
* [mailto:john.moehrke@med.ge.com John Moehrke] Security Cochair
 
* [mailto:john.moehrke@med.ge.com John Moehrke] Security Cochair
* [mailto:milan.petkovic@phillips.com Milan Petkovic]
+
* [mailto:d-stumpf@northwestern.edu David A Stumpf]
* [mailto:kenneth.salyards@samhsa.hhs.gov Ken Salyards]
 
* [mailto:consulting@woodstockhit.com David A Stumpf]
 
 
* [mailto:richard.thoreson@samhsa.hhs.gov Richard Thoreson] CBCC Cochair
 
* [mailto:richard.thoreson@samhsa.hhs.gov Richard Thoreson] CBCC Cochair
* [mailto:weida@apelon.com Tony Weida]
 
* [mailto:trish.williams@ecu.edu.au Trish Williams] Security Cochair
 
 
[[Security|Back to Security Main Page]]
 
[[Security|Back to Security Main Page]]
 +
 
==Agenda==
 
==Agenda==
#''(05 min) '''[http://wiki.hl7.org/index.php?title=October_9,_2012_Security_Working_Group_Conference_Call Oct. 9, 2012 Security Working Group Conference Call Minutes]  & Accept Agenda'''
+
#''(05 min)'' '''[http://wiki.hl7.org/index.php?title=October_9,_2012_Security_Working_Group_Conference_Call Oct. 9, 2012 Security Working Group Conference Call Minutes]  & Accept Agenda'''
#''(15 min)'' '''HCS Ballot Prep discussion''' – Mike Davis
+
#''(15 min)'' '''HCS Ballot Prep discussion and [http://gforge.hl7.org/gf/download/docmanfileversion/7017/9771/SecurityLabelingSystem.pptx Security Labeling System presentation]''' – Mike Davis
#''(10 min)'' '''Updated Nov. SWG Harmonization Proposals''' -  Kathleen Connor
+
#''(20 min)'' '''[http://gforge.hl7.org/gf/download/docmanfileversion/7014/9763/CLINICALLOINCCOMMITTEE120830.docx SHARP LIHIE LOINC Proposal] and [http://gforge.hl7.org/gf/download/docmanfileversion/7013/9762/HL7SecurityWGSHARPLIHIE.msg email discussion]''' – David Stumpf
#''(15 min)'' '''SHARP LIHIE LOINC Proposal'' – David Stumpf
 
 
 
 
#''(10 min)'' '''S&P Ontology Ballot Prep discussion''' – John Carter (or TBD)
 
#''(10 min)'' '''S&P Ontology Ballot Prep discussion''' – John Carter (or TBD)
 +
#''(05 min)'' '''Updated Nov. SWG Harmonization Proposals''' -  Kathleen Connor
 
#''(05 min)'' '''Other Business, Agenda for Next call, Action Items, and Wrap Up
 
#''(05 min)'' '''Other Business, Agenda for Next call, Action Items, and Wrap Up
 +
==Minutes==
 +
*'''RE:  Approval of Minutes and Agenda''' – Presiding Cochair, Mike Davis, asked for approval of the minutes and agenda.  Minutes and agenda approved (0-0-8)
 +
*'''RE:  Security Labeling System''' - Mike Davis and Duane Decouteau presented on the components, activities, and process ownership for a healthcare security labeling system, which would be used to implement a healthcare classification scheme. 
 +
[[Image:Security Labeling Service v2 JMD.png|600px|thumb|left|Diagram of the components of a healthcare security labeling system]]
 +
 +
Step 1) Clinical facts in an EHR are mapped to categories that may be deemed “undesirable to share” due to risk of harm from unauthorized disclosure – for example, the universe of clinical and administrative indicators of HIV.
  
==Minutes==
+
Step 2) Security Labeling rules are created based on policy driven risk assessment, including consideration of the need to protect sensitive clinical facts based on privacy law, organizational privacy policy, and patient consent directives.  In this step, risk assessment under a policy might include only a subset of the universe of indicators of sensitive information triggering a particular set of security labels.  E.g., the set of HIV indicators under HIPAA may differ from the set of HIV indicators under 42 CFR Part 2, where the provider that captures the HIV information must be part of a 42 CFR Part 2 covered program while under HIPAA the provider must be a covered entity.  This difference will result in different classification and handling caveat label fields for disclosure of HIV.  HIPAA classification security label field for HIV will have confidentiality code of “normal” with obligations for disclosure of minimum necessary and encryption in transit per risk assessment.  42 CFR Part 2 classification security label field for HIV will have confidentiality code of “restricted” with additional obligation to comply with consent directive and refrain policy of “do not redisclose without consent”.
*RE:  Approval of Minutes and Agenda – Presiding Cochair, XXX…, asked for approval of the minutes and agendaXXX moved; YYY secondedMinutes and agenda approved (0-0-0)
+
 
*RE:  Topic 1
+
Step 3) Potentially sensitive clinical facts are extracted from the set of information being requested for disclosure (e.g., a clinical document). 
*RE:  Topic 2
+
 
*RE: Topic 3
+
Step 4) Security Labeling System evaluates the clinical facts for the applicable policy and applies labeling rules and other transforms including metadata tagging, redaction, masking, and transport envelope packaging.
*RE:  Other Business, Agenda for Next call, Action Items, and Wrap Up
+
 
 +
Step 5) Deliver classified document to Access Control System.
 +
 
 +
Step 6) Access Control System makes authorization decision based on Security Label.
 +
 
 +
 
 +
*'''RE:  Integrity Vocabulary''' -  John Moehrke raised concerns about overloaded use of term “Integrity”, and questioned whether Integrity vocabulary for the healthcare classification scheme is a priority and whether Integrity concepts related to records management should be included.  John pointed out the differenced among the related concepts that may get conflated:  data integrity; non-repudiation; origin authentication; authorized alteration or hiding of the data, e.g., pseudonymization; provenance of an information artifact vs. the provenance of “second hand” information included in that artifact; confidence in the reliability of information; and the workflow status or stage of completeness of an information artifact.
 +
**Reed Gelzer, speaking as a lead from the RMES WG, reiterated that group’s interest in collaboratively working on distinguishing the various aspects of integrity as these pertain to ensuring health information fidelity and access control.   
 +
**Kathleen noted that several of these concepts are provided as example codes in the Security and Privacy DAM Integrity Code list, but there is no standard vocabulary with which to encode these concepts.   
 +
**Reed and Kathleen to work offline to refine use cases and requirements for integrity vocabulary to get a baseline to present to both RMES and SWG.
 +
*'''RE:  SHARPS LIHIE LOINC Proposal''' – David Stumpf and Carl Gunter presented on the [sharps.org Strategic Healthcare IT Advanced Research Projects on Security, or SHARPS] [http://gforge.hl7.org/gf/download/docmanfileversion/7014/9763/CLINICALLOINCCOMMITTEE120830.docx Proposed use of LOINC document ontology codes for data segmentation]. 
 +
**The main tenets are that the tagging of clinical data is static, and it is the policy and consent domains that may deem the tagged clinical data as sensitive.  This proposal envisions that the policy domains are handled by policy experts separately from the tagging of the clinical data, and that at run-time, the appropriate policy would be invoked for the data being considered for disclosure. 
 +
**The proposal defines 5 levels of increasingly complex segmentation approaches from simply tagging sensitivity at the document or section levels to using value sets or ontologies to define more fine grain levels of segmentation, as well an approach for tagging free text.
 +
**Mike Davis and John Moehrke among others noted the degree to which this proposal aligns with HL7 Security WG’s Health Care Classification Scheme and Security Labeling projects as well as the HL7 Security and CBCC WG collaboration in the ONC Data Segmentation for Privacy project, especially the VA/SAMHSA Data Segmentation for Privacy demonstration pilot.  Mike noted the need for clinicians to tell security experts which clinical facts may be sensitive, which would be an important contribution from the SHARPS project.  The similarity to the European effort to develop ontology of sensitive clinical facts was noted. 
 +
**Carl Gunter, the SHARPS project lead, provided background on the project as an ONC research grantee. He noted the value of working together on data segmentation. Participants agreed to review key work products to determine whether collaboration would be beneficial.
 +
*RE:  Other Business, Agenda for Next call, Action Items, and Wrap Up – due to time limitations, other topics were deferred to next week’s call.
 
Meeting adjourned at 2:00 PM Eastern
 
Meeting adjourned at 2:00 PM Eastern
 
==Action Items==
 
==Action Items==
*RE:
+
*RE: Participants to review **[http://gforge.hl7.org/gf/download/docmanfileversion/7014/9763/CLINICALLOINCCOMMITTEE120830.docx SHARP LIHIE LOINC Proposal]
*RE:
+
**[http://gforge.hl7.org/gf/download/docmanfileversion/7013/9762/HL7SecurityWGSHARPLIHIE.msg email discussion]
 +
**[http://gforge.hl7.org/gf/download/docmanfileversion/7017/9771/SecurityLabelingSystem.pptx Security Labeling System presentation]
 +
**[http://gforge.hl7.org/gf/download/docmanfileversion/6988/9701/1.HCSClassificationScheme20121001.docx Healthcare Classification Scheme presentation]
 +
**[http://gforge.hl7.org/gf/download/docmanfileversion/6988/9701/1.HCSClassificationScheme20121001.docx Healthcare Classification Scheme paper] 
 +
*RE: Integrity Vocabulary:  Reed and Kathleen to work on proposal offline
 
[[Security|Back to Security Main Page]]
 
[[Security|Back to Security Main Page]]

Latest revision as of 17:54, 19 October 2012

Security Working Group Meeting

Back to Security Main Page

Attendees

Back to Security Main Page

Agenda

  1. (05 min) Oct. 9, 2012 Security Working Group Conference Call Minutes & Accept Agenda
  2. (15 min) HCS Ballot Prep discussion and Security Labeling System presentation – Mike Davis
  3. (20 min) SHARP LIHIE LOINC Proposal and email discussion – David Stumpf
  4. (10 min) S&P Ontology Ballot Prep discussion – John Carter (or TBD)
  5. (05 min) Updated Nov. SWG Harmonization Proposals - Kathleen Connor
  6. (05 min) Other Business, Agenda for Next call, Action Items, and Wrap Up

Minutes

  • RE: Approval of Minutes and Agenda – Presiding Cochair, Mike Davis, asked for approval of the minutes and agenda. Minutes and agenda approved (0-0-8)
  • RE: Security Labeling System - Mike Davis and Duane Decouteau presented on the components, activities, and process ownership for a healthcare security labeling system, which would be used to implement a healthcare classification scheme.
Diagram of the components of a healthcare security labeling system

Step 1) Clinical facts in an EHR are mapped to categories that may be deemed “undesirable to share” due to risk of harm from unauthorized disclosure – for example, the universe of clinical and administrative indicators of HIV.

Step 2) Security Labeling rules are created based on policy driven risk assessment, including consideration of the need to protect sensitive clinical facts based on privacy law, organizational privacy policy, and patient consent directives. In this step, risk assessment under a policy might include only a subset of the universe of indicators of sensitive information triggering a particular set of security labels. E.g., the set of HIV indicators under HIPAA may differ from the set of HIV indicators under 42 CFR Part 2, where the provider that captures the HIV information must be part of a 42 CFR Part 2 covered program while under HIPAA the provider must be a covered entity. This difference will result in different classification and handling caveat label fields for disclosure of HIV. HIPAA classification security label field for HIV will have confidentiality code of “normal” with obligations for disclosure of minimum necessary and encryption in transit per risk assessment. 42 CFR Part 2 classification security label field for HIV will have confidentiality code of “restricted” with additional obligation to comply with consent directive and refrain policy of “do not redisclose without consent”.

Step 3) Potentially sensitive clinical facts are extracted from the set of information being requested for disclosure (e.g., a clinical document).

Step 4) Security Labeling System evaluates the clinical facts for the applicable policy and applies labeling rules and other transforms including metadata tagging, redaction, masking, and transport envelope packaging.

Step 5) Deliver classified document to Access Control System.

Step 6) Access Control System makes authorization decision based on Security Label.


  • RE: Integrity Vocabulary - John Moehrke raised concerns about overloaded use of term “Integrity”, and questioned whether Integrity vocabulary for the healthcare classification scheme is a priority and whether Integrity concepts related to records management should be included. John pointed out the differenced among the related concepts that may get conflated: data integrity; non-repudiation; origin authentication; authorized alteration or hiding of the data, e.g., pseudonymization; provenance of an information artifact vs. the provenance of “second hand” information included in that artifact; confidence in the reliability of information; and the workflow status or stage of completeness of an information artifact.
    • Reed Gelzer, speaking as a lead from the RMES WG, reiterated that group’s interest in collaboratively working on distinguishing the various aspects of integrity as these pertain to ensuring health information fidelity and access control.
    • Kathleen noted that several of these concepts are provided as example codes in the Security and Privacy DAM Integrity Code list, but there is no standard vocabulary with which to encode these concepts.
    • Reed and Kathleen to work offline to refine use cases and requirements for integrity vocabulary to get a baseline to present to both RMES and SWG.
  • RE: SHARPS LIHIE LOINC Proposal – David Stumpf and Carl Gunter presented on the [sharps.org Strategic Healthcare IT Advanced Research Projects on Security, or SHARPS] Proposed use of LOINC document ontology codes for data segmentation.
    • The main tenets are that the tagging of clinical data is static, and it is the policy and consent domains that may deem the tagged clinical data as sensitive. This proposal envisions that the policy domains are handled by policy experts separately from the tagging of the clinical data, and that at run-time, the appropriate policy would be invoked for the data being considered for disclosure.
    • The proposal defines 5 levels of increasingly complex segmentation approaches from simply tagging sensitivity at the document or section levels to using value sets or ontologies to define more fine grain levels of segmentation, as well an approach for tagging free text.
    • Mike Davis and John Moehrke among others noted the degree to which this proposal aligns with HL7 Security WG’s Health Care Classification Scheme and Security Labeling projects as well as the HL7 Security and CBCC WG collaboration in the ONC Data Segmentation for Privacy project, especially the VA/SAMHSA Data Segmentation for Privacy demonstration pilot. Mike noted the need for clinicians to tell security experts which clinical facts may be sensitive, which would be an important contribution from the SHARPS project. The similarity to the European effort to develop ontology of sensitive clinical facts was noted.
    • Carl Gunter, the SHARPS project lead, provided background on the project as an ONC research grantee. He noted the value of working together on data segmentation. Participants agreed to review key work products to determine whether collaboration would be beneficial.
  • RE: Other Business, Agenda for Next call, Action Items, and Wrap Up – due to time limitations, other topics were deferred to next week’s call.

Meeting adjourned at 2:00 PM Eastern

Action Items

Back to Security Main Page