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

Difference between revisions of "March 30th, 2010 Security Conference Call"

From HL7Wiki
Jump to navigation Jump to search
Line 6: Line 6:
 
==Attendees==  
 
==Attendees==  
  
*  
+
* [mailto:talbertson@inpriva.com Tabitha Albertson]
* [mailto: Bill Braithwaite]
+
* [mailto:bbraithwaite@anakam.com  Bill Braithwaite, MD]
 
* [mailto:sconnolly@apelon.com Steven Connolly]
 
* [mailto:sconnolly@apelon.com Steven Connolly]
 
* [mailto:mike.davis@va.gov Mike Davis] Security Co-chair
 
* [mailto:mike.davis@va.gov Mike Davis] Security Co-chair
Line 19: Line 19:
  
 
[[Security|Back to Security Main Page]]
 
[[Security|Back to Security Main Page]]
 
  
 
==Agenda==
 
==Agenda==

Revision as of 18:11, 30 March 2010

Security Working Group Meeting

Back to Security Main Page

Attendees

Back to Security Main Page

Agenda

  1. (05 min) Roll Call, Approve Minutes (To Be Posted Soon) & Accept Agenda
  2. (45 min) Update of Ongoing Projects
    1. Security and Privacy Ontology Project - (Mike) true version can be found on GForge. Will be discussed at next TSC meeting. Discussion at TSC meeting on which ontology to use. Some termoniolgy models in the current DAM that might provide discussion. The terminologists may propose a process to move forward to include Berndt and Cecil and develop the requirements for the ontology effort.

(Steve) have been listenting to the SOA ontology and they have been favoring Protege ontology tool (as well as BFO Basic Formal Ontology www.ifomif.org/bfo as upper level ontology). We should keep aware of the status of this as it is preferred we stay in line with SOA.

The TSC approved the  Security and Privacy Ontology Project:

excerpt from e-mail sent on 3/30/2010: (from Lynn Lasko of HL7) · Security and Privacy Ontology Project for Security Work Group [WG] of Foundation and Technology Steering Division [FTSD] (TSC Issue # 1478 – Status=Closed; Project Insight ID= 646). This project will develop a domain ontology encompassing the healthcare IT security and privacy domains providing a single, formal vocabulary embodying the concepts in each domain as well as concepts shared between the two. The concepts identified and defined in this ontology will be primarily drawn from those concepts contained in the Security and Composite Privacy DAMs. The concepts in this ontology will be extended in order to bridge to standard ontologies in associated domains such as enterprise architecture, clinical care and biomedicine. (Rob) We will need specific use case to clearly cover our spectrum of use, phrases, concepts (to which BFO will not be necessary as an ontology) we need to put together the material and understand how things interact--that shouldn't be left to the ontologist as we may make choices that don't match up (i.e. delete does not equal remove to an ontologiest)

    1. Security and Privacy DAM Harmonized Security and Privacy DAM Consolidated Peer Review Comments The TSC had unapproved our request to ballot this as DSTU level. Note OASIS has already been creating standards based on this model (in an adhoc way) OASIS would like to continue to develop subsequent profiles to include Internation realm, they will need a formal healthcare model. They are interested in adopting our HL7 infomration model. The arguement to change the ballot BACK to DSTU because we have external to HL7 a Security and Privacy Model. We are awaiting an answer from John Quinn and the Steering Division. Kudos to Ioana and Serafina with their consolidation of all the comments to get this to the May ballot/agressive schedule.
Reminder to sign up to vote on the ballot
  1. (5 min) Other Business
    1. (Pat) EEA - final rule of controlled substanced (pre-release last Friday), they ahve done a lot of security work that is more restrictive than what we've seen in normal healthcare. May be useful for the Security WG to look at this.

(Mike) the VA has looked at earlier drafts of this--not as HL7 members. We have not looked at the latest version. There are other ways of providing assurance in prescriptions. One of the areas we have looked at (in the earlier drafts), the first site to receive the Rx--provided an input for fraud. The prescribing physician would be at risk, the prescription would be in their name without a seal (i.e. authenticating seal) (Pat) they allowed biometric signatures in this version, which is much tighter than any other biometric has shown (outside of DNA) they took the NIST level three assurance....but restricted it to only two of the level three methods. One that was thrown out was the lingo card as well as one-time passcode out-of-band because they were too slow. (Mike) The prescribers who are using cards love it--workflow is enhanced

Action Items

Back to Security Main Page