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

April 26, 2011 Security Conference Call

From HL7Wiki
Jump to navigation Jump to search

Security Working Group Meeting

Back to Security Main Page

Attendees

Back to Security Main Page


Agenda

  1. (05 min) Roll Call, Approve Minutes & Accept Agenda
  2. (15 min) Review of hData Risk Assessment, Presentation Gerald Beuchelt
  3. (15 min) HL7 “Policy Advisory Committee” to help them prepare feedback on the USA “Federal Health IT Strategic Plan: 2011-2015” - John Moehrke
  4. (15 min) Update on Security and Privacy Ontology Tony Weida
  5. (5 min) Other Business

Minutes

Roll Call, Approve Minutes & Accept Agenda

Update on Security and Privacy Ontology - Tony Weida

Tony has spotted a few things on the ballot and is doing some additional editing on the ontology to separate the permissions from the Permission Catalog since they are one hand HL7 RBAC specification on the other hand a non-normative portion.

  • Would like to schedule ballot reconciliation at the upcoming May WG meeting

(Note: Ballot Reconciliation is on the Agenda for the WG meeting)

  • Intent was to submit as an Informative Ballot in this cycle but the TSC has put it forward as a DSTU. From the call we had the Steering Division they said we don’t have to review this and carry if forward as a DSTU---we can review the comments and the result of the review will lead to DSTU in September, but not try to reconcile this version as a DSTU. The Security WG can go through the reconciliation process and incorporate any comments as received, we will carry it forward in September and republish/ballot as a DSTU in September.


hDATA Presentation - Gerald Beuchelt

Introduction: A high level (Risk Assessment) discussion held on 4/21 between Diana, Suzanne, Gerald and Mark Kramer (Mitre) on the hData RESTful specification. Shown at this meeting was the Security Risk section added to the document as interpreted through the Risk Assessment Document. The following slides are a high level capture of what was discussed, how we approached security in general. If you have read the hData for the January 2011 ballot and the comments made against it specifically in the Security area—we really took the security comments to heart and wanted to make sure we addressed the concerns but still maintain the flexibility that we see in a applicable security layer. We were also introduced to the Security Risk Assessment cookbook which we had not been introduced to before.

See presentation: given by Gerald Beuchelt

Slide 2 – Bottom line, we did not want to lock down a complete security subsystem for the protocol itself, that would restrict or put too much burden on the developer or deployer that just wants to use hData for a specific use – so that was essentially our starting point.

  • What we 'are' wanting is a fairly flexible security approach.
    • Basic approach: We essentially that came to the conclusion we want to take a flexible security route on the one side define a security baseline –
    • enables fundamental protection for the protocol and the data there, while at the same time contain extensibility in the core protocol themselves so that domain specific WG or even deployers can define their own security mechanisms communicate those to the potential client and makes sure they fit the requirement at that point in time.
  • hData spec has pedigree/standards information cited and “must implement/may deploy” guarantees to the end-user of the hData, a minimal set of interoperable security mechanisms are available. (again, intended to be a baseline security and not everything required for a full security system)
  • Extension points
    • Customized security for domains and deployments you can customize the security and also for specific deployments.
  • Risk Assessment
    • Threats are specific to the domain (research database vs. hospital management system vs. other, etc)
    • we do try to adjust, address there are certain vulnerabilities that will be shared across entities (web-based technologies—http, SSL, TLS, etc) are common across implementations.
    • custom security implementations will introduce specific vulnerabilities
    • Risk cannot be uniformly assessed across all deployments or implementation.

We’ve tried to document as comprehensively as possible in both documents (in the hData spec this is addressed in Section 4 – Security Considerations) in the Record Format Section 2.6 deals with the meta data for the baseline security and the extension point for it.

Note: SOA has adopted the scope statement for hData. hData has been available as a draft (in SOA WG) and has asked that the security considerations be looked at—determine necessary Security framework in the core protocols to secure implementers and deployers

Gerald – SOA has recognized that HL7 doesn’t typically delve down to specific technology that far; at the request of the ArB, the record format itself defines a package approach which ties back to data modeling and conceptual modeling which is completely covered by the SAEAF and the general HL7 approach. The restful transport we are investigating how we want to leverage HL7 OMG HSSP project to make sure the components of the specification are technology specific (and more detailed) will be reviewed by OMG as well

Mike – are you finding from the discussion that this is predicated by HL7 in making a decision to go in this direction or is this coming from the SOA group (OMG side)? Is this a general trend that we moving toward in the industry--way from traditional web-services.?

hData has been HL7 for about 2 years now—we have been in discussions with TSC of the ITS WG, we went to ballot in January since then in ArB it has been considered a useful project for HL7 but it is SOA who is responsible for it.

Mike – I haven’t been tracking that…now that you’re here I’m asking questions I’m looking at the underline this as rest than as opposed to web-services

hData—the record format itself, is transport neutral; effectively packaging, organizing and annotating clinical information of different media types with meta data and making available through a service ‘’(unable to distinguish the type of service during the call).’’ We identify the restful transport as useful in the context of () service and essentially created that transport to allow the effective exchange hData compliant record format. One side is the organization of the record—tagging of specific meta data and the modeling that goes along with the hData profile which ties it back to the conceptual model and on the other side is the restful transport.

If there are further questions after the meeting, Gerald will answer those via e-mail or by phone. hData specs and presentations links have been posted here and in GForge

  • HL7 Policy Advisory Committee meeting - John Moehrke

The HL7 Policy Advisory Committee 'is requesting assistance to prepare feedback on the USA “Federal Health IT Strategic Plan: 2011-2015”' see April 19 Meeting Minutes for initial information

  • Feedback on the USA Federal Heath IT Strategic Plan needed
  • Updates were sent to the group from John Moehrke via e-mail with a few updates.
  • A list was being prepared with links to standards as discussed in an e-mail string between John and Serafina (Suzanne cc’d) to some mapping. The mapping may also help with the HL7 and the confidentiality codes project in CBCC


Privacy Mapping

  • Effort to identify code/sets value sets for the information model

Pat, Diana and Suzanne are combining our lists together in regards to identifying codes sets—the original spreadsheet was started by Steve Connolly and this is the continued effort

History: This is a specific task to identify US realm code sets/value sets that meet the specific classes; that satisfy the classes of the Harmonized privacy and security information model. This is being done as an example instance—we have plans of things to do with it, it is being done to identify the standards that support these classes and create a map of those and see what the results are. We may find that there are several international standard and little US standards which may extend the DAM in that manner from this way forward. It may also support additionally the ontology effort as well.

The baseline spreadsheet piece that Diana and Suzanne are currently working was started by Pat Pyette. Currently these are the title headers [Term, Definition, Source, DAM Definition] and the noted definitions identified in the DAM. This task may also assist in the CBCC project started We are still looking filling the definitions portion as well as There are obviously some terms missing---we have run across this before in several documents; and bear in mind we did not want to get in to the terminology business, but several of the terms we use on a regular basis are not defined in a standardized manner—wherein a source is identified by some standard. It makes no sense to define something if we cannot point to a standard to support.

This spreadsheet will be posted to GForge. Going forward:

We should be able to pick on a class here and apply an applicable standard, review definitions and determine that yes this is a reasonable definition or not, confirm a definitive source, etc.

General question: (Mike) if for example, we need some ISO standard... i.e. 184-3, is there any issue with respect with ISO to have that standard available for the folks working on that within this group? Usually those standards have some licensing fee applied to them… This would be a good thing for a co-chair to follow up on.

QUESTION: Is using the same definition as an ISO standard a part of the intellectual property--- or are we just harmonizing?

In contemplating the map—the map could identify the standard/s that we are using to link to a particular class or section to the standard that is relevant to that linkage without identifying it—I don’t think the group as a whole should be able to see it and not just take on faith. We should as a group have access to the standard that we are linking and say 'oh yea' that vocabulary seems appropriate without just saying it’s necessarily sufficient.

(Diana) There is publicly available vocabulary and glossary for ISO standard defined vocabulary. I don’t’ know what the legality is between ISO and HL7.but because it publicly available (it’s on the public facing ISO website) at the very least we should be able to post that—that has all the standards that are linked to particularly vocabulary along with the definition…

This list provides high level definitions but they probably do not have an extract of code sets or value sets for that specification at the granular level that’s a useful thing. At a very specific level for a list of terms they will not be posted for that document.

I wonder who the HL7 person is who would be to get legal access ….

We can ask the staff – ACTION ITEM: Mike to take on asking HL7 staff to determine (legal) access to needed ISO documentation. (Don Lloyd? Lynne Laakso?)

In the past we’ve had agreements with other SDOs as long as in the context of a particular work activity-(SDO to SDO)--I wouldn’t’ think there would be an issue…we have an agreement with ISO but we have to work through w/ HL7 staff to get access to particular standards that we want and I don’t’ know if there are any other requirements in regard to restricting access. It’s essential that the group must have access to the standards to do this work. We’re working from privately owned or organizationally owned copies of standards at this point.

Part of the problem is the presentation---what has been done, and what we have yet to do. Something graphical would be great...spreadsheets are not always the best.

Mind-Mapping - Discussion Personal brain – (personal brain or ‘the Brain’) demo scheduled for May 10


Action Items

Back to Security Main Page

Retrieved from "https://wiki.hl7.org/w/index.php?title=April_26,_2011_Security_Conference_Call&oldid=49884"