实验室信息管理系统的数据设计

李海燕，王树庆，胡广勇

北京市医疗器械检验所 （北京 101111）

我所在实验室信息管理系统（laboratory information management system，LIMS）的使用中遇到了业务数据计算瓶颈，本研究就该现象展开了细致的问题阐述和分析，通过具体案例从业务层面和数据库技术层面提出了一系列业务数据的优化方法，涉及实验室相关管理经验和数据库技术领域的前沿性研究，并指出了业务数据优化工作的难点与重点。

1 LIMS 应用单位简介

我所是经中国合格评定国家认可委员会（CNAS）、中国国家认证认可监督管理委员会（CNCA）、原国家食品药品监督管理总局（CFDA）等部门认可授权的一所综合性医疗器械产品检测机构，同时也是原CFDA授权设置的10个国家级医疗器械质量监督检验中心之一。目前，我所经国家相关部门授权的检验项目达1 294项，检验范围涵盖医用电子、医用射线、核医学、电声学、体外诊断系统、一次性医疗产品、医用防护用品、医用橡胶制品、口腔材料、生物安全柜、电磁兼容、生物相容性和体外循环及化妆品生物学评价等专业领域，承担着全国和北京地区医疗器械产品监督抽验检验、注册检验、认证检验、进出口商品检验、委托检验、仲裁检验等检测任务。我所先后获得德国TüV、美国UL、加拿大CSA等国际权威认证机构的认可，为国内医疗器械产品走向国际市场提供了便捷的检测技术服务；先后建成国内第一家10 m法医疗器械电磁兼容实验室、第一家具备生物安全柜检验能力的实验室、第一家医用防护产品检验实验室、第一家经CNAS认可的血细胞参考测量实验室等一批具有国际先进水平的实验室；先后获得并加入“北京市重点实验室”“博士后科研工作站”“中关村开放实验室”及原“食药总局高研院现场教学基地”“首都科技条件平台”。

2 LIMS 简介

LIMS 是利用计算机网络将实验室的实验仪器连接起来，根据实验室管理体系、计算机技术和质量控制体系来建立的信息管理体系，其实现了检验数据共享、量化考核等功能，从而提高了工作效率，降低了运行成本，促进了实验室的规范化管理，为提高实验室整体管理水平提供了先进的技术支持。

我们根据多年的LIMS 使用和维护经验总结了单位实验室信息化管理体系，从LIMS 用户提出的众多需求中提炼出新的业务需求，并进行了全面系统的分析，依托BPM 中间平台开发了北京市医疗器械检验所LIMS（BPM_LIMS）。目前，BPM_LIMS 已经平稳运行了6年，为单位的实验室管理提供了信息化支持，提高了工作人员的工作效率，在实验室日常管理中起着重要作用。

3 BPM_LIMS 存在的数据问题

近期BPM_LIMS 部分功能经常出现服务超时、无法响应、直接报运行错误等异常情况，如终止费用核算功能运行超时，无法正常使用，监控Oracle 数据库以及硬件服务器发现，调用该功能模块后，进入页面加载的期间，数据库服务器的单个CPU 进程资源占用率为100%，分析其原因为，该功能界面加载中需要数据库运算复杂的SQL 语句，该SQL 语句执行的计算量太大，导致单线程计算量超出了硬件CPU 的处理能力，因此导致报送服务超时的错误，从而导致页面加载失败。

我们分析相关功能模块，发现该模块的功能设计和检验过程管理、异常流程管理、费用设置管理、费用树目录等模块耦合度非常高。该功能运行时，需要同时调用、判断以上4个模块的各种任务状态、费用状态以及费用目录设置界面，在做最后确认动作时，还需要进行批量操作、合作检验状态、主检科室终止、辅检科室任务状态、辅检科室是否终止、调用费用设置、费用设置逻辑判断、发送通知等众多条件判断才能完成整个数据状态更新录入的操作。

我们通过功能梳理和逻辑条件分解，将页面从原来的集成页面拆分出来，缩短页面加载时间，简化判断条件，优化SQL 语句，解决页面崩溃问题；通过和业务部门沟通，做页面拆分、逻辑简化处理，缓解了当前的问题，但是并未彻底解决数据库访问压力大的问题。

BPM_LIMS 数据库的设计采用了传统的关系型数据库Oracle RAC 集群模式，可以实现负载均衡和热备功能。RAC 集群最大的优势在于高可用性，通过使用RAC 可以在一定程度上避免因故障引起的数据丢失和非计划停机，并缩短或排除计划停机时间，但RAC 并不是高性能的解决方案。Oracle 数据库集群对ERP 类的管理系统存在负载受限的设计缺陷，即集群默认主节点响应数据服务请求，不会将服务请求按照实际业务量进行负载均衡分散到各节点。BPM_LIMS 系统属于ERP 系统类型，且我们的单个SQL 请求数据运算量巨大。Oracle 数据库对业务请求的最小颗粒划分是以单个SQL 作为最小线程，无法再进行任务拆分。综合以上两个方面的原因，我们目前的数据运算量大的业务模块存在数据计算量超出服务器CPU 单核处理能力的问题。

4 业务数据问题分析与解决思路

我们业务数据的特性是数据量每年呈增量上涨，每个页面的查询、操作都建立在大量数据检索和条件判断之上，其中，数据查询、统计报表更需要在所有原始数据中进行大量复杂计算。目前，我们的原始数据还没有可以拆分的标准。由于不同维度对数据的筛选条件千差万别，没有一个可以统一分类或分解的指标，导致数据量越大，执行速度越慢，这一直是LIMS 的数据设计痛点，也是系统很多页面反应速度慢、执行效率低的问题根源。我们需要做的是梳理业务，分析业务数据类型，整理数据结构模型，然后提出新的业务流程和数据结构设计模型，重构业务模型和数据模型，才能从根本上解决问题。

首先，我们需要认真分析业务逻辑复杂、数据交叉的功能模块，从业务本身的流程规范和可操作性上进行业务梳理，然后分析能否简化业务流程，分离交叉数据，从而避免复杂的逻辑判断和数据计算。如合作任务的异常处理流程，其产生的业务背景是我们业务中经常出现检验样品需要不同的检验科室进行检验，并出具相应的检测结果，形成一份合成的检验报告。

在这种合作检验的业务场景下，检验任务受理、合同评审、任务分配、检验、结果录入、报告审核、报告签发等业务流程主线的各个节点都需要与多科室进行合作协调；此外，样品入库、领取、回库、退库管理，多科室检验费用核算，异常流程处理的暂停、终止等细小的分支管理亦涉及合作协调；然后就是以上各种业务场景的所有情况的排列组合；如此映射到BPM_LIMS 的业务流程中，就会是复杂的业务逻辑和数据交叉计算。如果我们的实际业务不能进行管理层面的业务拆分，系统的业务流程就不可能出现逻辑简化。

总之，要想简化BPM_LIMS 的业务逻辑，就要从管理层面解决问题的源头——业务管理模式，管理者和被管理者可能会对此种管理思维模式的转变产生抵触，此时需要高层管理者强有力的工作支持。

其次，业务管理模式改革确立后，根据新的业务流程，梳理业务需求，分析数据结构，构建新的数据模型。数据结构是计算机存储、组织数据的方式，是指相互之间存在一种或多种特定关系的数据元素的集合。通常，精心选择的数据结构可以带来更高的运行或存储效率[1]。

我们的业务场景最合适的数据库类型是关系型数据库。在设计开发过程中，开发人员通常要同时面对一个或多个数据实体进行操作，一般单个数据实体首先要分割成多个部分，然后按照结构化的方法再对分割的部分进行规范化；规范化以后，每个数据表都必须定义好各个字段，再分别存入到多张数据表中。此过程较复杂，其优点是整个数据表的可靠性和稳定性都比较高，但一旦存入数据后，如果需要修改表结构将会十分困难。

关系型数据库有4个特性（ACID 规则）：原子性（atomicity）、一致性（consistency）、隔离性（isolation）、持久性（durability），其中十分强调强一致性原则。数据按照最小关系表进行存储，数据管理一目了然，这是针对一张数据表的情况；如果是多张数据表，由于数据涉及多张数据表，数据表之间存在着复杂的关系，随着数据表数量的增加，数据管理会越来越复杂。

数据操作的瓶颈出现在多张数据表的操作中，而且数据表越多此问题越严重。一旦面对海量数据的处理，效率将会变得很差，特别是遇到高并发的情况，性能将会下降的非常明显[2]。想要缓解该问题，只能选择CPU 处理速度更快、性能更好的计算机，如此虽然可以拓展一些空间，但非常有限，即关系型数据库只具备纵向扩展能力。

最后，选择合适的关系型数据库以及数据库集群的搭建模式，这也是我们今后引进新平台、重新开发BPM_LIMS 需要慎重考虑的难点。关系型数据库常见的有Oracle、SQLServer、DB2、Mysql，除了Mysql，其余的关系型数据库都需要支付费用，个别数据库价格高昂，我们无法承受。即使Mysql 是免费的，但由于其开源的特性，其性能也受到了诸多的限制，并且缺乏强有力的技术支撑。目前，国产数据库的性能以及稳定性还有待提高。因此，关系型数据中我们可选择的范围很窄。

综上所述，要想解决BPM_LIMS 的数据问题，我们的主要精力还需要集中在改善数据库的SQL 性能、优化系统的业务流程两个方面。往往数据的优化同高效的检索算法和索引技术有关，因此，高效的SQL 和算法同样能给用户带来良好的数据库体验。LIMS 的数据分析与优化需要我们慢慢探索，通过更多的实际业务应用场景来检验每次优化的成果是否最切合实际及最实用。