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

Difference between revisions of "July 14th 2009 Security Conference Call"

From HL7Wiki
Jump to navigation Jump to search
 
(3 intermediate revisions by the same user not shown)
Line 5: Line 5:
 
==Attendees== (expected)
 
==Attendees== (expected)
  
* [mailto:bernd.blobel@ehealth-cc.de Bernd Blobel] Security Co-chair, absent
 
 
* [mailto:sconnolly@apelon.com Steven Connolly]
 
* [mailto:sconnolly@apelon.com Steven Connolly]
* [mailto:coynee@saic.com Ed Coyne]
 
 
* [mailto:mike.davis@va.gov Mike Davis] Security Co-chair
 
* [mailto:mike.davis@va.gov Mike Davis] Security Co-chair
 
* [mailto:gonzaleswebs@saic.com Suzanne Gonzales-Webb] CBCC Co-chair
 
* [mailto:gonzaleswebs@saic.com Suzanne Gonzales-Webb] CBCC Co-chair
* [mailto:rhamm@gmail.com Russ Hamm]
+
* [mailto:allen.hobbs@kp.org Allen Hobbs]
* [mailto:robert.horn@agfa.com Rob Horn]
 
 
* [mailto:djorgenson@inpriva.com Don Jorgenson]
 
* [mailto:djorgenson@inpriva.com Don Jorgenson]
 
* [mailto:glen.f.marshall@siemans.com Glen Marshall] Security Co-chair
 
* [mailto:glen.f.marshall@siemans.com Glen Marshall] Security Co-chair
 
* [mailto:rmcclure@apelon.com Rob McClure]
 
* [mailto:rmcclure@apelon.com Rob McClure]
* [mailto:john.moehrke@med.ge.com John Moehrke]
 
 
* [mailto:milan.petkovic@phillips.com Milan Petkovic]
 
* [mailto:milan.petkovic@phillips.com Milan Petkovic]
* [mailto:ppyette@perimind.com Pat Pyette]
 
 
* [mailto:scott.m.robertson@kp.org Scott Robertson]
 
* [mailto:scott.m.robertson@kp.org Scott Robertson]
 
* [mailto:dsperzel@apelon.com David Sperzel]
 
* [mailto:dsperzel@apelon.com David Sperzel]
* [mailto:richard.thoreson@samhsa.hhs.gov Richard Thoreson] CBCC Co-chair
 
 
* [mailto:ioana@eversolve.com Ioana Singureanu]
 
* [mailto:ioana@eversolve.com Ioana Singureanu]
 
* [mailto:weida@apelon.com Tony Weida]
 
* [mailto:weida@apelon.com Tony Weida]
Line 41: Line 35:
 
** A page will be created with the PDF documents as a back up
 
** A page will be created with the PDF documents as a back up
 
* Suggestion to approach publishing saying that the ballot will not benefit with this transformation
 
* Suggestion to approach publishing saying that the ballot will not benefit with this transformation
#''(15 min)'' '''[[add link]]] HL7 Risk Management Document'''  
+
#''(15 min)'' '''[[add link]] HL7 Risk Management Document'''  
#''#''(5 min)'' '''Other Business'''  what additional action items to we need to do
+
#''#''(5 min)'' '''Other Business'''   
* invite people to attend calls, increase awareness, start dialogue on issues with the vocabulary. (we will not have any discussions between the committees about the vocabularies)
+
* additional action items to we need to do
Mike would like to ask that the WG take a look at the ballot.  The first of August we should have a committment to go with this ballot.  An electronic ballot will be sent out to get committment from both working groups (CBCC, Security)
+
** invite people to attend calls, increase awareness, and start dialogue on issues with the vocabulary. (We will not have any discussions between the committees about the vocabularies)
** if we have existing mappings of the objects to SNOMED or LOINC so that the implementers could see how they align with the RBAC vocabulary, in the short term that would be the most concrete terms...is that feasible to post somewhere?  (Ioana)
+
Mike would like to ask that the WG take a look at the ballot.   
Response:  We could not find a consistent mapping which is why we chose to map to the HL7 EHR FM (Mike).  CDA, C-32 documents are being used to code structured documents.  if our security polices are not directly supported by this that puts a barrier because now we have to map the document type to the object list that is part of the permission catalog.  it just adds another indirect mapping to the process.
+
** The first of August we should have a commitment to go with this ballot.  An electronic ballot will be sent out to get commitment from both working groups (CBCC, Security)
 +
 
 +
Request: (from an implementer's view) If we have existing mappings of the objects to SNOMED or LOINC that could be referenced so that the implementers could see how they align with the RBAC vocabulary, in the short term that would be the most concrete term(?)...is that feasible to post somewhere?  (Ioana)
 +
Response:  We could not find a consistent mapping which is why we chose to map to the HL7 EHR FM (Mike).   
 +
(Ioana) CDA, C-32 documents are being used to code structured documents.  If our security policies are not directly supported by this that puts up a barrier because now we have to map the document type to the object list that is part of the permission catalog.  It just adds another indirect mapping to the implentation process.
 +
(Mike) Note:  NHIN has also chosen to use SNOMED CT codes in their structural roles.  We have opened up ASTM1986E terms and enumerate them as much as possible.  I’m not disagreeing that may be useful thing to do—and there are gaps, since SNOMED CT has gaps.  This group as a whole has made the decision to not go this route…we have enumerated this version.  If they would like to map this to SNOMED CT then they can, but we will not be doing this for this particular ballot.
 +
(Rob M) Vocabulary gaps, overlaps will be identified and resolved.
  
 
==Action Items==
 
==Action Items==
 +
 +
'''JOINT DISCUSSION between CBCC & Security''' to make sure we are all on the same page regarding Privacy in the Constraint Catalog
  
 
[[Security|Back to Meetings]]
 
[[Security|Back to Meetings]]

Latest revision as of 18:14, 14 July 2009

Security Working Group Meeting

==Attendees== (expected)


Agenda

  1. (05 min) Roll Call, Approve Minutes & Accept Agenda
  2. (15 min) EHR WG Meeting
  • Meeting information: 770-657-9270 Access: 510269, Today (Tuesday) 3:30-4:30 EST
    • Security has reported to EHR before with no mixed discrepancies
    • We hope they are receptive to the concept (and Security would like to get out of the vocabulary maintainence piece as this is not solely a domain vocabulary, but also includes consumer) domains of course can make domain vocabulary extensions
    • aligning with the EHR makes sense; the work we are doing is providing more than just HL7 content (also HITSP, Healthcare IT community. Note: ANSI provides sponsorship), more discussion needed in the Security WG
    • Steve and Suzanne will report back next week with any comments
  1. (15 min) XML Transformation of RBAC Documents
  • Suggestion to add a page linking to a PDF document
    • per Don Lloyd this suggestion was unacceptable for the ballot
    • Result: The conversion must be done by hand which is a very 'laborious' and 'long' process
    • Steve Connolly has taken on the conversion task
    • A page will be created with the PDF documents as a back up
  • Suggestion to approach publishing saying that the ballot will not benefit with this transformation
  1. (15 min) add link HL7 Risk Management Document
  2. #(5 min) Other Business
  • additional action items to we need to do
    • invite people to attend calls, increase awareness, and start dialogue on issues with the vocabulary. (We will not have any discussions between the committees about the vocabularies)

Mike would like to ask that the WG take a look at the ballot.

    • The first of August we should have a commitment to go with this ballot. An electronic ballot will be sent out to get commitment from both working groups (CBCC, Security)

Request: (from an implementer's view) If we have existing mappings of the objects to SNOMED or LOINC that could be referenced so that the implementers could see how they align with the RBAC vocabulary, in the short term that would be the most concrete term(?)...is that feasible to post somewhere? (Ioana) Response: We could not find a consistent mapping which is why we chose to map to the HL7 EHR FM (Mike). (Ioana) CDA, C-32 documents are being used to code structured documents. If our security policies are not directly supported by this that puts up a barrier because now we have to map the document type to the object list that is part of the permission catalog. It just adds another indirect mapping to the implentation process. (Mike) Note: NHIN has also chosen to use SNOMED CT codes in their structural roles. We have opened up ASTM1986E terms and enumerate them as much as possible. I’m not disagreeing that may be useful thing to do—and there are gaps, since SNOMED CT has gaps. This group as a whole has made the decision to not go this route…we have enumerated this version. If they would like to map this to SNOMED CT then they can, but we will not be doing this for this particular ballot. (Rob M) Vocabulary gaps, overlaps will be identified and resolved.

Action Items

JOINT DISCUSSION between CBCC & Security to make sure we are all on the same page regarding Privacy in the Constraint Catalog

Back to Meetings