Performance

Performance Overview

According to the implementation guide the round trip response must take no more than 15 seconds.

a maximum of 15 seconds between the user initiating the prior authorization request and seeing the resulting response.

Therefore it is important to optimize the performance of the server for a production enviornment. The following is a list of possible optimizations. This is list is not complete and extensive test should be used to validate any production server is compliant with the implementation guide.

Fhir Contexts

Creating a fhir context is an expensive call. In the CQL execution engine you will notice the default method will created two contexts for each rule which is executed. Instead a single FhirContext should be created for the entire server to access. To accomplish this the reference implementation creates a FhirContext.forR4() in App.java and exposes it to any necessary objects (such as the BundleRetrieveProvider and the ModelResolver). The R4FhirModelResolver creates a new FhirContext automatically. To get past that a modified version named ModelResolver is used by this reference implementation so it can share the FhirContext created earlier.

Asynchronous Rules

When a claim has multiple items they could be executed asynchronously. This reference implementation utilizes Java Threads to accomplish this task, synchronizing on the necessary calls to expression.evaluate and CqlLibraryReader.read(new StringReader(translator.toXml()));.

Preconverting ELM

The process to translate CQL into ELM is non-trivial yet the output is constant. If the CQL is not changing then neither will the ELM (the same CQL always produces the same ELM). As such the translation should not be done every execution. Instead either

1. the CQL should be preconverted to ELM so the CQL is never used, or
2. the server should save the ELM and only translate if the CQL file has been updated

Both approaches accomplish the same task except in the first the server is never responsible for the conversion as the ELM is manually made accessible, whereas the second approach is more dynamic and does not require pre-converting the CQL into ELM before starting the server.

This reference implementation has implemented the first approach and provides a debug tool debug/ConvertAll to convert all of the PriorAuth CQL files in the CDS-Library into ELM.

Load Balancing

This reference implementation is used as a proof of concept for the details inside the implementation guide. A production system should expect to recieve multiple concurrent requests. In order to achieve this result without giving up performance, implementers should design some system to process each incoming request in its own task and in parallel.

Similarly, each request should be split into parallel processes. One to handle the disposition/response and another to handle any auditing required. Production systems typically require an audit trail of all transactions. This can take up valuable time in the round trip process. As such it should be handled in parallel to the Claim disposition process as to not slow it down.

Optimizing Database Reads

This reference implementation has only been tested on very small datasets. With very large databases optimization should be done. One potential optimiziation is to create an index for the rules table. As the number of rules increases the table may become large. Since the table does not change frequently but has many reads it is the perfect candidate for an index.