Since 1994, the Collision Industry Electronic Commerce Association (CIECA) has been working with the collision repair industry to provide open standards that enable systems to communicate with each other. The use of Estimate Management Standard (EMS) has proliferated throughout the industry, and while the use of these standards have created value for participants within the collision industry framework, there have been some downsides as more and more application providers have created and installed “data sweepers” or “data pumps” that indiscriminately extract data. Many repairers are unaware of the breadth of data being extracted, where it is being extracted from, settings that would allow them to control the flow of information, or even how that information may be used beyond its intended purpose.

For years now the Society of Collision Repair Specialists (SCRS) has alerted its members about the potential risk and liability associated with inadequate control over vehicle owner data, and even data generated through participation in Direct Repair Program (DRP) agreements which may specifically include data security or privacy clauses. Until now, there have been limited mechanisms for repairers to mitigate the risk of sharing unintended information with data-sweeping programs installed on their servers, because many of these programs anonymously extract EMS files in their entirety as a background function.

There are a variety of “data pumps” collision repairers may find installed on their server, used to collect information to support a variety of programs associated with managing their business, relationships or programs. As one example, SCRS has fielded an increasing quantity of calls relative to data protection lately as the PartsTrader program has been rolled out across the country. As part of the setup to use PartsTrader, the collision shop must install a PI Client. As described by the company, “the PI Client is a small windows tray application and windows service which run on a repair shop PC or server. This little set of apps makes sure that estimates from your estimatic software are exported to PartsTrader, and once you’ve selected or ordered your parts, import the part prices and changes back into your estimate. This saves you the trouble of doing any importing or exporting of this information by hand. The PI Client takes care of this importing and exporting for you.” End-users of the system have noticed that on estimates where PartsTrader is required by the carrier (currently, just State Farm) the PI Client automatically exports parts information from your estimate into PartsTrader. The data files are exported from the estimating system into an EMS/BMS export directory on the file system, the PI Client reads the files from the export directory and then sends Business Message Specification (BMS) file data to PartsTrader.

The repairers who have agreed to use PartsTrader as a condition of their relationship with one carrier understood that there was a necessary means for communicating parts data with the company for it to function. Where the question began to arise is when end-users started noticing additional information on non-required estimates files populating in their PartsTrader dashboard. Depending on the estimating system being used, and how the settings are established within that system, on other estimates where the carrier did not require the use of PartsTrader (non-State Farm claims) PartsTrader has been extracting the following key identifying information: Insurance company ID, last 4 digits of the claim number, vehicle year, make and model.

SCRS was informed that the purpose of this information on non-required claims is necessary if the user chooses to voluntarily upload parts data on these repair orders, and that the user chooses if and when to import the parts data related to these estimates into PartsTrader. We were also advised that PartsTrader only maintains this information for two weeks, and that the part data is not imported into PartsTrader unless the user explicitly clicks the ”Import” link.

This all makes sense for users who may be interested in voluntarily using the system, but for those who don’t, it has raised concerns surrounding the amount of non-voluntary information being provided through this data pump that could give valuable information surrounding market volume and shop volume. It has also raised concerns over if this could be a violation of agreements with some carriers by sharing such information with an unrelated third-party. SCRS inquired with PartsTrader if a repair facility could establish settings that could restrict the non-required data from being shared, and they replied that there is some variability amongst estimating companies who ultimately are responsible for the configuration of that functionality, but the general answer is “yes”, the shop does have control over that.

SCRS sent a request to each of the estimating system providers (CCC, AudaExplore and Mitchell) inquiring if their system provided functionality that would allow end-users to modify settings to restrict any additional exchange of information, above and beyond that required by State Farm as a condition of their program.

CCC

CCC Information Services responded with an explanation that they have been aware this issue has been a longstanding concern of SCRS and our membership, and that their newly launched solution has a broad application and was not developed specific to any one data source or program. They were clear that the functionality was developed in response to the industry’s communicated desire for better control over all data. As such, the company advised they have implemented a feature within the CCC ONE Estimating application that allows repairers to take more control over their EMS export.

CCC ONE users have always been able to configure multiple EMS paths that can be used for different systems. But now repairers can gain more control over their data by defining insurance company specific export paths that will allow them to export only EMS files for a specific insurance company’s estimate. For example, if a repairer is using a shop management system they could define one path to export all EMS files to (which is most likely already configured.) And if the same shop was part of a direct repair program that required the use of a third party application when processing their claims, they could configure a second path just for that application. In this example, only the data for that insurance company’s estimates would be exported. Once the new path is created, the third party application would also need to be configured to import EMS from that directory.

To configure CCC ONE EMS settings, from within CCC ONE select Configure > Machine Settings

1. From Machine Settings under Import/Export select File Export

2. Select EMS 2.01 as the export type, all insurance companies or a specific insurance company and the desired export directory.

3. Repeat this process on every computer where EMS is configured to export.

4. Check with your third party application providers to update the import settings to use the newly created directory.

SCRS sees this solution from CCC as a tremendous advancement for the industry, and applauds solutions enabling repairers with the ability to control what data is shared with whom. We encourage all of our members to take the opportunity to inventory which applications currently residing on their desktops and servers that are using the CCC ONE EMS files, and make any necessary configuration changes.

AudaExplore, a Solera company

AudaExplore responded, confirming the variance in how the different systems manage user-control over the data, but providing equal protection over the end-user data as it relates to non-required data being accessed by PartsTrader. The company representatives advised that as a rule, AudaExplore has only enabled custom export to PartsTrader on the required State Farm profiles, and further only export data on an estimate-by-estimate basis from the damage page. Data relative to non-required estimate files would only be sent for the estimates the end-user electively sends to PartsTrader for quotes and that data is sent using CIECA BMS protocol in the export process to protect the user’s data to the greatest extent possible. SCRS was informed that there is EMS interaction from the work list where data for claims not sent for quotes would be available to PartsTrader if sent by the user, and that AudaExplore does not have any other direct interaction with PartsTrader where this data would be sent to them.

Some shops have voluntarily requested that PartsTrader be enabled for other profiles besides State Farm, and AudaExplore plans to implement that capability. The process would be the same, and AudaExplore would still restrict information sent to PartsTrader to the estimate data the user chooses to send for quotes from the damage page. This functionality would be the only way PartsTrader would have access to non-State Farm claim data, and this permission would only enabled for shops who specifically request it, and only relative to estimates they select to export for quotes.

SCRS believes this too serves as a beneficial approach. Establishing protocol that an explicate request must be made from the end-user to increase flow of data provides for greater likelihood that the end-user will understand who is receiving the information, and how it is being used. This type of transparency serves the industry well.

Mitchell International

Representatives from Mitchell responded to SCRS’ inquiries confirming our understanding of the data being made available to PartsTrader on non-State Farm claims, and the process in which they are able to extract it. When asked about end-user configuration to restrict access to non-required claims (currently anything not designated as State Farm) Mitchell responded, “that functionality is set for a future build.” They were unable to provide a target date in which such capabilities were expected to be implemented.

The conclusion is that there are advancements being made, or already in place, from some providers that allow collision repair facilities to maintain some semblance of control over how to manage the data files being exported from the estimating systems to other data collection sources. It is important that collision repair facilities be cognizant of what data collection programs are operating in the background on their systems, and further cognizant of system settings that can help them mitigate the amount of any undesired data transfer.

SCRS encourages all collision repair end-users to regularly monitor your programs, compare capabilities of the software providers relative to features that allow greater control over unwanted data transfer, and to continue to urge your software providers to adopt new standards such as BMS and other functionalities that allow you to protect your customer and business data.

To learn more about SCRS, or to join as a member, visit our website at www.scrs.com.