通用电子档案管理系统解决方案

通用电子档案管理系统解决方案

版本: V1.0

日期: 2026-07-10

一、问题背景

1.1 现状痛点

当前各类机构（社保、公积金、人力资源、学校、医疗、银行等）管理着海量的个人档案，普遍存在以下问题：

采集效率极低：

质量无法保障：

• 扫描过程中人工难以发现"扫错档"（如标称身份证，实际放入学历证书）
• 缺档、错档、重复档等问题在事后才能发现，纠错成本高
• 无 OCR 能力，无法对扫描件内容进行校验和全文检索

系统与业务深度耦合：

• 现有档案系统多针对特定业务（如社保养老保险）开发，表结构、字段命名、存储过程均绑定具体业务
• 无法复用到其他业务场景（公积金、人事、学校等）
• 个人档案的"一人一卷"约束与机构档案的"按全宗归卷"是两种不同模式，现有系统通过复制表结构（如 AC01/AC20）实现，维护成本翻倍

库房管理粗放：

• 无环境监控，温湿度异常靠人工巡检发现
• 档案实体库房与电子档案系统脱节

1.2 问题本质

个人档案采集的核心矛盾是：扫描仪硬件速度极快（100页/分钟），但软件流程把人绑在了关键路径上——每扫一页都要停下来手动选类型、填元数据、检查质量。人成了瓶颈，机器在等人。

解决思路：把人从采集流水线上摘出来。 机器干机器的（扫描/OCR/分类/校验），人只干机器干不了的（复核异常）。

二、方案概述

2.1 设计理念

核心原则: 采集效率优先, 人不在关键路径上

扫描只管扫描   → 分隔页QR码自动分组, 不停顿
元数据后填     → OCR + 业务系统自动补, 不手填
只看异常       → 95%自动通过, 人工只复核5%异常
文件不搬家     → 扫描时入库file_object, 全程不动

2.2 方案总览

本方案是一套通用电子档案管理系统，通过以下核心设计解决上述问题：

1. 分隔页批量采集流水线 —— 扫描与 OCR 解耦，暂存区暂存，异常复核后提升为正式档案
2. OCR 智能识别 —— 全文检索 + 文档类型分类 + 质量校验，自动发现错档/缺档/重复
3. 一套表两种模式 —— 个人档案（一人一卷）与机构档案（按全宗归卷）统一表结构，消除克隆表
4. 可配置档号规则 —— DA/T 13 合规的段式档号生成，不同门类不同规则
5. 业务系统零侵入 —— 通过 SPI 接口解耦，库表不含任何业务专属字段
6. 库房环境监控 —— IoT 设备接入，温湿度/光照/烟感/水浸/防盗实时监测告警

2.3 技术标准

三、核心技术创新

3.1 分隔页批量采集流水线

3.1.1 设计思路

传统采集是"逐人串行"：查一个人 → 扫描 → 手选类型 → 填元数据 → 保存 → 下一个人。

本方案采用"批量扫描 + 异步处理"：打印分隔页（含 QR 码）夹在每个人的材料前面，一把扫描全部，系统自动按分隔页分组，后台异步 OCR 识别类型和质量，只把异常推给人工复核。

3.1.2 分隔页设计

┌─────────────────────────────────────────┐
│  ▓▓▓▓▓▓▓▓                              │
│  ▓ QR码 ▓   身份证号: 460100199001011234 │
│  ▓▓▓▓▓▓▓▓   姓名: 张三                  │
│              模板: 城乡居民养老保险参保人员 │
│              序号: 0023                   │
└─────────────────────────────────────────┘

QR码内容(JSON): {"k":"460100199001011234","n":"张三","t":"SI_PENSION","s":23}

  k = 主体键 (身份证号, 必填)
  n = 主体名称 (姓名, 选填)
  t = 材料模板编码 (指定校验模板, 选填)
  s = 序号 (便于排序, 选填)

QR 码为主（毫秒级识别），纸面打印文字为辅（QR 码扫不出时降级走 OCR 读身份证号）。

3.1.3 采集流水线

阶段1: 批量扫描 (实时, 快)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  操作员将所有分隔页+材料放入扫描仪ADF
  系统自动:
    · 识别分隔页 QR 码 → 毫秒级, 不停顿
    · 按分隔页自动分组 (一人一组)
    · 每组创建临时案卷 (archive_dossier, status=DRAFT)
    · 扫描页存入暂存区 (scan_page)
  此阶段不做: OCR / 类型识别 / 质量检测 / 元数据录入
  产出: 500人 × 5页/人 = 2500页 → 25分钟

阶段2: OCR 后处理 (异步, 后台)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  系统自动对每页暂存数据:
    1. 全文 OCR → ocr_result.ocr_text (建全文索引)
    2. 文档类型分类 → ocr_result.identified_type + type_confidence
    3. 质量检测 → scan_page.quality_status + quality_issues
    4. 字段提取 → ocr_field (身份证号/姓名/日期, 含置信度+坐标)
  
  系统自动对每组(人):
    5. 比对材料模板: 应有材料 vs 实际识别
    6. 缺档/错档/重复 → scan_group.quality_summary
    7. 异常项标记 → scan_page.review_required = 1
  产出: 2500页 → ~30分钟

阶段3: 人工复核 (只看异常)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  系统只推异常项给复核员 (约5%):
    · 类型不匹配 (预期身份证, 实际学历证)
    · 置信度低 (OCR不确定是什么)
    · 质量问题 (模糊/倾斜/空白/截断)
    · 缺档 (材料不齐)
    · 重复 (同类型多张)
  
  复核操作: 确认 / 改类型 / 重扫 / 丢弃
  产出: ~125页异常 → ~1小时

阶段4: 自动提升入库 (系统自动)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  复核通过 → 自动 promote 为正式档案:
    scan_page.file_object_id      → archive_document.file_object_id (文件不动)
    scan_page.identified_type     → archive_document.doc_type
    scan_page.material_item_id    → archive_document.material_item_id
    scan_group.temp_dossier_id    → archive_dossier (DRAFT → 正式)
    scan_group.subject_key        → archive_subject_bind.subject_key
  文件对象全程不搬移, 只改引用

3.1.4 效率对比

传统方式 (逐人串行):
  单人: 扫描1分 + 元数据3分 + 校验1分 = 5分钟/人
  日产: 8小时 ÷ 5分 = 96人/天
  10万人: 1042天 ≈ 3年

本方案 (批量+异步):
  扫描: 500人 × 5页 = 2500页 ÷ 100页/分 = 25分钟
  OCR: 异步 30分钟
  复核: 5% × 2500 = 125页 × ~30秒 = 1小时
  日产: 8小时 ≈ 2000人/天
  10万人: 50天

提升: ~20倍

3.2 OCR 智能质量校验

3.2.1 设计思路

OCR 在档案系统中的最大价值不是字段提取（那个手填更快），而是质量校验——自动识别每页扫描件的文档类型，与材料模板预期比对，发现人眼难以发现的错档。

3.2.2 三层质量检测

页级检测 (每页扫描件):
  1. 类型识别: OCR + 分类 → 识别为"身份证"/"户口本"/"参保登记表"...
  2. 预期比对: 该位置应该是"身份证" → 与识别结果比对
     · 匹配 → PASS
     · 不匹配 → FAIL, 标记 WRONG_TYPE (如: 预期身份证, 实际学历证)
     · 无法识别 → 置信度低, 标记需人工复核
  3. 清晰度: 模糊/倾斜/低分辨率 → 标记 UNCLEAR/SKEWED/LOW_RES
  4. 完整性: 页面截断/空白页 → 标记 INCOMPLETE/BLANK

组级检测 (一个人的一组扫描件):
  5. 缺档: 材料模板要求7种, 只扫了5种 → 缺2种
  6. 错档: 扫了学历证但模板里没有 → 多余
  7. 重复: 扫了2张身份证 → 重复
  8. 汇总: quality_summary = PASS / FAIL / PARTIAL

校验逻辑示例:
  应有 (从材料模板): [身份证, 户口本, 参保登记表, 缴费存折]
  实际 (OCR识别):    [身份证✓, 学历证书✗, 参保登记表✓, 缺缴费存折✗]
  结果:
    · WRONG_TYPE: 页2 标称户口本, 实际学历证书
    · MISSING: 缺缴费存折
    · MATCHED: 身份证, 参保登记表

3.2.3 OCR 三大能力分层

全文检索和类型分类是采集效率的基础设施，字段提取是高阶可选能力。

3.2.4 字段提取复核闭环

OCR 提取字段 → 置信度 >= 阈值?
  ├── 是 → 直接采用 (is_verified=1)
  │        身份证号阈值 95%, 姓名阈值 80%, 日期阈值 85%
  └── 否 → 进入人工复核队列 (is_verified=0)
            ↓ 人工核对原件
            ├── 确认正确 → is_verified=1
            └── 修正 → is_verified=2, verified_value=修正值

3.2.5 OCR 引擎 SPI

OCR 引擎不写死，通过 SPI 接口接入不同实现：

OcrEngineProvider (接口)
  OcrResult process(FileObject file, OcrTemplate template)
  返回: 全文文本 + 文档类型 + 各字段值 + 置信度 + 坐标

实现选项:
  TesseractEngine     开源, 本地部署, 免费 (政务内网)
  PaddlePaddleEngine  百度开源, 中文识别强
  CloudOCREngine      阿里云/腾讯云 OCR API (云上部署)
  CommercialEngine    商业 OCR (汉王/商汤)

3.3 一套表两种档案模式

3.3.1 设计思路

个人档案和机构档案是两种完全不同的组织方式，现有系统通过复制表结构（AC01 vs AC20）实现，导致维护成本翻倍。本方案通过 archive_mode 字段在统一表结构上支持两种模式。

3.3.2 两种模式对比

3.3.3 全卷宗约束（个人档案）

个人档案的"全卷宗"是档案学基本要求，不是业务定制：

1. 同一 subject_key + subject_type 在同一 category 下只允许一个 dossier
2. archive_document.dossier_id 非空（件必须挂卷下）
3. 删除 dossier 级联删除 document + subject_bind + storage_record（整卷销毁）
4. 移交/借阅以 dossier 为最小单位（整卷流转）
5. 不同人的档案物理隔离：存储路径按主体分目录

3.4 可配置档号规则

3.4.1 设计思路

DA/T 13-2022 规定档号结构为：全宗号-门类代码-年度-保管期限-机构/问题-案卷号-件号-页号。不同门类选用不同段组合，现有系统硬编码档号生成逻辑，无法配置。本方案将档号拆解为可配置的"段"。

3.4.2 段式档号配置

archive_no_rule (规则) ──1:N── archive_no_segment (段)

段类型:
  FONDS_NO         全宗号        来源: archive_fonds.fonds_no
  CATEGORY_CODE    门类代码      来源: archive_category.category_code
  YEAR             年度          来源: archive_dossier.archive_year
  RETENTION_CODE   保管期限代码  来源: archive_retention.retention_code
  ORG_TOPIC_CODE   机构/问题代码 来源: archive_catalog_node.node_code
  DOSSIER_SEQ      案卷号        来源: SEQUENCE (序列生成, 左补零)
  DOC_SEQ          件号          来源: 卷内序号
  PAGE_NO          页号          来源: 文件内页号

示例:
  个人档案档号: 0010-PERS-V001-0001
    (全宗0010 - 个人档案PERS - 机构V001 - 案卷0001)
  机构档案档号: 0010-DOC-2024-D30-OFF01-0001
    (全宗0010 - 文书DOC - 年度2024 - 定期30年D30 - 机构OFF01 - 案卷0001)

3.5 库房环境监控

3.5.1 设计思路

JGJ 25-2010 对档案库房环境有明确要求（温度 14~24°C、湿度 45~60%、照度≤50lx 等），现有系统无环境监控能力。本方案通过 IoT 设备接入实现实时监测和自动告警联动。

3.5.2 监控体系

IoT 传感器 (archive_env_device, role=SENSOR)
  │ 温湿度/光照/空气质量/烟感/水浸/红外/门磁/防磁
  │ 按采集间隔自动上报读数
  ▼
环境读数 (archive_env_reading) ← 时序数据
  │
  │ 读数入库时对照阈值规则实时判断
  ▼
告警记录 (archive_env_alert) ← 超阈值自动生成
  │
  ├─ 告警联动 → 设备控制 (archive_env_control_log, trigger=AUTO_ALERT)
  │              ↓ 自动下发指令 → 空调/除湿机/净化器
  │
  └─ 人工确认 → 处置闭环 (acknowledged → resolved)

人工巡检 (archive_env_inspection) ← 定期巡检八防, 补充自动监测
  防火/防盗/防潮/防虫/防鼠/防光/防尘/防磁

3.5.3 双级阈值机制

• 预警级 (WARNING)：接近标准阈值时触发，自动启动环控设备调节
• 严重级 (CRITICAL)：超过标准阈值时触发，通知人工介入
• 日波动限：JGJ 25 要求温度日波动≤±2°C，湿度≤±5%

四、系统架构

4.1 分层架构

┌─────────────────────────────────────────────────────────────────┐
│                        前端应用层                                 │
│  扫描客户端 | 复核工作台 | 档案管理 | 查询检索 | 库房监控大屏     │
├─────────────────────────────────────────────────────────────────┤
│                        业务服务层                                 │
│  采集服务 | OCR服务 | 整理服务 | 保管服务 | 利用服务 | 监控服务   │
├─────────────────────────────────────────────────────────────────┤
│                        核心档案引擎                               │
│  档案实体 | 全生命周期 | 档号生成 | 权限控制 | 审计日志           │
├─────────────────────────────────────────────────────────────────┤
│                    SPI 扩展层 (业务解耦)                          │
│  SubjectProvider | ArchiveNoGenerator | OrgProvider              │
│  OcrEngineProvider | MaterialCatalogProvider                     │
├─────────────────────────────────────────────────────────────────┤
│                        数据持久层                                 │
│  39张表 10个分区 | 文件存储(本地/FTP/OSS) | 全文索引              │
└─────────────────────────────────────────────────────────────────┘

4.2 SPI 接口设计

所有业务相关逻辑通过 SPI 接口隔离，库表本身不含任何业务专属字段：

4.3 多通道采集

通道1: 批量扫描 (SCANNER)
  分隔页 + ADF + 异步OCR
  适合: 存量纸质档案大规模数字化

通道2: 文件导入 (IMPORT)
  拖拽 PDF/图片批量导入, 选材料模板, OCR自动分类
  适合: 已有数字化文件的批量入库

通道3: 移动端采集 (MOBILE)
  手机拍照 → 上传 → OCR
  适合: 基层网点/现场办公无扫描仪

通道4: 业务联动 (EVENT)
  业务系统办件完成 → 触发归档任务 → 前端提示"请扫描XX材料"
  适合: 日常业务产生的增量档案

所有通道: 先进暂存区, 后端异步处理, 异常才找人

五、库表结构总览

5.1 表清单（39表，10个分区）

A. 基础配置层 (8表)
   archive_fonds            全宗
   archive_category         档案门类(含模式/组织规则/流转粒度)
   archive_catalog_node     目录节点树(统一目录+分类)
   archive_retention        保管期限(永久/定期30年/定期10年)
   archive_security_level   密级(公开/限制/秘密/机密/绝密)
   archive_storage          库房库位(树)
   archive_no_rule          档号规则
   archive_no_segment       档号规则段(可配置段类型/来源/顺序)

B. 档案实体层 (5表)
   archive_dossier          案卷(统一, archive_mode区分个人/机构)
   archive_document         文件/件(dossier_id可空, 支持件级整理)
   archive_subject_bind     主体绑定(泛化, 个人档案必须/机构档案可选)
   archive_file_object      文件存储对象(SHA-256哈希, GB/T 18894)
   archive_doc_metadata     文件元数据(key-value, GB/T 18894)

C. 整理层 (2表)
   archive_cataloging       编目记录
   archive_appraisal        鉴定记录(价值/期限/密级/销毁, 含审批)

D. 保管层 (3表)
   archive_storage_record   入库记录(入库/出库/移库)
   archive_transfer         移交记录(跨部门/进馆/跨全宗)
   archive_destruction      销毁记录(鉴定→审批→销毁, 不可逆)

E. 利用层 (2表)
   archive_use_application  利用申请(借阅/查阅/复制/摘录, 含审批)
   archive_use_record       借阅记录(借出/归还/续借)

F. 材料模板层 (3表)
   archive_material_template  材料模板(可配置, 替代硬编码)
   archive_material_item      材料项(替代AK02的a1-a26)
   archive_material_check     缺档检查(材料完整性检查结果)

G. 权限审计层 (3表)
   archive_data_permission   数据权限(角色-门类-密级)
   archive_audit_log         操作日志(全生命周期追溯)
   archive_audit_detail      字段变更明细(old/new值)

H. 库房环境监控层 (6表)
   archive_env_device        监控设备(IoT传感器+环控设备)
   archive_env_reading       环境读数(时序数据)
   archive_env_threshold     阈值规则(预警/告警双级+日波动限)
   archive_env_alert         告警记录(触发→确认→处置闭环)
   archive_env_inspection    巡检记录(八防检查)
   archive_env_control_log   设备控制日志(告警联动+人工远程)

I. OCR 智能识别层 (4表)
   archive_ocr_result        OCR结果(全文+类型分类+置信度)
   archive_ocr_field         提取字段(含置信度+坐标+复核)
   archive_ocr_template      提取模板(按材料类型配置)
   archive_ocr_field_def     字段定义(提取方式/区域/正则/阈值)

J. 扫描采集层 (3表, 暂存区)
   archive_scan_batch        扫描批次
   archive_scan_group        扫描分组(分隔页界定, 含质量汇总)
   archive_scan_page         扫描页(暂存核心, 含OCR+质量+复核)

5.2 档案全生命周期

参数配置 → 采集/收集 → 整理 → 归档 → 保管 → 利用 → 处置
   │           │          │       │       │       │       │
   │           │          │       │       │       │       ├─ 鉴定销毁
   │           │          │       │       │       ├─ 借阅/查阅/复制
   │           │          │       │       ├─ 入库/移库/移交
   │           │          │       ├─ 档号生成/编目/分类
   │           │          ├─ 组卷/立卷/鉴定
   │           ├─ 批量扫描/文件导入/移动采集/业务联动
   ├─ 全宗/门类/目录/库位/保管期限/密级/档号规则/材料模板

5.3 暂存区与正式档案的关系

暂存区 (扫描采集层)              正式档案区 (档案实体层)
  scan_batch                      archive_dossier
  scan_group    ──promote──→      archive_document
  scan_page                       archive_subject_bind
  │                               archive_file_object (不变)
  │
  └─ file_object_id 全程不变, 只改引用
  └─ scan_page.status = ARCHIVED (保留暂存记录)

5.4 GB/T 18894 四性保障

六、应用场景

6.1 适用领域

本方案适用于所有需要管理大量个人档案的机构：

6.2 共同特征

所有场景共享以下特征，本方案可直接适用：

1. 一人一档 —— 每个人一个独立档案卷宗，不能混淆
2. 材料类型固定 —— 每类人员的应备材料清单可定义（材料模板）
3. 需扫描数字化 —— 纸质材料需扫描为电子件
4. 量大 —— 个人档案数量级远超机构档案
5. 需对接业务系统 —— 档案主体信息来自业务系统

6.3 部署方式

通过 SPI 接口适配不同业务系统，同一套档案核心引擎服务多个场景：

                    ┌─ 社保部署 (SubjectProvider=查IC01)
                    ├─ 公积金部署 (SubjectProvider=查公积金职工表)
通用档案核心引擎 ────├─ 人事部署 (SubjectProvider=查员工表)
(39张表, 不变)      ├─ 学校部署 (SubjectProvider=查学籍表)
                    ├─ 医院部署 (SubjectProvider=查患者表)
                    └─ 银行部署 (SubjectProvider=查客户表)

七、技术实现要点

7.1 扫描客户端

• 支持生产级扫描仪 ADF（Auto Document Feeder），100页/分钟
• TWAIN/ISIS 协议接入，不依赖 ActiveX（支持现代浏览器）
• 扫描时实时识别分隔页 QR 码，自动分组
• 扫描页直接上传至文件存储，写入暂存区

7.2 OCR 处理引擎

• 异步队列处理（消息队列：RabbitMQ/Kafka）
• 支持多引擎并行（不同材料类型可用不同 OCR 模型）
• 全文索引：PostgreSQL tsvector+GIN / MySQL FULLTEXT / Elasticsearch
• 分类模型：可基于 OCR 文本关键词匹配，也可接入图像分类模型

7.3 全文索引方案

库表只存 ocr_text 原文, 索引方案由部署 DB 决定:
  PostgreSQL: 生成列 tsvector + GIN 索引 (原生全文检索)
  MySQL:      FULLTEXT INDEX (ngram parser 支持中文)
  Oracle:     CTXSYS.CONTEXT 索引 (Oracle Text)
  大规模:     同步到 Elasticsearch

7.4 时序数据存储

archive_env_reading 高频写入表 (100传感器×1次/分 = 14.4万条/天)
按时间分区:
  PostgreSQL: PARTITION BY RANGE (reading_time) 按月
  MySQL:      PARTITION BY RANGE (TO_DAYS(reading_time)) 按月
  Oracle:     INTERVAL PARTITIONING 按月自动
历史归档: 超过1年降采样为每小时均值

7.5 文件存储

存储方式可配置: LOCAL / FTP / OSS / S3
路径规则 (个人档案按主体隔离):
  /{fonds_no}/{category_code}/{subject_key_prefix}/{subject_key}/{dossier_no}/{file_name}
  示例: /0010/PERS/4601/460100199001011234/0010-PERS-V001-0001/scan_001.pdf

八、与现有系统对比

8.1 采集效率对比

8.2 架构对比

九、知识产权说明

本方案包含以下具有新颖性的技术创新，具备申请发明专利的条件：

9.1 创新点1: 基于OCR的个人档案质量校验方法

用 OCR 识别扫描件文档类型，与材料模板预期比对，自动检测错档/缺档/重复。解决"人工难以发现扫错档"的技术问题。

9.2 创新点2: 个人档案分隔页批量采集方法

针对"一人一卷"约束，设计含主体键的 QR 分隔页，扫描时自动分组并创建临时案卷，异步 OCR 后复核提升。将采集效率提升20倍。

9.3 创新点3: 暂存区到正式档案的无迁移提升方法

文件对象在暂存区创建后全程不搬移，仅通过引用状态变更实现"提升"，避免大文件复制开销，暂存区脏数据不污染正式档案表。

十、总结

本方案的核心价值主张：

把人从档案采集流水线上摘出来。

通过"分隔页批量扫描 + 异步OCR + 异常复核 + 自动入库"的采集流水线，将个人档案采集效率提升20倍。通过"OCR类型分类+材料模板比对"实现采集时实时质量校验，解决错档/缺档/重复问题。通过"一套表两种模式+SPI接口"实现通用化，一套核心引擎服务社保、公积金、人事、学校、医疗、银行等多个领域。

完整库表结构（39张表）见同目录 archive_generic_schema.sql。