Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-11071

Improve security label guidance - 2016-09 core #90

    XMLWordPrintableJSON

    Details

    • Type: Change Request
    • Status: Waiting for Input (View Workflow)
    • Priority: Medium
    • Resolution: Unresolved
    • Specification:
      FHIR Core (FHIR)
    • Raised in Version:
      DSTU2
    • Work Group:
      Security
    • Related Page(s):
      Security Labels
    • Related Section(s):
      6.1.1
    • Resolution Description:
      Hide

      Kathleen is working up a smaller valueset based on most likely to be used values and explaination of how to use them.

      Show
      Kathleen is working up a smaller valueset based on most likely to be used values and explaination of how to use them.
    • Change Category:
      Correction

      Description

      Existing Wording: All of 6.1.1 Security Labels discussion.

      Proposed Wording: Add correct HL7 HCS guidance on use of security labels clearly differentiating between the 0..1 Security Label that may be assigned to a FHIR Resource/profile instance and the 1..1 Confidentiality + 0..* other security label fields. Add [co-occurence constraint. security.exists() implies security.where(code.inValueSet("http://hl7.org/fhir/ValueSet/v3-Confidentiality")).exists. Add Delete the 6.1.1.2 Core Security Labels. Include the missing Security Label fields and vocabulary for integrity and trust.

      Comment:

      The structure of security labels is not correctly described or modeled. The authors use the term "security label" for components of a security label - the security label field, which is what is valued by security/privacy tags from HL7 HCS. There's only one security label on any information artifact. Like national security information, healthcare information is by definition protected, so there must be at least one confidentiality code, even if the information is de-identified, in which case the information would have a confidentiality code = unrestricted - which is equivalent to the national security information confidentiality code = declassified. And the logic for security labels requires that there only be one confidentiality code field in a security label. It is nonsensical and ignores business requirements for the authors to leave this minimum security label field 0..* .

      Add correct HCS guidance on use of security labels clearly differentiating between the 0..1 Security Label that may be assigned to a FHIR Resource/profile instance and the 1..1 Confidentiality + 0..* other security label fields. Delete the 6.1.1.2 Core Security Labels as these are not based on any known policy or business requirements, and without such basis are merely favored security labels selected by authors. These were never discussed much less approved by the Security WG that is the authority for security labels in HL7. Add co-occurrence constraint to ensure that any security label includes 1..1 Confidentiality security label field.

      Summary:

      Improve security label guidance

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              k.connor Kathleen Connor
              Reporter:
              k.connor Kathleen Connor
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated: