基于Bootstrap框架的临床数据管理系统的设计与开发
2018年11月10日
目 录
第一章绪论... 6
1.1 选题背景及其意义... 6
1.2国内外研究现状... 7
1.2.1 临床大数据管理系统发展现状... 7
1.2.2医疗电子表单管理发展现状... 8
1.3研究目标... 9
1.4 研究内容... 10
1.5论文整体结构... 10
第二章相关技术研究... 12
2.1 AngularJS技术简述... 12
2.2 RESTful API +swager 13
2.3 Oauth2.0身份验证... 15
2.3.1 OAuth2.0. 15
2.3.2 协议流程... 15
2.3.3 Authorization Grant 16
2.4 Bootstrap可视化布局... 17
2.5 Data Migration. 19
2.6本章小结... 19
第三章需求分析... 20
3.1用户权限分析... 20
3.2 分系统需求分析... 21
3.2.1研究信息管理子系统... 21
3.2.2项目管理子系统... 22
3.2.3质量管理子系统... 23
3.2.4数据导出子系统... 24
3.2.5系统配置管理子系统... 25
3.3系统安全性需求分析... 26
3.3.1 身份认证技术实现... 26
3.3.2 基于角色的访问控制策略... 28
3.3.3 AES和RSA混合加密算法的设计与实现... 28
3.4本章小结... 30
第四章系统设计... 31
4.1设计的原则和目的... 31
4.2 系统应用架构设计... 32
4.3 系统总体流程设计... 35
4.3.1 数据录入流程... 35
4.3.2 数据字段导出流程... 35
4.3.3 数据删除流程... 36
4.4功能结构设计... 37
4.3.1 登录管理子系统... 37
4.3.2研究信息管理子系统... 40
4.3.3项目管理子系统... 42
4.3.4质量管理子系统... 42
4.3.5 数据导出子系统... 43
4.3.6系统配置管理子系统... 44
4.4 系统流程设计和E-R图设计... 46
4.5数据库设计... 46
4.5.1系统用户相关表... 46
4.5.2项目配置相关表... 46
4.5.3菜单操作权限相关表... 47
4.5.4表单部件配置相关表... 48
4.5.5表单规则相关表... 49
4.5.6案例数据相关表... 50
4.5.7质疑相关表... 51
4.5.8其他相关表... 51
4.3.9系统E-R图设计... 52
4.7 本章小结... 53
第五章 系统实现与测试... 54
5.1测试环境... 54
5.2 系统各子系统实现与测试... 54
5.2.1 系统登陆和注册子系统... 54
5.2.2 研究信息管理子系统... 55
5.2.3 项目管理子系统... 57
5.2.4 质量管理子系统... 59
5.2.5 数据导出子系统... 61
5.2.6 系统管理子系统... 62
5.3 胃癌核心信息数据库案例测试与研究... 67
5.3.1 案例实现... 67
5.3.2 结果研究... 67
第六章总结与展望... 68
6.1总结... 68
6.2展望... 68
主要参考文献... 70
摘要
临床数据由于存在数据结构复杂、数据量大等问题，使得临床科研很难有足够的数据作为支持，尤其是很多临床科研数据存在于单个医院，甚至是单个部门，这种数据孤岛现象使得临床科研工作的开展备受阻力，数据瓶颈问题已经成为阻碍临床科研进步的重点难题，亟待解决。
我国科研数据管理系统虽然较以往有了很大的发展，但当前数据管理系统大多数是为单一部门的使用而设计、实现的，缺少全局性的考虑，难以应用于复杂部门关系的领域，如果应用于医疗系统，则将会有很多工作需要人工去弥补完成，造成人力资源极大的浪费。且当前数据管理系统缺少监督机制，数据录入进度难以掌控，同时也缺少问题反馈机制，还需要人与人之间私下沟通解决，效率低下，也缺少成熟的平台去解决问题。所以目前的绝大多数数据管理系统难以应用于实际业务，其应用普及度、可扩展性、安全性等因素都需要进一步提高，且关于临床医疗数据管理的系统更是少见。基于这些考虑，本文开发一套可以应用于实际工作的临床科研数据管理系统用于管理临床领域医疗数据，以提高临床科研效率。
在应用现代软件工程理念和技术的基础上，通过对现代医疗领域的临床科研工作的实际需求进行深入分析，完成了临床科研数据管理系统的设计，构建了系统整体架构、各子系统功能模块和数据库表结构的详细设计，基于ASP技术实现了该系统的各项功能。最后基于Windows平台、IIS服务器、SQL Server 2008数据库系统等环境对系统进行运行测试，测试结果表明该系统实现了高效数据采集、数据存储、数据管理和数据分享医疗领域的科研数据且系统能够稳定运行。
关键词：科研数据管理系统；医疗系统；数据分享
Abstract
Because of the complex data structure and large amount of data, it is difficult for clinical research to have enough data to support it. Especially, many clinical research data exist in a single hospital or even a single department. This phenomenon of data islands makes the development of clinical research work very difficult. Data bottleneck has become a key problem that hinders the progress of clinical research. It needs to be solved urgently.
Although our country's scientific research data management system has made great progress compared with the past, most of the current data management systems are designed and implemented for the use of a single department, so lack of overall consideration, it is difficult to apply in the field of complex Department relations. If applied to medical systems, there will be a lot of work to be done manually, resulting in waste of human resources. At present, the data management system lacks supervision mechanism, data entry progress is difficult to control, and there is also a lack of problem feedback mechanism. It also needs private communication between people to solve problems. It is inefficient and lacks a mature platform to solve problems. Therefore, most of the current data management systems are difficult to be applied to actual business, and their application popularity, scalability, security and other factors need to be further improved, and the clinical medical data management system is rare. Based on these considerations, this paper develops a data management system for clinical scientific research that can be applied to practical work to manage medical data in clinical field, so as to improve the efficiency of clinical scientific research.
Based on the application of modern software engineering concepts and technologies, through in-depth analysis of the actual needs of clinical scientific research in modern medical field, the design of data management system for clinical scientific research has been completed. The overall structure of the system, the functional modules of each subsystem and the detailed design of database table structure have been constructed. The functions of the system have been realized based on ASP technology. Finally, the system is tested based on Windows platform, IIS server, SQL Server 2008 database system and other environments. The test results show that the system achieves efficient data acquisition, data storage, data management and data sharing in the field of medical research data, and the system can run stably.
Key words: scientific research data management system; medical system; data sharing
第一章绪论
1.1 选题背景及其意义
机器学习技术和大数据时代的来临使得大规模的数据的产生、管理、应用的时机和数据的用途越来越得到广泛关注。尤其是普遍为人所用的通信业务、社交网络、电商网络等也加速了数据的传播与产生[1]。大数据，这一新兴的领域也日渐成为社会中一项不可或缺的基础资源，其意义不仅体现在数据量的“大”上，更体现在数据内部所蕴含的信息资源。但随之而来的问题是数据的管理成为了一项令人棘手的问题，数据量级的增大带来了管理的难度、共享的需求度、传输的信道压力等等问题，临床科研领域同样面临着类似的问题，亟待解决[2]。
近年来，医疗信息化成为现代医院的一大趋势，这不仅体现在数字化的医疗信息管理，也体现在现代化的高效的数据管理能力[3]。但目前绝大多数医院的医疗数据仅仅局限于医院内部使用，甚至仅仅局限于科室内部使用，数据孤岛现象极为严重。这种医疗数据的信息孤岛现象体现出我国医院与医院之间、医院与管理部门之间的各自为战现象，也体现出我国医疗卫生现代化建设的症结所在[4]。2010年，原卫生部推出了“十二五”医疗卫生信息化建设规划，简称为3521工程，3表示建设国家、省、城市的3级卫生信息化平台，以此提高我国卫生服务的质量、医疗服务水平、新农村合作的医疗水平、基本药物制度和综合管理等五项内容，建立电子病历和健康档案数据库和网络；按照这个需求制定的实施方案将会产生及其巨大的数据量，其中一张普通的CT的大小可以达到150M，一张普通的基因序列记录的数据大小大约为750M，一张病人的病理图甚至可以达到5G的数据量，如果再考虑到人口基数和不同时间点进行的不同诊断，则数据量的积累将难以极速爆炸[6]。在数据采集阶段，医疗临床数据包含大量非结构化的病理数据和病人健康情况数据，如果不能采取合理的方法采集数据则会造成数据采集过程中存在错误数据的情况[7]；在数据分析阶段，如果海量数据仅仅存在于单一的医院、甚至是单个部门中，则会造成花费巨大力气采集的数据难以被最大化的使用。所以临床医疗数据采集、管理平台的建设刻不容缓，以使得临床医疗可以被标准化的采集、规范的管理和更广泛的共享[8]。
临床医疗将不是某一家医院或医院某一部门的专有资源，高效的实现海量、异构数据的采集、管理、存储和分享等方面将对临床科研的进步有很大帮助，也能促进临床数据更广泛的共享。海量的临床医疗数据也是临床科研开展的基础，如果没有数据支持，将无法开展科研工作，所以如何实现临床科研数据的有效管理成为了本文的研究重点。
1.2国内外研究现状
1.2.1 临床大数据管理系统发展现状
目前国内还没有关于临床科研数据管理的文献，临床科研数据管理系统的构建也更是处于国内空白，只有少数相关的内容能够借鉴。其中蔡佳慧等人[9]发现了我国卫生信息化建设的速度越来越快，医疗领域所接收的数据量越来越大、数据类型复杂，医疗领域已然进入了大数据时代。在分析现代医疗领域特点的基础上总结了现代医疗领域所面临的信息化建设的挑战和需求，并结合具体情况提出了可行的措施。周光华等人[10]在分析了现代医疗卫生领域特点的基础上判断了医疗卫生领域大数据时代的来临，在概述大数据时代各行业的情况的基础上综述了我国医疗卫生数据资源的分布情况和在医疗领域的应用情况，提出了当前大数据医疗所面临的重点和难点，并为行政部门提出了参考意见。林青等人[11]提出了智慧社区医疗系统的总体结构、系统组成以及软件功能。智慧社区医疗系统能够采集、查询、管理、统计社区医疗卫生数据并将数据进行云管理，实现社区医疗数据的云管理和互联网服务。殷焕炯[12]在分析了现代医疗信息化特点的基础上探索了大数据在现代医疗领域方面的应用现状。针对大数据的基本概念和医药研发、疾病诊断、卫生管理的特点进行分析和研究，为新时代大数据的应用方式、理论提供依据。盛芳菲等人[13]提出了一种基于Hadoop的智慧医疗数据存储和查询方法，能够实现结构化数据和非结构化数据的存储，提高了数据存储、管理的可靠性和扩展性，并优化了医疗图片数据的效率和存储方式，采用分布式的方式实现管理系统提高了数据访问的效率和数据分享的效果。Gary Cohen等人[14]将医疗数据管理系统部署到互联网中实现对病人医疗数据的管理，通过互联网远程获取数据的优势实现了对慢性病的长期监测，获取病人的病理数据，并实现对数据的分析为患者提供治疗意见。M Fuminori等人[15]提出了一种病人、医务人员和通信网络上的研究人员可以共享医疗数据的医疗数据管理系统，该系统能够存储病人治疗期间的医疗数据，并向患者公开医学信息、执行有效的远程诊断以及向医学研究提供医学数据等服务。Liu，Zhao等人[16]针对人工处理数据、人工开发接口生成工具等传统办法所面临的困境提出了一种基于XML文档的接口生成和数据访问的快速开发模型，并将其应用于医学临床数据管理系统的开发中。该模型包括两个部分：接口生成引擎和数据自动访问机制，使用抽象工厂模式来构造、应用面向对象语言的多态技术和反射技术进行实现，从而可以在各种数据库和应用平台之间快速切换，不仅节省60%的设计时间，也提高了系统的开发效率和可维护性。Karin Probst[17]提出了人力资源信息系统（HUMARIS），该系统是由国家癌症研究所研发的自动化医疗数据采集和管理系统。该系统的设计容量为每年处理、存储和检索多达1500例外科和尸检病例的临床和调查信息，提供诊断清单、病例摘要、库存、统计报告等内容。该系统的功能相对简单，但能够有效的采集和管理医学数据。
1.2.2医疗电子表单管理发展现状
我国经济的告诉发展使得国家、社会对临床科研的成果需求也更高，与此同时的投入的越来越多，医院的科研水平也作为核心竞争力显得日益突出。当前情况下的科研数据管理系统仍不普及，很多科研工作者仍然使用人工的方式进行数据采集、处理、分享和管理等[18-20]，有些使用诸如excel等半自动化的方式进行数据的管理和处理，这种数据管理方式的问题主要有：（1）数据属性复杂时，管理难度很大；（2）数据手工录入，容易出现认为错误；（3）难以维护，容易发生奔溃导致数据丢失；（4）效率地下，没有利用现代化的信息化手段。所以，临床科研数据管理系统的需求度越来越高，合理的利用现代化的智能手段进行数据的采集、管理、分享、维护等操作，不仅可以大幅提高数据管理效率，而且能降低人力成本的同时减少认为错误的发生，使临床科研数据的管理更加智能化、高效化和信息化。
目前，一些高校率先建立了科研信息管理系统用于科研信息的管理，网络上也有一些做好的数据管理系统，但对于临床科研领域的数据管理显得有些不足，主要是因为：（1）高校的科研信息管理系统大多数处于实验状态，实用性偏差，难以用于实际的工程应用；（2）互联网公开的数据管理系统功能通常较为简单，且可扩展性、安全性等要素缺少系统设计，考虑因素不足，在实际使用中难以稳定运行；（3）这些管理系统大多数是为单一部门的使用而设计、实现的，所以缺少全局性的考虑，难以应用于复杂部门关系的领域，如果应用于医疗系统，则将会有很多工作需要人工去弥补完成，造成人力资源的浪费；（4）缺少监督机制，数据录入进度难以掌控，同时也缺少问题反馈机制，还需要人与人之间私下沟通解决，效率低下，也缺少成熟的平台去解决问题；（5）系统中缺少对数据格式的统一定义，在数据传输时需要数据格式转换或数据属性的抛弃以适合其他系统，导致数据完整性受到破坏，也难以普及系统。
通过上述总结可以看出，在当前情况下建构高效的临床科研数据管理系统是十分必要且十分紧急的任务，高效、准确的数据管理和完备的系统管理对于提高当前临床科研水平将有巨大帮助。当前情况下，科研数据管理系统日益朝着大众化、可用化、智能化的方向发展，主要的原因是计算机硬件设备性能的提高和硬件价格的降低，使得个人、单个团体部署个人的网络应用系统成为可能，这些客观条件使得管理系统如雨后春笋一般大量出现，逐渐取代人工。由于近年来网络成本的降低、性能的提高，使得管理系统的开发也从传统的C/S结构过度到了B/S架构，甚至是基于B/S的分布式架构、云架构等结构，大幅提高了管理系统的性能和安全性。
现代的基于互联网的B/S架构的数据管理系统的访问结构通常是浏览器/服务器的结构，主要是在浏览器端输入、发出请求，在服务器端实现系统的功能并返回处理结果到浏览器端，浏览器解析出服务器返回的结果并输出到屏幕上供用户使用[21]。这种访问方式需要在系统的服务器端运营网络应用成功、数据库系统等应用，而客户端只需要普通的浏览器即可完成服务，与传统的管理系统相比对客户端性能的要求更低，其访问者不受地域、时间、平台的限制，能够实现任意地点、任意时间的对服务器的访问以获取所需的资源。且服务器端的维护成本、维护难度也较C/S结构更容易，也最大限度的共享了网络资源。目前，国内大多数数据管理系统都是基于局域网而建设的，基于互联网的数据管理系统仍然处于起步阶段，亟待解决[22]。
通过上述论述可以发现，我国科研数据管理系统虽然较以往有了很大的发展，但绝大多数产品难以应用于实际业务，其应用普及度、可扩展性、安全性等因素都需要进一步提高。基于这些考虑，本文开发一套可以应用于实际工作的临床科研数据管理系统用于管理临床领域医疗数据，以提高临床科研效率。
1.3研究目标
我国经济总量已经跃居世界第二且发展势头不可阻挡，全面小康化也马上达到，在此阶段下，普通人对医疗的关心和需要也越来越高，如何提高现有医疗水平称为一项重点研究内容，而实现这一目标的有效手段就提高临床医疗科研水平，而海量、可用的临床数据的保证是科研高效开展的前提，所以临床医疗数据的采集、管理和分析成为了各医疗机构普遍关心的议题。
正是基于这样的考虑和需求，很多医疗机构都认识到了医疗数据对于医院未来发展的用处，也意识到了临床数据在医院管理、医疗水平提高、临床科研水平提高等方面所蕴含的高价值。很多医院都成立了数据管理平台并建构了数据管理系统，但普遍仅仅做了最基本的工作，仅仅收集了最基础的数据，没有系统的收集医疗领域的数据。
本文考虑到这些需求，将构建一套能高效管理海量的、多样化、异构的医疗数据管理系统为研究目标，以实现临床医疗数据的高效管理、提取和分享。通过对存储的海量医疗数据的分析，能够分析出病人身体状况与病症之间的关系、病症之间的关系、为病人自动推荐治疗方案或缓解策略、系统性的评估个人的身体状况等结果，通过临床科研能够实现这些分析结果或服务，以此提高患者的健康状况，为全民的健康状况所服务。因此，本论文研究的海量异构临床科研数据管理系统在提高全民身体将康水平、提高医疗科研水平等方面具有积极地、重要作用。
1.4 研究内容
通过分析医疗领域的潜在需求、挖掘领域现存的问题，并利用现代化的软件工程技术和数据管理技术，针对临床科研数据管理存在的特点和难点进行着手，构架了用于管理海量、异构的临床科研数据的管理系统。主要的工作内容为如下所述。
1、通过对国内外相关研究项目的论述和分析，阐明了本文的研究背景和研究意义；
2、研究并学习了ASP技术、SQL Server 2008技术、UML技术等内容，并将这些技术用于构建临床科研数据管理系统；
3、针对医疗领域和科研领域的特点对系统各角色用户的需求进行深入挖掘，分析出了各角色用户最需要的功能；
4、利用现代化的软件工程技术设计并实现了临床科研数据管理系统，并搭建环境进行测试。
1.5论文整体结构
第一章是总体介绍本文研究的背景和意义，阐述了为什么开展此项工作，并结合国内外的研究现状说明了本文的研究目标和研究内容。
第二章介绍了本系统设计与实现过程中需要的技术，首先说明了ASP技术的原理、特点、数据访问控制模型和系统应用的数据库系统，之后介绍所用集成开发环境Visual Studio 2010和软件工程建模工具UML，最后介绍了构建数据仓库的理念。
第三章为系统的需求分析内容。首先介绍了系统的三种类型的角色和每种角色的实际需求，之后对系统的整体结构和各子系统的结构进行了详细说明，最后对系统的非功能性需求进行了阐述。
第四章为系统设计部分。首先阐述了系统的设计原则、目的和系统整体架构，之后从结构图、流程图和时序图等方面对系统给的各子系统的设计进行了详细说明，后续对系统流程设计和E-R图设计进行描述，最后对系统的数据库各子系统的表的结构、字段等内容进行说明。
第五章为系统实现与测试章节。首先说明了系统的测试环境，之后对各子系统的功能模块的实现结果和测试结果进行说明。
第六章为总结与展望章节，总结了本文的工作内容并指出了本文工作的不足之处，也指明了下一阶段所需努力的方向。
第二章相关技术研究
2.1 AngularJS技术简述
AngularJS于2009年由Misko Hevery等人创建，后为Google所收购。AngularJS是一个JavaScript框架，可以扩展应用程序中的HTML标签，从而能够在Web应用程序中通过HTML标签来声明动态内容。AngularJS有很多特性，最为核心的是MVVM开发模式、模块化、自动化双向数据绑定技术、语义化标签、依赖注入、测试驱动开发等等。通过数据与模板的双向绑定，开发人员可以从繁重的DOM操作中抽出身来，可更加专注于业务逻辑的开发。AngularJS是以一个JavaScript文件形式发布的，可直接通过<script>标签添加到网页中。
AngularJS通过指令方式扩展了HTML，提供了组件化开发嘲。Angular的内置HTML指令也可以提供绑定数据的控件指令，提高前端数据处理能力，从而提高前端开发效率。在传统的web应用系统开发过程中，采用HTML来进行前端页面呈现，但是在如今对网页和应用系统如此高要求的情况下，传统的前端开发模式已经不能够满足要求，通常会采用类库和框架来解决静态网页技术在构建动态网页上的不足。类库通常是一些函数的集合，程序开发人员可以将自己的开发工作保存在一个类库中进行分享，供大家去使用，从而避免了大量重复的代码出现，需要相应的功能和代码只需要调用类库即可，如常用的jQuery库等。框架是一些已经实现了的非常常用的重复性的业务逻辑，用来将程序员从大量重复性的工作中解放出来，如AngularJS等一。
AugularJS是基于HTML基础上扩展的开发工具，目的是希望通过扩展HTML标签来构建动态的web应用，因此，AngularJS主要运用和创新的技术点：一是数据双向绑定技术，二是依赖注入[451。因为AngularJS前端开发框架对于数据的处理具有高效性，可以将数据和视图分离开来，提供一个更高层次的抽象来将应用系统的开发进行简化，所以对于CRUD(增加、查询、更新、删除)应用系统，即管理信息系统的前端页面更加适合，但是对于操作很频繁，应用复杂的例如游戏或者图像处理类的应用就不合适了。
AngularJS是一个新出现的强大客户端技术，它利用并且扩展HTML，CSS和javascfipt，弥补了它们的一些非常明显的不足[46]。因此可以使用扩展的HTML标签来实现一些动态内容。AngularJS有五个最重要的功能和特性：数据双向绑定，模板化，MVVM开发模式，服务和依赖注入机制和指令。
(1)数据双向绑定：这是AngularJS最突出、最实用的特性，可以减少大量数据同步代码的编写，从而节约开发时间，使开发人专注于应用。传统页面开发过程中，当Model发生变化，开发人员需要手动处理DOM元素，并将变化的Model发送到相应的视图中，视图中发生变化时，也需要开发人员通过DOM操作将变化的属性获取出来，这两个过程开发人员都需要频繁的进行解析和处理，增大了工作量。数据双向绑定机制，同步了DOM和Model，尤其当用户交互比较多，数据操作多的时候，更加反应出其优点。
(2)模板：在AngularJS中一个HTML文件就是一个模板。HTML模板将会被浏览器解析到DOM中，DOM会成为AngularJS编译器的输入，AngularJS将会遍历DOM模板来生成一些dkective(指令)，所有的指令都负责针对view来设置数据绑定。
(3)MVVM开发模式：通过上文对MVVM模式的分析，MVVM以Model为中心，让View层和Model层进一步分离解耦，各层次功能明确，各司其职，减少了前端开发工作量，提高了开发效率。
(4)依赖注入机制：AngularJS中提供了大量的服务来提供某个特定的功能。AngularJS中就是可以在控制器中请求所需要的服务作为参数，AngularJS就可以侦测到相应的服务提供给开发人员。依赖注入机制允许开发人员可以请求需要的依赖，而不是去寻找它们。
(5)指令：在AngularJS中可以创建自定义的标签，用来装饰元素或者操作DOM属性。这些指令可以作为标签、属性、注释和类名使用。该前端框架中提供了一些自定义制定可以供框架使用者使用。
AngularJS版本有AngularJSl、AngularJS2、AngularJS4三个大版本。前期经历过了AngularJS 1．0—1．5版本，于2014年10月份发布了AngularJS2．0版本，但是和Angularl．x相比，发生了很多颠覆性的变化。也可以理解为1．X与2．0完全是不同的框架。对比于1．X版本，AngularJS2．0版本不再对DOM对象进行封装，开发者可以直接对DOM对象进行操作。但AngularJS2．0版本将专注于移动应用的开发，并且目前AngularJS2．0版本的开发者还在不断更新，所以主要基于AngularJSl．3进行前端框架的设计与研究中研究的是AngularJSl．3版本。
2.2 RESTful API +swager
REST(Representational State Transfer，表现层状态转化）将互联网上的一切实体定义为资源，每一个资源至少对应一个URI，每个URI代表一类操作，使得Web资源、服务具有可寻址性。此外，客户端与服务器间的交互是无状态的，而通过标准的HTTP方法（GET、PUT、POST、DELETE等）实现网络资源的处理，提供幂等性（POST 除外）的资源操作方法 。 设计REST风格的API需要遵循以下原则：
１）唯一专有名词表示原则
在REST风格的URI设计中，资源是一个实体，统一使用名词表示，且该名词应保证在本 API系统中的唯一性。 此外，名词应选择该资源在本API应用领域的专有名词。
２）分层独立性原则
每一个符合REST风格的API都应该是分层独立的，分层是指每个API都是内部封装的，其交互范围限制在单个层。 独立性包含两个方面， 首先是功能的独立性，即一个API提供的功能尽量不依赖其他API的执行结果，如果必须依赖其他API，则依赖API应尽量作为调用API的一个模块，封装于API内部。 其次是部署的独立性，如果该API具有长期使用、需要更新和调用量大等特点，则该API应尽量部署到专有域名和服务器上。
３）安全性原则
RESTful API的数据安全性原则是指调用者在执行对数据库的操作指令时，系统检测该数据库是否提供该操作，对于风险性操作执行操作限制、备份保护、日志记录、
风险提示等。
４）简单化原则
简单化原则是指构造的API。URI应尽量简短，去除冗余信息。 在构造URI时，目录深度尽量不要超过2级，对于同一资源的多个操作，操作尽量放在参数里。
５）无状态原则
无状态原则是指服务器端不保存客户端请求的状态（如session、cookie等），即客户端每次发起的请求是崭新的、独立的。
６）版本兼容原则
API的更新应尽量保持与原版本的兼容 ，并以不同的版本标识， 版本号应放入URI，易于标识和调用。
７ ） 执行结果一致性原则
该原则针对API返回结果的信息一致性进行设计，即服务器执行API后的返回数据中包含请求参数、请求地址、返回状态码、返回信息、成功信息、失败信息和执行结果等信息，便于调用者自检，确定执行参数和返回结果的正确性。
８）缓存原则
REST使用缓存设计原则，执行频率较高的API应缓存以提升加载速度，缓存分为临时缓存和长久缓存两个部分，对于某一时刻调用较高的API缓存至内存中，对于长期调用频率较高的API缓存至硬盘。
2.3 Oauth2.0身份验证
2.3.1 OAuth2.0
OAuth2.0 协议在实现认证授权的过程中会涉及到几个“实体”，它们在此过程中扮演者不同的角色。在 OAuth2.0 协议中定义了以下四种角色，具体描述如下：
（1）资源拥有者(Resource Owner，简称“RO”) ：能够授权保护资源的访问权限的实体。如果它是一个“人”，一般就是指最终用户。
（2）客户端( Client) ：在获得授权后，能代表用户请求访问受保护数据信息的第三方应用。可以是桌面应用、Web 应用或者其设备中执行的程序。
（3）授权服务器( Authorization Server，简称“AS”)：检测用户授权信息无误后，发放访问令牌给客户端的服务器。
（4）资源服务器( Resource Server，简称“RS”) ：用户托管受保护数据信息的服务器。能够接受客户端携带访问令牌发起的资源访问申请，并且做出响应。
2.3.2 协议流程
虽然，OAuth2.0 协议具体的授权流程会因所采用的授权类型不同而有所变化，但整个授权流程从整体而言均为客户端应用（client）与资源拥有者（RO）、授权服务器（AS）以及资源服务器（RS）进行的 3 步交互实现，分三个阶段。各角色之间通信抽象流程，如图 2.8 所示，这被称为经典的“Three-Legged OAuth。
图 2.8 抽象的协议流程
OAuth2.0 认证授权的具体步骤大致如下：
1. 阶段 1 获取用户授权
（A）客户端向用户（RO）请求授权。该请求可以通过向用户直接发起（如图所示），也可以通过 AS 作为中介来间接地发起；
（B）用户收到授权请求后，决定是“同意”授权又或者是“拒绝”响应。若同意授权，会向客户端返回一个授权许可，其代表用户的授权凭据；
2. 阶段 2 发放访问令牌
（C）当客户端收到用户的授权响应后，其携带授权信息向 AS 发出申请Access Token 的请求；
（D） AS 对客户端进行认证并校验授权许可，验证通过后发放 Access Token；
3. 阶段 3 访问受保护资源
（E）当获得 Access Token 以后，客户端携带 Access Token 向 RS 发起受保资源的申请；
（F） 认证 Access Token 确认通过后，向客户端开放用户许可范围内的数据信息。至此，整个授权流程结束。
2.3.3 Authorization Grant
OAuth2.0 中的授权许可（Authorization Grant）代表一种中间凭证，它代表了 RO 针对客户端应用获取目标资源的授权。OAuth2.0 定义了如下 4 种Authorization Grant，体现了授权采用的方式以及 Access Token 的获取机制。
① 授权码授权( Authorization Code Grant) ：该模式要求：在获取用于向 RS发起访问受保护数据信息申请时携带的 Access Token 之前，需要先向 AS 获得一个与用户授权信息有关的授权码。
② 隐式授权( Implicit Grant)：它代表一种“隐式”授权方式，即客户端在取得RO 授权的情况下直接获取 Access Token，而不是间接地利用获取到的授权码来取得 Access Token。
③ 资源所有者密码凭证授权( Resource Owner Password Credentials Grant)：采用 RO 的凭证（如：用户名和密码）直接作为获取 Access Token 的授权方式。该方式要求用户对客户端足够信任。
④ 客户端凭证授权( Client Credentials Grant)：客户端应用自身的凭证直接作为它用于获取 Access Token 的授权类型。这种类型的授权方式适用于客户端应用获取属于自己的资源，应用本身即为资源拥有者。
2.4 Bootstrap可视化布局
Bootstrap是一个自由和开源的工具集合，用于创建网站和web应用程序。它包含基于HT地和CSS的设计模板、表格、按钮、导航和其他的界面组件，就像可选的JavaScript夸张等。Bootstrap框架的目的是旨在简化web开发。
Bootstrap是一种前段开发框架、用于用户的接口，不同于在驻留到后台服务器的代码。它也是一个web应用框架，就是为了支持动态网站和web应用程序的软件框架。
Bootstrap 是目前比较流行的前端框架，最初是由 Twitter 的两位员工 MarkOtto 和 Jacob Thornton 一起开发设计的，自推出后就备受欢迎。Bootstrap 最大的优点也是备受推崇的原因是可以方便的实现响应式布局，能使网站页面在不同设备终端上完美展现。Bootstrap 是在 HTML、CSS、JavaScript 的基础上开发的。它为用户提供一套通俗易懂的 Web 设计工具包，开发人员可以使用它方便快速地设计出简洁漂亮的响应式页面，省去了开发人员为不同设备终端设计样式的烦恼，也在一定程度上减少了网页的开发与维护成本。使用 Bootstrap 设计的界面比较和谐、简洁大方和一致，可以提高用户体验。
Bootstrap 具有以下特性：
（1）组件部分：Bootstrap 包含丰富多样的组件，比如按钮组、导航条、字体图标、进度条、排版、下拉菜单等，这些模块化的组件也便于修改。
（2）预定义样式表：Bootstrap 中预定义样式表对页面字号和字体具有统一规定，可以使界面看起来更一致，这些样式表也可按照开发人员的意愿进行修改。
（3）响应式栅格系统：是在网格系统的基础上发展起来的。网格系统在日常生活中应用广泛，比如应用到平面设计中可以使应用的设计更简单、美观。栅格系统可以随着屏幕或者窗口大小的改变，自动分为最多 12 列，而不会表现出跟网格系统—960 栅格系统分为宽度固定的列的行为一样。这时 Bootstrap 响应式布局的优点就被充分体现出来，它可以根据不同情况以合适的方式使网页展示出来。
（4）jQuery 插件：包括滚动条、弹出框、模态框、警告框等，也可以帮助开发人员设计出精致的具有动画和其它交互的效果，而且这些插件也可按需修改。
(5)框架代码
Bootstrap官网上，提供了具体的框架代码，开发网站时，并不需要弄清框架具体的实现，只需直接使用Bootstrap官网上的组件、样式，也可以对Bootstrap中的所有的CSS变量进行修改，根据自己的需求修改框架中的代码，实现自己网站页面。
(6)一个框架、多种设备
网站基于Bootstrap框架，能够适应各种屏幕的大小和各种规格的分辨率，不需要复杂的编写便可以快速应用到不同的设备。不仅支持主流的浏览器的最新版本，而且充分贯彻了移动先行的宗旨，全面支持移动平台的开发
(7)组件丰富
Bootstrap中包含了很多直接可以使用可以直接使用的文本框、下拉菜单、表单等，并可以较为简便的开发一个响应式网站。
(8)代码简洁
Bootstrap的代码简洁、易于修改，非前端开发人员也可以使用。Bootstrap提供多种帮助使用者学习并利用资源的方法，每一种方法针对不同的水平的开发人员和不同类型的网站，本文主要使用包含了编译并压缩好后的CSS、JavaScript的Bootstrap框架，其中，下载压缩包到本地后，然后按照自己应用的需要解压到相应的目录下，便可以看到以下的目录结构：CSS文件下包含bootstrap．CSS、bootstrap．min．CSS、bootstrap．廿1eme．CSS等文件，jS下包含bootstrap．js、bootstrap．min．js等文件。在具体的项目中，可以根据情况，任意使用上述文件，即不同的排版的网站可以引入不同的文件，实现想要达到的效果，Bootstrap官网展示了目录的文件结构，其中包含编译好的CSS和JS(bootstrap．木)文件，还有经过压缩的CSS和JS(bootstrap．rain．*)文件。
2.5 Data Migration
2.6本章小结
本章重点阐述了医疗领域临床科研数据管理系统的构建技术，其中包括ASP技术原理、特点和数据访问控制模型，SQL Server 2008数据库系统，Visual Studio 2010软件系统开发集成环境，UML建模语言等，分别从这些技术和思想的历史发展、技术特点等内容进行详细说明。
第三章需求分析
3.1用户权限分析
本系统的角色共分为八种：（1）访客，能够访问网络系统的开放页面；（2）普通用户，能够访问权限内的项目数据；（3）中心管理员，主要负责分配各中心的权限；（4）项目管理员，主要负责管理项目内的用户；（5）逻辑审核人员，审核数据是否符合逻辑；（6）SDV审核人员，对数据进行SDV审查；（7）人工审核人员，对数据进行最后的审查；（8）系统管理员，系统管理员主要负责系统的日常维护、系统升级、项目分组、项目表单设计等内容。如表3-1所示，为系统的各种角色具体的权限。
表3-1临床科研数据管理系统角色功能分析
| 编号 |
角色名 |
角色描述 |
| 1 |
访客 |
访客角色能够访问系统的一些开放式页面，例如研究中的项目概况展示页面等。 |
| 2 |
普通用户 |
普通用户是数据管理系统的主要用户群体，项目管理员能够授予普通用户对项目的访问、操作等权限，普通用户在被授予对项目的访问、操作等权限后能够实现诸如数据查看、数据录入等操作。 |
| 3 |
中心管理员 |
中心管理员负责管理研究中心对各信息数据库的操作的权限，管理研究中心能够访问、录入、管理哪些项目的数据。 |
| 4 |
项目管理员 |
项目管理员隶属于研究中心，在明确了研究中心所拥有的项目操作权限后，项目管理员将具体项目的操作权限分配至普通用户，管理哪些用户能够对本研究中心所管理项目进行访问等操作。 |
| 5 |
逻辑审核人员 |
系统数据在录入时采用三级审核机制以确保录入系统的数据的正确性，逻辑审核人员是三级审核机制的第一级审核机制，在普通用户录入数据后系统会自动进行逻辑审查，如果系统判定普通用户录入的数据存在逻辑问题，则会停止数据流转到下一级，并由逻辑审核人员判定由用户重新录入数据还是数据不存在逻辑问题而进行下一级流转。 |
| 6 |
SDV审核人员 |
SDV审核人员处于三级审核机制的第二层，对经过逻辑审核无问题的数据进行SDV审核，如果无问题则流转到下一级进行最后一步的人工审核，否则将数据返回，用户修改后重新提交进行审核。 |
| 7 |
人工审核人员 |
人工审核人员处于三级审核机制的最后一层，通常采用第三方进行数据的人工审查，实现对数据正确性的最后判定，如果判定无问题则会将数据最终录入到系统中，否则返回给用户进行修改并重新提交。 |
| 8 |
系统管理员 |
系统管理员为该系统的超级管理员，主要负责系统的日常维护和系统的各项配置，主要包括项目组的管理、数据部件信息的管理、表单的设计及管理、数据分类管理、机构信息的管理、用户管理等内容。 |
3.2 分系统需求分析
临床数据管理系统主要负责存储、查询、管理临床医疗数据以供科研使用，临床数据管理系统按照功能和实际业务可以将整体系统分为七个子系统，即：登录管理子系统、研究信息管理子系统、项目管理子系统、质量管理子系统、数据导出子系统、统计分析子系统和系统配置管理子系统，下面结合用例如对各子系统进行详细描述。
3.2.1研究信息管理子系统
研究信息管理子系统主要实现研究信息的展示、研究数据的查询、数据录入进度展示与查询、问题反馈的展示。研究信息管理子系统中最重要的功能模块是研究数据管理模块，其中研究数据管理模块能够通过键入病人姓名查询该病人的病例数据，也能够通过键入的病人的姓名进行病人病例数据输入或修改。不同的科研项目数据库拥有不同的数据类型，例如胃癌核心信息数据库中的数据清单包括九章：（1）基本信息；（2）基线评估；（3）肿瘤学评估；（4）手术信息；（5）术后恢复；（6）系统治疗；（7）放射治疗；（8）介入治疗；（9）随访信息。每页数据清单都有详细的内容需要填写，例如胃癌核心信息数据库中的基线评估清单中需要填写肿瘤位置、肿瘤浸润深度、淋巴结转移、远处转移、胃癌所致合并症等内容。
研究信息管理子系统包括如下几个重要的功能：项目选择、项目概况展示、项目概况查询、研究数据查询、研究数据管理、数据录入进度管理、数据录入进度查询、反馈问题的管理等功能。研究信息管理子系统的用例图如图3.2所示。
图3.2 研究信息管理子系统用例图
3.2.2项目管理子系统
项目管理子系统主要实现了研究项目的管理与维护，例如项目管理员可以管理哪些用户获得了该项目的授权、能够主动邀请用户参与该项目的管理等内容。项目管理子系统还实现了部件信息提示对应的功能、反馈问题的回复功能以及规则设置的功能，用户可以自定义规则。
项目管理子系统包括如下几个重要的功能：新建研究中心、编辑研究中心内容、研究中心的授权用户管理、研究中心的用户邀请、项目概况的管理、编辑部件提示信息、搜索部件提示信息、删除部件提示信息、问题反馈管理、规划设置管理等功能。项目管理子系统的用例图如图3.3所示。
图3.3研究信息管理子系统用例图
3.2.3质量管理子系统
质量管理子系统主要负责检查录入数据的结构正确性、数据完整性等内容，以决定是保存数据到数据库中还是需要对数据进行修订后再保存到数据库中。质量管理子系统的用例图如图3.4所示。
图3-4质量管理子系统用例图
3.2.4数据导出子系统
数据导出子系统的最主要功能是能够导出自定义格式的数据到本地，以供后续科研实验使用。在进入所选数据库后进入数据导出子系统，可以自定义所需导出的数据字段，例如基本信息 Patient Demography：Name；Sex；ID_National；Nationality；Race；基线评估 Baseline：Date_FirstD；Date_ComfirmedD；Age；His_Cancer；His_Familycancer；His_FamilyGC；肿瘤学评估 Cancer Identification：Location_Tumor；Size_Tumor_Patho；Number_Tumor等数据字段。在配置好导出字段后点击“导出”按钮即可导出所需要的数据。
数据导出子系统包括如下几个重要的功能：新建数据导出、导出字段查看、导出字段编辑、数据导出、编辑导出的数据等功能。数据导出子系统的用例图如图3.5 所示。
图3.5 数据导出子系统用例图
3.2.5系统配置管理子系统
系统配置管理子系统包含了两个部分的功能：项目的配置与管理和系统用户的管理。其中项目的配置与管理的项目信息功能实现了编辑项目信息；项目分组功能实现了项目的分组管理；项目数据字段的配置实现了项目所需要填写的数据字段，例如临床科研数据管理系统中的胃癌核心信息数据库的随访信息的“患者状态”部件，配置的部件代码为Condition_Followup，部件类型为单选；项目配置还实现了诸如表单配置等功能。在系统用户的管理功能模块中包括了机构信息的管理和用户信息管理，其中机构信息管理主要包括了项目信息编辑、可访问用户的授权、机构的项目授权，用户信息管理包括用户信息的编辑、重置密码等功能。
系统配置管理子系统包括如下几个重要的功能：项目组管理、项目组信息管理、数据配置管理、表单配置管理、数据配置管理、数据分类管理、帮助解答管理、机构信息管理、用户管理等功能。数据导出子系统的用例图如图3.6所示。
图3.6 数据导出子系统用例图
3.3系统安全性需求分析
本系统中存储的数据均为病人的临床数据，对于个人而言属于极为隐私的数据，一旦发生数据泄漏问题则后果难以估量。所以，数据管理系统的保密性和安全性要求很高，现主要从身份认证技术实现、基于角色的访问控制策略（你的提纲是第三方通信、验证，但我不知道你具体实现，没法写，写这个标题可以吗？）、数据加密存储与传输三个方面对系统的保密性和安全性进行论述。
3.3.1 身份认证技术实现
本文采用Web Service作为服务接口，结合XML和SOAP技术，通过SOAP消息中封装令牌和Access Token授权口令，构件身份和服务认证的统一身份认证系统。通过使用基于公钥机制的SSL/TLS认证方式来保证密钥分发过程中数据的完整性和秘密性。同时，在认证服务器和用户端、应用服务器和认证服务器端都使用SSL／TLS方式进行密码交互。通过基于Web服务的ESB应用模型、WebLogic应用服务器、OpenSAML库、Apache提供的OAuth开放源码库以及JavaEE开发平台对基于OAuth 2．0的单点登录系统进行了实现，通过sAMLAu—thFiher控制页面加入单点登录。同时将APP信息、用户和APP之间的授权关系、SAML令牌、AccessToken等信息存储在数据库表中，应用系统信息管理数据库表字段如表1所示。
表 1 应用系统信息管理数据库表字段
| 字段 |
说明 |
| appid |
Client_id |
| appsecret |
Client_secret |
| appname |
应用名称 |
| appowner |
应用的所有者 |
| owneremail |
应用拥有者的email |
| appdescribe |
应用描述 |
| status |
应用是否通过审核 |
| callbackurl |
调回的url |
| addtime |
添加时间 |
统一身份认证平台交互流程如图*所示，具体流程如下：①由客户端携带客户端凭证(如客户端证书等)调用SAMIRequest(统一身份认证服务)生成携带SAML令牌的sOAP请求；②认证服务器根据用户请求与用户信息，调用SAMLPOSTProfile类的prepare方法生成相应的SAMLResponse，通过该SAMLResponse生成相应SAM—LAssertion并进行签名；③客户端转发携带SAML令牌的SOAP消息后向应用服务器请求资源；④应用服务器将该SOAP消息转发到统一身份认证平台，调用Verify服务验证令牌有效性；⑤验证通过后，由统一身份认证平台调用统一授权服务颁发给用户一个访问该应用资源的AccessToken，包括用户所在组别等信息；⑥由应用服务器根据通过认证用户所在的组别为用户提供不同的资源。
图 * 统一身份认证平台交互流程
3.3.2 基于角色的访问控制策略
3.3.3 AES和RSA混合加密算法的设计与实现
在传递数据的时候，使用AES算法加密传输数据，同时使用RSA算法加密传送AES密钥，结合两种加密算法各自的特点，发挥优点，避免缺点，从而得到了一种新的混合数据加密技术。在相同条件下，AES加密速度比解密速度快，RSA解密比加密慢很多；而无论加密还是解密，RSA都比AES慢很多，由于RSA进行的是大数计算，无论是软件还是硬件实现，速度一直是一个较明显的缺陷。
AES加密算法的优点：能够直接用硬件去实现，加密的程度较高，速度较快，对于加密大量数据非常的适用。缺点：加、解密过程使用同一个密匙进行，对于密匙的管理和保护较难。
RSA加密算法的优点：具有公钥和私钥两个不同的密钥，公钥用于加密数据，私钥用于解密数据，难于破解；并且不需要通过网络传送保密的密钥。缺点：加密的速度比较慢。
从密钥管理、运算速度、签名认证和安全性能等方面比较AES和RSA两种加密算法：（1）密钥管理：RSA算法是非对称加密技术，利用公钥进行加密，即使是和不同的对象之间进行通信，关键还是要保管好自己的解密私钥，所以在使用该算法时，加密密钥更换是很容易实现的；而AES算法是对称加密技术，在和不同的对象进行通信的时候，AES需要产生和保管不同的密钥，所以密钥的更换较难实现。（2）运算速度：AES算法的运算速度要比RSA算法的运算速度快。这是因为AES算法的密钥长度最大也就256位，利用硬件或软件都能够实现；而RSA算法，至少需要1024位才能确保安全，而在加、解密过程中会需要很多的运算，因此RSA算法的运算速度肯定要比AES算法要慢。（3）签名认证：RSA属于非对称密码体制，利用RSA算法可以进行数字签名和身份认证操作；AES不能实现数字签名和身份认证，这是由于AES属于对称密码体制。（4）安全性能：目前还没有能够完全破译AES和RSA的良好方法，所以两者的安全性都很好。从以上4个方面的比较可以知道，对于大量的数据文件，由于RSA算法加密速度较慢，所以并不合适；而AES算法虽然加密速度很快，但是如何在开放的网络传输环境中保管好AES密钥，成为使用AES加密首先要考虑的问题。
因此，可以在传递数据的时候，使用AES算法加密传输数据，同时使用RSA算法加密传送AES密钥，结合两种加密算法各自的特点，发挥优点，避免缺点，从而得到了一种新的混合数据加密技术。
AES和RSA混合加密算法加解密过程，如图*所示。
图* AES和RSA混合加密算法实现流程
接收方：（1）生成1024位的RSA密匙对。（2）向发送方传递RSA公匙。发送方：（1）接收接收方发过来的RSA公匙密码；（2）随机生成AES密匙；（3）用AES密匙加密数据，用RSA公匙加密AES密匙；（4）将加密后的AES密匙写入数据文件的头部，加密后的数据写入数据文件的尾部；（5）将数据文件发送给接收方。
接收方：（1）接收发送方发过来的数据文件，并利用自己的RSA私钥解密AES密匙。（2）利用解密后的AES密匙解密数据文件。JAVA语言的安全性非常高，通过“SunJCF”提供了对各种加密技术的支持，包括DES，3DES，AES，RSA等数据加密技术。JAVA当中的常用数据加密类有：KeyGenerator类用于获得各类对称加密技术的密匙；KeyPairGenerator类用于获得非对称加密技术的密匙；Cipher类是ASP加密的主要类，用于按一定的算法对数据进行加密、解密、包装和返包装。而AES和RSA混合加密算法利用ASP语言可以较容易实现。
3.4本章小结
本章主要说明了临床科研数据管理系统的需求分析，首先说明了系统的三种角色并对各种角色的功能进行详细说明；之后对系统的六个子系统进行需求需求分析，并结合用例图对系统的子系统进行需求分析；最后对系统的五项非功能的需求分析进行详细的阐述，在响应时长、可行性等方面对系统进行分析。
第四章系统设计
4.1设计的原则和目的
临床科研数据管理系统主要存储着病人的病例数据以用于科研实验，数据的种类繁多且数据量可能会达到PB级，且对海量的数据进行处理的实时性要求很高，这些特点和要求给临床科研数据管理系统的实现带来了不小的挑战。例如在系统的响应时长和服务的并发处理方面，在大规模数据量方面实现海量并发请求的处理的实时反馈，对系统的性能、响应能力和高并发的支持能力都提出了很高的要求。医疗数据的特点是数据量大、数据间的关联性强、不同用户对数据字段请求的也不一样，这些对系统的数据管理模型提出了很高的要求。而且，系统存着的海量数据的查询、分析、提取等任务的类别很多，都为系统的性能进一步提出了要求。另外还有如下几个设计的原则和目的。
1、采用结构化、平台化的柔性开发方法，以保证系统后续的可持续发展
临床科研数据管理系统采用是B/S架构进行开发，设计模式上采用MVC模式、模块化设计思想，以持续性的适应医疗系统和科研系统的变化情况，为后续的科研工作提供数据保障。
（1）架构化的数据管理平台
临床科研数据管理系统在设计时考虑到临床科研数据管理的一体性问题，对系统的架构进行进行设计，包括：用户信息与权限的管理、项目的纵向管理、项目的横向管理、系统管理等内容。
（2）平台化科研数据管理工具
为了满足临床科研实验的数据需求和管理的要求，实际了临床科研数据管理系统以完成海量数据的管理工作，系统设计了不同的模块完成整体功能，系统的用户只需通过简单的培训就可以基本掌握该系统的使用。
2、针对临床科研的特点设计并开发该系统
针对临床科研工作的特点对本系统进行设计、规划和实现，对科研科研数据进行全方位、立体化的管理，并提高数据获取的效率和准确性。
3、系统的技术特点
该系统采用先进的软件开发方法和信息化策略，通过B/S架构实现了临床科研数据管理系统的搭建工作，通过架构华、平台化的方法实现了系统整体框架和各功能模块的设计与实现，既实现了现有功能需求，也为后续扩展留下了接口。
4.2 系统应用架构设计
临床科研数据管理系统设计到海量医疗数据的储存、提取与管理，需要优化海量数据的存储结构，才能提高数据的提取、管理效率，为临床医疗的科研工作提供数据支持，为了满足这一需求需要考虑以下两个问题。
（1）系统能够满足海量结构复杂的数据的高效管理
数据管理系统中存在着大量类型复杂、类型各异的数据，例如胃癌核心信息数据库中，仅基线评估清单中就保存着肿瘤位置、肿瘤浸润深度、淋巴结转移、远处转移、胃癌所致合并症等数据字段，除了结构化的数据外，还有一些非结构化的数据需要保存，诸如系统中存储的一些图片数据。
（2）实现了海量复杂数据的管理和实时的业务反馈
通常情况下，系统的实时性与系统的复杂性成反比，也就是说越是复杂的系统其实时性的服务能力越低，反之亦然。所以一般系统都会在这两个相反的指标上选一个平衡点，本系统对实时性的要求较一些服务型的网站低一些，但医疗数据的复杂性是无法避免的一个问题，所以系统更多重点在复杂数据的管理上，对实时性要求不是特别高，但系统的响应时间也通常不超过5s。
图4.1系统设计架构图
如图4.1所示，为临床科研数据管理系统的架构层次图，各层次具有的功能如下所述。
（1）业务层：业务层处于临床科研数据管理系统架构的最顶层，业务层调用功能层的接口完成对外服务，为医生、信息管理者、系统管理者等用户提供多样化的服务，包括数据导出、系统配置、信息查询、信息统计等服务。
（2）功能层：该层位于业务层的下层、平台层的上层，功能层主要为服务层提供功能接口，同时也从平台层获取服务接口，形成结果后为业务层提供服务。该层主要包括数据采集、数据归档和数据的统计分析。
（3）平台层：该层位于功能层的下层、基础层的上层，主要是搭建系统的整体平台，完成底层的基础计算和数据流处理，包括数据批量处理、数据统计分析的基础算法库、数据流实时处理等功能。
（4）基础层：基础层处于临床科研数据管理系统架构的最底层，为系统的正常运行提供支持，该层主要包括了数据库、分布式计算文件系统、多服务器等内容，以完成海量医疗科研数据的存储与访问，为系统提供硬件和基础软件的支持，保证系统的高可用性、高性能和高可扩展性。
通过上述说明的临床科研数据管理系统的架构层模型的特点、内容、数据采集处理模型、数据流计算引擎、数据存储优化策略等内容，构建了如图*所示的系统数据管理与分析的设计框架图。
图4.2系统数据管理与分析的设计框架图
海量异构的临床科研数据通过基于Storm的实时大数据处理框架整合到数据库中，并通过数据统计与分析的算法进行状态动态的采集与分析，实现数据从“采集端-储蓄端-使用端”的整合，实现为不同用户提供精准化的数据服务和安全可靠的数据管理业务，进而使得最后使用数据更为高效。
临床科研医疗数据管理系统有下面三个特点：
（1）系统具有一定的灵活性。临床科研数据的需求会随着项目的不同与发展需要的数据字段也会有所变化，可能会增加新的表单、新的字段，或删除现有冗余的表单或冗余的字段，系统要能够在不大规模变动的基础上进行重构。
（2）系统要具备可扩展的能力。临床科研数据管理系统的功能需求存在动态性，需要现有系统框架具有一定的可扩展性，以备后续系统扩展用。
（3）系统模块具有重复使用性。临床科研数据管理系统不仅能够应用与临床科研数据的管理，也能够用于其他海量异构数据的管理，例如用于交通数据的管理、物流数据的管理等领域。
4.3 系统总体流程设计
4.3.1 数据录入流程
临床科研数据管理系统最主要的功能是实现海量异构医疗数据的管理，所以数据录入流程是该系统重要的流程之一，能否实现高效、准确的数据录入是系统后续功能实现的基础步骤。首先需要登录系统并对权限进行验证，权限通过后方可录入数据到系统中，可以查询某位病人的姓名以继续录入数据或修改数据，也可以新建病人的姓名以开启新的数据条目，检查数据录入格式后将数据保存到系统数据库中。具体的数据录入流程图如图4.16所示。
图4.16数据录入请求流程图
4.3.2 数据字段导出流程
临床科研需要大量的医疗数据作为支撑，所以从临床科研数据管理系统中导出所需数据是提高临床科研水平和效率的关键环节。第一步与数据录入流程一样需要先登录系统并进行权限验证，选择需要导出数据的项目，通过选择或查询的手段选定所需导出数据的字段并开始数据导出。具体的数据导出流程图如图4.17所示。
图4.17数据字段导出请求流程图
4.3.3 数据删除流程
随着临床科研需求的变化或系统的变化等原因，使得数据库中的数据需要进行部分删除或调整。数据删除流程的第一步是登录系统并进行权限验证，通过后可以进行数据删除操作。首先需要选定项目，之后选择数据或通过查询的方式选择数据，进行删除操作，系统进行删除权限验证、信息审查、正确性审查后删除数据库中数据并返回删除成果提示。具体的数据删除流程图如图4.18所示。
图4.18 数据删除请求流程图
4.4功能结构设计
按照功能和实际业务的需求分析，临床科研数据管理系统将整体系统分为六个子系统，即：研究信息管理子系统、项目管理子系统、质量管理子系统、数据导出子系统、统计分析子系统和系统配置管理子系统。具体功能结构图如图所示。
图4.3系统功能结构设计图
软件工程领域的时序图是以时间顺序为基线对对象间的消息互动进行描述的，通过刻画对象间不同时间顺序发送的消息来清晰的表示出对象间的顺序和关系。下面结合流程图与时序图对系统的子系统进行详细的说明。
4.3.1 登录管理子系统
4.3.1.1注册账户设计
登录管理子系统是临床科研数据管理系统的一个基础功能模块，该子系统分为账户的注册和账户登录，如图*所示，为系统的账户注册流程图。
图4.5 账户注册功能模块流程图
用户打开临床科研数据管理系统后首先需要登录系统，如果没有账户需要点击“注册”按钮注册账户。本系统的注册需要邀请码才能进行注册，如果没有邀请码则需要向系统管理员申请邀请码，后续注册步骤与常规网站注册流程相似，需要注意的带星号的空是必要填写的。用户填写完所有的注册信息后，信息的内容会通过网络传递到服务器的后端进行审核，如果用户注册的信息经过审核通过则会提示用户注册成功，否则返回注册失败，需要用户重新进行账户的注册。如图*所示，为账户注册功能模块的时序图。
用户在登录临床科研数据管理系统后，系统后加载登录主页面，加载主页面需要1000毫秒的时间。之后会通过UserUtil.isLogin()函数判断用户是否登录过该系统，没有登录过则调用startActivity()函数进行登录，并跳转到注册页面，供用户填写注册信息。用户填写好信息后调用SendMsg()函数将用户填写的信息发送到服务器进行处理，检验合格后反馈给用户注册成功的信息，并调用saveUserInfo()函数将用户的信息保存到服务器的数据库中以被下次用户登录检验。
图4.6 注册模块的时序图
4.3.1.2登录系统设计
用户登录功能模块是所有用户都要用到的功能模块，登录功能与常规网络系统类似，通过输入用户的用户名和密码到系统服务器进行比对，如果正确则返回登录成功和系统主页面，否则返回登录失败。
如图*所示，为临床科研数据管理系统的登录功能模块的时序图。用户进入系统后需要输入账户名和密码并通过login()函数传递到服务器中进行正确性校验，并返回用户的登录状态。通过saveInfo()保存用户的活动信息，并通过sendMsgToTarget()函数将信息通过网络传送到服务器端进行处理和保存，并通过onCreate()创建用户的个性化主页面内容或跳转到对应的页面中。
图 4.8 用户登录功能模块时序图
4.3.2研究信息管理子系统
研究信息管理子系统重点功能是科研数据的查询和录入进度的展示，通过研究信息管理子系统的科研数据查询接口可以查询个人项目的所用病人的数据，也可以通过输入特定病人的姓名查询特定病人的临床病例数据。
研究信息管理子系统主要需要设计如下功能模块：项目选择、项目概况展示、项目概况查询、研究数据查询、研究数据管理、数据录入进度管理、数据录入进度查询、反馈问题的管理等功能模块。其中研究数据查询功能模块的时序图如图4.9所示。
系统信息管理员填写注册信息后通过sendSearchMsg()将查询请求通过数据查询接口发送到数据查询页面，并通过数据访问通道DAO实现与数据库的数据交互，查询成功后通过函数returnInfo()返回查询数据的结果，调用EncapData()函数将数据封装后返回到前段供用户使用。
图4.9系统管理角色查询研究数据的时序图
问题反馈的管理功能模块的时序图如图4.10所示。信息管理员选择未解答的问题并点击反馈按钮发送请求后进入问题反馈处理页面，填写好反馈内容后通过sendMsgToTarget()函数将反馈的数据发送到服务器端的数据库中调用saveInfo()函数进行数据保存，并调用returnInfo()函数返回数据到前段。
图4.10系统管理角色回复问题反馈的时序图
4.3.3项目管理子系统
研究中心内容编辑功能模块的时序图如图4.11所示。在选定管理中心后点击“编辑”按钮调用给你jumpToPage()函数跳转入管理中心编辑页面，填写好编辑信息后调用saveInfo()函数保存结果到系统数据库中。通过returnInfo()函数将信息返回到前段提示用户，并调用refreshPage()函数刷新页面，显示新的内容。
图4.11研究中心内容编辑的时序图
4.3.4质量管理子系统
质量管理子系统的数据审查功能模块的时序图如图4.12所示。在录入数据后系统会自动调用数据审查模块对录入的数据的完整性、结构合法性等内容进行审查，系统调用审查dataReview()函数对数据，如果审查结果有疑问则调用jumpToPage()函数跳转入人工审查页面，人工调用manualReview()函数通过数据库调用有疑问数据记录的详细数据，通过returnInfo()函数将信息返回到前段提示用户，并调用refreshPage()函数刷新页面，显示新的数据审查结果。
图4.12数据审查的时序图
4.3.5 数据导出子系统
研究数据导出功能模块的时序图如图4.13所示。信息管理员调用selectField()函数选择待导出字段后提交数据导出请求，进入数据导出页面后调用exportData()函数开始数据导出，调用sendMsgToTarget()函数向服务器发送数据导出请求后，服务器将数据发送至前段完成数据导出。
图4.13研究数据导出的时序图
4.3.6系统配置管理子系统
系统管理员系统信息及版本进行维护功能的时序图如图4.14所示。系统管理员查看系统信息及版本维护操作后提交修改请求，通过jumpToPage()函数跳转入系统维护页面，后调用versionMaintain()函数开始系统维护，维护后调用saveInfo()函数将结果保存到系统数据库中，并通过returnInfo()函数将结果返回到前端。
图4.14系统管理员系统信息及版本进行维护功能的时序图
系统部件设计功能模块的时序图如图4.15所示。系统管理员查看系统部件信息后提交修改请求，通过jumpToPage()函数跳转入部件信息编辑页面，后调用elementEdit()函数开始部件信息编辑，编辑完成后调用saveInfo()函数将结果保存到系统数据库中，并通过returnInfo()函数将结果返回到前端。
图4.15系统部件设计的时序图
4.4 系统流程设计和E-R图设计
4.5数据库设计
4.5.1系统用户相关表
如表4-1至4-3为系统用户相关的数据库表。其中表4-1为机构信息表，该表记录了机构地址、机构编号、机构名称等内容；表4-2为用户信息表，该表记录了用户的个人信息，诸如用户姓名、邮箱地址、联系电话等内容。
表4-1机构信息表Organization详细描述
| 序号 |
字段名 |
字段类型 |
字段长度 |
是否为关键字 |
备注 |
| 1 |
Id |
int |
- |
是 |
|
| 2 |
CreationTime |
datetime2 |
7 |
否 |
|
| 3 |
CreatorUserId |
bigint |
- |
否 |
|
| 4 |
IsEnabled |
bit |
- |
否 |
是否有效 |
| 5 |
LastModificationTime |
datetime2 |
7 |
否 |
|
| 6 |
LastModifierUserId |
bigint |
- |
否 |
|
| 7 |
OrgAddress |
nvarchar |
50 |
否 |
机构地址 |
| 8 |
OrgCode |
nvarchar |
50 |
否 |
机构编号 |
| 9 |
OrgName |
nvarchar |
50 |
否 |
机构名称 |
| 10 |
OrgTelephone |
nvarchar |
50 |
否 |
机构联系电话 |
| 11 |
OrgWebSite |
nvarchar |
50 |
否 |
机构官网 |
4.5.2项目配置相关表
如表4-4至4-9为项目配置相关的数据库表。其中表4-4表示项目组信息表，项目组主要用于临床研究团队同时拥有多个研究项目需要记录时的情况，该表记录了项目组的创建时间、项目组编号、项目组名称等内容；表4-5为项目信息表，表示每个临床项目的具体信息，该表记录了项目的相关信息，诸如项目名称、项目编号、项目所属项目组、项目描述等内容；表4-6为项目特殊配置表，主要针对案例详细信息的是否展示配置，每个研究项目需要的案例基本信息有细微差别，根据配置统一化，该表记录了项目的一些详细信息，其中包括项目是否已全系视图显示、是否脱敏、是否以姓名首拼音码显示等项目配置。表4-7为授权机构临床研究权限表，该表通过OrganizationId字段和ProjectId字段实现了机构和项目的关联记录。表4-8为研究中心信息表，每个研究项目都可以同时拥有多个研究中心，该表记录了研究中心的信息，主要包括研究中心地址、研究中心是否有效、研究中心名称、研究中心代号、研究中心网站等内容。表4-9为授权用户具体操作权限表，同一个账号可能有多个临床研究项目权限，通过IsDefault字段设置每次进入的默认项目，该表记录了授权用户在研究项目中具有的权限，包括项目角色ID、研究中心ID和系统用户ID等内容。
表4-5项目信息表Project详细描述
| 序号 |
字段名 |
字段类型 |
字段长度 |
是否为关键字 |
备注 |
| 1 |
Id |
int |
- |
是 |
|
| 2 |
CreationTime |
datetime2 |
7 |
否 |
|
| 3 |
CreatorUserId |
bigint |
- |
否 |
|
| 4 |
LastModificationTime |
datetime2 |
7 |
否 |
|
| 5 |
LastModifierUserId |
bigint |
- |
否 |
|
| 6 |
IsActived |
bit |
- |
否 |
是否有效 |
| 7 |
ProjectCN |
nvarchar |
50 |
否 |
工程名称 |
| 8 |
ProjectCode |
nvarchar |
50 |
否 |
项目编号 |
| 9 |
ProjectDescription |
nvarchar |
max |
否 |
项目概况描述 |
| 10 |
ProjectName |
nvarchar |
50 |
否 |
项目名称 |
| 11 |
ProjectTitle |
nvarchar |
50 |
否 |
显示在每个操作页面的项目名称 |
| 12 |
IsMainProject |
bit |
- |
否 |
是否主库 |
| 13 |
ProjectGroupId |
int |
- |
否 |
所属项目组 |
4.5.3菜单操作权限相关表
如表4-10至4-12为菜单操作相关的数据库表。其中表4-10表示菜单信息表，该表记录了菜单编号、是否有效、菜单名称、排序号、父节点ID、URL地址等内容；表4-11表示项目角色表，该表记录了项目角色ID、角色编号、角色名称等内容；表4-12表示角色菜单权限表，该表记录了菜单ID、项目角色ID等内容。
表4-11 项目角色表ProjectRole详细描述
| 序号 |
字段名 |
字段类型 |
字段长度 |
是否为关键字 |
备注 |
| 1 |
Id |
int |
- |
是 |
|
| 2 |
CreationTime |
datetime2 |
7 |
否 |
|
| 3 |
CreatorUserId |
bigint |
- |
否 |
|
| 4 |
LastModificationTime |
datetime2 |
7 |
否 |
|
| 5 |
LastModifierUserId |
bigint |
- |
否 |
|
| 6 |
RoleCode |
nvarchar |
max |
否 |
角色编号 |
| 7 |
RoleName |
nvarchar |
max |
否 |
名称 |
4.5.4表单部件配置相关表
如表4-13至4-21为表单部件配置相关的数据库表。其中表4-13表示目录信息表，用于展示的录入结构的目录节点，该表记录了目录名称、父目录ID、是否自定义目录、是否展示目录名称等内容；表4-14表示部件分类表，主要是方便bootstrap设计时，快速找到部件，对所有部件进行分类管理，该表记录了创建时间、创建者ID、部件类别名称、是否有效、所属项目ID等内容；表4-15表示部件类型表，该表记录了类型名称、创建时间、识别名称等内容；表4-16表示部件信息表，该表记录了部件的详细内容，包括部件分类ID、部件编号、部件名称、识别代号等内容；表4-17表示部件详细信息表，该表记录了编号表示、名称、简称、部件ID、排序等内容；表4-18表示组合部件表，该表记录了ID、排序、部件分组ID、组内的部件ID等内容；表4-19表示部件扩展信息表，该表记录了是否验证、是否选择时追加文本框、追加文本框的内容、选择追加选项、是否必答、验证提示信息、日期空间展示模式等内容；表4-20表示控件表格表，该表记录了部件ID、列标题、列控件类型、列填充内容等内容；表4-21表示表单部件表，表单内的部件集合，表单设计保存后生成，该表记录了菜单ID、最后修改时间、排序等内容。
表4-16部件信息表Widget详细描述
| 序号 |
字段名 |
字段类型 |
字段长度 |
是否为关键字 |
备注 |
| 1 |
Id |
int |
- |
是 |
|
| 2 |
CreationTime |
datetime2 |
7 |
否 |
|
| 3 |
CreatorUserId |
bigint |
- |
否 |
|
| 4 |
ElementTypeId |
int |
- |
否 |
部件类型ID |
| 5 |
IsActived |
bit |
- |
否 |
是否有效 |
| 6 |
LastModificationTime |
datetime2 |
7 |
否 |
|
| 7 |
LastModifierUserId |
bigint |
- |
否 |
|
| 8 |
OrderIndex |
int |
- |
否 |
标识代号 |
| 9 |
Tip |
nvarchar |
max |
否 |
提示信息，即表单展示时鼠标移到问号时显示的内容 |
| 10 |
WidgetCategoryId |
int |
- |
否 |
部件分类ID |
| 11 |
WidgetCode |
nvarchar |
50 |
否 |
编号 |
| 12 |
WidgetName |
nvarchar |
50 |
否 |
名称 |
| 13 |
RefGroupId |
int |
- |
否 |
|
| 14 |
DataRefCategory |
nvarchar |
50 |
否 |
|
4.5.5表单规则相关表
如表4-22至4-23为表单规则相关的数据库表。其中表4-22表示表单规则表，该表记录了规则名称、规则触发ID、规则类型、规则表达式、检查类型、危险项等内容；表4-23表示规则详细信息表，该表记录了js控件名、js变量名、控件ID、规则ID、跨表单取值的FormId等内容。
表4-22 表单规则表FormRule详细描述
| 序号 |
字段名 |
字段类型 |
字段长度 |
是否为关键字 |
备注 |
| 1 |
Id |
int |
- |
是 |
|
| 2 |
TargetItemName |
nvarchar |
50 |
否 |
规则名称 |
| 3 |
TargetItemId |
nvarchar |
50 |
否 |
规则触发ID（表单设计拖拽后部件生成的ID） |
| 4 |
RuleType |
int |
- |
否 |
规则类型：逻辑验证，计算验证 |
| 5 |
IsNull |
bit |
- |
否 |
|
| 6 |
Expression |
nvarchar |
50 |
否 |
表达式 |
| 7 |
FormId |
int |
- |
否 |
|
| 8 |
Tip |
int |
- |
否 |
提示信息 |
| 9 |
OrderIndex |
int |
- |
否 |
排序 |
| 10 |
RuleFlag |
int |
- |
否 |
检查类型 |
| 11 |
ChallengeTip |
nvarchar |
50 |
否 |
危险项 |
4.5.6案例数据相关表
如表4-24至4-27为案例数据相关的数据库表。其中表4-24表示案例信息表，新建案例时填写的数据内容，一般填写后不可更改，该表记录了操作用户ID、身份证号、分组结果、姓名、项目ID、手机联系方式等内容；表4-25表示案例表单状态表，该表记录了案例的每个表单的操作状态，包括案例ID、表单ID、案例状态、新建用户的操作用户名、表单完成率等内容；表4-26表示案例表单的填写值表，该表记录了案例的录入内容，包括部件ID、案例ID、表单ID、对应案例表单状态ID等内容；表4-27表示表单状态不适用时产生数据表，该表用于系统初次判断表单内容不合法但后续改正判断并需要重新填写表单的情况，包括案例ID、表单ID、原因、状态等内容。
表4-25 案例表单状态表ReSearchUser详细描述
| 序号 |
字段名 |
字段类型 |
字段长度 |
是否为关键字 |
备注 |
| 1 |
Id |
int |
- |
是 |
|
| 2 |
ReSearchUserId |
int |
- |
否 |
案例ID |
| 3 |
FormId |
int |
- |
否 |
表单ID |
| 4 |
CreateAt |
datetime2 |
7 |
否 |
|
| 5 |
Flag |
int |
- |
否 |
状态：1保存草稿；2提交；2不适用 |
| 6 |
Creator |
nvarchar |
50 |
否 |
新建用户的操作用户名 |
| 7 |
LastUpdater |
nvarchar |
50 |
否 |
操作用户的ID |
| 8 |
LastUpdateTime |
datetime2 |
7 |
否 |
进入随机化日期 |
| 9 |
Percentage |
float |
- |
否 |
当前表单的完成率，即已填写的/总部件数 |
4.5.7质疑相关表
如表4-28至4-30为质疑相关的数据库表。其中表4-28表示案例目录质疑状态表，该表记录了案例ID、目录ID、质疑类型、审核状态等内容；表4-29表示案例详细表单质疑状态，该表记录了案例ID、表单ID、逻辑质疑状态、人工质疑状态、SDV质疑状态、是否冻结等内容；表4-30表示质疑详细信息表，该表记录了案例表单质疑表ID、部件ID、具体部件内容ID、表格时产生的ID、自动产生的质疑描述、修改后的值、人工产生质疑描述、质疑状态、发送后录入者可查看质疑修改、是否关闭、质疑类型等内容。
表4-28 案例目录质疑状态表ChallengeCategory详细描述
| 序号 |
字段名 |
字段类型 |
字段长度 |
是否为关键字 |
备注 |
| 1 |
Id |
int |
- |
是 |
|
| 2 |
ReSearchUserId |
int |
- |
否 |
案例ID |
| 3 |
FormCategoryId |
int |
- |
否 |
目录ID一级目录 |
| 4 |
ChallengeType |
nvarchar |
50 |
否 |
质疑状态质疑类型:0逻辑.1SDV,2人工 |
| 5 |
ChallengeStatus |
bit |
- |
否 |
审核状态:0未审查；1检查中,2已完成。状态主要用于色块显示，展示时都只显示一级目录质疑状态 |
4.5.8其他相关表
如表4-31至4-34为其他相关的数据库表。其中表4-31表示导出说明表，该表记录了导出状态、导出描述、文件路径、项目ID等内容；表4-32表示导出内容表，表示导出时选择具体要导出的部件，该表记录了创建时间、创建人ID、表单ID、导出申请ID等内容；表4-33表示帮助与解答表，主要维护一些系统统一的问答内容，展示在项目首页方便使用者了解常规问题，该表记录了回答内容、是否有效、项目ID、问题描述等内容；表4-34表示使用者的问题及反馈表，使用时产生问题时提问，由管理员反馈用户提出的问题，该表记录了反馈内容、反馈时间、提出的问题、研究中心ID、状态等内容。
表4-34使用者的问题及反馈QuestionAnswer详细描述
| 序号 |
字段名 |
字段类型 |
字段长度 |
是否为关键字 |
备注 |
| 1 |
Id |
int |
- |
是 |
|
| 2 |
Answer |
nvarchar |
max |
否 |
反馈内容 |
| 3 |
AnswerTime |
nvarchar |
max |
否 |
反馈时间 |
| 4 |
CreationTime |
datetime2 |
7 |
否 |
|
| 5 |
CreatorUserId |
bigint |
- |
否 |
|
| 6 |
LastModificationTime |
datetime2 |
7 |
否 |
|
| 7 |
LastModifierUserId |
bigint |
- |
否 |
|
| 8 |
Question |
nvarchar |
max |
否 |
问题 |
| 9 |
ReSearchOrgId |
int |
- |
否 |
研究中心ID |
| 10 |
Status |
int |
- |
否 |
状态 |
4.3.9系统E-R图设计
系统E-R图如图4.19所示。
图4.19系统部分E-R图描述
4.7 本章小结
本章重点说明了临床科研数据管理系统的系统设计部分，从设计原则、设计目的和系统架构设计入手整体上阐述系统的设计架构和设计理念。之后利用流程图和时序图对系统的七个子系统的功能结构进行详细说明，并对系统重点流程和E-R图的设计进行详细说明。最后对系统数据表结构设计进行详细阐述。
第五章 系统实现与测试
临床科研数据管理系统按照功能和实际业务可以将整体系统分为七个子系统，即：登录管理子系统、研究信息管理子系统、项目管理子系统、质量管理子系统、数据导出子系统、统计分析子系统和系统配置管理子系统。下面分别对这七个子系统进行的实现进行详细说明并进行测试。
5.1测试环境
如表6-1所示，为系统的测试硬件环境和软件环境。
表6-1 系统的测试环境
| 硬件配置 |
硬件名称 |
型号/备注 |
| Web服务器 |
CPU |
Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz |
| 内存 |
8GB |
|
| 硬盘 |
500 GB |
|
| 操作系统 |
Windows 7 |
|
| 数据库服务器 |
CPU |
Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz |
| 内存 |
8GB |
|
| 硬盘 |
500 GB |
|
| 操作系统 |
Windows 7 |
|
| 服务器程序 |
网络运行环境 |
IIS |
| 数据库软件 |
数据库系统 |
SQL Server 2008 |
5.2 系统各子系统实现与测试
5.2.1 系统登陆和注册子系统
临床科研数据管理系统需要登录后才能进行后续操作，如果第一次登录需要进行注册。如图5.1所示为系统登录界面截图，如图5.2所示为系统账户注册界面截图。
图5.1系统登陆主界面图5.2 系统注册主界面
5.2.2 研究信息管理子系统
如图5.3至图5.6为研究信息管理子系统的运行截图。如图5.3所示，为项目概况主页的运行截图。如图5.4所示，为研究数据研究数据查看与编辑页面的运行截图，其中图5.(a)为研究数据管理的主页面，在次页面输入病人姓名后查询该病人的相关数据，图5.(b)至图5.(j)为该病人所有相关的数据，分别为：（1）基本信息；（2）基线评估；（3）肿瘤学评估；（4）手术信息；（5）术后恢复；（6）系统治疗；（7）放射治疗；（8）介入治疗；（9）随访信息。
图5.3项目概况主界面
图5.4(a)研究数据管理界面图5.4(b) 病人基本信息查看
图5.4(c)病人基线评估图5.4(d) 病人肿瘤学评估
图5.4(e)病人手术信息评估图5.4(f) 病人术后恢复
图5.4(g) 系统治疗图5.4(h) 病人放射治疗
图5.4(i) 病人介入治疗图5.4(j) 病人随访信息
图5.4研究数据查看与编辑页面
如图5.5所示，为病人数据录入进度的运行截图。如图5.6所示，为项目相关问题反馈的运行截图。
图5.5数据录入进度图5.6项目问题反馈
5.2.3 项目管理子系统
如图5.7所示，为研究中心管理子系统的运行主界面截图。点击“新建研究中心”和“编辑”按钮可以进入新建研究中心页面或编辑现有研究中心，运行截图如图5.8和图5.9所示。
图5.7研究中心管理主界面
图5.8研究中心信息编辑界面图5.9新建研究中心主界面
如图*所示，为研究中心邀请用户参与系统应用或管理的运行截图。
图5.10研究中心信息用户邀请界面
如图5.11所示，为项目概况编辑主界面的运行截图，通过编辑项目概况介绍信息，将会改变研究信息管理主界面项目概况简介的内容。
图5.11项目概况编辑主界面
如图5.12所示，为字段提示查看主界面的运行截图。如图5.13所示，为项目问题反馈主界面的运行截图。
图5.12字段提示查看主界面图5.13 项目问题反馈主界面
5.2.4 质量管理子系统
如图5.14所示，为质量管理子系统的运行截图。质量管理子系统最先进行录入数据的逻辑审查，即系统自动对录入数据的逻辑正确性进行审查，运行截图如图5.15所示。
图5.14逻辑审查界面
如果逻辑审查不通过，则进行SDV审查，运行截图如图*所示。
图5.15SDV审查界面
如果系统仍然判定录入的数据的正确性存在问题，则需要进行人工审查，运行截图如图5.16所示，点击“画笔”按钮可以进入人工审查操作界面，人工审查的具体界面的运行截图如图5.17所示。
图5.16人工审查界面
图5.17人工审查操作界面
可以通过质疑导出功能将网络系统的质疑导入到统一界面进行详细查看，具体运行截图如图5.18所示。
图5.18质疑导出界面
5.2.5 数据导出子系统
如图5.19至图5.21所示，为研究数据导子系统的运行截图。如图5.19所示，为研究数据导出的页面的运行截图。
图5.19研究数据导出主界面
点击“新增导出”按钮新建导出字段，运行截图如图5.20所示。
图5.20新增研究数据的导出
如图5.21所示，为研究数据导出字段查看的运行截图，在导出数据前可以查看设置的导出字段。
图5.21研究数据导出字段查看
5.2.6 系统管理子系统
如图*所示，为项目组管理子系统的运行主界面截图。点击“新建项目组”可以进入新建项目组的页面的，其运行截图如图5.所示。点击“编辑”按钮进入项目组信息的编辑页面，其运行截图如图5.所示。
图5. 项目组主界面
图5. 新建项目组图5. 编辑项目组信息
如图5.所示，为项目信息查看页面的运行截图。如图5.所示，为数据配置主界面页面的运行截图。
图5. 项目组信息查看图5. 数据配置主界面
点击“编辑”按钮进入部件属性编辑的编辑页面，其运行截图如图5.所示。
图5. 部件属性编辑界面
如图5.所示，为表单配置主界面页面的运行截图。点击“新建目录”可以进入新建表单目录的页面的，其运行截图如图5.所示。点击“编辑”按钮进入表单目录的编辑页面，其运行截图如图5.所示。
图5. 表单配置主界面
图5. 表单目录编辑界面图5. 新建表单目录界面
如图5.所示，为数据分类主页面的运行截图。点击“新建”按钮可以进入新建数据分类页面，其运行截图如图5.所示。点击“编辑”按钮可以进入数据分类编辑页面，其运行截图如图5.所示。
图5. 数据分类主界面
图5. 新建数据分类主界面图5. 编辑数据分类界面
如图5.所示，为帮助与解答主页面的运行截图。点击“新建”按钮可以进入新建编辑帮助与解答页面，其运行截图如图5.所示。点击“编辑”按钮可以进入编辑帮助与解答编辑页面，其运行截图如图5.所示。
图5. 帮助与解答主界面
图5. 新建帮助与解答界面图 5. 编辑帮助与解答界面
如图5.所示，为机构信息查看主页面的运行截图。点击“编辑”按钮可以进入机构信息查看编辑页面，其运行截图如图5.所示。点击“查看用户”按钮可以进入机构用户查看页面，其运行截图如图5.所示。
图5. 机构信息查看主界面
图5. 机构信息编辑界面图5. 机构信息用户查看界面
如图5.所示，为项目授权界面页面的运行截图。
图5. 项目授权界面
如图5.所示，为用户管理主页面的运行截图。点击“新建用户”按钮可以进入用户信息新建页面，其运行截图如图5.所示。点击“编辑”按钮可以进入用户信息编辑页面，其运行截图如图5.所示。
图5. 用户管理主界面
图5. 用户信息新建界面图5. 用户信息编辑界面
5.3 胃癌核心信息数据库案例测试与研究
5.3.1 案例实现
5.3.2 结果研究
第六章总结与展望
本文重点研究了临床科研数据管理系统的设计与实现，通过对异构医疗数据的研究开发出了适合临床医疗领域的数据管理系统，为临床医疗领域科研工作的进步起到了推动作用。
6.1总结
临床数据由于存在数据结构复杂、数据量大等问题，使得临床科研很难有足够的数据作为支持，尤其是很多临床科研数据存在于单个医院，甚至是单个部门，这种数据孤岛现象使得临床科研工作的开展备受阻力，数据瓶颈问题已经成为阻碍临床科研进步的重点难题，亟待解决。
针对当前数据管理系统大多数是为单一部门的使用而设计、实现的，缺少全局性的考虑，难以应用于复杂部门关系的领域，如果应用于医疗系统，则将会有很多工作需要人工去弥补完成，造成人力资源极大的浪费的问题，以及当前数据管理系统缺少监督机制，数据录入进度难以掌控，同时也缺少问题反馈机制，还需要人与人之间私下沟通解决，效率低下，也缺少成熟的平台去解决问题，目前的绝大多数数据管理系统难以应用于实际业务，其应用普及度、可扩展性、安全性等因素都需要进一步提高，且关于临床医疗数据管理的系统更是少见的问题，本文开发一套可以应用于实际工作的临床科研数据管理系统用于管理临床领域医疗数据，以提高临床科研效率，具有如下意义。
1、针对现代临床科研领域对于海量数据采集、存储、管理、分享等方面的需求，提出了一套用于管理海量临床医疗数据的管理系统，优化了数据采集流程、提高了数据管理效率、严格了数据完整性监测要求，最终提高了数据管理的效率和服务质量。
2、采用现代的软件工程技术和软件工程理念，构建了系统整体架构、各子系统功能模块和数据库表结构的详细设计，基于ASP技术实现了该系统的各项功能，并基于Windows平台、IIS服务器、SQL Server 2008数据库系统等环境对系统进行运行测试，测试结果表明该系统实现了高效数据采集、数据存储、数据管理和数据分享医疗领域的科研数据。
6.2展望
临床医疗数据的数据类型涉及面广、数据中存在非结构化的数据、数据量巨大、数据管理复杂度和难度很大，对数据管理系统的要求很高。系统的设计和实现过程中，在各角色的需求、系统架构设计、系统流程梳理、平台搭建等方面做了很多工作，但还存在以下几方面需要在后续的工作中进一步完善。
1、进一步探索数据存储优化模型。随着系统应用的普及，所存储的数据量会呈现指数级速度增长，海量数据的存储、访问、查询会对系统性能、结构等方面造成巨大压力和考验。后续要进一步优化系统的数据存储、访问、查询模型，运用新技术提高系统的稳定性和性能。
2、利用数据挖掘实现系统数据的自动分析和系统各项参数指标的自适应调整。下一步将利用现代火热的机器学习技术及其深度学习对系统中的医疗数据进行自动分析，利用分析结果对系统结构、参数的优化提出参考结果。
主要参考文献
[1] 张振, 周毅, 杜守洪,等. 医疗大数据及其面临的机遇与挑战[J]. 医学信息学杂志, 2014, 35(6):2-8.
[2] 汪鹏, 吴昊, 罗阳,等. 医疗大数据应用需求分析与平台建设构想[J]. 中国医院管理, 2015, 35(6):40-42.
[3] 罗旭, 刘友江. 医疗大数据研究现状及其临床应用[J]. 医学信息学杂志, 2015, 36(5):10-14.
[4] 代涛. 健康医疗大数据发展应用的思考[J]. 医学信息学杂志, 2016, 37(2):1-8.
[5] 彭传薇, 刘琛玺, 李小华. 浅谈医疗数据质量重要性及其影响[J]. 解放军医院管理杂志, 2005, 12(5):467-468.
[6] 彭传薇, 李小华, 刘琛玺. 医院医疗数据质量现状和影响因素分析[J]. 中国医院管理, 2005, 25(9):37-39.
[7] 唐凯, 管世俊, 黄钊,等. 区域医疗信息化中的医疗数据交换平台[J]. 医疗卫生装备, 2010, 31(5):35-37.
[8] 马灿. 国内外医疗大数据资源共享比较研究[J]. 情报资料工作, 2016, 37(3):63-67.
[9] 蔡佳慧, 张涛, 宗文红. 医疗大数据面临的挑战及思考[J]. 中国卫生信息管理杂志, 2013(4):292-295.
[10] 周光华, 辛英, 张雅洁,等. 医疗卫生领域大数据应用探讨[J]. 中国卫生信息管理杂志, 2013(4):296-300.
[11] 林青, 黄玉蕾. 医疗卫生领域大数据共享的应用研究[J]. 信息安全与技术, 2016, 7(4):12-14.
[12] 殷焕炯. 大数据在医疗卫生领域中的应用[J]. 网络安全技术与应用, 2017(5):123-124.
[13] 盛芳菲, 郎宝军, 张韧, et al. 基于Hadoop的智慧医疗数据管理方法:, 2013.
[14] Cohen G , Goldsmith J , Roller P , et al. MEDICAL DATA MANAGEMENT SYSTEM AND PROCESS[J]. 1999.
[15] Fuminori M, Hirofumi H. MEDICAL DATA MANAGEMENT SYSTEM[J]. 2004.
[16] Liu X, Zhao J, Huang J, et al. Research of Quick Developing Model in the Medical Clinical Data Management System[C]// International Conference on Bioinformatics & Biomedical Engineering. 2011.
[17] Probst K . Humaris — An Automated Medical Data Management System[J]. Methods of Information in Medicine, 1967, 06(02):65-69.
[18] 程学旗, 靳小龙, 王元卓,等. 大数据系统和分析技术综述[J]. 软件学报, 2014(9):1889-1908.
[19] 王琳, 商周, 王学伟. 数据采集系统的发展与应用[J]. 电测与仪表, 2004, 41(8):4-8.
[20] 邬伦, 张毅. 分布式多空间数据库系统的集成技术[J]. 地理与地理信息科学, 2002, 18(1):6-10.
[21] 金澈清, 钱卫宁, 周敏奇,等. 数据管理系统评测基准:从传统数据库到新兴大数据[J]. 计算机学报, 2015, 38(1):18-34.
[22] 商琳, 骆斌. 一种基于数据仓库的数据挖掘系统的结构框架[J]. 计算机应用研究, 2000, 17(9):63-65.
[23] 薛医贵. 基于ASP的高校人力资源管理信息系统研究[J]. 电子设计工程, 2016, 24(6):162-164.
[24] 张蕾, 翟大昆. ASP技术考[J]. 云南民族大学学报(自然科学版), 2001, 10(1):295-297.
[25] 武怀生, 李秀明. 基于ASP技术的企业商务网站的设计与实现[J]. 现代电子技术, 2014(18):60-62.
[26] 宿静茹, 濮德敏. 利用ASP技术实现数据库WWW动态查询[J]. 情报学报, 2000, 19(5):532-537.
[27] 彭建, 黄家林. 基于ASP技术的Web网站安全措施分析[J]. 电脑与信息技术, 2002(2):31-33.
[28] 陈玮. 基于ASP技术的林业信息服务平台构建[J]. 东北林业大学学报, 2008, 36(12):84-86.
[29] 尹露禾, 叶震. ASP技术在WEB数据库中的应用[J]. 电脑开发与应用, 2000(2):19-21.
[30] 陆鑫. 利用ASP技术实现WEB数据库的访问[J]. 电子科技大学学报, 2000, 29(1):87-90.
[31] 孙俊, 李正明, 杨继昌. ASP技术与ASP.Net技术的比较[J]. 微型机与应用, 2003, 22(1):6-7.
[32] 赵燕燕. ASP技术在Web数据库开发中的使用[J]. 河南医学高等专科学校学报, 2009, 21(1):93-94.
[33] White M. Microsoft SQL Server 2008 Bible[J]. John Wiley & Sons, 2009.
[34] Fritchey G, Dam S. SQL Server 2008 Query Performance Tuning Distilled[J]. Apress, 2009.
[35] 孙国强, 孟晓阳, 许燕, et al. 基于SQL SERVER 2008在医院信息系统中构建数据仓库[J]. 中国数字医学, 2009, 4(6):70-72.
[36] 郑群, 邸铮. SQL Server数据库安全性研究[J]. 无线互联科技, 2016(7):98-99.
[37] 张运诗, 仲兆准, 钟胜奎, et al. 基于Visual Studio 2010的员工信息数据库设计和实现[J]. 电脑知识与技术, 2013(28):6246-6249.
[38] 石峰. Visual Studio2010应用解折[J]. 经济师, 2011(7).
[39] 秦佳. 基于UML的电子商务系统设计[J]. 电子技术与软件工程, 2017(23):59-59.
[40] 何耀光, 康汶, 詹先信, et al. 基于UML的电子商务在线销售系统分析与设计[J]. 计算机与现代化, 2011(2):171-174.
[41] 孟倩, 周延. UML在数据库建模中的应用[J]. 计算机工程与应用, 2005, 41(16):179-181.
[42] 张秀国, 徐晓红. 基于UML的数据仓库构造方法的研究[J]. 计算机工程与设计, 2002, 23(11):21-23.
[43] 陈荟慧, 王伟静. 基于UML的数据流图可视化编辑工具的设计[J]. 计算机技术与发展, 2012, 22(5):145-149.
[44] 甄凤其. 基于UML的数据库应用系统开发研究[J]. 电脑知识与技术, 2009, 5(7):1779-1781.