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

Difference between revisions of "July 28, 2015 Security WG Conference Call"

From HL7Wiki
Jump to navigation Jump to search
 
(One intermediate revision by one other user not shown)
Line 74: Line 74:
  
 
==Meeting Minutes==
 
==Meeting Minutes==
''Meeting Minutes for July 21'''
+
'''Meeting Minutes for July 21, 2015'''
* Meeting Minutes for July 21 were unanimously approved
 
  
* no additional agenda items suggested or added
+
* The minutes from the July 21 meeting were unanimously approved
  
 
'''PASS Access Control Conceptual Model (SOA)''' Update - Diana
 
'''PASS Access Control Conceptual Model (SOA)''' Update - Diana
* discussion on how obligation will fit into the PASS AC Model
 
* how obligations are dealt with in terms of SLS, and how to put obligations into the AC model at a higher (conceptual) level
 
* SOA meeting on Monday, discussion w/Don; placement of SOA diagram
 
** pointed to process documents that SOA follows when completed functional model documents
 
** based on the template (SOP/development practice) the diagrams of the FM will come after the FM model requirements
 
  
** Kathleen would like to know why SLS is more in the weeds than obligations
+
Discussion:
** ACS is a conceptual model, whereas SLS is more specific
+
* How obligations will fit into the PASS AC Model;
 +
* How obligations are dealt with in terms of SLS; and
 +
* How to put obligations into the AC model at a higher (conceptual) level
  
there are some drawings in the SLS that have been adapted for that standards, with a little modification we can use those diagrams to update the SOA AC.  Items will be convered ''conceptually''
+
* At the SOA meeting on Monday, Diana had a discussion with Don regarding the placement of the SOA diagram
* in terms of behavioral modeling,
+
** Pointed to process documents that SOA follows when completing functional model documents
* Per Kathleen, there are items already in HL7 on obligations and care should be taken to align with those items.
+
** Based on the template (SOP/development practice), the diagrams of the FM will come after the FM model requirements
  
* as an interoperability spec, we need to be able to relay that information
+
* Kathleen would like to know why SLS is more in the weeds than obligations
 +
** ACS is a conceptual model, whereas SLS is more specific
  
what the contract needs to say between the parties (what is being consumed)
+
* There are some drawings in the SLS that have been adapted for standards; with a little modification we can use those diagrams to update the SOA Access Control document. Items will be covered ''conceptually''
what labels would be put on the document, including handling instructions which convey some policy.
+
** Per Kathleen, there are items already in HL7 on obligations and care should be taken to align with those items
 +
** As an interoperability spec, we need to be able to relay that information
 +
*** What the contract needs to say between the parties (what is being consumed)
 +
*** What labels would be put on the document, including handling instructions which convey some policy.
 +
*** When the obligations are a type of polcy that can be conveyed with security labels, but can also be enforced by custodian
  
when the obligations are a type of polcy that can be conved w security lables, but can also be enforced by custodian
+
'''ACS Model''' - Dave
Discussion
 
  
'''ACS Model - '''
+
* Revised version of functional model and corresponding requirements statements (v3) sent to Diana and Kathleen for distribution to group and comment
* revised version of functional model and corresponding requirements statements (v3) to Diana,Kathleen for distribution to group/for comment
+
** Biggest change is consolidation/streamlining of the authorization manager
** biggest changes is consolidation/streamlined the authorization manager and started to promote to green level
+
** Consolidated version to be cleaner
** consolidated to be cleaner (and to what Muhammad has recommend)
 
otherwise generally the same
 
  
Capabilities listing
+
* Capabilities list
* within the functional model diagram, reworked into a requirements statement
+
** These are listed within the functional model diagram and have been reworked into requirements statements
* in most cases, its background, or clarification.  a subrequirement
+
** In most cases, it's background or clarification (including sub-requirements)
** recommend items should read as ''shall''  
+
** Recommended items should read as ''shall''  
** additional recommendations noted
+
** Additional recommendations noted
* note that guidance is heavily 'copy and paste'
+
** Note that guidance is heavily "copy and paste"
  
what is the timeline for folks to provide comments?
+
* What is the timeline for folks to provide comments?
* not specified yet
+
** Not specified yet
* items will be posted on GForge and link sent to Security WG
+
** Items will be posted on GForge and a link will be sent to Security WG
  
 
'''Joint Vocabulary Alignment'''
 
'''Joint Vocabulary Alignment'''
* preliminary guide for creating dicitionary vocabulary
 
* basic process outlined in the guide, in using the process group has come up with definitions in the viewpoint in EHR which will allow Security, Provenance and ___ and where they fit
 
* two definitions were processed (not quickly) at the last meeting; several distinctions were relayed at the last meeting making the process not quick, not repeatable.  Having a process is better than where we were but the fine-grained distinctions may not relay to other languages.
 
* the notion of the extended definitions i.e. W3C mold, there is a core, one-sentence/well-crafted definition (following the rules), the extended definition contains much more detail, and in general where the definition is trying to get to.  A broader description
 
* definite progress made, but there is concern on how long it will be before the definitions will be completed
 
* rules were determined from several places including Wiktionary (dictionary version of Wikipedia)
 
  
Example shown
+
* Diana has created a preliminary guide for creating dicitionary definitions
 +
* Basic process outlined in the guide; in using the process, the group has come up with definitions from the viewpoint of EHR which will allow the group to see where the definitions align with Security and Provenance
 +
* Two definitions were processed (not quickly) at the last meeting; several distinctions were relayed at the last meeting making the process not quick and not repeatable. Having a process is better than where we were, but the fine-grained distinctions may not relay to other languages.
 +
* The extended definitions (i.e., in the W3C mold, there is a core, one-sentence, well-crafted definition (following the rules)) cover much more detail and generally cover where the definition is trying to get to
 +
* Definite progress made, but there is concern on how long it will be before the definitions will be completed
 +
* Rules were determined from several places including Wiktionary (dictionary version of Wikipedia)
 +
 
 +
* Diana presented the proposed process for creating dictionary definitions for EHR Lifecycle terms.
 +
** Two dictionary terms were attempted and agreed upon at this meeting using the proposed process.
  
 
'''PSAF Update''' - Kathleen
 
'''PSAF Update''' - Kathleen
sketching out policy information models previsoulsy working on the HCS
+
 
in Harmonization:
+
* Sketching out policy information models that were previously worked on in the HCS
 +
 
 +
In Harmonization:
 
* an e-mail thread
 
* an e-mail thread
* technical conficitiaonly changes
+
* technical confidentiality changes
* presentation by Graham/Lloyed and approved by JOhn Moehrke
+
* presentation by Graham/Lloyd and approved by John Moehrke
** in the proposal it said that the Security WG -
+
 
** provenance observation
+
''Meeting adjourned at 1300 PDT''
issue raised on governance
 

Latest revision as of 15:52, 4 August 2015

Attendees

x Member Name x Member Name x Member Name
x Mike DavisSecurity Co-chair . Duane DeCouteau . Chris Clark
John MoehrkeSecurity Co-chair Johnathan Coleman . Aaron Seib
x Alexander Mense Security Co-chair . Ken Salyards x Christopher Brown TX
. Trish WilliamsSecurity Co-chair . Gary Dickinson . Tim McKay
x Kathleen Connor . Ioana Singureanu . Mohammed Jafari
x Suzanne Gonzales-Webb . Darrell Woelk . Galen Mulrooney
x Diana Proud-Madruga Grahame Grieve x William Kinsley
x Rick Grow x Chethan Makoahalli Lloyd McKenzie
x Dave Silver x [mailto: Bill Kleinebecker] [

Back to Security Main Page

Agenda DRAFT

  1. ( 5 min) Roll Call, Agenda Approval, Approve July 21 Meeting Minutes
  2. ( 5 min) PASS Access Control Conceptual Model (SOA) Update - Diana, Don Jorgenson
  3. (10 min) ACS model - Mike/Dave Silver
  4. ( 5 min) Joint Vocabulary Alignment Update - Diana
  5. ( 5 min) PSAF Update - Kathleen
  6. ( 5 min) Status of Provenance and AuditEvent subcommittee - Kathleen/John
  7. ( 5 min) FHIR Security Discussion Block Vote for approval August 4
  8. ( 5 min) October 2015 HL7 WGM - Atlanta, Georgia USA - agenda items
    • Please send any agenda items to Suzanne

FHIR AuditEvent Block Vote

  • 7432 2015May core #720 - AuditEvent requestor (Helen Broberg) Not Persuasive
  • 7565 2015May core #856 - Fix link (Kathleen Connor) Not Persuasive with Mod
  • 8123 AuditEvent constraints are too tight (Lloyd McKenzie) Persuasive
  • 6233 AuditEvent confusion on 'idenfier' elements that are actually strings. Affects understanding as well as search (which should not be token) (John Moehrke) Persuasive with Mod
  • 6269 AuditEvent needs a Participant userId type code to explain how to understand the value in userId (e.g. Patient ID in CX form) (John Moehrke) Persuasive with Mod
  • 7431 2015May core #719 - AuditEvent source identifier (Helen Broberg) Persuasive with Mod
  • 7564 2015May core #855 - AuditEvent.event value set is a mess (Kathleen Connor) Persuasive with Mod

Meeting Minutes

Meeting Minutes for July 21, 2015

  • The minutes from the July 21 meeting were unanimously approved

PASS Access Control Conceptual Model (SOA) Update - Diana

Discussion:

  • How obligations will fit into the PASS AC Model;
  • How obligations are dealt with in terms of SLS; and
  • How to put obligations into the AC model at a higher (conceptual) level
  • At the SOA meeting on Monday, Diana had a discussion with Don regarding the placement of the SOA diagram
    • Pointed to process documents that SOA follows when completing functional model documents
    • Based on the template (SOP/development practice), the diagrams of the FM will come after the FM model requirements
  • Kathleen would like to know why SLS is more in the weeds than obligations
    • ACS is a conceptual model, whereas SLS is more specific
  • There are some drawings in the SLS that have been adapted for standards; with a little modification we can use those diagrams to update the SOA Access Control document. Items will be covered conceptually
    • Per Kathleen, there are items already in HL7 on obligations and care should be taken to align with those items
    • As an interoperability spec, we need to be able to relay that information
      • What the contract needs to say between the parties (what is being consumed)
      • What labels would be put on the document, including handling instructions which convey some policy.
      • When the obligations are a type of polcy that can be conveyed with security labels, but can also be enforced by custodian

ACS Model - Dave

  • Revised version of functional model and corresponding requirements statements (v3) sent to Diana and Kathleen for distribution to group and comment
    • Biggest change is consolidation/streamlining of the authorization manager
    • Consolidated version to be cleaner
  • Capabilities list
    • These are listed within the functional model diagram and have been reworked into requirements statements
    • In most cases, it's background or clarification (including sub-requirements)
    • Recommended items should read as shall
    • Additional recommendations noted
    • Note that guidance is heavily "copy and paste"
  • What is the timeline for folks to provide comments?
    • Not specified yet
    • Items will be posted on GForge and a link will be sent to Security WG

Joint Vocabulary Alignment

  • Diana has created a preliminary guide for creating dicitionary definitions
  • Basic process outlined in the guide; in using the process, the group has come up with definitions from the viewpoint of EHR which will allow the group to see where the definitions align with Security and Provenance
  • Two definitions were processed (not quickly) at the last meeting; several distinctions were relayed at the last meeting making the process not quick and not repeatable. Having a process is better than where we were, but the fine-grained distinctions may not relay to other languages.
  • The extended definitions (i.e., in the W3C mold, there is a core, one-sentence, well-crafted definition (following the rules)) cover much more detail and generally cover where the definition is trying to get to
  • Definite progress made, but there is concern on how long it will be before the definitions will be completed
  • Rules were determined from several places including Wiktionary (dictionary version of Wikipedia)
  • Diana presented the proposed process for creating dictionary definitions for EHR Lifecycle terms.
    • Two dictionary terms were attempted and agreed upon at this meeting using the proposed process.

PSAF Update - Kathleen

  • Sketching out policy information models that were previously worked on in the HCS

In Harmonization:

  • an e-mail thread
  • technical confidentiality changes
  • presentation by Graham/Lloyd and approved by John Moehrke

Meeting adjourned at 1300 PDT