Like any organization, the Collision Industry Electronic Commerce Association (CIECA) has evolved over the years. Since CIECA was established in 1994, the primary objective has remained the same: to develop and publish data standards to help the collision industry be more efficient.

It’s an exciting time for CIECA as we embark on the next chapter of industry standards. As we create JSON-Based CIECA Open API Standards, the organization is looking for volunteers to join its committees. To learn about the committees and how they operate, we’ll take a look back at standards over the years. In the following article, Phil Martinez, technical consultant for Mitchell, an Enlyte Company, and Dan Webster, principal architect for Enlyte, share information about the past, present and future of CIECA Standards.

Martinez is the Executive Committee Vice-Chair of CIECA and the chair of the Vehicle Damage & Imaging Committee, and has been involved in creating CIECA Standards since the organization’s inception. Webster has been a member of CIECA’s Architecture Committee since the early 2000s and has acted as committee chair since 2011.

Martinez: Each CIECA Standard that we have developed since the organization was formed has a unique role within our industry. CIECA’s first data standards were created for insurance carriers to send vendors assignment data and populate their estimating data. They used EDI (Electronic Data Exchange) X12, a data format based on ASC (Accredited Standards Committee) X12 Standards. ASC was the largest and most recognized data standards organization in the 1990s and X12 was used to exchange specific data between two or more trading partners.

Soon after assignment standards were developed, we began working on estimating standards. We met quarterly and there was a lot of participation from insurance carriers as well as other segments of the industry. Companies wanted to ensure their requirements were met. It took many years to complete the process because of ASC’s rigid process. The challenge was that ASC X12 was never highly adopted in the industry due to the high cost of the translation software. Only large companies could afford to invest the money, infrastructure, and resources needed to purchase and support the expensive translators.

Q: Can you tell us about the creation of EMS and BMS Standards?

Martinez: We found an industry need to exchange information between local systems and ASC X12 wasn’t the best method to use. As a result, CIECA began looking at creating a new standard for the industry and formed a committee to develop EMS (Estimate Management Standard). EMS had a unique role to play within the industry and for our trading partners.

Electronic data was coming of age and the industry looked to CIECA to help solve another problem: how to share information between applications on local personal computers. Companies were spending huge amounts of time rekeying information from an estimating system into a body shop management system. Of course, what comes with re-entering data manually? Mistakes. The industry needed a way to get information from the estimating system into the body shop management system to create repair orders, start repairs and order parts. 

As new technology was introduced in the early 2000s, we realized it was time to create new standards once again. In 2004, the EMS Committee evolved to become the Architecture Committee and we began developing BMS (Business Message Suite) Standards. X12, EMS, and additional data were the building blocks for these standards. The first version we officially released was more of a proof of concept. We soon realized more information was required in the standard before companies could implement it.

We finally delivered the first standard and services. BMS version 1.3.4 was approved on August 3, 2004, and BMS 1.3.7 was approved on January 11, 2005 and became the first version implemented by vendors and carriers. The estimate and assignment were the first standards and it expanded from there. Today, there are hundreds.

Similar to when we created our original standards, there was a lot of industry participation.

Q: Why is EMS still being used?

Martinez: While we thought BMS would replace EMS, it has played a unique role in the industry and that is why some CIECA members still use it.

Q: Can you tell us about the current focus of CIECA’s Architecture Committee and why new standards are being developed?

Webster: Over the last 20 years, the primary role of the Architecture Committee has been to maintain BMS Standards and release updates twice a year. We have improved the process of maintaining the BMS but that isn’t needed so much anymore since it’s now a mature standard.

As the industry continues to adopt new technologies, the Architecture Committee is reinventing itself to meet the needs of the industry. Things have moved forward and it’s time to refresh our standards.

Today’s integrations are Application Programming Interfaces (APIs) that are settling on REST (Representational State Transfer), JSON (JavaScript Object Notation) and its json-schema definition language, and OAS (OpenAPI Specification (OAS) as their base technologies.

CIECA has had an interest in JSON and REST APIs since 2013 but in 2021, we’re taking a leap forward. During our committee meetings, we’ve had serious talks about which version of OAS and json-schema we will use and best practices for using them. Our committee members are practitioners of these technologies and we’re focusing on proofs of concept using OAS and json-schema to help us find and address issues.

Similar to how we combined X12 and EMS as the basis of BMS, we are doing the same now. We are looking at what is needed in the industry in 2021 and the foreseeable future and casting it in the language of OAS and JSON/json-schema.

Maybe we added too much detail in the BMS schema so we are streamlining it and flattening its hierarchy. We’re trying to use only what is needed and make the standards more understandable and approachable.

Martinez: We needed to start thinking outside the box about the new services and standards that could be created for the industry. As we embark on the next generation of CIECA Standards, we should ask ourselves some of the same questions we did as we developed past standards. We always learn and need to remember what we did well and what we could do better.

Mitchell has always been a supporter of data standards and a lead contributor to the development and creation of both past, present and future standards. We have always tried to play a leadership role within the standards community pushing for open standards. Please help us on our next endeavor into our future Open API Standards.

Q: What is required to be successful with this project?

Martinez and Webster: Industry participation!  

Martinez: What we are missing now is industry participation. We really need those experienced in developing JSON messages and using REST APIs to join our committees and help us be successful and deliver the industry the newest and best standards possible.

Although every company has its own requirements, we have many things in common. If you want your specific data requirements included in a standard, this is the time to get involved!

Webster: It’s an exciting and interesting time and your contributions can really be magnified at this point. I encourage all industry segments to join the Architecture Committee and help us build the next generation of CIECA Standards!

For more information about CAPIS and to join a CIECA Committee, email Paulette Reed, technical project manager: paulette@cieca.com. Reed manages the meetings and helps develop the documentation that will be presented to CIECA members.