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

January 5th 2010 Security Conference Call

From HL7Wiki
Jump to navigation Jump to search

Security Work Group Weekly Conference Call

Meeting Information

Attendees

Agenda

  1. (05 min) Roll Call, Approve Security WG 12/15 Minutes, Approve CBCC WG 12/15 Minutes & Call for Additional Agenda Items
  2. Report-Outs:

Minutes

1. Action Items

  1. Steve: Determine whether the NUCC Provider Specialty Code Set distinguishes between licensed and non-licensed providers.
    • There is additional work to be done defining a number of classes as there may be missing attributes or questionable definitions of some attributes. Classes that have been called out include: Authority, Certification, Location, InformationReference
    • The spreadsheet will be updated with additional columns noted in the Security DAM Value Sets section below.

2. Resolutions

  • Initial focus for the Security DAM value sets exercise is to identify US Realm value sets

3. Announcements

  • Security DAM ballot signup closed on Jan 4. Voting closes on January 11
  • Security co-chair elections take place during the Phoenix Meeting

4. Updates/Discussion

PASS Update:

The PASS Alpha project posted a set of objectives and deliverables for Winter/Spring 2010 on the PASS Wiki site. This list was reviewed with the workgroup in last Monday’s meeting.

Based on feedback from the group, the objectives will be prioritized and one or more deliverables will be selected based on the support from the group.

Security DAM Value Sets:

The Work Group recognized that ultimately there is a need to describe value sets that support cross-boarder interoperability, but the initial focus of this effort is on developing value sets for the US Realm.

  • The Value Sets spreadsheet depicts all the classes and attributes defined in the Security DAM.
    • A number of classes in Security DAM diagrams have not been defined in the Security DAM.
      • Those rows have been highlighted blue
    • This raised two questions: one of style (replicating shared concepts in multiple documents), the other, whether there is an intent to merge the two DAMs.
  • Many of the classes and attributes are shared between the Security and Privacy Preferences information models. The Security Value Sets table shows the Security information model which is about enforcement in the engine.
    • At the time of writing the Security DAM, it was decided not to duplicate shared classes in the Security DAM.
      • Shared classes may not be identical since obviously there are different perspectives between Security and Privacy
      • If there are missing classes or attributes (not been defined in either DAM, this is an oversight.
        • Please enter this as a comment to the Security DAM or bring this discrepancy to the attention of Ioana and/or Serafina
    • There are a few classes and attributes which appear to be the same but whose names are slightly different (e.g., ClinicalCondition and Condition)
      • This is due to the fact the two DAMs have not yet been harmonized. It was noted during today’s meeting that the ultimate goal is to harmonize the Security and Privacy information models by September 2010.
    • It was suggested that we add additional columns to capture the Privacy information model values/definitions for shared classes/attributes
      • This will help in the harmonization efforts. Whether this means to join them together as one model or indicate there are mappings between the two to harmonize them is to be determined.
      • The WG agreed to add columns to capture the Privacy concepts if they happen to be identified while focusing on Security, but the initial focus should only be on Security Value Sets for the US Realm.
  • A new column called Data Type has been added to the Value Sets spreadsheet to distinguish attributes described by vocabulary from those that not (string, integers, date-time, identifiers).
    • Vocabulary attributes will be noted by data types “CNE” or “CWE”.
  • When encoding rules are used to define unique identifiers such as patients and providers, the data type will be noted as “II” and the encoding rule details entered into the Assigning Authority/URI/Value column. E.g.,:
    • The unique ID for providers is the National Provider Identifier (NPI). The Assigning Authority for NPI is the National Plan and Provider Enumeration System (NPPES). (This is in reference to the providerId attribute within the Certification class)
    • The HIPAA Provider Taxonomy code used to designate a provider’s area of practice or specialty, is the National Uniform Claim Committee (NUCC)). (This is in reference to the specialty attribute within the Certification class)
    • Assigning Authorities have unique identifiers as well.
  • Once values have been populated for each appropriate attribute, Mike suggested that it would be helpful to drill down to tables containing the specific values in the recommended code sets.
    • We will look into developing a mechanism will to accomplish this and the spreadsheet will be updated accordingly (e.g., Sharepoint location to store those tables).
  • A Comments column will capture the assumptions/conclusions made for each attributes based on the WG’s discussion about those attributes.
    • The Comment column will also note those attributes recognized as having “immature” code set definitions (where the code sets are not well established or complete). This allows the WG to prioritize which attributes to focus on first.


The following classes and attributes were discussed during the meeting:

  • Purpose of Use: This is one of the attributes which illustrates two issues:
  1. the maturity level of code sets
  2. existence of equivalent terms in the Security & Privacy models.
    • There are many possible code sets due to different perspectives. For instance, the Security model is intended to represent Access Control policies but it needs to harmonize with a patient’s purpose of use, which may be different.
    • This is a bridging attribute and requires attention
  • Level of Assurance (LoA): this data type for this attribute is “CWE”.
    • NIST 800-63 has identified four (or five) levels associated with this concept which at this point in time, is the most appropriate code set to describe this attribute. There is also an effort underway by OASIS and Liberty Alliance to create a value set for this concept but as yet, it is not currently available for use.
    • In situations like these, we shouldn’t be picky about choosing the code set since it may change in the future. NIST 800-63 is the appropriate Value Set Source for now.
    • The Comments column will be used to capture the known efforts, such as OASIS and Liberty Alliance
  • Certification: definition in the Security DAM for this class: A user's certifications may affect their access to specific IIHI for a patient. Healthcare providers are certified to provide specific services or use specific healthcare devices. This class deals specifically with professional certifications that may affect a user’s privileges in a healthcare organization.
    • The WG questioned whether this class describes individual’s medical credential, and requests clarification for the definition. During this discussion, the group equated the word Certification with credential.
    • ASTM 2210 is explicit about describing providers that have licensed credentials versus those that are non-licensed to allow for access control decisions to be based on a provider’s credentials.
    • The NUCC code set was suggested for the Specialty attribute (the only coded attribute within this class), but we need to confirm whether the NUCC code set distinguishes which provider taxonomy codes are equated with licensed credentials.
    • It was noted by Bill Braithwaite that there is a difference between being credentialed as a Physician and a Surgeon and practicing in a particular specialty (e.g., Internal Medicine, Pediatrics), the latter is what the NUCC Provider taxonomy describes.
    • A question was raised as to whether NUCC codes map to non-licensed ASTM providers.
      • The VA mapped the ASTM Structural Role codes to NUCC codes in the Structural Roles catalog. Some ASTM non-licensed providers map to NUCC codes (e.g., Nurse’s Aide and Phlemotomist), but others, such as Orderly, Interpreter, Patient Advocate, clinical and administrative personnel do not map to NUCC codes.
  • ClinicalCondition: Question for Ioana about it is not defined in either the Security or Privacy DAM.
    • The class Condition in the Privacy DAM is equivalent to Clinical Condition
    • SNOMED is the designated coding system for Condition (and Clinical Condition)
  • FunctionalGroup: there are three attributes defined for this class (ID, name and code). The question is whether code is an II data type, in which case the ID attribute would be part of the definition of the code attribute (ID, assigning authority and code value).
    • It was recommended that ASTM 1986 value set be used for the attribute FunctionalGroup.code within Functional Group.
  • InformationObject: This is the RBAC object vocabulary
  • InformationReference: This is a generalization of InformationObject.
    • The HL7 confidentiality code system is recommended for the time being as there is still outstanding discussion around the concept of sensitivity attribute
  • Location: The work group felt that the Security DAM definitions for this class and its attributes requires more thought and discussion. In addition, neither attribute (workstation ID and address are subject to vocabulary.
  • ObligationPolicy: The definition for this class indicates that an obligation policy may be used to specify additional privacy preferences specified by a client/patient. The obligation may be used to indicate that the receiver of an information object may not be allowed to redisclose or persist the information object(s) indefinitely.
    • The attribute identified in this class is ObligationCode (eventCode). It identifies the action required before completing a workflow step. In this model we assume it is coded concept but in today's implementations it's primarily an ad-hoc rule reference (e.g. the name of a DB stored procedure) and thus it is not interoperable across organizations.
    • An obligation may be associated with the release of an object. For example it may require a signature. This information is passed as rule for an application to enforce. In other cases it may require that audit record be created.
    • Currently, there is no standard set of obligations that have been identified and therefore Ioana indicated that a standard vocabulary does not exist at this time. So this is an attribute that may require the creation of a
    • Don thought that the XSPA XACML profile may have defined a vocabulary associated with obligations, but Mike does not recall this. Obligations can be created using a standard policy language, and the obligation would have some internal value which has no inter-operable purposes. We’ve talked about a work item, and we may raise this as a HL7 item. We can write 10 policies that the patient would have. If we did that, we’d havea codified list of policies like that. We’ve talked about these as potentially obligation policies, but currently there is no list that we can site.
    • Richard stated that CFR 42 Part II is an obligation policy, but Mike didn’t believe that a list exists for encoding this concept.
  • Organization: This class looks a lot like the Authority class.
    • This could be overloaded for a different purpose
    • The question is what are we trying to do with Organization? What is the distinction between Organization and the Authority for this policy?
      • The policy could be set by a particular entity but it could apply to certain organizations. An organization may be an authority but it may be referred to as an Organization, not an authority, so it may have different vocabularies.
      • The policy could be set by a particular entity but it could apply to specific organizations.
        • The organization may be an authority but it may be referred to as an organization but not an organization. They have different roles.
          • Example: The authority for the policy is the state of Maryland, but there is a list of organizations of organizations in Maryland that the policy applies to.
      • If the purpose of the class is that the organization is the organization this policy applies to as opposed to the authority over those organizations. Then this would be the organization this policy applies to. If this is the purpose, it is important to have this attribute in the policies.
      • John asserts that If an organization has multiple departments/areas for which separate policies exist, the organization would be identified as the Authority and the policy that is specific to that department would have an attribute in the policy the equal to the department’s unique identifier.
    • The Organization class is used in two ways:
    1. As a subset of Authority used to identify additional attributes to the Authority
    2. To qualify users belonging to a specific organization
    • The question is, do we need more than a unique identifier for an “organization”? Do we need to have a description of the type of organization?
    • We need to expand on the attributes for this class.
  • It was decided that there would be an offline meeting between Steve and Ioana to clarify the intent of the remainder of classes that are in question. Other than that, Steve can take this exercise and complete it without further input from the Work Groups.
    • After Steve completes his work, the spreadsheet will be circulated to the workgroup for their consideration.

The meeting was adjourned at 3:00 PM EST.

Retrieved from "https://wiki.hl7.org/w/index.php?title=January_5th_2010_Security_Conference_Call&oldid=31186"