What is Elements?
Elements is a collection of distinct, but closely-related, applications and microservices that communicate mostly by message queuing in order to process insurance application data for underwriting. This decoupled architecture is more easily scaled, maintained and extended, and is more robust in general, when compared to monolithic applications. Additionally, Elements is deployed in Amazon Web Services which provides very inexpensive computing resources with incredibly high flexibility and scaleability.
Elements is a distributed system that uses asynchronous message queuing as the primary means of communication between components. Queuing decouples components and allows messages to be stored for later processing in case a component is temporarily unavailable. This allows Elements to be robust when faced with unreliable resources, such as internet connections and third-party data providers.
The primary use-case for Elements is that of underwriting an application. In that case, an application is received from the carrier system by the Carbon WS component, and placed into a request queue to be picked up by the Carbon Processor. The processor determines how the request should be handled, and publishes a message that is picked up by the appropriate third-party data components found in the Sblock subsystem. Sblock components each have but one job: interact with a single third-party processor to obtain requirement data and place that data on a queue to be picked up again by the Carbon Processor. The Carbon Processor correlates the requirement data and sends the correlated data to the rules-based Underwriting Service for underwriting. Once the underwriting response is available, the Carbon Responder then ensures delivery of the results to the Carrier via a web service call, FTP delivery, etc.
Secondary use cases for Elements are administrative tasks such as user and system accounts/credentials and drug database maintenance, and rules authoring. Rules authoring is a web GUI that in which insurance application forms are graphically modeled in tree form using sections, questions, and answers, with appropriate scores assigned to the answers. The form model is then used to generate rules that the Underwriting Service uses to score application data.
|Load Balancer||Used to provide scaleability and fault-tolerance.|
|EMI||Elements Management Interface. A web application used to manage and configure Elements as well as to model application forms for rules generation.|
|Auth Service||The Elements Authentication/Authorization Service. Allows Elements components to ensure that incoming requests are valid, and provides credentials for third-party services.|
|Underwriting Service||Makes underwriting decisions on insurance applications through the use of customer-provided business rules and proprietary scoring algorithms.|
|Carbon WS||The “front-end” web service called by carrier systems. This component’s primary job is to enqueue client requests to the main request queue, so it must be fault-tolerant. This design allows requests to be honored in the unlikely event that a downstream component is unavailable.|
|Carbon Processor||The “traffic cop”, or main underwriting workflow engine of Elements. The Carbon Processor:
|Carbon Responder||Receives responses from the response queue and delivers them via a web service call back to the carrier system, or FTP drops, or other configurable techniques.|
|Hydrogen||Obtains RX history from ExamOne ScriptCheck.|
|Lithium||Obtains medical history from MIB.|
|Beryllium||Obtains ID verification information from LexisNexis.|
|Sodium||Obtains MVR data from ADR.|
|Magnesium||Obtains MVR data from LexisNexis.|
|Potassium||Obtains RX history from Milliman Intelliscript.|
|Neon||Scores lab test (blood and oral fluid) results|
Elements and AWS
Elements is deployed, in an automated fashion, in Amazon Web Services (AWS). AWS is the top-ranked cloud platform and offers access to a vast and dynamic array of networking, computing, and storage resources. “Dynamic” is the key word here. When properly leveraged, AWS technology allows entire systems, including networking and security services, application servers, databases, and more, to be provisioned as-needed, and programatically, with a single command. Systems built on the platform can easily be engineered for fault-tolerance and varying loads due to the dynamic nature of AWS’ technologies.
In AWS, computing resources are charged as you go, generally hourly. There are no up-front contracts required. This, combined with the ability to dynamically create entire systems, is a game-changer when it comes to IT resource planning. For example, a test system that exactly mimics production can be brought to life just long enough to run a test suite, and then destroyed when the tests are complete. The customer only pays for the computing resources used during the test run. Since a given test run might last a couple of hours at most, the cost can be shockingly inexpensive to someone used to long-term datacenter costs.