51.0.1Prior Auth CRD (Coverage Requirement Discovery) Module Overview

Experimental

51.0.2Prior Auth CRD (Coverage Requirement Discovery) Introduction

The Coverage Requirements Discovery (CRD) module in Smile Digital Health facilitates interactions between the Electronic Medical Record (EMR) systems, referred to as the Client, and the payer systems to determine prior authorization requirements for specific healthcare services to be provided to a patient.

Built on the Fast Healthcare Interoperability Resources (FHIR®) standards, Prior Auth CRD aligns with the HL7 Da Vinci Coverage Requirements Discovery (CRD) implementation guidelines (IG). The Prior Auth CRD module supports FHIR® version R4 and enhances the prior authorization workflow with several key features:

• Prefetching Required Data Resources: The module depends on the CDS hooks module that can automatically fetch necessary data resources required for prior authorization.
• Camel Integration: The module allows client to configure a camel route in order to determine prior authorization requests and their eligibility.
• Additionally, clients may choose to use our in-built CQL Engine for Prior Authorization Determination, which utilizes Clinical Quality Language (CQL) to evaluate the prior authorization requirements alongside Provider Eligibility Checks, which insures that the provider is eligible to request the prior authorization.

51.0.3Prior Auth CRD (Coverage Requirement Discovery) Module Overview

51.0.3.1CDS Service Discovery

The Prior Auth CRD module registers one or more CDS services to the CDS hooks module dependency. These services are available at the discovery url of the CDS hooks module i.e. {{baseCDSHooksModuleUrl}}/cds-services. This list includes:

• Endpoint URLs: The specific endpoints that can be accessed.
• Required Resources: The necessary data resources that must be submitted with the order. If these resources are not provided, the module will automatically prefetch them using the provided authentication.
• Configuration Options: Available configuration details are provided via the davinci-crd.configuration-options extension.

51.0.3.2Processing Hook Request

• The client sends a request containing the necessary fields for prior authorization.
• The request is then sent to the camel route that is configured in the module itself for further evaluation.
  • Clients can configure JS functions or custom Java processors/endpoints/components, which can be used in camel routes.
• The module then converts the response at the end of camel exchange and sends it back to the user. Note:The outcome of the camel process is expected to be a CdsServiceResponseJson as a Java object or in a String format.

51.0.3.3Camel processing

• Starting v2025.05, camel route will be used for evaluation of a prior auth request.
• The camel context contains :
  • Request Body: The camel exchange body.
  • PriorAuthCrdContextJson: This contains additional context for the request. This object is passed as a camel exchange property with key priorAuthCrdContextJson.
• At the end of the exchange, the module expects the exchange to return CdsServiceResponseJson as a Java object or in a String format.

51.0.3.4Camel processors

• There is one default camel processor, for CRD use case, that is shipped with the module and can be used for default CQL engine processing.
  • Clients can use the default camel processor, named crdApplyProcessor in their camel route to use CQL engine to evaluate the prior auth request.
    • The crdApplyProcessor requires a route parameter named planDefinitionId, which will be used to perform the PlanDefinition/$apply call.
    • The crdApplyProcessor also requires PriorAuthCrdContextJson to include configurations related to crdApplyProcessor using the property crdApplyProcessorConfig on PriorAuthCrdContextJson.
      • Example route using the default processor :

      <route>
         <from uri="direct:start"/>
         <to uri="smile:prior_auth_crd_module_id/crdApplyProcessor?planDefinitionId=plan_definition_fhir_resource_id"/>
      </route>
      

51.0.3.5CQL Engine Processing

• The system determines the Patient in context by expecting the member ID to be present as Coverage identifier and use this to match the Patient.
  • This behaviour can be overridden by setting patientId in PriorAuthCrdContextJson inside Camel context, where clients can have their own logic to determine the Patient in context.
• After determining the Patient in context, a request is submitted to the CQL Engine via the PlanDefinition/$apply operation.
• The CQL Engine evaluates the business logic and determines whether the requested service requires prior authorization. It then returns a response containing the authorization determination.
• The Prior Auth CRD module processes the response from the CQL Engine and returns it to the client, providing the necessary coverage eligibility information and prior authorization status.
• The following example shows an interceptor that can be used as a starter Prior Auth CRD interceptor, implementing a hook method for available pointcut.