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

Add more guidance on what is expected in annotations

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • US Da Vinci Risk Adjustment (FHIR)
    • 1.0.0
    • Clinical Quality Information
    • STU
    • Report Annotation
    • Hide

      The Risk Adjustment use case project participants and implementers had extensive discussions around the workflow around annotation and remediation post ballot and resulted in design changes related to Remediation and Annotation, which would also help address this comment. 

      Remediation 

      • The IG will no longer use the Task profile. The Risk Adjustment Clinical Evaluation Evidence Task profile will be removed. 
      • The IG will update the "Report Remediation" page to "Submit Data to Payer". The IG will create a new Risk Adjustment Data Exchange MeasureReport profile and uses the base FHIR $submit-data operation. This Data Exchange MeasureReport will be used for submitting any clinical evaluation evidence such as a C-CDA to Payer.  

      Annontation will be renamed to Condition Category Remark.

      • The Condition Category Remark is to allow providers to add any notes or provide any updates about a Condition Category that is on the original payer generated coding gap report. 
      • The Remark is not intended to change the status of a coding gap. It is intended to let the payer know information such as whether the provider has or has not addressed the gap, it could also help to support "soft closure" use case. 
      • Will remove relatedData attribute from the Condition Category Remark (previously Annotation) and keeps relatedDataIdentifier. 

      If Provider identifies a gap or gaps on the original Payer generated coding gap report need to be closed or updated, they must use the Data Exchange MeasureReport and the $submit-data operation to submit the clinical evaluation evidence to support gap closure and invalidation.

      These updates will ensure that there will be a clear delineation between when using Remark vs. Data Exchange MeasureReport and what may go into them. 

      The "Report Remediation" and "Report Annotation" pages, and relevant sections on the General Guidance will be updated to reflect the changes and to make the guidance more clear. 

      In 2.1.3.4  will have more clarification added along the lines of that which is mentioned in section 2.5: "Note: The Condition Category Remark extension is not intended to change the status of a Condition Category gap. To change the status, follow the Submit Data to Payer section of this guidance. Note that both a Condition Category remark and Submit Data to Payer can be generated at the time the Provider sees the patient if that is appropriate."

      Show
      The Risk Adjustment use case project participants and implementers had extensive discussions around the workflow around annotation and remediation post ballot and resulted in design changes related to Remediation and Annotation, which would also help address this comment.  Remediation  The IG will no longer use the Task profile. The Risk Adjustment Clinical Evaluation Evidence Task profile will be removed.  The IG will update the "Report Remediation" page to "Submit Data to Payer". The IG will create a new Risk Adjustment Data Exchange MeasureReport profile and uses the base FHIR $submit-data operation. This Data Exchange MeasureReport will be used for submitting any clinical evaluation evidence such as a C-CDA to Payer.   Annontation will be renamed to Condition Category Remark. The Condition Category Remark is to allow providers to add any notes or provide any updates about a Condition Category that is on the original payer generated coding gap report.  The Remark is not intended to change the status of a coding gap. It is intended to let the payer know information such as whether the provider has or has not addressed the gap, it could also help to support "soft closure" use case.  Will remove relatedData attribute from the Condition Category Remark (previously Annotation) and keeps relatedDataIdentifier.  If Provider identifies a gap or gaps on the original Payer generated coding gap report need to be closed or updated, they must use the Data Exchange MeasureReport and the $submit-data operation to submit the clinical evaluation evidence to support gap closure and invalidation. These updates will ensure that there will be a clear delineation between when using Remark vs. Data Exchange MeasureReport and what may go into them.  The "Report Remediation" and "Report Annotation" pages, and relevant sections on the General Guidance will be updated to reflect the changes and to make the guidance more clear.  In 2.1.3.4  will have more clarification added along the lines of that which is mentioned in section 2.5: "Note: The Condition Category Remark extension is not intended to change the status of a Condition Category gap. To change the status, follow the Submit Data to Payer section of this guidance. Note that both a Condition Category remark and Submit Data to Payer can be generated at the time the Provider sees the patient if that is appropriate."
    • Yan Heras/ Corey Spears: 21-0-0
    • Clarification
    • Non-compatible
    • Yes

    Description

      The purpose and effect of a report annotation by the provider is not described. The IG should describe what are usually contained within such an annotation that a provider would want to provide and what it may accomplish. A clear delineation between what might be in an annotation or an evaluation evidence task needs to be made.

      Attachments

        Activity

          People

            Unassigned Unassigned
            corey_spears Corey Spears
            Corey Spears
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: