Challenges faced
Many recordkeepers and plan providers today do not have comprehensive eligibility processing capabilities, often resulting in a significant amount of manual intervention and a large number of errors.
We had a provider enquire if they could use the light-weight COREDC engine to compute the eligibility for them, without a data migration from their system to ours. They wanted to continue using their system, but simply use our engine for processing.
This presented a win-win opportunity for both the provider and Congruent, with either party not needing to make changes to their existing systems.
What do we have?
COREDC has eligibility processing capability, which would mark employees either eligible or ineligible against a plan and a source. It is capable of validating against plan provisions including age, actual hours, equivalency and elapsed hours with additional provisions to include grandfathering rules, break in service definition etc., all done in minutes for a large number of participants.
What did the provider have?
The provider had a legacy system which process eligibility against specific plan provision rules. They were processing eligibility only through files and this was costing them more time and money than they would have liked. It would take them hours to complete a processing, and sometimes, even days.
Now, these are some questions we had in our minds as we embarked on solutioning for this provider :
How will data be transferred across systems
What would be the format in which data will be transferred
How will the Source System (Provider’s Record Keeping System, “RKS”) data be translated to COREDC format data especially since their schemas will vary
How would COREDC with a Service Oriented Architecture handle files from legacy system
The Solution we built
To address the challenges described above, we have built a layer called Integration Layer – which sits in between the provider’s RKS and COREDC. The Integration Layer is a BizTalk Server, which can take files like MS Excel, CSV and Flat files as input. The BizTalk server has workflow which can hold the mapping between the provider’s RKS and COREDC schemas. The BizTalk server also takes care of any transformations between the systems. Once all transformations are completed, data from the file is transformed to XML in a canonical format which is accepted by COREDC. BizTalk server then passes the data to COREDC Service.
Once the processing is complete in COREDC, data is returned to BizTalk server as XML in Canonical format. BizTalk server then calls the corresponding workflow which translates the data to the Prospect System format or to a different format if required. The provider’s RKS can then take the generated file to perform other operations.
A few technicalities
The diagram below is a pictorial representation of how BizTalk server sends and receive data
There are “Receive” and “Send” ports / folders in BizTalk server. Receive folder will be the place where files from the provider’s RKS are placed, which would then be the trigger to initiate the processing. They will be processed by workflows inside the BizTalk engine, which would then call COREDC services. After the processing, the result from COREDC will be returned by applying transformations and the resultant data or file will be placed in the Send folder. This would enable the provider’s RKS to do further downstream processing.
This would enable both the provider’s RKS and the COREDC to work in silos as well as transform data across systems via BizTalk server without any changes to the existing system. This would not need data migration as data will still reside on the provider’s RKS and COREDC can be used only for processing.
To achieve the end objective of implementing such an elegant solution, the expectation would be that both functional and technical SME’s from both side will be involved to do the mapping and identify the transformation to understand the different formats of file expected as input and output for processing from the provider.
Please feel free to contact the following email id for any queries or a demo.
