eiConsole for ACORD – Underwriting (Demo)
Most of the popular lab and paramedical vendors have adopted ACORD XML as their preferred data format for communicating with carriers and other trading partners. These providers support a combination of ACORD TXLife transactions for processes including Requirement Ordering, Status Notification, and Results Transmittal. Now, the carrier’s challenge is to cope with the subtle and not so subtle differences in what each vendor expects. Variations might include different ACORD type codes for requirement codes, lab results and status, different required aggregates, elements, and relations for the TXLife 121 and 1122 transactions, different strategies for representing requirement results, including attachments, and of course different supported protocols for encryption, compression, and transport. In a typical implementation, a carrier may have several underwriting systems – each one of those with multiple interfaces hardcoded to each vendor’s unique requirements. Now, this approach tightly couples the code and the Source System to the formats of the vendor partners. It’s expensive to implement and it’s hard to maintain.
PilotFish, the eiConsole, and the eiPlatform offer a better solution. Each underwriting system can produce and consume data in its own native format – maybe that’s MQ, or maybe that’s a database result set. Maybe it’s Java, or maybe it’s .Net. Now, this information is then exposed to the PilotFish eiPlatform where there’s a single transformation per Source System into a single “Gold Standard” or canonical model. As required, additional data transformations can be configured to tweak or convert that gold standard into the specific format of each of the vendors. This might mean switching between ACORD versions, re-mapping of requirement codes, or generating a completely different data format, such as NAILBA. This approach is loosely coupled, quick to implement, and inexpensive to maintain. Let’s look under the covers to see how these eiPlatform interfaces are built in the eiConsole.
You’re now looking at the eiConsole’s Route File Management window, which contains a list of templates for all the ACORD TX Life Medical Underwriting transactions. It also contains a fully configured example interface. This time a paramedical request.
Opening this interface we see how the flow of data from Source Systems to Target vendors is represented on this screen. The developer or business analyst need only configure the stages in between.
The Listener is responsible for handling connectivity to the Source System, such as polling a database, picking up a file, or receiving a message from a queue.
Next, we have the Source Transformation. This step is used to convert the data into the Gold Standard canonical model. First, data is converted into XML. In this case we have a proprietary file parsed by the File Specification Editor.
This tree represents the structure of the file that we’ll be parsing into XML.
Next, this data is transformed into our Gold Standard ACORD representation. Logical data transformations are represented as W3C standard XSLT generated by the eiConsole’s best-of-breed Data Mapper.
This tool provides a graphical view of the Source and destination formats on the left hand side of the screen and the right hand side of the screen. It then simply allows you to drag-and-drop the two together to create the logical mapping that you see here in the middle.
The pallet of tools at the top of the mapping panel allows for further manipulation of the data. This includes things like looping, conditional logic, etc. Note that the Data Mapper also includes special support for ACORD TXLife specific constructs, such as extensions, type codes, and relations.
Once data has been transformed to our canonical model, we enter the Routing stage. Here routing rules can be used to determine which vendor system should receive a particular order.
Once an order has been routed to an appropriate Target, the Target Transformation is used to tweak or convert the Gold Standard ACORD message into the specific format of each trading partner.
We now come to the Transport stage. Before physical transmission of the file, Processors can be used to do things like adding an authorization form to a data stream as an image.
Finally, a Transport component is configured to synchronously or asynchronously transmit the order on to our Target System.
Once interface configuration in the eiConsole is complete, we can unit test the interface in Testing Mode.
After Unit Testing has passed, the final step is the deployment of the newly configured interface to the eiPlatform server, a process that is as simple as copying a set of configuration files.
That is how easy it is to streamline medical underwriting interfaces with the eiConsole. Replace cumbersome coding with quick configuration; you’ll save yourself headaches and your company hundreds of thousands of dollars.