The Data Dictionary

It's all about the data!

The purpose of any integration is to exchange data between two or more parties.  Speaking a common language is an essential part of the process.  The Data Dictionary provides a common vocabulary that all parties to the process can use to build API's.

The CIECA Data Dictionary is a significant body of work that has been developed by all segments of the industry for more than 25 years.  It is a comprehensive body of work and has become the de facto standard for the industry.

In this tutorial we will take a closer look at how the CIECA Data Dictionary is structured.

Elements of the Data Dictionary


Key terms that are used through the dictionary are defined with instructions on their usage and application.  (Example:  Administrative Information refers to the aggregate of data which describes the parties (individual or companies) and locations associated with the data in the document.  The data includes a party (see Section 3.1 for details), address details, communication information such as phone, email, etc., related identification number, reference numbers and comments.) 

Documentation Conventions

Documentation conventions are essential in building and implementing the CIECA standards.  This section/subsection educates the reader about documentation conventions that have been used throughout the specification manual.   (Example:  Repeating elements and aggregates may appear more than once and are indicated by “Repeating” in the Usage column.

Data Types

The CIECA Business Message Specification is designed around a small number of data types that are used to represent all data passed between senders and receivers using the messages defined in this specification. (Example:  Boolean:  Boolean indicates a logical True or False condition. The physical representation of Boolean data is 0 or false for False, 1 or true for True.  The Boolean data type is used in cases where there can only be two possible states for a particular Property. When adding a new Boolean value to an existing Aggregate, the default value must always be False for reasons of maintaining backward compatibility, so choose the semantic meaning of the Boolean element with care

Building Blocks

CIECA Specification is constructed using the following building blocks:

  • Element:  The most basic unit of data in the CIECA Specification to define a single piece of information (of a specific data type).  This applies only to XML.
  • Aggregate:  A group of related elements to provide a mechanism for coding logic rules and a convenient method to refer to related information using a single name.
  • Message: A collection of elements and/or aggregates to be passed from the sender to the receiver (Request Message) or from the receiver to the sender (Response Message).
  • Service:  A single function or a collection of similar functions that are used by companies, individuals and small businesses. A single function or a collection of similar functions that are used by companies, individuals and small businesses.
  • Document:  A collection of services and messages sent as a single unit between sender and receiver.


Repeating groups of data are represented in the data dictionary as 'Aggregates'.  In the BMS Standard, section 3 defines the common elements and aggregates.  Parties, contact information, addresses and other elements that are used frequently throughout the repair process are defined as Aggregates.

This illustration shows the Address Aggregate within the BMS Standard.  Each data element is identified as a Tag <Address>.  The data type is defined as well as the Usage (Required, Optional, etc.).   A Description provides additional information to help understand the data elements usage.

Data Dictionary by Standard


The EMS Standard supports only Service (Estimate).  It has it's own Data Dictionary that is unique to the EMS.  The EMS was created using dBase and does not use aggregates for repeating groups.  Each data element in the EMS has a unique tag that does not correlate with the BMS or CAPIS standards.


The BMS data dictionary is contained within the BMS document.  As mentioned previously, the BMS is designed to support XML based integrations and makes extensive use of aggregates.  Data elements that common across multiple services are defined in the Common Aggregates section of the dictionary.  Data elements that are unique to a specific service are contained in a corresponding section of the document.


The CAPIS data dictionary includes all data elements in a single comprehensive dictionary.  Data elements are organized in alph sort.

NOTE:  At this time the CAPIS Standard is still in development.