Prior Auth CRD (Coverage Requirement Discovery) Module OverviewExperimental
Please
contact us if you would like to try out this experimental new feature.
Prior 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.
Prior Auth CRD (Coverage Requirement Discovery) Module Overview
CDS 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.
Processing 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.
Camel 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.
Camel 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.
CQL 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.