Digital Organon

Executive Overview

Digital Transformation is a passes - the new norm is Enterprise Transformation.

Digital Organon's technology platform DigiOrganon provides complete modernization capability to transform legacy applications onto new age digital architectures. The platform has capability to automate calculations of total cost of ownership savings and will highlight how to launch a self-funded digital transformation project. The platform also helps to automate the process of moving the service layer into new age technologies and also to replace legacy mainframe and RDBMS databases to cloud native databases.

The move to digital creates enormous opportunities for you. Analysts believe there is $100 billion of economic value to be invested on cloud modernization. But legacy systems and outdated development processes are holding you back.

Legacy Modernization is a strategic initiative that enables you to apply the latest innovations in development methodologies, architectural patterns, and technologies to refresh your portfolio of legacy applications. This is much more than just “lift and shift”. Moving your existing apps and databases to faster hardware, or onto the cloud might get you slightly higher performance and marginally reduced cost, but you will fail to realize the transformational business agility, scale, or deployment freedom that true legacy modernization brings.

New digital-native competitors are disrupting established markets and out-innovating the incumbents, unencumbered by legacy processes and technology. Think Amazon and eBay for retail, Airbnb for accommodation, Uber for transportation, WeChat for communications, Expedia for travel, Stripe for payments – the list goes on. The average tenure of companies in the S&P 500 is falling – market research predicts that 50% of today’s S&P-listed companies will be replaced over the next 10 years. Legacy systems are barriers to innovation, and increase your risk of being part of that 50%.

DigiOrganon includes Service Layer Migrator that can move applications hosted on Hibernate, Spring JDBC or any other ORM/data access layer to a NodeJS or MERN stack.

It also includes Database migrator tool to facilitate and simplify existing database cluster analysis, data migrations and data synchronizations from various 3rd party databases into MongoDB. Ultimately, this migrator tool will allow the user to pre-configure and map data migrations via a user interface and monitor the migration events.

Data Migration

The data migrator component includes the following high-level functional considerations:

• Extraction of System Metadata such as Table Definitions, Column Definitions, Database Constraints and Dependencies.
• Facilitation of Mapping Design, Transformations, Job Group Design
• Extraction, Transformation, and Loading of Data into MongoDB
• Monitoring of the Job Loads and reporting of progress
• Error Logging, Data Correction and Performance Tuning Options
• Automatic creation of collection structures
• Reusable Migration tasks

Service Layer Migration

The Service layer migrator will assess the functionality and configuration by analyzing the code and configuration files related to Hibernate, JDBC or any other data access components. It will also create new code on NodeJS or MERN stacks.

TCO Calculation

The TCO calculator can connect to any data center and understand the total number of databases, application servers etc. It provides the total cost of existing hardware and software resources and can calculate the TCO savings over the next few years of enterprise transformation.

DigiOrganon : Healthcare case study

This complete application running on Jboss, drools, hibernate and oracle is transformed into NodeJS based MongoDB application.

• Enrollment file submitted by the Employer groups will be routed to an intermediate processing location
• Employer groups will be submitting Full Files weekly
• Files will be processed by Edifecs field mapping process and output will be send to MongoDb rules engine for processing
• A delta file should be created by the MongoDB rules engine
• The Integration layer will call the enrolment sparse HealthRules connector service to update membership data in HealthRules
• HealthRules payor would return an EnrollmentResponse, this provides details of the enrollment and the status (success/failure)

Delta Processing Requirements

• If a member is present in the current week file and does not exist in last week file, then that should be added as a new record with “CREATE” maintenance type
• If a member is present in both the current week file and in last week file and if there is a change in record comparison, then that should be added as a new record with “CHANGE” maintenance type
• If a member is present in both the current week file and in last week file and if there is a coverage end date populated, then that should be added as a new record with “TERMINATE” maintenance type
• If a member is present in both the current week file and in last week file and if there is no change in record comparison, then that should not be added to the Delta
• Records for members should be added to the output delta if a member was rejected during processing in prior weeks and is present in the current week file without any changes
• If a file comes without any records or less than 95% of volume from prior week, processing should be stopped and notification sent to support teams for next steps
• The process should be able to handle initial full file, without manual intervention

Business Rules/Validations

• Update existing version on member records for all demographic information
• A new version of the member should be created when a member moves from one account to another account or one sub account to another sub account
• Plan effective date for the member should be used as the “As of Date” in HealthRules for version changes
• If a member is not present in the current week file but was present in the prior week, that member should be reported in the error report
• Hire Date of the subscriber should be earlier than the original effective date
• Member match should be done using SSN, Member First Name, Member Last Name and Date of Birth and if SSN is not available using Member First Name, Member Last Name and Date of Birth
• Member is Subscriber field should be marked True for Subscribers
• Member reported as disabled should provide effective date of disability, if effective date is not provided report as warning and load member without disability status
• Address standardization should be turned off during processing

Handling Errors/Warnings/Terminations

Address standardization should be turned off during processing

• Member - Last Name
• Member - First Name
• Date of Birth
• Account Number
• Benefit Plan
• Relationship code
• Coverage eff date

Success Report should show a summary of records processed along with counts of rejected records

The error report should have all the below information assuming all data is available in the error scenario

• Member - Last Name
• Member - First Name
• Date of Birth
• Account Number
• Benefit Plan
• Relationship code
• Coverage eff date
• Coverage eff date
• Status
• Exception type
• Exception message

Error Report will be sent to Employer Groups and BPO for processing or correction

Records hitting HealthRules Payor warnings will be sent to BPO Workbaskets for updates

Termination Scenarios

• Cancelling Coverage
• Employee Termination
• Moving from one Sub-Group to other
• Switching Plans due to life event
• Corrections/Removal to enrollment

Send Termination Date in the file when Termination is known.

Send on at least two weekly files past the termination date; this includes keeping Future Terminations on File until Term Date is passed.

The Exception to this is where Coverage Start Date = Coverage End Date (DTP*348 = DTP*349) in these cases, send only twice and drop from file as there is no reason to keep sending a future dated enrollment that is cancelled.

When Employee moves from one sub-group to other

We offer key expertise in following market leading technologies.

Big DATA, Hadoop, Storm, Spark, Kafka, MongoDB, AngularJS, NodeJS, R language, Python, Mahout, Liferay, Spring, Cassandra, Neo4j

Key Digital Themes we support

• Social Media Analytics
• Data Aggregation and Transformation
• Natural Language Processing and Text Analytics
• Predictive Modelling
• Campaign Management
• Automation and Robotics with Digital Extraction
• Loyalty Management
• Customer 360 profiling
• Data Visualization
• Advanced Analytics