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

Provide clarity on why solicited workflow varies from existing guidance in financial module

    XMLWordPrintableJSON

Details

    • Change Request
    • Status: Published (View Workflow)
    • Highest
    • Resolution: Not Persuasive with Modification
    • US Da Vinci CDex (FHIR)
    • 1.0.0
    • Patient Care
    • Attachments
    • 3.4.1.1
    • Hide

      Background:

      The Section in the FHIR Specification that the commenter is referencing :

      13.0.10 Attachments - Supporting Information 

      There is often a need to provide supporting information, commonly referred to as attachments, to document the need for a service and/or to confirm that the good or service was authorized or rendered. This information may be in many forms, including: scanned documents, PDFs, word processing files, X-Rays, images, CDAs and FHIR Resources.

      Supporting information may be provided, as a reference or the actual material, to support the Claim (complete claim or Preauthorization) or ExplanationOfBenefit in a variety of manners:

       

      • Included: in the .supportingInfo section;
      • Unsolicited: in a Communication which refers to the Claim or Explanation of Benefit; or
      • Solicited: in a Communication in response to a CommunicationRequest from the insurer requesting more information; or
      • Input: in the input parameters of a FHIR operation or Task.input element if a Task resource is used.

       

      HIPAA requirements for attachments rule is that the standard must be compatible with existing X12 transactions (837,277). CDex Project will define a set of FHIR transactions that are compatible with these X12 transactions (277, 278).  In other words, CDex working with the PIE workgroup will add support for Attachments Request using FHIR based request (content to be added to CDex for Sept/ Ballot) specifically for the "solicited attachments" use case.

       

      However, as documented in the Da Vinci HREX IG (http://hl7.org/fhir/us/davinci-hrex/exchanging-request.html#request), given the downsides associated with Requesting exchange using CommunicationRequest, CDex will be using a Task based approach instead.   We will create a tracker to suggest changes to the Financial Management Group page to expand the list of options and discourage the use of CommunicationRequest.

      Show
      Background: The Section in the FHIR Specification that the commenter is referencing : 13.0.10 Attachments - Supporting Information  There is often a need to provide supporting information, commonly referred to as  attachments , to document the need for a service and/or to confirm that the good or service was authorized or rendered. This information may be in many forms, including: scanned documents, PDFs, word processing files, X-Rays, images, CDAs and FHIR Resources. Supporting information may be provided, as a reference or the actual material, to support the  Claim  (complete claim or Preauthorization) or  ExplanationOfBenefit  in a variety of manners:   Included : in the .supportingInfo section; Unsolicited : in a  Communication  which refers to the Claim or Explanation of Benefit; or Solicited : in a  Communication  in response to a  CommunicationRequest  from the insurer requesting more information; or Input : in the input parameters of a FHIR operation or Task.input element if a  Task  resource is used.   HIPAA requirements for attachments rule is that the standard must be compatible with existing X12 transactions (837,277). CDex Project will define a set of FHIR transactions that are compatible with these X12 transactions (277, 278).  In other words, CDex working with the PIE workgroup will add support for Attachments Request using FHIR based request (content to be added to CDex for Sept/ Ballot) specifically for the "solicited attachments" use case.   However, as documented in the Da Vinci HREX IG ( http://hl7.org/fhir/us/davinci-hrex/exchanging-request.html#request ), given the downsides associated with Requesting exchange using CommunicationRequest, CDex will be using a Task based approach instead.   We will create a tracker to suggest changes to the Financial Management Group page to expand the list of options and discourage the use of CommunicationRequest.
    • Eric Haas/Jay Lyle:9-0-1
    • Correction
    • Non-substantive

    Description

      Why does the Solicited Workflow only account for non-FHIR request? Is the intent to never support FHIR for solicited requests as defined in the financial module attachment guidance (hl7.org/fhir/financial-module.html#attachments)? This guidance specifically calls out solicited scenario with the CommunicationRequest resource from an insurer asking for more information. If there is a clear rationale for not choosing to not consider it/align to guidance in the base spec - it should be clearly stated.

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

      Attachments

        Issue Links

          Activity

            People

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

              Dates

                Created:
                Updated:
                Resolved: