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

coverage determination issues with prefetch

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • US Da Vinci CRD (FHIR)
    • 1.1.0-ballot [deprecated]
    • Financial Mgmt
    • Supported Hooks
    • Hide
      "4.3.4.7 Controlling hook invocation

      Provider systems SHALL only invoke hooks on payer services where the the patient record indicates active coverage with the payer associated with the service. Providers MAY limit hook invocation to only those payers that are believed to potentially have relevant information related to the current action - for example, clinical guidance, contraindication detection, etc. This might be more payers than just those that are likely to provide coverage for the services referred to by the hook."

      Add a line:

      "For requests on information related to prior auth, in order to reduce complexity CRD clients SHOULD only invoke the hook on the payer service associated with their best guess of which coverage will be primary."

       

      2) Streamlining the request so payers can respond quickly. In https://build.fhir.org/ig/HL7/davinci-crd/hooks.html#prefetch:

      "In most cases, payers will require information about a patient’s coverage. Retrieval of this information is only dependent on the patient context and not on any other information being passed by the hook."

      Modify to:

      "In most cases, payers will require information about a patient’s coverage. In order to reduce the time CRD services spend on member matching, CRD clients SHOULD limit the coverages provided to just those relevant to the CRD service. How this happens is up to the CRD client.

      3) Setting up for a unique plan id in the future. In https://build.fhir.org/ig/HL7/davinci-crd/hooks.html#enabling-a-crd-server:

      "Provider and EHR Vendor organizations MAY leverage the payer registry developed by PDex (which will eventually fold into the national directory under FAST) as a means of determining which endpoints exist for which payers as candidates for configuration."

      Add a line:

      "Once plans are in the national directory, CRD Clients SHOULD include that plan identifier as way to uniquely identify that plan."

      Show
      "4.3.4.7 Controlling hook invocation Provider systems  SHALL  only invoke hooks on payer services where the the patient record indicates active coverage with the payer associated with the service. Providers  MAY  limit hook invocation to only those payers that are believed to potentially have relevant information related to the current action - for example, clinical guidance, contraindication detection, etc. This might be more payers than just those that are likely to provide coverage for the services referred to by the hook." Add a line: "For requests on information related to prior auth, in order to reduce complexity CRD clients  SHOULD  only invoke the hook on the payer service associated with their best guess of which coverage will be primary."   2) Streamlining the request so payers can respond quickly. In  https://build.fhir.org/ig/HL7/davinci-crd/hooks.html#prefetch: "In most cases, payers will require information about a patient’s coverage. Retrieval of this information is only dependent on the patient context and not on any other information being passed by the hook." Modify to: "In most cases, payers will require information about a patient’s coverage. In order to reduce the time CRD services spend on member matching, CRD clients  SHOULD limit the coverages provided to just those relevant to the CRD service. How this happens is up to the CRD client. 3) Setting up for a unique plan id in the future. In  https://build.fhir.org/ig/HL7/davinci-crd/hooks.html#enabling-a-crd-server: "Provider and EHR Vendor organizations  MAY  leverage the  payer registry  developed by PDex (which will eventually fold into the  national directory under FAST ) as a means of determining which endpoints exist for which payers as candidates for configuration." Add a line: "Once plans are in the national directory, CRD Clients SHOULD include that plan identifier as way to uniquely identify that plan."
    • Bob Dieterle / Jeff Brown : 8-0-0
    • Clarification
    • Non-substantive

    Description

      With https://jira.hl7.org/browse/FHIR-35794 and https://jira.hl7.org/browse/FHIR-36746 we removed use of ServiceRequest:insurance (and related fields on other profiles) to get the coverage since it is generally not populated at order-sign, and instead went with a prefetch returning the patient's list of active coverages. 

      This pattern has seen challenges at MultiCare + Cambia as when there are multiple coverages, it isn't clear which ones Cambia is actually responsible for and should have their group and subscriber number evaluated for member matching. There are plan identifiers on the Coverage resource, however they are provider owned so to work around this issue Cambia is maintaining a list of the 6 or so MultiCare plan IDs that correspond to Cambia.

      Some other comments on this area:

      • The CRD client does have to make a best guess of which coverages to use in order to decide which endpoints to call, so if that work is already being done and we have a way to pass it along to the service it makes sense to do.
      • The CRD service does want the full list of active coverages in order to do claim adjudication to give accurate responses to certain card types (ex: medicare / advantage / supplemental plans). Though many payers will already have this info.
      • The guidance on "typically only the coverage related to a payer will actually flow to the CRD Server due to limits on information disclosure" is not accurate to how things are currently set up- There are a few ways to limit access to particular sensitive coverages at that level, but not on a broad per payer basis (the concept of which plan records are authorized to be viewed by particular endpoints does not exist). I would expect the default case to be that all of the patient's coverages are returned by a Coverage.Search operation.

      Some options to improve this:

      A) The burden reduction IGs plan to make use of the national directory to get endpoints ("Provider and EHR Vendor organizations MAY leverage the payer registry developed by PDex (which will eventually fold into the national directory under FAST) as a means of determining which endpoints exist for which payers as candidates for configuration."), and the national directory has a pattern of establishing unique identifiers for the records it contains (https://jira.hl7.org/browse/FHIR-38150), so we could say that CRD clients SHALL provide that identifier on Coverage resources once it is available.

      B) We could go back to using ServiceRequest:insurance or an equivalent extension and clarify it's a best guess specific to calling the endpoint rather than something that's actually linked to the ServiceRequest at that time.

      C) We could update the guidance to clarify that there may be custom handling of the prefetch for patient coverages to make it more request-specific to the endpoint being called. 

      I'm leaning towards A

      Attachments

        Activity

          People

            Unassigned Unassigned
            kjohnsen Kyle Johnsen
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: