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

Improve security label guidance - 2016-09 core #90

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • FHIR Core (FHIR)
    • DSTU2
    • Security
    • Security Labels
    • 6.1.1
    • Hide

      Apply updated html found in comment

      Show
      Apply updated html found in comment
    • Mohammad Jafari / Kathleen Connor : 12-0-0
    • Clarification
    • Non-substantive
    • R5

    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

        Activity

          People

            john_moehrke John Moehrke
            k.connor Kathleen Connor
            Watchers:
            6 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: