Мне кажется лучше примерно так:
Таблица ЛЮДИ:
1) ИД ЧЕЛОВЕКА (ГУИД)
2) ОГРН УЧРЕЖДЕНИЯ (УНИКАЛЬНЫЙ ИД УЧРЕЖДЕНИЯ)

Таблица ДОКУМЕНТЫ
1) ИД СОСТОЯНИЯ (СЧЕТЧИК)
2) ID чел в табл ЛЮДИ
3) АДРЕС (храним ID, значение из справочника)
4) ФАМИЛИЯ (храним ID....)
5) ИМЯ (храним ID....)
6) ОТЧЕСТВО (храним ID....)
7) ДАТА РОЖДЕНИЯ
8) МЕСТО РОЖДЕНИЯ (храним ID.... можно ссылка на КЛАДР)
9) ВИД ДОКУМЕНТА
10) ID последнего документа того-же вида (предыдущего паспорта, предыдущего ИНН)
11) СЕРИЯ
12) НОМЕР
13) ДАТА ВЫДАЧИ
14) документ действителен

Таблица СТАТУС
1) ID чел в табл ЛЮДИ
2) СТАТУС (ПЕНСИОНЕР,СТРУДЕНТ И Т.П.) (храним ID, значение из справочника)
3) ДАТА ПОЛУЧЕНИЯ СТАТУСА

как уже говорили выше
обязательно полная номализация, СУБД с циферками в разы лучше работает
при этом самая ёмкая таблица
Таблица ДОКУМЕНТЫ
1) int
2) int
3) int
4) int
5) int
6) int
7) date
8) int
9) int
10) int
11) char
12) char
13) date
14) bool

На любые атрибуты человека, такие как ФИО, дата рождения.. должен быть некий документ, чел не може прийти и просто сказать - я Вася... ок, Вася, так и запишем
должен быть либо паспорт, либо ИНН.... удостоверение...
Сменил чел имя => сменил паспорт.. последний актуальный документ тот, у которого дата выдачи самая поздняя и действительны, и история смены документов на лицо, сперва свидетельство о рождении, затем паспорт, ИНН, затем другой паспорт...

В туже табличку и ИНН, и пенсионное свидетельство...

Аналогично со статусом.

На счёт объединения данных:
- на рабочем месте, данные экспортируются в txt или XML (или ещё как) без всяких GUID, в полном виде, обязательно должны быть документы, на основании которых внесены данные...
<men>
<fio>Иванов....</fio>
<docum>
<type>паспорт</type>
<num>9931 231244</num>
.....
</docum>
</men>

- в центре, файл импортируется, ищются совпадения по другому никак. например ФИО и даты совпадают, сопадает номер предыдещего паспорта, но паспортные данные отличаются и более поздняя дата - значит новый паспорт...
другими словами, даже не набор правил для сравнения, а комплексный алгоритм, сравниваем по разным критериям, выставляем % совпадения... далее помечаем где вероятность менее 100% и оператор смотрит... в процессе работы, выявляются новые "правила", и совершенствуется алгоритм

в принципе ИНН или номер пенс.свид это довольно "уникальный" номер, да, он может меняться у одного человека, но не представляю, чтобы у двух разных людей в одном регионе эти номера совпали

неувязочка..
...
7) МЕСТО ЖИТЕЛЬСТВА
8) МЕСТО РАБОТЫ
9) СОЦИАЛЬНЫЙ СТАТУС
...
мне кажется, что место работы связанно с социальным статутом косвенно,
человек, учясь в институте, может работать системным администратором наример...
какой у него соц. статус? а когда он закончил институт и работатет тамже?
вы не отследите чётко когдаменяется статус
да и мед.полис могут менять не один раз на одной работе,
а если на двух работах одновременно? не два же полюса будут делать? и страховые компании могут быть разными

авторЯ специально не показывал тип идентификатора - думаю мне пока важнее определиться со структурой БД, а уже потом решить какие типы идентификаторов использовать.
ИМХО длинное целое, или просто целое, либо счётчик в таблице, либо извратиться, и сперва, например ставить год рождения :) например 1973ХХХХХХ


авторБолее глубокую разбивку считаю нецелесообразной, т.к. это существенно затруднит работу с данными и разработку отчетов, тем более, что таблица ПОСЕЩЕНИЯ так-же имеет 4 подчиненных таблицы (пока :) )
ой зря вы так, при ваших-то объёмах... всё, что может повториться, должно быть вынесено в отдельный справочник, вы этим увеличите производительность, думаю не совру, если скажу что на 40...60% и уменьшите объёмы данных, и отчёты в разы быстрее генериться будут

маленький пример:
как-то парился с тел справочником, то, что было - плоская таблица (~10тыс записей, Access)
объём - ~2 метра
после нормализации, где я просто для улиц отдельную таблицу вынес, объём уменьшился до 600кб
а можно было бы ещё и именами и фамилиями заняться :)
так было всего 10тыс записей!!!! а если 500тыс?

с данными работать будет не сложнее, все сложности решаются средствами СУБД, например вьюхами и процедурками

ещё вам просто прописанны:
- набор таблиц аля-КЛАДР
- набор таблиц "ХОЗЯЙСТВУЮЩИЕ СУБЪЕКТЫ" (место работы, страховые компании...)

хотя решать конечно вам

и хотябы базку со справочниками в интернет выставить, очень упростит синхронизацию и актуализацию...
а лучше всю базу, DB account+VPN+ЭЦП - думаю достаточно безопасно

и ещё...
а если будет такая ситуация, в учреждении ошибаются с вводом, например с именем, года рождения...
- чел, определяется, как новенький, и нет связи с его предыдущими посещениями
- данные могут дублироваться с кем-нибудь, дата паспорта более поздняя...запись как двойник удаляется, и.. "а такого чела вообще к нам не приходило..."

может стоить придать записям статус..
- "новая" - как ввели в учреждении
- "к обработке" - как получили из учреждения
ПРОВЕРКА
- "ошибочная" - с указанием ошибки, отправляется опять на места для уточнения
- "верная" - когда всё нормально обработалось, тоже можно послать об этом уведомление

PS вы случаем не новый вариант "Катарсиса" делаете?