In Part 1 of this series on leveraging database technology to track policy information, we looked at how you can use an off-the-shelf program like Excel to get your data-house in order.

However, spreadsheets have limitations when capturing policy data. For example, you could capture policy language and provisions in Excel — a column for each provision value and its corresponding language and Bates number — but one clause could apply to multiple columns, and the ability to sort, group and filter across policies is restricted.

Relational Database Advantages

In contrast, a relational database allows the user to store a piece of information just once and associate it with multiple other pieces of information.

Policies have multiple limit types and those limit types may even have various sub-limits. A relational database allows you to store the parts of the policy that do not change for the various limit types (policy number, carrier, dates) in one table, and the parts that do change by limit type (SIR/deductible, attachment point, per occurrence limit and aggregate limit) in another related, or linked, table.

When capturing actual policy language, a relational database is infinitely more useful than a spreadsheet or flat file. You might wish to capture the Limits of Liability section of a policy to determine if aggregate limits are present for bodily injury claims, and separately review that same language for property damage claims. In that case, it makes sense to capture larger chunks of language together, rather than break them up — preventing the need to revisit the policy, should the need for an additional review arise. If you make an error or otherwise need to update a piece of language, you need only make the change once.

You also can extract policy language by provision to prepare briefs, compare changes in underwriting across years, and aid legal analyses in countless other ways. Best of all, you can draw conclusions through clean, customized reports — rather than large and unwieldy stacks of paper or spreadsheets.

Converting to a Relational Database

Even if you’ve already followed good data practices in your spreadsheet, it still might be a good idea to convert to a relational database to store your policy data. Database programs typically allow users to generate customized forms to streamline data entry and reports to organize and aggregate information. Most database programs also have easy-to-follow wizards that allow even novice users to quickly and accurately import data. Because your spreadsheet has consistent fields, data and data types, there should be no information lost during the conversion.

In Part 3 of this series, we’ll examine best practices for capturing policy information in a relational database system.

What’s the current state of your policy data? Do you use a relational database? If so, what advantages do you utilize? What tips can you share?