PilotFish Interface Exchange (PIE)

A marketplace for eiConsole (IDE) interface templates, components and industry bundles
eiConsole IDE 90-Day Free Trial!
Licensor contacts
Associated Industry
Insurance
Associated Application
All
Prerequisites
While not a prerequisite, we highly recommend the PilotFish eiConsole and eiPlatform to support integration of this product.
Version
7.11R1
Release Date
July 14, 2011
Resource Type
Complementary Product
Recommended Version of eiConsole
8.11 RC1 Build: r5007

Product details

Insurance Validation Server

Insurance Validation Server enables the automated validation and certification of trading partners' messages to standardize initial and ongoing information exchange. A company that is receiving the same messages from multiple trading partners (for example, a TxLife 103) can "publish" their message formats and rules to allow the trading partners to test their message transactions before going "live".

Because Validations are configured using the XCS eiConsole and deployed to the XCS eiPlatform in exactly the same way that interfaces are deployed, there is enormous flexibility relative to the Submission, Validation, and Responses to test messages.

How it Works

Submission

The Validation Server can accept incoming "test documents" through a variety of protocols, including but not limited to email, HTTP, HTML Form, and FTP. A trading partner wishing to validate their messages may submit those messages in any of a variety of different ways. For instance, a developer wishing to test an ACORD Life 2.17 New Business transaction may alternatively:

  • Send an email with "ACORD LAH 2.17 103 Transaction Test" in the subject line
  • Post the XML to test.yourcompany.com/lah2.17/103
  • Select "ACORD TXLife 2.17 New Business (103)" from a drop-down on a web page
  • FTP a file to the "lah/2_17/103" directory on test.yourcompany.com

Validation

Inbound test documents can be subject to any required validation through a "pluggable" validation architecture. Validation rules can be expressed in XML Schema, Schematron, or in a custom XML validation dialect. Validation models can be "layered", where a number of different models are applied to the same instance document. For example, the same document may be validated against:

  • ACORD TXLife 2.17 Schema Validation
  • ACORD TXLife 103 Certification Rules
  • ACORD TXLife 103 Your Company-Specific Implementation Rules
  • ACORD TXLife 103 Carrier-Specific Implementation Rules for another Carrier

ACORD can provide the "standard" validation rules. Your company and other partners in the insurance value chain can also submit validation requirements to be deployed to the transaction Validation Server. Using this feature, a trading partner can ensure that their messages are not only ACORD certifiable, but that they can be consumed by your company.This approach also has the benefit of exposing those areas where partners' interpretations are at odds with yours, or with the standard itself.

Response

Validation results can be produced as XML, or as a human-readable HTML report. This report enumerates the rules executed against a particular instance document, the success or failure of the aforementioned rules, and any relevant details in the case of a failure. The report is returned to the submitter through the appropriate transport protocol (email, HTTP, web page, FTP, etc).