2022-09-22 OEM Repair Procedures and Guild Sheet Data Meeting Minutes


Public Page





Sep 22, 2022


As participants in this meeting, we need to be mindful of the constraints of antitrust laws. There shall be no discussions of agreements or concerted actions that may restrain competition. This prohibition includes the exchange of information concerning individual prices, rates, coverages, market practices, claims settlement practices, or any other competitive aspect of an individual company’s operation. Each participant is obligated to speak up immediately for the purpose of preventing any discussion falling outside these bounds.


  • Antitrust

  • Meeting minute review

  • Welcome/Networking

  • Review Project Plan

  • Set Priority

  • Work on Workflows

Meeting Minutes

  • Antitrust Accepted

  • Meeting minutes reviewed and accepted

  • Review of Project Plan

    • Time was spent in the meeting to review the Project Plan because everyone has day jobs and not able to review.

    • What Standard is CIECA creating?

      • If CIECA is going to create a standard around the steps required to confirm and validate that you actually did the calibration per to OE, the specific OEMS work construction. How do we document that? Yes, there are ways to get around and fool a calibration, we have mobile calibration units that don’t have a garage that are setting targets out in a driveway. We know that if the surface is not level that it can cause the calibration to not be valid and you don’t know until the car is driven.

      • A standard method needs to be created to validate the calibration was done per the OEMs specifications for our insurance partners and for our consumers that actively has been performed per the OE Specifications.

      • The Calibration Committee is kicking off in 2 weeks to address getting the Calibration information into the estimate and through to invoice.

        • We will bring the Calibration topic to the Calibration Committee

  • Review of SOP

    • Where is finding the correct Repair Procedures and identifying the correct Repair Procedures? Is it under the blueprint process?

      • The finding the correct Repair Procedures is before you start to disassemble the car, some OEMs require this before disassembly because you can damage a car if you do not follow the repair procedures.

      • The disassembly standard and blueprint standard provided by Andrew as a guide are used as a measurement tool to gauge that the final work product of the blueprint process was completed to the standard of our company. So, these are not used at the beginning, Generally the beginning of the blueprint process these are used for whether it's a disassembly technician or a blueprinter or repair planner to verify that they did everything that they were required to do before this work product gets handed off to the next phase of the repair of the entire repair process.

      • If you look there under the far left, it's assembly column on the blueprint standard where it says pre tear down review with tech. Although this is not going to the weeds like what we're trying to establish now that's when the technician and the and the repair planner are going through reviewing repair instructions verifying you know high voltage lockout any of the specialized things that need to be done.

      • The task the committee is looking at doing is trying to figure out a way to capture the OE procedures, to figure out a way to consistently capture the OE procedures and attach them as part of the work file and a common standard so that we can always have those procedures as part of the work standard documented.

      • A pretty extensive pre disassembly routine which involves teachers and procedures and review, documenting really not only what need to be done, but what was what was actually done to the vehicle and the end result. But certainly, that first step along with you know that the scan and huddle around the vehicle is pooling of those procedures before we're starting to put any type of tool on the car.

      • One of the problems identified in the Business Plan is finding of the OEM Repair Procedures and how to identify the OEM repair procedures. everybody who is used repair procedures here on the call, there is 20 different sets of them from each manufacturer. They all have different terminology. They have their placement of the procedure information, even though it's related to 1 area of the vehicle may be in a different part of the procedure platform and you know there's a lot of non-standard. We need standardization in the middle to make it easy to access the repair procedures by each manufacturer and to get the information quick easy.

      • What if we took and we looked at and try to group and if we grouped the procedures like safety procedures, panel replacement procedures, disassembly procedures, if we had the ability to be able to break it into categories, does that maybe make that process a little simpler, frank, even if they got to go look in different areas?

        • Maybe 10

      • We are going to run into on the OEM data. Is that so many of those procedures are clumped into a single category? Toyota is a big proponent of putting everything for the hood or the bumper in one gigantic procedure. This means the search comes back as a one enormous procedure which repair, and estimates have to edit to a smaller version or figure out how to qualify it so that you can break it into segments. This is not a successful way to do business.

      • How do companies like Auto Owners Insurance pull this information from different OEMs?

        • They get license from the OEM

        • Repair logic automate it to some degree, should we reinvent the wheel or piggyback off what they have?

      • Every time CIECA start down the path of creating a new set of standards, we kind of go through this period of wrangling over proprietary versus nonproprietary versus standard. And the reality is it's not our goal at secret to standardize how everybody does their job or how what every company calls things. Certainly CCC Mitchell and Audatex don't do anything the same way internally within their systems.

        But our goal is to find a language that we can exchange information, you know, using a common language. And so, you know, just as we go through this, I don't want to discourage the conversation because I think this is part of the the creative process we go through on all of these. But just just kind of keep it grounded on the fact that we really aren't trying to make.

        Ford, GM and Audi be the same company and do things the same way that will never in a million years happen. But is there a way that I can request information from them and that they can bundle it up and return it to me in a standard way?

        You know, recognizing that they're going to have their own terminology. So it's really more that how do I ask for it? How do you return it to me?

      • Rental Surcharges is an example of all rental companies have codes for their surcharges and prices. For SLP and Car seat, but to talk to everyone, we use the CIECA code to map that to other systems. We need to build the cross references.

      • Typically, CIECA’s process of developing a standard, we will identify kind of a generic workflow and that's often one of the out first output to the committee. And Frank, you can probably weigh on in this since I know you've been through this process, I think what I think what's been presented here is a great start for thinking about that because what you're trying to do is identify those points where you are going to make a request out and or receive information back. So it isn't that doesn't have to be too specific to, you know, exactly.

        You know what you do or what you call it, but that there is kind of a high-level generic flow that anybody's going to go through that says OK first, we do this and then we need information. So that's when we go out and make a call out to, you know, maybe the OE or whoever and then we get that information back and that feeds Step 2. So, I do think that there is value in trying to identify a generic industry workflow, but it is never anything more than that.

        You know when you actually apply those triggers in your company's processes?

        You know, that doesn't really have to exactly match the second generic workflow, but it will in general follow that. So hopefully that makes sense.

      • Do we want to start building these cross references? Is this a bigger priority than the SOP we started last week?

      • Accessing when you're going to access the repair procedures and when to access those repair procedures when you're within your estimating such repair planning platform. Whether it's part of the SOP document here or pre scanning the vehicle, the point being is going to be it's going to occur to specific point, but it's also going to occur through a specific platform as well, right. It may occur through an estimating platform may occur through the scanning platform or the diagnostic tool platform.

        So, the workflow generic workforce important because you have to know when you're going to be accessing the data. But it's also about making sure that we can genericized the terminology so we can access that specific information within whatever one of the manufacturer systems. As an example, an adaptive cruise control system, you have an adaptive cruise control system on a Nissan on the Mercedes, and a four on a Chrysler and GM, but each of their systems have different names, but you could still use adaptive cruise control to find those specific components, so there's an example of what I mean.

        • For example, and Nissan, they have multiple components for adaptive cruise control where Ford has one or whatever. My point being, this is one of the steps they have to be able to do is well, if I'm if I want to look up an adaptive cruise control component in a in an OEM manufacturers system, I have to map adaptive cruise control and again I'm going to use Nissan to their IC sensor or whatever.

        • Another example, things like automatic emergency braking, that's currently the term used by the NHTSA to describe the function of a vehicle intervening in a collision now. Mercedes, I believe, has a term that they use in marketing department has a description of that term. It may rely on different technologies behind the scenes then Subaru does with its eyesight as an example, right? But they're performing that function and maybe to Frank's point, we focus on the function of what that particular system is and then work back and have this cross-reference table of what all the different OEMs call that particular functional system. That may or may not be doable. I don't know because some OEM's may have systems that other OEM's don't.

        • Do we want to limit the scope then to maybe five or ten of these systems as a starting point, rather than taking all of them on because it's already sounding like it's a pretty daunting task?

        • CIECA doesn’t want to recreate the wheel by the way, both AAA and SAE have and I'm picking out 8S and the 8S only right now, those two organizations have gone down the path of quote UN quote, standardizing the system description for everybody.

        • SAE is a standard already. Why wouldn't we emulate that and try and figure? I mean, I'm. I'm just thinking out loud, but maybe that's a great starting point. If SAE has some district descriptions from the engineering society, that might be a good starting point.

        • CIECA needs Build Sheet data to share for the vehicle to help identify the Repair Procedures needed.

        • Every OEM certification program has their own auditing process for how they certify shops and the expectation of how you document these items is different.

    • Path of the project

      • The path is not known for this project yet, we are working through the storming phase to figure out what questions to ask, what do we feel like is priority, this is the beginning and things may change as we work into the details of each item under the scope of our committee.

        • also think that this particular topic poses some unique challenges and I just want to pose this concept out to everybody. In the past, most of what CIECA has done is what's called structured data. I ask you for a VIN number, so I'm going to give you a data field and you're going to give me back a VIN number.

        • In this particular area, we're venturing into the area of what's called unstructured data. I'm going to ask you for a BLOB of data, and you're going to give it back to me. And what that blob of data is just depends on some metadata that I pass along with my request. The data can be retrieved by the VIN number 2000 GMC Sierra 1500 with the you know, the XLT trim package Crew Cab and that's part of the metadata. The data received and maybe in future meetings I would welcome input from many of the companies that currently do integrate with the owes to get this information, how they're approaching it without getting into their proprietary you know. What metadata do I need to pass so that the OE can identify what it is I'm looking for, and then how do they deliver that blob of text or data or graphics to me?

        • An example message is asking an OEM for a repair procedure for one of the things they're probably going to look at is, are you a member you sort of, you know, do you have a subscription with them? So, you'll have to pass a flag or some kind of verification for that. And then you would have to have again our standardized codes. We're going to send a code in and then they're going to go through their system and spit back whatever they came based off of that code. So.

          That's kind of what we just we need to look at and then of course.

          I'm getting everybody to use those codes and standards.


  1. Add Build Sheet Data to the Scope of the project, to make sure that we are going to need to know what we are working on in a car, what is on the car and make sure we are hitting all the things that are on the car and this needs to be looked into for a total loss segment.

Great Meeting Everyone

Up Next

  • Antitrust

  • Meeting minute Review

  • Welcome/Networking

Action items




  • @Paulette Reed

  • Andrew Batenhorst

  • Paul Barry

  • Shaughn Kennedy

  • Ross Whiteley

  • Paul Marshall

  • Trent Tinsley

  • Dave Butler

  • Dale Ringwald

  • Michael Giarrizzo

  • Bruce Davidson

  • Frant Terlep

  • Gene Lopez

  • Stacey Phillips

  • Aaron Rolfsrud

  • Erin Solis

  • Nick Dominato

  • Todd Korpi

  • Ginny Whelan

  • Tim Ronak

  • Kelci Lemanski

  • Eric Schultz


Participants in the meetings are noted for your information.  If you have questions on the committee’s activities, please contact a recent attendee. https://cieca.atlassian.net/wiki/spaces/CPSC/pages/1354760193