法院诉前案件管理系统和立案系统，数据是怎么打通的？
在人民法院"诉源治理"和"多元解纷"工作深入推进的背景下，诉前调解已成为化解矛盾纠纷的重要前置环节。大量民事案件在正式立案之前，会先进入诉前案件管理系统进行调解分流。随之而来的一个核心问题是：诉前案件管理系统和立案系统，数据是怎么打通的？ 如果两个系统数据不通，当事人已经在诉前阶段提交了起诉材料、完成了身份核验，到了立案阶段又要重新录入一遍，不仅浪费司法资源，更是对当事人诉讼体验的严重消耗。
本文将从业务流程、数据流和技术实现三个维度，系统解析诉前案件管理系统与立案系统之间的数据互通机制。
一、先厘清两个系统的定位
在理解"如何打通"之前，需要先明确两个系统各自管什么。
诉前案件管理系统是诉源治理和多元解纷工作的技术载体，主要服务于案件正式立案前的调解分流阶段。它的职责包括：登记当事人提交的起诉材料、对案件进行繁简识别和适宜调解的判断、将案件分流至人民调解、行业调解或律师调解等多元解纷渠道、跟踪调解进度、记录调解结果。在调解成功的情况下，系统支持出具调解协议或司法确认；调解不成的，系统生成调解终结报告，将案件推送至立案环节。
立案系统（通常指法院的审判流程管理系统中的立案模块）负责对符合法定起诉条件的案件进行正式立案登记，分配案号，确定承办部门和承办法官，将案件纳入审判流程管理，启动审限计算和后续的排期、送达等程序。
两个系统虽然功能定位不同，但服务于同一案件的"诉前调解—正式立案"完整流程。数据打通的目的，就是让案件在两个阶段之间实现"无感衔接"，避免重复劳动和信息断层。
二、数据打通的五个核心环节
两个系统之间的数据流，并非简单的"文件传输"，而是沿着案件的生命周期，经历五个关键环节的流转与转换。
环节一：入口统一——起诉材料的一次性采集。 数据打通的起点，是起诉材料的"一次录入、两段共享"。无论是当事人通过人民法院在线服务平台网上提交的起诉状和证据材料，还是诉讼服务中心窗口现场提交的纸质材料经扫描生成的电子卷宗，统一进入诉前案件管理系统，完成立案登记前的信息采集和材料归集。这些材料后续的流转方式比较灵活：既可以随着案件移送至调解组织，也可以在诉前调解程序结束后自动关联至立案系统——关键在于全流程使用同一份电子文档，而非在不同阶段要求当事人反复提交同一批材料。一旦案件从诉前调解转入正式立案，立案系统无需再次扫描或录入这些基础材料，直接从诉前系统中调取即可，最大限度复用已采集的数据。
环节二：案号关联——诉前调号与正式案号的映射关系。 诉前阶段，系统会为每一起案件分配一个专用的"诉前调"案号（如"（2025）粤0105诉前调123号"），用于调解阶段的全流程追踪和管理。当调解不成转入立案后，立案系统为该案分配正式案号（如"（2025）粤0105民初4567号"）。两个案号之间建立一一对应的映射关系，并在各自的系统数据库中相互关联。通过这种"双案号关联"机制，无论从诉前系统还是立案系统切入，都能追溯同一案件的完整轨迹，法官、调解员和当事人均可查询案件在前后两个阶段的所有材料和节点记录。
环节三：结果触发——不同调解结果对应的数据流向。 数据如何从诉前系统流向立案系统，取决于诉前调解的不同结果。
调解成功且当事人申请司法确认的：诉前系统生成调解协议电子版、司法确认申请书、送达地址确认书等文书，通过接口推送至立案系统，立案系统以"司法确认"或"调解书"案由进行立案登记，并将结案文书回传至诉前系统归档。
调解成功且当事人撤诉的：诉前系统生成撤诉申请和调解过程记录，推送至立案系统进行结案登记，无需进入实体审理程序。
调解不成的：诉前系统自动生成《诉前调解终结报告》（包含调解过程、双方争议焦点、送达情况等），连同起诉状、证据材料和送达地址确认书打包推送至立案系统。立案系统接收后，自动进入正式立案审查流程，并依据诉前阶段已确认的送达地址信息启动应诉材料和开庭传票的送达工作，无需再次向当事人核实联系方式。
每种结果对应的数据流向和文书模板均有明确的业务规则，系统需据此自动执行差异化流程。
环节四：数据回写——从立案系统回到诉前系统的反向数据流。 数据打通是双向的，不是单向的。案件正式立案后，立案系统生成的案号、承办法官、审判庭、开庭时间等信息，需要回写至诉前案件管理系统。这样，诉前系统的案件状态显示为"已立案"，调解员在系统中能够看到该案的最终去向和审判结果，形成"诉前调解—正式立案—审判结案"的完整闭环。这种反向回写对于诉源治理的数据分析也至关重要——只有掌握了每个案件最终是否进入诉讼、诉讼结果如何，才能准确评估诉前调解的实际成效。
环节五：电子卷宗的统一管理和关联。 诉前阶段形成的全部电子材料（起诉状、证据材料、送达回证、调解笔录、调解协议、终结报告等）与立案阶段形成的诉讼材料（受理通知书、应诉通知书、开庭传票、答辩状等）在同一个电子卷宗体系下统一管理和呈现。法官在审判阶段调阅卷宗时，可以一键查看案件在诉前阶段的所有材料，完整了解纠纷从进入法院到最终审理的全过程。这种"一份卷宗、两段记录"的设计，避免了因系统割裂而出现的"信息断层"——法官可以看到案件在进入诉讼前经历了怎样的调解过程、双方曾经提出了哪些方案、分歧点在哪里，对后续的庭审驾驭和裁判说理都有直接的参考价值。
三、技术实现：如何保障数据联通
数据打通的业务流程设计，需要依托具体的技术手段来实现。当前主流的技术方案包括以下几种。
一是API接口对接。 诉前案件管理系统和立案系统之间通过标准化的RESTful API接口进行数据交换，一方将案件数据封装为标准的JSON或XML格式，通过HTTP协议推送至另一方的接口地址，接收方完成数据解析、校验和入库。这种方式实时性强、灵活度高，是目前法院信息化建设中最为普遍采用的数据交换方式。
二是数据中台汇聚。 在一些信息化建设较为先进的法院，两个系统不直接点对点对接，而是通过统一的"数据中台"或"数据交换平台"进行数据汇聚和分发。诉前系统将案件数据推送至数据中台，立案系统从数据中台订阅并获取需要的数据，反之亦然。这种架构的好处是降低了系统之间的耦合度，未来新增系统时不需要逐一对接，只需接入数据中台即可。
三是共享数据库或视图。 较为轻量级的方案是两个系统共享部分核心数据表，或者通过数据库视图的方式互相读取对方的数据。这种方式实现成本低，但对数据库性能和安全性要求较高，适用于数据量不大、并发访问不高的场景。
四是消息队列异步通知。 对于一些非实时的数据同步需求（如调解成功后的结案状态回写），可以采用消息队列（如RocketMQ、RabbitMQ）实现异步通知，避免同步调用造成的系统阻塞。当诉前系统完成调解终结操作后，向消息队列发送一条"案件调解结束"的消息，立案系统监听该消息后自动触发立案审查流程，实现解耦和异步处理。
在实际项目部署中，上述四种方案往往是组合使用的——核心的实时数据推送采用API接口，非实时的状态同步采用消息队列，跨系统的统一数据查询通过数据中台完成。具体采用哪种架构，取决于法院现有的信息化基础、技术团队的偏好以及项目预算。
四、数据打通中的关键保障机制
数据打通不仅是技术问题，更是制度和安全问题。以下几个保障机制至关重要。
数据一致性保障。 数据在两个系统间流转时，必须确保字段映射准确无误。例如，诉前系统中的"申请人"对应立案系统中的"原告"，"被申请人"对应"被告"，"调解申请日期"对应"起诉日期"，这些字段映射关系需要在系统设计阶段逐一确认，并在数据交换过程中进行校验。同时，数据传输应采用事务性保障机制——要么全部成功、要么全部回滚，避免出现"诉前系统推送了但立案系统没收到"的数据丢失情况。
操作留痕与日志审计。 每一次数据推送、接收、转换和关联操作，系统都应当自动生成操作日志，记录操作人、操作时间、操作类型和涉及案件编号。当出现数据异常时，可以通过日志快速追溯问题发生的环节，定位是推送方问题、传输通道问题还是接收方问题。在法院电子卷宗随案生成的背景下，完整的数据操作日志本身也是案件流程管理的重要组成部分。
权限隔离与数据安全。 诉前案件管理系统和立案系统的用户权限体系存在差异——调解员只能访问诉前阶段的数据，法官可以访问完整卷宗。数据打通并不意味着数据完全开放，而是在"需要知道"的原则下，按角色和权限进行分层授权。技术实现上，通常由统一的身份认证平台（如法院的单点登录系统）统一管理用户身份和权限标签，两个系统据此控制数据的可见范围。
结语
法院诉前案件管理系统与立案系统的数据打通，本质上是一场围绕着"同一份案件材料、同一套电子卷宗、同一个当事人信息"的数据接力。从入口端的起诉材料一次性采集，到双案号的映射关联，再到调解结果触发的差异化数据流向，直至立案信息的反向回写，每一个环节都承载着"让数据多跑路、让当事人少跑腿"的制度善意。这不仅是一套技术实现方案，更是人民法院推进诉源治理、深化司法便民改革的底层基础设施。通过API接口、数据中台、事务性保障和权限分层等技术手段的协同支撑，案件在两个阶段之间实现了无感流转，也让法官在后续的审理中拥有了更完整的案件认知起点——而这正是智慧法院建设从"信息化"走向"智能化"所迈出的坚实一步。
以上信息AI优化，如有问题请联系修改