By Jay Walkington, sr. director, data services at Riskonnect
Your company has embarked on choosing a new RMIS solution. Researching vendors in the market to choose a comprehensive solution that meets your needs can be a daunting task. While your search may focus on functionality, features, configurability, and UI, don’t overlook the critical importance of your data that will reside in the new system.
Data prowess, data quality, and data security are key factors to your company’s successes, driving both important financial and nonfinancial decisions at every turn. Ramifications of data issues could include inaccurate reporting, improper payments, business process delays, errant decisions, or even fines for regulatory infractions. To help evaluate critical data-quality capabilities, here are 12 questions to ask your potential RMIS vendor.
1. What is your approach to data quality?
Insurance data can be messy. Claims and detailed transactions can take on a life of their own through takeovers, system migrations, spreadsheets, old claims, intake, manual data entry, and data providers’ varying business rules. All these factors can lead to data inconsistencies and/or errant data that will impact your business processes and reporting.
How will your vendor address these issues as they come up during a data implementation? Do they treat data as a throughput, potentially propagating those issues, or do they have a documented strategy to mitigate through data-exception resolution, data-provider notifications, and normalizing data across multiple data sets? Discuss with your vendor their approach and make sure you fully understand how errant data can impact your business decisions.
2. What standard data interfaces do you offer?
Standard interfaces can be a primary driver to reduce costs and implementation timelines. Understand the full library of standard data interfaces that a vendor provides and their plans to expand those standard offerings in the future. Just as important is their approach to maintain those standards as data providers enhance their layouts in the future. Your focus may be on your existing data-interface needs, but don’t lose sight of your potential future needs when selecting a vendor.
3. What type of documentation do you offer for standard data interfaces?
Ensure detailed documentation is available from your vendor on their standards. While prior experience with a data provider is beneficial, it does not necessarily mean they have a comprehensive standard in place. Detailed documentation will clearly outline what’s included — and more important — what’s not included in the standard offering.
4. Do you have an API strategy as data-transfer technologies progress?
Batch (SFTP) data file transfers have been the standard in the insurance industry for over twenty years, but that’s rapidly changing. As customers have grown more sophisticated, the need for real-time data exchange via APIs is sweeping the industry. Your vendor should have a clearly defined strategy from both a standard and custom implementation approach. Also, discuss with your vendor their strategic partnerships with data providers and rating agencies to continue to build toward the future.
5. What security certifications do you maintain?
In this day and age, data security is paramount. Fines and – even more important — reputational risk from data breaches or other cyber incidents can be crippling to your company.
Thoroughly review your vendor’s security documentation with your internal IT department to understand their measures and who will have access to your data. Focus on each vendor’s security certifications and understand what each protection provides. Do not accept the bare minimum in this area even if it currently meets your own company’s thresholds. Certifications and general data security are constantly evolving, so it’s essential to understand the vendor’s commitment to protect your data both now and in the future.
6. What data file formats do you support?
ASCII delimited/fixed, or MS Excel are common formats for file transfers. Many data providers, however, send data in XML, JSON, MS Access, binary, SQL Server backups, Oracle backups, and many other file formats. Each data provider will have a preferred format to send data.
At minimum, make sure your selected vendor can accept these specific file formats. If not, you may incur additional fees from the data provider for custom development and for custom data extracts in a different format. Additionally, you’ll have to factor in the extra time, as well as maintenance of a custom process, to the overall cost of the project.
7. What different types of platform environments will you maintain for us?
As a best practice, your vendor should maintain at least two separate environments: UAT and production. Data should be loaded, tested, and approved in a current UAT environment before it’s promoted into production. This step is often sacrificed by vendors in an attempt to expedite data implementation. However, maintaining these safeguards greatly reduces any risks to your production data/users/workflows.
8. What is your approach to staffing our data during implementation?
Insurance data is complex, and data providers typically view and structure data differently. This is especially important when it comes to claim financials and corresponding detailed transactions. Understanding the incoming data, mapping data elements and financials, and designing the logic to properly convert data into a platform are highly specialized skills. And technically coding this conversion logic correctly and efficiently is another distinct skill set. Does the vendor staff specifically for these skill sets — or do they rely on a jack-of-all-trades approach? Recognizing and staffing for these specific skill sets typically results in a higher quality product and reduced UAT timelines. This also provides checks and balances throughout the data conversion lifecycle.
9. How many hours do you estimate for our involvement in data-related implementation activities and what will be our responsibilities?
Depending on the vendor, your responsibilities could be drastically different. Does your vendor offer full-cycle data services, or do they push some of those responsibilities back to you?
Discuss with your vendor in detail what your specific responsibilities will be, e.g., field/location/code mappings, addressing code errors, general data cleanup, UAT, and ongoing data processing. Your time is a valuable commodity. Understand your level of involvement, how that will fit into your team’s existing workload, if your team members have the proper skillset to perform certain tasks, and the impact on continuity if an individual were to leave your company. Make sure these items factor into the total cost of the services that you choose to implement.
10. Do you have defined and transparent QA and UAT processes?
QA and UAT tasks can easily derail an implementation if not done properly with a planned approach. Before you begin your UAT, the vendor should complete a thorough QA process to ensure data is converted properly to specifications.
It’s important to note that the person who built the data interface should not be the same person performing the QA. After the vendor’s QA is complete, what reports, documents, and checklists can you expect to receive to help you with your UAT efforts? Understanding a vendor’s processes and attention to detail can save countless hours on the backend of an implementation.
11. Do you have a standard backout (recovery) process if issues arise during data loads?
Vendors should have safeguards in place to ensure data is loaded properly; however, there may be occasion to rollback data that was loaded into the system. In these cases, is the vendor’s process automated or manual? If manual, is it clearly defined as to not disrupt any other parts of the system or users? Being prepared for emergencies can help avoid serious problems when these situations arise.
12. Are business rules consistent for all data entered into the platform?
Each vendor defines the business rules for data entered into their platform. This could take many forms, including required fields, code validations, sequential dates (loss, report, close, re-open), financial/status balancing, etc. These business rules need to be consistent whether data is entered through the front-end, via a batch (SFTP) interface, or API.
If you aren’t satisfied with any of the vendor’s answers, move on to another vendor that can provide what you need. Above all, be thorough in your questioning. Something overlooked or minimized at this stage could come back to bite you down the road. Ensuring the accuracy and consistency of the data in your chosen platform will pay dividends for years to come.
If you’re ready to draft an RFP for a RMIS, start with this list of the most critical RMIS-related questions, and learn more about Riskonnect’s Data Transformation Services.
