项目文档:需求规格说明书
1. 引言
1.1目的
在完成了针对医院病历存储系统的前期调查,同时全部小组成员进行了全面深入的讨论和分析的基础上,提出了这份需求规格说明书。作为项目提出小组,也在其中了解了包括界面设计、搜索方式等用户需求。该文档重点描述了病人病历存储系统的功能需求,并将其作为系统设计阶段的主要输出。
本文档的预期用户包括:医生,数据上传人员
1.2项目背景
项目名称:病人病历存储系统;
项目提出者:精准医疗小组;
开发单位:华中农业大学信息学院;
用户:全体医生和管理员;
项目实施单位:精准医疗小组;
1.3缩写说明
GM:管理员;
Admin:普通医生用户;
1.4术语定义
无。
1.5参考资料
【1】jQuery教程: http://jquery.com/
【2】materialize框架开发手册: https://materializecss.com/
【3】HTML教程: http://www.w3school.com.cn/html/
【4】JavaScript教程: http://www.w3school.com.cn/JavaScript/
【5】Php教程: http://www.w3school.com.cn/php/
1.6版本信息
具体版本信息如表A-1所示
表A-1 具体版本信息
修改编号 | 修改日期 | 修改后版本 | 修改位置 | 修改内容概述 |
1 | 2018-4-29 | 1.0 | 全部 | 完成第一次编写 |
2 | 2018-6-21 | 1.1 | 部分 | 完成第一次修改 |
2.任务概述
2.1系统定义
2.1.1 项目来源及背景
湖北省华中农业大学农业生物信息重点实验室委托。中国版TCGA适用于构建癌症病人转录组,就诊以及生存期等综合医疗数据的网站服务平台 ,旨在提供规范化的就诊信息以及随访和预后信息的收集以及处理。同时也是一个强大的数据驱动平台,可让癌症发生研究人员和生物信息学家搜索并下载癌症数据进行分析.
2.1.2项目要达到的目标
本项目是为了提供规范化的就诊信息以及随访和预后信息的收集以及处理。让癌症发生研究人员和生物信息学家搜索并下载癌症数据进行分析.
2.1.3系统整体结构
图A-1给出了系统的物理组成结构。
图A- 1系统的物理组成结构
2.1.4系统各部分组成,与其他部分的关系,各部分的接口等
本系统是一个独立运行的系统,不需要与其他系统连接。
2.2运行环境
2.2.1设备环境
本地服务器wamp;线上服务器阿里云;
2.2.2硬件环境
无要求;
2.2.3软件环境
适用于全部浏览器;(IE8以上版本,firefox,google等)
2.2.4网络环境
本地需要apache提供虚拟地址;线上提供服务器地址;
2.2.5操作环境
Windows系列及ubuntu;
2.2.6应用环境
系统工作流程如图A-2所示:
图A- 2系统工作流程图
2.3 条件限制
2.3.1列出进行本软件开发工作的假定和约束,如经费限制,开发期限等
本项目由本组人员开发,开发经费较少。
2.3.2列出本软件的最终用户,用户的教育水平和技术专长
最终用户一般为医生和管理员;
2.3.3列出本软件的预期使用频度等
本软件主要是医生录入下载更改病人信息和管理员上传信息的时候使用,使用频率中等。
3 数据描述
3.1静态数据
本系统支持本地时间同步、病人信息存储;
3.2动态数据
(1)用户登录信息
(2)用户搜索结果
(3)病人样本信息
(4)病人病历信息
(5)上传数据信息
3.3数据库描述:数据库名称、版本
Mysql数据库。
3.4数据字典
数据项目 | 代号 | 数据类型 | 数据长度 | 取值范围 |
用户名 | User_name | Varchar(30) | 30 |
|
病人姓名 | Username | Varchar(30) | 30 |
|
密码 | Password | Char(32) | 32 |
|
登录时间 | Login_time | Char(11) | 11 |
|
电子邮件 | | Varchar(20) | 20 |
|
身份证 | ID_card | Varchar(20) | 20 |
|
住院号 | Number_hospital | Varchar(20) | 20 |
|
出生年月 | birthday | Varchar(20) | 20 |
|
性别 | Gender | Char(1) | 1 |
|
电话 | Telephone | Int(11) | 11 |
|
地址 | address | Varchar(200) | 200 |
|
民族 | Nation | Varchar(10) | 10 |
|
医院 | hospital | Varchar(100) | 100 |
|
癌症分型 | Cancer_type | Varchar(7) | 7 |
|
抽烟史 | Smoke_year | Varchar(10) | 10 |
|
TNM | TNM | Varchar(10) | 10 |
|
确诊时间 | Time_confirm | Varchar(20) | 20 |
|
是否死亡 | Died | Char(1) | 1 |
|
死亡时间 | Time_dead | Varchar(20) | 20 |
|
死亡原因 | Dead_reason | Text |
|
|
最后更新时间 | Last_update | Varchar(20) | 20 |
|
酗酒史 | Drink_year | Varchar(10) | 10 |
|
吸毒史 | Drug_year | Varchar(10) | 10 |
|
诊断描述 | Diagnosis_desc | Text |
|
|
手术描述 | Operation_desc | Text |
|
|
其他不良习惯史 | Others | Varchar(20) | 20 |
|
放疗方案 | X_treat | Text |
|
|
放疗后状态 | After_ X_treat | Text |
|
|
药物治疗方案 | Drug_treat | Text |
|
|
药物治疗后状态 | After_ Drug_treat | Text |
|
|
分析结果文件路径 | Sample | Varchar(250) | 250 |
|
样本是否公开 | Access | Char(1) | 1 |
|
是谁处理数据 | Screen_by | Varchar(10) | 10 |
|
产生时间 | Creat_time | Int(11) | 11 |
|
样本类型 | Sample_type | Varchar(8) | 8 |
|
上传者 | Upload_by | Varchar(10) | 10 |
|
3.5数据采集
用户数据库:
Diagnosis数据库:
病人基本信息数据库:
存储数据库:
样本数据库:
4 功能需求
4.1 功能划分
4.1.1 系统功能组成
(1)用户登录判断
(2)录入病人信息
(3)根据条件查询
(4)样本排序
(5)更新病人信息
(6)添加病人病历
(7)下载数据
(8)数据信息上传
4.1.2 功能编号和优先级
系统功能优先级如表A-2所示。
表A-2 系统功能优先级
编号 | 名称 | 优先级 | 描述 | 主要发起者 |
1 | 用户登录判断 | 重要 | 判断登录用户等 | 系统 |
2 | 录入病人信息 | 重要 | 病人信息录入 | 医生 |
3 | 根据条件查询 | 重要 | 根据信息查询 | 医生/管理员 |
4 | 样本排序 | 重要 | 样本排序 | 医生 |
5 | 更新病人信息 | 重要 | 修改病人基本信息 | 医生 |
6 | 添加病人病历 | 重要 | 给系统添加病人病历 | 医生 |
7 | 下载数据 | 重要 | 下载病人数据 | 医生 |
8 | 数据信息上传 | 重要 | 上传病人数据 | 管理员 |
4.1.3 功能定义
(1)用户登录判断:对登录用户信息进行判断,防止非相关人员的登录。
(2)录入病人信息:对医生所诊断的病人的信息进行记录。
(3)根据条件查询:根据病人部分信息查询全面信息。
(4)样本排序:对数据库内的病人数据进行排序。
(5)更新病人信息:对老病人信息等进行更新。
(6)添加病人病历:对新病人添加病历。
(7)下载数据:下载数据库内病人的部分或全部信息。
(8)数据信息上传:数据上传人员上传部分信息。
4.2 功能描述
4.2.1 功能说明
(1)用户登录判断:只有医生(admin)和数据上传人员(gm)等可以登入。
(2)录入病人信息:包括病人姓名、出生日期、性别、住院号、身份证号、医院、癌症分型、抽烟史、酗酒史、吸毒史、其他不良生活习惯史、临床分析、主治医生邮箱。
病人病历包括:诊断描述、手术情况描述、放疗方案、放疗后状态、药物治疗后方案、药物治疗后状态、确诊时间、是否死亡、死亡时间、死亡原因
(3)根据条件查询:条件有三个,分别为身份证号、姓名和住院号。
(4)样本排序:根据存储编号排序。
(5)更新病人信息:可以更新之前创建全部的录入病人信息。
(6)添加病人病历:增加病人病历。
(7)下载数据:可下载由数据上传人员上传的病理样本。
(8)数据信息上传:数据上传人员上传对应病人的病理样本。
4.2.2 详细描述
采用数据流图的方法建立模型。
登录页面数据流图。
主界面数据流图。
查询功能数据流图。
更新病人信息数据流图。
数据下载数据流图。
添加样本数据流图。
数据上传数据流图。
5.性能需求
5.1数据精确度
(1)要按照严格的数据格式输入,不能输入非法字符,否则系统不给予响应进行处理。
(2)查询时要保证准确率为100%,所有包含查询关键字的记录都应能查到,不能有遗漏。
5.2时间特性
一般操作的响应时间应在1-2秒内。
5.3适应性
(1)满足医生和数据上传人员的使用需求,尽可能涵盖更多的信息。
(2)对前面提到的运行环境要求不应存在困难。
(3)对windows系列和ubuntu都适用。
6. 运行需求
6.1用户界面
6.1.1界面风格
遵循materialize框架的风格。
6.1.2界面描述和样式
(1)用户登录界面
(2)主页面
(3)病人信息录入界面
(4)数据下载界面
(5)数据管理界面
风格简洁大气,气质高雅,色彩明丽。
6.2硬件接口
(1)本系统不需要特定的硬件或硬件接口进行支撑。
(2)在windows系列和ubuntu上运行。
6.3软件接口
运行于windows系列和ubuntu系统。
6.4故障处理
正常使用时不应出错,若运行时遇到错误,退出程序后自动重启,并向开发小组发送错误信息。
7.其它要求
7.1检测或验收标准
(1)搜索数据库的故障率低于1%
(2)身份验证的故障率低于1%
(3)连接网站的失败率低于1%
7.2可用性、可维护性、可靠性、可转换性、可移植性要求
(1)本系统故障率低于5%
(2)系统要求模块设计
(3)系统可在windows系列和ubuntu系统上运行
(4)不支持移动设备
7.3安全保密性要求
无。
7.4开发要求
(1)用wampserver开发。
(2)按照黑盒测试方法测试用例进行验收。
本文档由精准医疗小组撰写,如需复制、使用本文请联系小组成员,谢谢。