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

Need clarification on who is signing for whom

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • US Da Vinci CDex (FHIR)
    • 1.1.0-ballot [deprecated]
    • Patient Care
    • STU
    • Attachments
      Direct Query
    • 3.2.6, 3.4.5
    • Hide

      Background

      For context section 3.2.6  Signatures for the Direct Query transaction and as the comments states "The signature SHALL represent a system-level attestation by the sending organization that they are the source of the information."

      The rationale for the organizational signature is that: 

      • Synchonous - There no human intervention in direct query so the expectation that a human will sign it to the data is unrealistic
      • "The signature SHALL represent a system-level attestation by the sending organization [singing on behalf of itself] that they are the source of the information."
      • Always system level sig if required by agreement. (no way to assign a sig to individual transaction)
      • If there is a requirement for an individual attestation by either party, then a task-based query is required.
      • Note that "a signed search bundle could have entries within it that are individually signed as well (e.g CCDA, PDF, Image, CDA on FHIR ). 

      For context section 3.4.5  Signatures for Attachments and as the commenters states "[in contrast to section 3.2.6] The signature SHALL represent a human provider signature on resources attesting that the information is true and accurate."

       

      The rationale for the individual signature is that: 

      • it is assumed there may need be human intervention to assemble the attachments when preparing the Parameters resource for this operation.
      • "The signature SHALL represent a human provider signature [singing on behalf of themself] on resources attesting that the information is true and accurate."
      • Note that the attachments may already be inherently signed (for example, a wet signature on a PDF or a digitally signed CCDA) or if  FHIR  resources transformed into a signed FHIR Document and that is what signed
      • Signature requirement is made at the query level and communicated using the "signature" task input element.

       

      Are these in conflict? 

      Maybe, see actions to clarify below

      Is this trying to say that we want a human provider to sign on behalf of their organization?

        No they are attesting different things for each context.

      Or is it suggesting that the signature represents different things in different contexts

      Yes see the explanation above

       

      i.e. system signature when the request comes from the payer org but human signature when the request comes from the provider org?"

      This interpretation is incorrect! In all cases the signature is required by the Payer.

      It's not clear why the two scenarios should be treated differently, and it's not clear what to do when the provider org sends a request from an automated workflow without a human present.

      as explained above if a provider signature is required to attest to the claim data then human intervention is by definition required and Direct Query transaction cannot be used.  See below for clarifications to be added to guide.

      Action 

      1. We will add a summary section in the Signatures pages "Who is Signing". to summarize these different scenarios and reference it in each of the detailed signature rules.

      2. Will add to asynch/Task Based Queries that:

      • May also be negotiated by parties e.g., for automated workflows.
      • acceptable to have system level signatures
      • May need provider signatures in addition to what is negotiated by parties
      Show
      Background For context section 3.2.6  Signatures for the Direct Query transaction and as the comments states "The signature  SHALL  represent a  system-level  attestation by the sending organization that they are the source of the information." The rationale for the organizational signature is that:  Synchonous - There no human intervention in direct query so the expectation that a human will sign it to the data is unrealistic "The signature  SHALL  represent a  system-level  attestation by the sending organization [singing on behalf of itself]  that they are the source of the information." Always system level sig if required by agreement. (no way to assign a sig to individual transaction) If there is a requirement for an individual attestation by either party, then a task-based query is required. Note that "a signed search bundle could have entries within it that are individually signed as well (e.g CCDA, PDF, Image, CDA on FHIR ).  For context section 3.4.5  Signatures for Attachments and as the commenters states " [in contrast to section 3.2.6] The signature  SHALL  represent a  human provider  signature on resources attesting that the information is true and accurate."   The rationale for the individual signature is that:  it is assumed there may need be human intervention to assemble the attachments when preparing the Parameters resource for this operation. "The signature  SHALL  represent a  human provider  signature [singing on behalf of themself]  on resources attesting that the information is true and accurate." Note that the attachments may already be inherently signed (for example, a wet signature on a PDF or a digitally signed CCDA) or if  FHIR  resources transformed into a signed  FHIR Document  and that is what signed Signature requirement is made at the query level and communicated using the "signature" task input element.   Are these in conflict?  Maybe, see actions to clarify below Is this trying to say that we want a human provider to sign on behalf of their organization?   No they are attesting different things for each context. Or is it suggesting that the signature represents different things in different contexts Yes see the explanation above   i.e. system signature when the request comes from the payer org but human signature when the request comes from the provider org?" This interpretation is incorrect! In all cases the signature is required by the Payer. It's not clear why the two scenarios should be treated differently, and it's not clear what to do when the provider org sends a request from an automated workflow without a human present. as explained above if a provider signature is required to attest to the claim data then human intervention is by definition required and Direct Query transaction cannot be used.  See below for clarifications to be added to guide. Action  1. We will add a summary section in the Signatures pages "Who is Signing". to summarize these different scenarios and reference it in each of the detailed signature rules. 2. Will add to asynch/Task Based Queries that: May also be negotiated by parties e.g., for automated workflows. acceptable to have system level signatures May need provider signatures in addition to what is negotiated by parties
    • Eric Haas/Bob Dieterle: 8-0-3
    • Clarification
    • Non-substantive

    Description

      3.2.6 says "The signature SHALL represent a system-level attestation by the sending organization that they are the source of the information." but 3.4.5 says "The signature SHALL represent a human provider signature on resources attesting that the information is true and accurate."

      Are these in conflict? Is this trying to say that we want a human provider to sign on behalf of their organization? Or is it suggesting that the signature represents different things in different contexts, i.e. system signature when the request comes from the payer org but human signature when the request comes from the provider org? It's not clear why the two scenarios should be treated differently, and it's not clear what to do when the provider org sends a request from an automated workflow without a human present.

      Attachments

        Activity

          People

            Unassigned Unassigned
            sutley Spencer Utley
            Hans Buitendijk
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: