Rules Engine

Purpose

The Rules Engine allows for dynamic and automatic claim disposition. When a Prior Authorization request is made a response must be given within 15 seconds. This requires an automated engine to determine the disposition of the claim. In some cases it may be necessary for human intervention but the hope is the majority of prior authorization requests will be handled automatically by this rules engine.

This reference implementation utilizes the CDS-Library for the rules. The rules are CQL files which are executed against the Claim Bundle. There is no requirement to implement the Rules Engine as done here. This is simply to illustrate one possible way of implementing the rules.

CDS-Library

The necessary rule files for the rule engine are located in the CDS-Library. After cloning this repo the rules engine must be configured to point to that location by updating the relative path in config.properties.

CQL Files

The CQL rule files are expected to have two expression definitions: PRIORAUTH_GRANTED and PRIORAUTH_PENDED. These two expressions must return a boolean value. The PRIORAUTH_GRANTED expression returns true if the request is approved. The PRIORAUTH_PENDED expressions returns true if the request needs to be pended. See "Steps to Execution" below to understand how these rules are used.

CQL to ELM

For performance reasons the rules engine utilizes the preconverted ELM instead of translating the CQL on each request. The ELM files are also in the CDS-Library. The debug endpoint of this reference implementation provides two tools for assisting in the conversion. The first is the POST debug/Convert endpoint. Posting to this endpoint with the contents of a CQL file in the body will return the translated ELM (as XML). The second is the POST debug/ConvertAll endpoint. Posting to this endpoint (no body required) will automatically convert all of the prior auth CQL rule files in the CDS-Library into ELM (overwriting previous contents of the ELM files if they exist).

Rule Mapping

Each request must be mapped to a specific rule file to execute. This mapping is done by the Rules table. Everytime the server starts up the TopicMetadata from CDS-Library is used to populate the table. The system and code of the requested Claim.item is used to determine which rule file to execute.

Note: this process is currently being discussed as the (system, code) pair is NOT unique.

Steps to Execution

The flow of the rules engine is as follows: 0. Before submitting a claim: rule files are created and converted to ELM. The Rules table is populated with the mapping

1. For each Claim.item in the request a new thread is created to compute the disposition of that item.
2. The system and code are used to map the request to a rule
3. CQL setup: creating a library (from the ELM), a context, and adding the Bundle to the context data provider
4. The PRIORAUTH_GRANTED rule is executed. If this returns true then the disposition is granted. If this returns false proceed to step 5
5. The PRIORAUTH_PENDED rule is executed. If the request could not be granted then it is either denied or pended. If this returns true then the disposition is pended. If it returns false then the disposition is denied.