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

March 30th, 2010 Security Conference Call

From HL7Wiki
Jump to navigation Jump to search

Security Working Group Meeting

Back to Security Main Page

Attendees

Agenda

  1. (05 min) Roll Call, Approve Minutes (To Be Posted Soon) & Accept Agenda
  2. (55 min) Update of Ongoing Projects
    • Security and Privacy Ontology project
    • PASS Audit update
    • Privacy Policy Reference Catalog update

Minutes

1. Action Items - none

2. Resolutions - none

3. Updates/Discussion

Security and Privacy Ontology Project

Latest version of the Security and Privacy Ontology Project Statement is posted on GForge. 

 Earlier today, Lynn Lasko sent out an email reporting that the TSC has 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.

  • Now that we’ve completed the Composite Security and Privacy DAM ballot, we can begin to focus on this project.
  • Discussions to date have focused on tooling – Protégé versus IHTSDO Workbench.
  • Tools and whether or not to use an upper level ontology are two fundamental points we should keep in mind as we consider how to keep in alignment with the SOA work group’s approach. We should at least be aware of the decisions they make in these areas.
  • Mike: After speaking with Ken Rubin about the status of the SOA Ontology project, my sense is that they will probably follow our lead since we are a little further along (with respect to getting our project approved).
  • Steve: SOA has yet to get their project scope statement approved by either the TSC or the ArB, so in that respect they are behind us, but Jobst has been down this road before, and he is eager to move forward once the project becomes official. So we may be administratively ahead, but I’m not sure we’re technically ahead.
  • Mike: I’m not exactly sure how this is done formally, but we can start with the information model (DAM), review the classes and attributes and start with some terminology base, like the RBAC catalog to create our ontology. It would be useful to get an ontology expert to talk to us about how these things might be done.
    • We’ve included some terminology models in the current balloted DAM that provide discussion for how to organizing the terminologies. Ioana has some ideas on how to approach this, and the terminologists will also have input into a process to move this project forward. It’s hoped that Bernd and his group as well as Cecil Lynch can also help us develop the requirements for this effort.
  • Steve: Discussions taking place in the SOA ontology meetings indicate they favor using the Protégé ontology tool, and they also advocate using BFO (Basic Formal Ontology www.ifomif.org/bfo) as an upper level ontology.
  • Rob: We are at great risk of treading into very arcane academic disagreements which we’ve got to avoid to make headway. OWL is a good way to leap and also has a lot of formalisms that those who want to create implementable systems struggle with, talk to anyone at the NCI. It really isn’t worth spending a lot of time debating whether or not to use BFO.
  • Mike: I want to accomplish something usable. The first is that this ontology would be useful for the efficient performance of access control decision engines. This is reflected in the fact that OASIS has, within their XACML group, created a proposal for an ontology decision point. If our work here can provide an ontology that supports that OASIS work, we would have an immediate application and use that would have immediate impact. On the other hand, we could also create an ontology on the privacy side that provides an easy way for patients to express consent directives using a hierarchical structure. If we focus on a couple of sweet points, one, to harmonize this with the OASIS work if that goes forward and a recognized need for the notation of efficient performance of a security engine. They way that would work is that if someone had roles at a higher level, they would inherit the permissions of the roles at the lower levels of the chain and they wouldn’t have to be specified at the lower levels. If the access control required something at a lower level and the person had a role at the higher level, it would overtake the lower level role and you wouldn’t have to explicitly have all the linkages, you could simply use the hierarchy to quickly make a decision. At the same time we can look at the Consent Directive side, which I think Richard and CBCC would approve.
  • Rob: I think the basic things we need are hierarchies and the ability to inherit qualities, elements, properties, of ancestor elements. There may be some other formal ontology functionality that will turn out to be some value, but first we need to turn out hierarchies that allow for the propagation of attributes, role capabilities for example. Let’s do that and then we can move on. We don’t need BFO, or even formal ontology work to do that. We need to create the concepts and we need a number of moderately complicated use cases to clearly identify how things interact so that we can make sure that the terminology and the structures that we craft, and particularly how the structures will be used, are tested. Where Mike’s been especially correct, it is important to do this in a context that isn’t specifically in one domain or another, but that they overlap. The use cases have to take into an entire spectrum of use that runs from person A or entity A – and here are the constraints for which information should be used, all the way through system A to system µ, actually servicing that function. This way, we cover everything. We get a bunch of uses cases that dentify the phrases, concepts and how they should work together and we’ll make great leaps. And to do that we have the domain expertise to that and we don’t have to worry about stumbling all over ourselves and worry about whether or not BFO is necessary as an upper level ontology.
  • Mike: Reflecting back on the work that we did with Tony Weida on the hierarchy of vocabulary for actions and the RBAC catalog, we took that off the table saying it was too difficult to tackle at the time. We can get back to that now, as we took out all the hierarchical aspects of the work. We were having religious discussions as to whether “delete” was more important than “remove” so it got flattened.
  • Bill: I agree with Mike’s approach. Let’s make sure this is practical and we’ll let the ontologists worry about which mechanism and which hierarchy...
  • Rob: What we need to do is put together the use cases and put the the materials together so the ontologists understand how things interact. We don’t want to just throw how things relate to each other to the terminologists, because we’ll make choices that don’t work. Before we’re done, we have to have those discussions and consolidate – make things more general, and then there’s agreement on the generalities. Otherwise --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 ontologist)

Security and Privacy DAM Harmonized Security and Privacy DAM Consolidated Peer Review Comments

  • Mike: I have an update on the Domain Analysis Model. Originally, the TSC did not approve our request to ballot the DAM at the DSTU level and changed it Informative despite the fact the Privacy DAM had been balloted DSTU. I brought this up at a recent Steering Division meeting and they accepted my argument that it should be DSTU. The argument was based on two things:
  1. OASIS has been creating profiles on an ad hoc basis, not on information models. OASIS wants to continue to develop health care profiles but they want to branch out from US profiles to International profiles. Therefore, they need a normative Information Model upon which to base their profiles.
  2. Within the US, the Federal Health Information Standards and Modeling Standards (FHIMS) group that is interested in adopting our harmonized information model as part of their overall information model. They want this to be an normative standard as well.
  • These two external organizations are the basis ballot the harmonized Security and Privacy Domain Analysis Model as a DSTU with the intent to move to Normative following the trial period.
  • Kudos to the effort by Ioana and Serafina to consolidate the comments and putting this package together to get this into the May ballot. It was a tremendous effort and we should be grateful for keeping us on this very aggressive schedule. Three cheers.
  • Everyone here should be signed up and able to vote (remotely) on the ballot. I will let you know when it’s time to vote.

Walk-in Items for Security

  • Bill Braithwaite – DEA has issued an IFR rule for ePrescribing for controlled substances. They have done a lot of work on security that is a lot more restrictive than we’re accustomed to in healthcare . They are recommending very tight controls on second factor authentication that physicians will need to sign prescriptions on controlled substances. It may be useful for the Security WG to review this. We have 60 days to respond to this as it is an IFR.
  • Mike: The VA commented on earlier drafts of this--not as HL7 members. We have not looked at the latest version. There are a couple of approaches for controlled substances. The VA has advocated and implemented an approach using smartcards in a pilot with the DEA. There are other ways of providing assurance in prescriptions. One of the areas we have looked at (in the earlier drafts), was that the first signature applied to a prescription was at the site that received it, which might be a relay site or the filling pharmacy. We felt that his provided an opportunity for fraud. Without a signature from the prescribing physician, the prescribing MD was at risk. Without any kind of seal on it from their organization, they would be left hanging in terms of being able to repudiate a prescription that someone else may have submitted on their behalf using their DEA number, etc. I think they addressed this in this version.
  • Bill: This version requires biometric authentication as a second factor to a password. But they put very strict restrictions on testing that would be necessary to make sure the chance of biometric identifying the wrong person was a very small percentage. My initial review says this is much tighter than any biometric has been able to show other than DNA in the environments we are working with in electronic prescribing. They also took the NIST level three assurance for second factor authentication and carved it out and said only hard tokens and tightly controlled tested biometrics would be allowed and the other methods under level three assurance were not allowed. Which I think means it will not be a cost effective implementation mechanism in most clinical environments that are not already using HSPD 12 or other tightly controlled mechanism like the military or the VA are using, but in the private sector, this is going to be a problem.
  • Mike: I thought they were going for level three and not level four.
  • Bill: Yes, but they restricted it to only two of the level three mechanisms. One that they threw out is what I call the bingo card because the logic was that someone could copy the bingo card, at least for a month, steal the person’s second factor for authentication. And then they threw out one-time pass codes by alternative out-of-band transmissions because it was too slow. Unfortunately their information about it being too slow was wrong. It is not logical to throw out technological aspect in a regulation because next month it won’t be too slow.
  • Mike: They’re stuck between a rock and a hard place to provide the necessary security for prescribing controlled substances. Issuing cards to a limited number of people who prescribe might not be an onerous thing and the clinicians who use this love it. The workflow is greatly improved because the prescriptions get delivered immediately to the pharmacy and make it ready for the patient.

Other Business

Privacy Policy Reference Catalogue
  • Pat: The scope statement was submitted to Steering Division a week ago and haven’t heard back anything since then. Nothing else to report.
Rio Meeting Update
  • Mike: With respect to the Rio meeting, I sent an email to Bernd to make sure that the Security WG would be open to anyone from the meeting who wanted to talk about Privacy.
  • Suzanne: Joint Monday Security/CBCC meeting will take place on Monday. We will provide a report to Bernd and David Rowed so they are aware of the status of our projects. The reason that Max was pushing for this meeting is because he has a new project starting up. So he asked David to take over for this meeting in order to discuss this project. There is also the joint meeting with Patient Care which David usually attends as well.
  • Pat: There was an outstanding question about the process for selecting a proxy for the meeting. As of last week, we were left with the impression that David was an interim co-chair, or is he simply a proxy for the Rio meeting.
  • Suzanne: He is simply substituting for Max who originally thought he would be able to attend and is not. So the outcome of the meeting of the 17 March was not to elect an interim co-chair, only a proxy co-chair.
PASS Audit Update
  • Pat: As everyone is probably already aware, we did not make the cutoff for the May ballot, which is a good thing so we can spend time gain consensus. The focus of the ballot is going to be around capabilities to support, not to do, but support accounting of sidclosues. From a privacy perspective, this is not just security but it has significant privacy implications. Anyone who is not aware of that, I urge you to attend the Monday meeting, Noon eastern time. This ballot will be everything from conceptual down to a platform specific model, so it will be implementable. Progress will continue to be reported out during this call for those who are unable to attend on Mondays.

Meeting adjourned at 2:55 PM EDT No significant motions or decisions were made

Back to Security Main Page

Retrieved from "https://wiki.hl7.org/w/index.php?title=March_30th,_2010_Security_Conference_Call&oldid=35228"