This wiki has undergone a migration to Confluence found Here

November 12, 2013 Security WG Conference Call

From HL7Wiki
Jump to navigation Jump to search

Back to Security Main Page


Member Name Present Member Name Present Member Name Present
Mike Davis Security Co-chair x John Moehrke Security Co-chair Trish Williams Security Co-chair
Bernd Blobel, Security Co-chair . . .
Johnathan Coleman Kathleen Connor x Duane DeCouteau x
Reed Gelzer Suzanne Gonzales-Webb CBCC Co-chair x Brian Handspicker
Muhammed Jafari Don Jorgenson Diana Proud-Madruga x
Harry Rhodes Ioana Singureanu David Staggs
Richard Thoreson CBCC Co-chair Tony Weida x Scott Weinstein
Rick Grow x Liora Alschuler x Russell Ott x
Eric Pupo x . .

Back to Security Main Page


  1. (05 min) Roll Call, Approve Minutes & Accept Agenda
  2. (15 min) LOINC Clinical Document Ontology Discuss security related aspects and ballot comments (moving to next week)
  3. (10 min) 'LOINC Clinical document ontology - Russ Ott
  4. Ballot Reconciliation Comments Security and Privacy Ontology
  5. (10 min) Other Business

Meeting Minutes

Review of comments 'HL7_IG-LOINCONT_R1_D12013SEP_kathleen_connor_20130916051237' HL7 IG LOINC Ontology Ballot Question 1: Tony response:

Question 2:

FHIR Resources in XDS metadata. In some situations are any of these sections in CCD?

Liora: What is the role, where is the role of the author? Why is this focusing from the role component--the author might be a resident as a person trying to access?

There is no issue in using LOINC codes in access codes. It appears to me that there is an overloading of the term 'role'... security vs. operational vs... whatever role. As long as we are clear on where the term role ‘‘It’s making assertions on an access control role As long as it is not specific to a security access role--we have agreed that what is being discussed here is that they are not the same.

LOINC can be brought in as an addition to the ontology.

To be clear, recommends/proposes that this document NOT talk about access control.

  • The intent for adding the information was to consider access control--if the role was not
  • When looking at the document sites--they may not have access to certain clinical document.
    • Without saying you have to use that type of access of control
    • When choosing a document site the user needs to be aware of the access control required. The document code will be persistent--the relevance of RBAC or another access control, may have a bearing.

• The RBAC catalog defines permissions, not roles. It requires an actionable object. Security is not authoritative on the roles or objects being controlled. There is no intention of security to own or control clinical vocabulary---we don’t want to be the owners of clinical vocabulary. We’re going to define these clinical objects using logic, then the RBAC catalog should be applied to that vocabulary. Otherwise, what kind of objects are we trying to control? There’s no clinical objects floating around in the security environment, which is our space…I think security should be separated from clinical stuff…I wouldn’t be going around to define clinical objects and insist that they have such a statement in them.

Are there any concerns with the IG moving forward without the statements of access control in it? (Mike): that is your choice

(Russ) We will proceed to strike the reference to the S&P ontology and RBAC catalog from the LOINC IG document. There may be a general statement on access control---i.e. guidance, highlighting documents while access controls rules may change, the document persistence will remain. (Russ) then there will be no conformance statements on Security/Security and Privacy Ontology. We will offer this disposition and bring it back once worded to the Security group for acceptance.

Attendee list is limited this week. Tony’s resolution will be discussed next week when a larger quorum can be achieved.

Meeting adjourned.