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

inline security must address .meta.security

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • FHIR Data Segmentation for Privacy (FHIR)
    • 0.3.0
    • Security
    • STU
    • Inline Security Labels
    • Hide

      Update:

      • We will add a discussion on how this is a roadmap item and is being left for future work.
      • We will note that the resource meta.security should record the high water mark for inline labels.
      • HWM algorithm will be left to policy
      • HWM for confidentiality is based on the order.
      Show
      Update: We will add a discussion on how this is a roadmap item and is being left for future work. We will note that the resource meta.security should record the high water mark for inline labels. HWM algorithm will be left to policy HWM for confidentiality is based on the order.
    • Mohammad Jafari / Cindy Blackwell : 6-0-0
    • Enhancement
    • Non-substantive

    Description

      I think the concept of inline tagging is mostly good, but the practice is flawed. 

      Where in bundle we use a high-water mark at the bundle level to indicate the highest content contained... there should be a similar high-water mark in the resource holding inline tagging. YET, if this was done with the .meta.security; then the inline extension would have nothing to do as .meta.security applies to everything. 

      SO, I previously indicated that the extension has-inline-security-label should be replaced with a code in .meta.security..... I still think there should be a code... but now find a use for this root level extension. The root level extension should be of datatype CodeableConcept at 1..*; and hold the high-water mark. 

      But, I am not sure this works either... as the Resource as handled by an application unaware of inline tagging needs to be told that the resource is high-water mark sensitive.

       

      I am not convinced that this model will work except in an environment where policy indicates that inline will always be used, thus no need for a "has-inline...".

      Attachments

        Activity

          People

            Unassigned Unassigned
            john_moehrke John Moehrke
            John Moehrke
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: