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

Provider Attestation guidance needs fixing

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive
    • Icon: Medium Medium
    • US Da Vinci DTR (FHIR)
    • 1.0.0 [deprecated]
    • Clinical Decision Support
    • Requesting Additional Information from the User [deprecated]
    • Hide

      In some cases, if there isn't specific data that can be retrieved computably from the EHR, it may be sufficient for a payer to merely have an attestation by the provider that certain documentation exists, that a certain patient condition exists, or that certain actions have been completed.  This can be represented in a Questionnaire as a simple boolean or choice question where the text describes what the user is attesting to.  Payers SHOULD design questionnaires to support attestation rather than discrete data where this is sufficient for the business requirements.

      Some payers may require that attestations or other answers be 'signed' (the electronic equivalent of 'initialing' the answer.  The [signatureRequired] extension on the Questionnaire item and the [signature] extension on the QuestionnaireResponse

      Questionnaires may also support attaching reports or other supporting documentation (e.g. images, pathology reports, etc.) where providing question answers is not sufficient.  The 'attachment' question type can be used to support this.  Attachments might be found by searching for DocumentReference, DiagnosticReport or Media instances, or by the provider directly uploading something to the Questionnaire rendering tool.

      Note:  Ticket FHIR-36468 requires that the author be associated automatically with any manual entry, and will satisfy most requirements to document the source of an attestation.  The signature extension is available where a more formal authentication of author is required.

      Show
      In some cases, if there isn't specific data that can be retrieved computably from the EHR, it may be sufficient for a payer to merely have an attestation by the provider that certain documentation exists, that a certain patient condition exists, or that certain actions have been completed.  This can be represented in a Questionnaire as a simple boolean or choice question where the text describes what the user is attesting to.  Payers SHOULD design questionnaires to support attestation rather than discrete data where this is sufficient for the business requirements. Some payers may require that attestations or other answers be 'signed' (the electronic equivalent of 'initialing' the answer.  The  [signatureRequired]  extension on the Questionnaire item and the  [signature]  extension on the QuestionnaireResponse Questionnaires may also support attaching reports or other supporting documentation (e.g. images, pathology reports, etc.) where providing question answers is not sufficient.  The 'attachment' question type can be used to support this.  Attachments might be found by searching for DocumentReference, DiagnosticReport or Media instances, or by the provider directly uploading something to the Questionnaire rendering tool. Note :  Ticket FHIR-36468 requires that the author be associated automatically with any manual entry, and will satisfy most requirements to document the source of an attestation.  The signature extension is available where a more formal authentication of author is required.
    • Bob Dieterle / Greg White: 18-0-0
    • Clarification
    • Non-substantive

    Description

      1. Attestation isn't something we can make a 'SHALL' - because attestation isn't necessarily appropriate/sufficient for certain types of payer requirements. 
      2. We shouldn't be making any statements around how HTML should be defined.  There's no guarantee that the SMART app or EHR will be using HTML at all to render Questionnaires.   
      3. Supporting information and attestations are orthogonal concepts.  We will need separate questions for those things.  If you have a question that's asking for a date, you can't then send an 'attestation' code - and doing so wouldn't make sense.  What answers are allowed is defined solely by the design of the Questionnaire - DTR can't 'force' allowing additional answer codes.  (And shouldn't try to.)
      4. Having an 'author' extension on each item for attestation is not representing the semantic you're wanting (it's also not in SDC).  The standard way to do this in SDC is with the signatureRequired element (and the corresponding signature extension in the instance)

      What we should say is this:

      "In some cases, if there isn't specific data that can be retrieved computably from the EHR, it may be sufficient for a payer to merely have an attestation by the provider that certain documentation exists, that a certain patient condition exists, or that certain actions have been completed.  This can be represented in a Questionnaire as a simple boolean or choice question where the text describes what the user is attesting to.  Payers SHOULD design questionnaires to support attestation rather than discrete data where this is sufficient for the business requirements.

      Some payers may require that attestations or other answers be 'signed' (the electronic equivalent of 'initialing' the answer.  The [signatureRequired] extension on the Questionnaire item and the [signature] extension on the QuestionnaireResponse

      Questionnaires may also support attaching reports or other supporting documentation (e.g. images, pathology reports, etc.) where providing question answers is not sufficient.  The 'attachment' question type can be used to support this.  Attachments might be found by searching for DocumentReference, DiagnosticReport or Media instances, or by the provider directly uploading something to the Questionnaire rendering tool."

      Attachments

        Activity

          People

            Unassigned Unassigned
            lloyd Lloyd McKenzie
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: