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

Describe reasoning for choosing Bundle.signature in attachment signatures or signatures page

    XMLWordPrintableJSON

Details

    • Change Request
    • Status: Resolved - No Change (View Workflow)
    • Highest
    • Resolution: Not Persuasive
    • US Da Vinci CDex (FHIR)
    • 1.0.0
    • Patient Care
    • Attachments
    • 3.4.5
    • Hide

      Background:

      An Enveloped Signature is a Digital Signature Document/Object that contains both the signature block and the content that is signed.  Enveloped signatures do not include their own value in the calculation of the Signature.

      Resolution:

      In addition to time and budgetary constraints, a single JSON based Enveloped Signature method vs allowing for multiple options is mandated to simplify implementation.

      Benefits:

      1. Single object: Bind both a document and the signature into one document
        1. no risk signature document and content documents will be made unavailable through revision or access control.
      2.  Granularity: The Enveloped Signature Option supports one document per signature document.
      3.  Can be used when there is no Document Sharing infrastructure (ask John what this means)
      4. Covers all transactions described in CDEX:
           - Search Bundles which can be attested by systems
           - FHIR Documents (for Task Based Queries and Attachments) - "an immutable set of resources with a fixed presentation that is authored and/or attested by humans".
                -  Avoids many of the issues with "How to handle when References are included in the resource being signed?"
      5. The workflow may involve data being retransmitted and the delivery mechanisms doesn't allow transmitting multiple disjoint resources.
      6. Provenance signatures are about retaining signatures on a per version basis. In our use-case, there's no updating of the data, just a single exchange.

      There are many design decision when constructing a FHIR implementation guide - each with its own set of trade-offs. There is little value in documenting unused options which could expose future version of the guide to unnecessary rehashing of design decisions and throttle adoption due to concern about future breaking changes.

      Show
      Background: An Enveloped Signature is a Digital Signature Document/Object that contains both the signature block and the content that is signed.  Enveloped signatures do not include their own value in the calculation of the Signature. Resolution: In addition to time and budgetary constraints, a single JSON based Enveloped Signature method vs allowing for multiple options is mandated to simplify implementation. Benefits: Single object: Bind both a document and the signature into one document no risk signature document and content documents will be made unavailable through revision or access control.  Granularity: The Enveloped Signature Option supports one document per signature document.  Can be used when there is no Document Sharing infrastructure (ask John what this means) Covers all transactions described in CDEX:    - Search Bundles which can be attested by systems    - FHIR Documents (for Task Based Queries and Attachments) - "an immutable set of resources with a fixed presentation that is authored and/or attested by humans".         -  Avoids many of the issues with "How to handle when References are included in the resource being signed?" The workflow may involve data being retransmitted and the delivery mechanisms doesn't allow transmitting multiple disjoint resources. Provenance signatures are about retaining signatures on a per version basis. In our use-case, there's no updating of the data, just a single exchange. There are many design decision when constructing a FHIR implementation guide - each with its own set of trade-offs. There is little value in documenting unused options which could expose future version of the guide to unnecessary rehashing of design decisions and throttle adoption due to concern about future breaking changes.
    • Eric Haas/Jay Lyle:9-0-1

    Description

      Why is Bundle.signature being mandated over allowing Provenance.signature. I may be misinterpreting but the rules of the digital signature page (hl7.org/fhir/signatures.html) that FHIR Document points to, seem to encourage detached digial signature on Provenance with their trial note discussion (https://confluence.hl7.org/display/FHIR/Digital+Signatures) pointing to bundle.signature being used for integrity signatures instead of document signatures. The enveloped signature page doesn't discretely call out why Bundle.signature is used as the envelope. Since these linked pages are still evolving themselves - it is recommended to describe why you chose the path of enveloping using bundle to prevent the reader from making similar jumps between pages that offer multiple options

      (Comment 6 - imported by: Ron G. Parker)

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              Rongparker Ron G. Parker
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: