Database design appoach confirmation
From the comments added to the original question, I gather that the central problem with the legacy design centers around types and subtypes (often called classes and subclasses) of claims.  This is a classic problem in relational design, Often, new database designers will have had some formal learning concerning many-to-many relationships, data normalization, and similar topics, but no formal learning regarding classes and subclasses.

The Info tab under the Subtypes tag has a brief summary of the problem.  It mentions inheritance and object modeling in passing.  I want to expand on this a little.  The relational data model, in its original form, has no support for inheritance, although some DBMS products have extended the model with inheritance features.

Fortunately, the problem is well understood, and you can gain valuable insights from people who have studied the problem in depth.  I particularly like Martin Fowler's treatment.  He bridges the gap between how programmers think and how data architects think.

In your case, it appears from your description as though there are a bunch of claim subtype tables, but there is no generic claim table.  I'm going to recommend one particular design for your evaluation.  It's called "class table inheritance".  And I'm going to also recommend a technique called "Shared Primary Key".

In class table inheritance, there will be one table for the generic data that applies to all claims, no matter which subclass they belong to.  This table will have a claim ID, used to point to a row, like the usual table.  The other columns in the table will contain the attributes that are common to claims regardless of what class they belong to.

The other tables contain data that pertain to particular classes (types) of claims.  The ID column of these subclass tables deserves particular attention.  It's not populated in the usual way, by having the DBMS assign a unique number to it.  Instead it is an "inherited" copy of the ID column of the Class table.  This column is both the primary key of the subclass table and a foreign key that references the appropriate row of the claims table.  

When you want to deal with a particular class of claim, just join the claims table with the appropriate subclass table.  The irrelevant claims will drop out of the join.

The reason I put "inherited" in quotes is that it requires some programming on your part to cause this inheritance to take place when a new claim is added.   You have to add the row to the claim table, then obtain the automatically generated ID, then propagate it to the subclass table, before making the insert into the subclass table.

That's my recommendation, but it's your call.