某某项目需求功能规格说明书模板.docx

某某项目需求功能规格说明书模板.docx

《某某项目需求功能规格说明书模板.docx》由会员分享，可在线阅读，更多相关《某某项目需求功能规格说明书模板.docx（23页珍藏版）》请在冰豆网上搜索。

某某项目需求功能规格说明书模板

***项目

需求功能规格说明书

***

紫旭科技集团有限公司

2014年6月

批准人:

***项目经理

紫旭项目经理

作者:

紫旭

制定日期:

更新日期:

版本:

1.0

更改记录

日期

作者

版本

更改参考

紫旭

0.5

初版

紫旭

0.56

根据从化会议修订

紫旭

1.0

提出向专家汇报版本

审核人

姓名

职位

分发

副本号

姓名

地点

图例索引

●概述

⏹编写背景

***项目是为实现***及其附属医院“走进一家医院，八家医院为你服务”的战略目标，而具体执行的项目。

在本项目中首先实现跨5家附属医院患者和公众健康信息的共享，并基于该共享平台，扩展对患者和公众的附加服务、对科教研工作的支持、对医疗管理服务工作的支持功能。

为了使***及其所属医院的需求得到合理体现，使***及其附属医院的信息化建设适应并能够有效地支持***医疗信息共享系统的建设，编写此需求功能规格说明书明确在本项目中所完成的各项需求。

本说明书对项目后续的设计、开发、上线等阶段的工作具有明确的指导和规范作用。

⏹系统目标

联合***附属五家医院的医疗资源，充分发挥***医疗集团在临床、教育和科研上的优势，实现模式创新、资源优化、服务一流的***医疗服务体系；同时，为***五家附属医院提供医疗教育和科研的平台，使***在医、教、研上同步发展，达到国际先进水平是本项目的主要目标。

具体来说，本期系统建设将实现一网，即中大医疗网；两库，即电子病历库和医疗资源库；三平台，即患者服务平台、医教研协作平台与管理创新平台。

⏹系统概述

◆系统功能总体描述

在本项目范围内，将搭建医疗信息共享平台，提供相关的业务功能：

●建立医疗信息共享工程的基础平台，包括网络、数据中心、数据库等，建设数据采集平台、数据管理与存储平台、数据展现和门户系统；

●建立***门户系统，门户系统将成为医生、患者、管理者、科研人员进行交流的界面；

●通过门户网站实现对患者的服务功能，主要是对医院服务信息的浏览和个人就诊记录的查看；

●通过门户网站实现对医护人员的服务功能，主要是病患基本信息、就诊履历、检查报告及影像资料等的查看；

●通过对医院管理类的数据采集和统计，让学校和医院管理者能获取到自己职责和权限内的管理信息，支持医院的高效运作；

●通过对科研数据的采集和管理，让科研/教学人员能够获取相关的科研数据和信息，支持科研/课题的分析，支持科研的成果共享；

●五家医院信息共享；

本期系统将面向四大类用户，提供面向医生的中大电子病历服务、会诊与远程医疗服务、转诊与转检服务；面向患者的医院资源信息查询服务、健康教育和咨询论坛服务、个人电子健康档案服务、门诊预约挂号服务和一卡通服务；面向科教人员提供科研支持服务、教学支持服务、以及临床与管理知识库服务；面向管理者提供医疗服务质量监控服务、执业人员管理服务、医院管理统计分析服务和事件报告与分析服务。

其整体功能构架如图。

图1.1功能总体组件模型示意

整个系统采用SOA构架，遵循HL7与DICOM标准，支持HL7RIM模型；在界面设计上遵循人性化、简约性、多样性原则；系统在精度、时间特性、安全性、可靠性、可用性、易用性、可维护性及可扩展性方面满足本说明书所规定的需求。

◆系统用户综述

集成平台最终用户为以下几种类型：

角色类别

角色名称

描述

管理者

系统管理员

平台管理员

负责权限管理、分级管理员管理联系等

医院管理员

负责平台中与该医院相关的信息和业务管理

平台管理员

学校管理员

负责平台中与学校相关的信息和业务管理

平台管理员

论坛管理员

负责论坛总体事务

平台管理员

网站信息管理员

负责网站信息的维护和更新

平台管理员

系统用户

公众

任意互联网用户，可访问一般面向公众的信息

患者

在平台系统或医院信息系统中有记录的患者

平台管理员

医生

包括主治医生、一般医生等

医院管理员

专家（论坛）

被授权的医生、科教人员等，可以在论坛中解答患者咨询，并配有博客

论坛管理员

注册用户（论坛）

任意互联网用户，已在论坛注册

论坛管理员

科研人员

***内部科研人员，可访问专有的知识库和病历信息

学校管理员

教学人员

***内部教学人员，可访问专有的知识库和病历信息

学校管理员

管理人员

***及附属医院内部管理人员，可访问专有的管理服务模块

平台管理员

构建用户划分及用户应用时，主要考虑和遵循下列因素和规则：

⏹用户的分类

◆二级用户分类：

由用户的不同性质分为管理员和用户两大类，并根据应用需求进一步细分为13类用户；

◆分级管理机制：

构建分级管理的树型用户管理关系，减少集中式管理中管理员的工作负担，并与实际业务结合，实现责任制的管理机制；

⏹用户对信息的私有性

◆患者电子健康档案的私有性：

患者的健康档案仅由患者本人及当前主治医生可见，在进行隐私处理后可向科研和教学人员进行授权访问；

◆医院管理信息的私有性：

各医院只能查看自有医院的管理信息，以及中大医疗网处理后生成的公开信息；

⏹用户在应用中的约束性

◆电子健康档案应用约束：

如会诊中各医生对患者电子健康档案访问的时间性约束、科教人员对患者电子健康档案访问的颗粒度约束等

◆应用约束规则制定和管理：

平台系统中的各类应用中，针对不同用户类型制定相应的约束规则，并配合专员落实，由平台管理员等进行约束规则的管理及优化；

⏹用户在平台中的可维护性

◆用户行为审计：

用户在平台系统中的关键行为/操作将被作为历史记录进行存档，以作为信息处理的凭证；

◆用户信息管理：

用户信息，尤其是患者有关信息的变更，需要引入人工审核，同时，每次变更均保存完整的患者个人信息，作为历史记录存档。

⏹假设条件

◆系统功能流程遵循中大医统一规定的业务流程与规范，各附属医院均按此规范进行相关工作。

◆各附属医院根据中大医统一规定的数据共享内容与数据上传时间点，按时上传相关数据。

●业务概念定义与术语定义

⏹业务概念

***建设的核心是实现共享服务，即在本期项目中实现***所属的5家医院之间医疗信息的共享，充分发挥***医疗体系在医教研上的优势，最终实现模式上的创新，建立一体化的患者服务体系。

同时促进***在医、教、研上同步发展，达到国际先进水平。

主要业务概念包括：

◆区域卫生信息化（RegionalHealthInformationNetwork）

在一定区域范围内，为医疗服务提供者、卫生管理机构、患者、医疗支付方以及医药产品供应商等机构提供以数字化形式搜集、传递、存储、处理卫生行业数据的业务和技术平台，以支持医疗服务、公共卫生以及卫生行政管理的工作过程。

◆区域卫生信息组织（RegionalHealthInformationOrganization-RHIO）—

筹备、建设、管理和运维区域卫生信息网，并以区域卫生信息网为平台提供相关服务的机构。

⏹术语

在本报告中，主要用及的专业术语解释如下：

◆PMI：

患者主索引

在整个中大医疗网，唯一标识患者身份，通过它可获取完整的患者健康档案（EHR）。

◆SOA：

面向服务构架

它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。

接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。

这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。

◆HL7：

卫生信息交换标准（HealthLevel7）

标准化的卫生信息传输协议，是医疗领域不同应用之间电子传输的协议。

HL7汇集了不同厂商用来设计应用软件之间界面的标准格式，它将允许各个医疗机构在异构系统之间，进行数据交互。

●技术架构需求

⏹技术架构概述

***在系统架构上，主要建立三个平台，如下图所示。

图4.1中大医疗网平台系统示意图

第一，数据集成服务平台（简称数据采集平台）提供对***附属8家医院的信息集成，为上层应用平台的建设提供一个标准的、统一的数据视图和业务服务操作界面。

该平台主要由集成服务总线予以实现。

第二，信息管理和存储服务平台提供了对业务数据的集成存储、数据管理、服务提供和在线分析支持四部分核心服务内容。

第三，信息发布调阅服务平台提供了对共享工程数据的个性化展现的门户服务，及针对科研和医院管理的专业化业务分析和统计管理门户服务。

⏹技术架构框架

图4.7中大医疗网技术架构示意图

在系统拓扑层面上，整体技术架构分为中心端、网络、前置服务器、医院应用系统四个部分组成：

●功能性需求

⏹概述

系统面向四大类用户提供4大类服务，共15个服务与47个具体业务场景，如表。

主类

分类

业务场景

⏹[D.1]***服务

◆场景描述

场景编号

D.1.A

场景名称

场景描述

场景注释

主要客户

业务价值

本场景涉及人员角色包括患者、患者主管医生，涉及系统包括医院信息系统、中大医疗网，其基本场景如下图。

图5.4D.1-中大电子病历构建与应用场景示意

患者首次来中大某附属医院就诊，其主管医生对患者进行诊治，并将相关信息录入本院信息系统；系统依据中大医患者数据管理规范规定决定患者数据上传内容与时间点，各附属医院信息系统通过中大医疗网前置机将相关数据发往中大医疗网；中大医疗网根据中大医疗网患者电子病历建立流程与规范，创建该患者的中大电子病历；患者以后来中大任何一家附属医院就诊，主管医生向中大医疗网传递该患者ID或就诊卡号以及查询请求，中大医疗网可检索获得该患者PMI，并根据该PMI及医生需要返回该患者的中大电子病历数据。

中大电子病历包含患者基本信息、患者就诊信息、患者临床检验信息、患者检查信息（包含影像数据）以及患者电子病案信息，患者基本信息创建调用过程已经在患者主索引构建与应用一节中说明，以下逐一说明其它信息的具体创建与调用流程。

因各院信息化水平不同，各院所提供数据的质量与内容会有所差别。

在中大医疗网建立了中大电子病历的全集，各院可根据自己的实际情况尽可能提供数据，中大医疗网经过标准化后保存。

对于部分数据的缺失与不完整，中大医疗网在技术上不做要求，需通过行政手段干预。

所有上传电子病历文本数据至少保存20年。

◆涉及的行为角色列表

行为角色列表：

名称

描述

备注

患者

特定医院就诊的患者

主管医生

患者的主管医生

拥有该患者病历浏览权限

◆业务流程

●流程描述－D.1.A

流程编号

D.1.A

流程名称

患者就诊信息构建流程

描述

患者就诊信息构建流程描述

从何处开始

患者在中大某附属医院就诊

以何结束

患者就诊信息构建完成

输入

患者基本信息

输出

与PMI关联的患者就诊信息

服务使用者

患者主管医生

服务提供者

医院信息系统、中大医疗网

相关业务规则

中大电子病历建立流程与规范

患者在医院的就医过程和治疗手段相对信息系统是一个复杂的过程，患者每一次的就诊是过程相关的，而且对于实现临床数据共享和管理上的要求都具有参考价值。

就诊信息在中大系统内的各医院已有的信息系统中都已经是结构化的数据，在这些数据提交给中心系统时，需要将这些数据同时进行标准化，为整个医疗信息共享系统的其他业务服务，同时也为今后各种社会卫生范围内的统计分析提供标准化的基础数据。

构建患者的就诊记录需要从各医院的信息系统中收集数据，由于各医院都是异构的系统，因此要在数据交换平台上统一医院的数据标准，保证中心端数据格式的一致。

患者在中大系统内五家（扩展后是8家）医院中的任何一家医院就诊后，医院的HIS系统应将其完整的本次就诊信息传递给中心端，这些信息应包括相应的关联项。

完整的一次HIS系统中的就诊记录在门诊时是指患者的一次挂号后所产生的相关信息，包括：

挂号记录、诊断记录、医嘱记录、费用记录，其中医嘱记录中有可能包含处方和申请单以及相关的结果数据；一次完整的住院记录包括：

住院登记信息、诊断信息、医嘱明细、费用信息、病程录、病案首页、出院小结以及相关的医嘱单、执行单和结果数据。

信息的关联主要是指在门诊业务中，患者有可能在同一就诊日多次挂号（不同的就诊科室），在这种情况下HIS系统需要通过关联的信息区分不同的就诊记录，如果HIS系统无法在整个就诊记录中进行关联，中心系统将仅根据患者的主索引信息、就诊日期将患者的就诊记录关联起来，患者就诊科室以及相关的诊治记录可能无法匹配。

在住院记录中可以凭住院号和住院流水号进行关联。

就诊信息上传构建的业务流程如下：

图5.5D.1.A-患者就诊信息构建流程

中心系统接收到医院上传的就诊记录数据后，将对所有的数据进行校验，保证所有保存在中心系统的数据是合理有效的，对通过校验的数据分类后存入中心数据库中。

数据校验的目的是检查就诊记录中患者的信息是否符合标准，数据是否有关联，主要有以下两种情况：

一是得到就诊记录无法关联患者的主索引记录，这时需要从上传数据的医院重新取得主索引数据；二是上传的数据没有一致的关联性，即无法确认一次就诊记录，系统可以将此类记录进行标注，不做其他处理。

如果已经上传的数据在医院端出现了修改，中心端的数据也要做出相应的修正，保持与医院数据的一致性，但是在中心端所做的修正必须有完整的日志记录，便于日后查看和分析。

数据分类是将医院上传的数据按照中心端的统一定义重新进行结构化的存储，使各医院异构系统的数据在中心端统一。

●流程描述－D.1.B

流程编号

D.1.B

流程名称

患者就诊信息调阅流程

描述

患者就诊信息调阅流程描述

从何处开始

医生发出调阅指令

以何结束

调阅完成

输入

患者ID和查询条件

输出

历史就诊记录

服务使用者

主管医生

服务供应者

中大医疗网

相关业务规则

中大电子病历调阅流程与规范

医生在portal上通过其工作站发出查询指令，并给出查询条件（如：

患者ID，查询时间段等）后，查询指令将提交给中大中心系统，中心系统接受指令后进行身份认证，通过认证则中心系统根据医院提交的查询条件在数据库中进行查询，并将查询结果返回到发起查询的医生工作站上，同时在中心系统中记录日志。

未通过认证的则记录日志，说明未通过原因。

业务流程如下：

图5.6D.1.B-患者就诊信息调阅流程

◆相关数据说明

广义的中大电子病历的主要业务数据包括：

患者基本信息、患者就诊记录信息、检验报告信息、检查报告信息和患者病案信息。

●患者基本信息

参照患者主索引构建一节。

●患者就诊信息要求

患者就诊记录是患者在医院中一次就医的整体信息，包括挂号记录、住院登记信息、诊断信息、医嘱明细（处方和申请单）、费用信息，按照门急诊与住院的分类如下：

门急诊信息包含挂号记录、诊断记录、医嘱记录、处方信息、申请单信息；

住院信息包含住院记录、病程录、医嘱记录、手术记录、入出院诊断记录、病案首页、出院小结。

●检验报告数据要求

报告单信息：

主要信息包括医院信息、检验报告单号、被检人信息、诊断、标本信息等；

明细指标信息：

记录详细的检验内容（包括结果的范围值），含细菌结果和药敏结果；

●检查报告数据要求

报告单信息：

主要信息包括医院信息、检查报告单号、被检人信息、诊断、检查设备、部位信息等；如果没有结构化的报告，这些信息可能统一存在于DICOM数据中。

影像信息：

采用DICOM标准；

●电子病案要求

病历主表：

主要信息包括概要信息、诊断明细、手术明细等

出院小结：

中大电子病历涉及到的相关数据总结如下：

编号

数据类别

数据内容说明

1

患者基本信息

包含患者唯一号、患者姓名、性别、出生日期、身份证号、住址、婚姻状况、出生地、血型等基本信息

2

门诊患者就诊记录

包含就诊流水号、医院代码、就诊时间、就诊科室、就诊医生、诊断类型、诊断编码、患者主诉、既往病史、过敏史等信息

3

医嘱明细信息

包含医嘱ID、就诊流水号、医院代码、医嘱说明、下医嘱科室、下医嘱医生、申请单信息、药品信息等

4

收费明细信息

包含收费明细ID、就诊流水号、医院代码、收费项目编码、单价、数量、金额等

5

收费汇总信息

包含收费记录ID、就诊流水号、医院代码、总金额、医保金额、自费金额等

6

住院患者就诊记录

包含就诊流水号、医院代码、住院科室、住院时间、出院时间、床位、入院诊断、出院诊断、患者主诉、既往病史、过敏史、病程记录、体格检查记录、关键体征记录、诊疗方案、会诊记录等

7

手术记录信息

包含手术流水号、就诊流水号、医院代码、手术名称、手术医生、麻醉方式、麻醉医生等

8

检验报告信息

包含检验报告单号、就诊流水号、医院代码、检验项目ID与名称、报告日期、检验结果等

9

检查报告信息

包含检查报告单号、就诊流水号、医院代码、检查项目ID与名称、报告日期、检查结果报告等

10

影像数据

包含就诊流水号、医院代码、患者信息、符合DICOM的影像资料等

注：

为考虑平台系统的完整性及可扩展性，以及短期内的稳定性和实际业务状况，在系统中实现和保留了费用信息的数据结构，但在接口中是否上传该类数据有待进一步讨论决定。

●非功能性需求

⏹页面需求

◆页面设计原则

用户界面的元素包括界面主颜色、字体颜色、字体大小、界面布局、界面交互方式、界面功能分布、界面输入输出模式，要保持统一的风格。

总体而言应遵循以下原则：

●人性化原则

让对象和控件明显、直觉的、显而易见的。

在界面使用体现现实的技术。

对象和概念在面向对象的界面里应该类似它们在现实世界的样子。

当可能的时候，应该尽量避免对象的人造体现。

让系统的控件清晰可见并且功能易于识别。

使用视觉的或文字提示来帮助用户理解功能，记住关系，并识别当前系统状态。

鼓励直接的或自然的交互。

让用户直接地与对象交互并减少用户非直接的技术或过程。

识别一个对象并执行与它相关的任务，例如拿起电话的听筒来回答来电，在真实世界中往往不是一个独立的行为。

使用直接动作或交互技巧，用户界面不需要明显地单独地在一个序列中选择动作。

虚拟真实三维界面是特别设计成直接的交互。

●简约性原则

界面的组织不要按功能模块的思维来划分和拼凑，不要认为代码实现上是独立的两个对象，在界面上就要对应两个对象，而是以用户的工作任务和流程分析来组织；保持界面简单和直接，用户能从直觉的、便于使用的功能受益。

确保基本的功能明显地展现在用户面前，而高级的功能易于学习；尽量减少界面上的对象和动作的个数，但是能足以让用户完成每天的任务。

只有对用户任务分析后表明需要才把功能包括进去；为易于访问和使用而组织功能；避免设计一个混杂着功能的界面。

一个良好组织的界面只是在背后默默地支持用户更加高效地工作。

●支持性原则

提供主动的协助。

软件系统应该帮助用户执行各种各样的任务。

每个用户的系统知识和处理任务的能力不一样。

让软件系统能识别个体用户的能力并提供适当的协助。

以标题说明、提示、系统帮助的形式提供协助。

提供的协助信息应该是简单的、简明的和有效的。

同时也应该是灵活的。

系统应该能适应用户能力的提高，并培训用户达到独立使用系统的能力。

注意这种协助是主动的，而不是被动的，它不需要用户刻意去寻找帮助，不需要用户打售后支持电话，不需要用户寻找软件光盘来查阅说明书，甚至不需要用户打开联机帮助。

通过简单有效的形式提供随时随地的协助，但是这种协助不是硬推的形式，例如，强迫用户每次使用系统之前要阅读注意事项。

有些软件系统在每次启动时默认都会有一个欢迎界面，在这个界面提供系统的简介，帮助用户如何开始使用系统，帮助用户导航到联机帮助文档或例子。

●多样性原则

支持替代的交互方式。

让用户选择一个适合特定情形的交互方式。

每一种交互设备都是为了特定的用户使用而优化设计的，没有一个唯一的交互方式是在任何情况下都是最好的。

因此，拥有不同的交互方式选择的界面能适应更大范围的用户技能、物理能力、交互习惯和工作环境。

让用户能够在不同的方式之间切换来完成一个交互过程。

例如，允许用户使用鼠标快速地定位，然后通过键盘来调整选择。

为不同能力和不同工作环境的用户提供广泛的交互方式。

除此之外，还要考虑页面的安全性和个性化。

在项目进入设计阶段时要首先开始用户界面原型的设计，并且所有最终确定的界面作为需求分析中功能的实例。

◆页面风格定义

导航栏

提供整体功能模块导航，各页面采用共用窗口链接方式，根据实际业务需要可采用顶层导航和左页导航的方式。

用户操作栏

提供用户人机交互界面，根据业务需要安排在页面中部或右上部

信息栏

基础信息显示在页面中部，附属信息（结果信息）在页面中下部

版权信息栏

属于整个网站主体框架，位置固定不变，一般在右下角

颜色、图标、字体、控件风格由项目统一规定。

⏹数据库服务器性能需求

⏹应用服务器性能需求

⏹系统性能需求

⏹外部接口需求

⏹业务容量需求

⏹输人输出要求

⏹数据管理要求

⏹其他需求

⏹正常运行时段：

365天×24小时

⏹系统维护时段：

按照系统与平台的业务类型和业务特点，其主系统应当至少满足99.9%的可用性（允许平均每月有40分钟左右的维护时间）

⏹批量作业时段：

每天凌晨0：

00至4：

00

⏹高峰业务时段：

每天8：

00-18：

00

⏹审计日志：

需要对文档交换过程进行审计，安全审计，对所有文档的发布、检索、获取进行全程审，并对审计结果进行日志记录，考虑定期清理审计日志；

⏹业务日志：

（用户登录、可维护性日志）记录系统用户登陆日志和操作日志，其中操作日志主要包括数据增加、删除和修改的日志，考虑系统访问量和系统性能，查询操作不考虑记录日志，并考虑定期清理历史日志。