患者监护系统模型分析

患者监护系统模型分析

【摘要】当代社会，计算机发展遍布各个行业，对医院来说，拥有一套完善的计算机辅助系统，对医院的生存及竞争将具有深远意义。病人住院需护士监护，随着医院规模及病人的增加，医院就需大量护士，并且人具有局限性，不可能不间断的监测病人病情及生理信号，这时候，就需要一套患者监护系统，对病人实施全天候监护。本文通过研究患者监护系统的不同模型，运用计算机知识，得到相关模型，使病人得到最佳的监护。

【关键词】医院；患者监护系统；模型

1 问题陈述

目前住院病人主要由护士护理，这样不仅需要大量护士，而且由于不能随时观察危重病人的病情变化，还可能会延误抢救时机。某医院打算开发一个以计算机为中心的患者监护系统。1）写出问题定义，并分析开发这个系统的可行性。2）建立它的对象模型，动态模型，功能模型及用例模型。

医院对患者监护系统的要求是随时接收每个病人的生理信号（脉搏、体温、血压等），定时记录病人情况形成患者日志，当病人的生理信号超出医生规定的安全范围时向值班护士发出警告信息，同时护士还可以要求系统印出某个指定病人的病情报告。

2 问题定义及分析

2.1 问题定义：在医疗监护系统中，由“病人”，“护士”和“时钟”组成数据源点，它们的功能分别为：产生生理信号，要求病情报告，产生病情日期和时间以供护士定时取样，由接收警告信息和病情报告的护士组成数据终点，从而通过计算机对整个系统进行操作，护士可以随时接收每个病人的生理信号，使患者及时得到治疗。

2.2 可行性分析：上述问题可以通过患者监护系统接收生理信号，要求报告，产生病情的日期及时间来发出警告信息及病情报告，使护士及时掌握病人的情况，控制病人病情。因此开发此系统具有可行性。

3 对象模型

3.1 对象模型表示静态的，结构化系统的“数据”性质。它是对模拟客观世界实体的对象以及对彼此间关系的映射，描述了系统的静态结构。

3.2 从对患者监护系统问题陈述中，可找出下列名词作为对象的候选者：患者监护系统、医院、患者、护士、护理、危重病人、随时、接收、生理信号、定时、记录、患者日志、超出规定的安全范围、值班护士、警告信息、病情报告。

通常，通过此分析找到的候选对象中有许多并不是问题域中真正有意义的对象，必须对这些候选对象进行严格的筛选，只保留应该记录的信息或需要提供服务的那些对象。

具体说到患者监护系统，本软件系统的主要功能是监护患者病情、“患者”、“病人”、“危重病人”是同义词，都是被监护对象名；“值班护士”、“护士”是同义词，都是监护者对象名；“护理”、“接收”、“记录”是护士监护的属性；“随时”和“定时”都是时间和日期的属性；“生理信号”、“患者日志”都是病人病情的属性；“超出规定的安全范围”是患者安全范围的属性。

接下来分析确定问题域中对象彼此之间的关系。“警告信息”和“病情报告”有许多共同点，可从其中泛化一个父类“生理信号”；“随时”和“定时”有许多共同点，可泛化出一个父类“时钟”。此外，问题域的对象之间还有下述关联关系：一名护士可护理一名病人也可能护理多名病人；一名护士某一时刻只能接收一份病情报告也可能没有接收到病情报告；一名病人只能有一名护士护理也可能有多名护士护理。

综上所述，画出患者监护系统的对象模型。

4 动态模型

4.1 动态模型表示瞬时的，行为化的系统的“控制”性质，规定了对象模型中对象的合法变化序列。建立起对象模型之后，就需考察对象的动态行为。所有对象都具有自己的生命周期。对一个对象来说，生命周期由许多阶段组成，在每个特定阶段中，都有适合该对象运行规律和行为规则，用以规范对象的行为。生命周期中的阶段也就是对象的状态。

通常，用UML提供的状态图来描述对象的状态，触发状态转换的事件及对象的行为。

4.2 状态图描绘系统中的状态转换，患者监护系统功能是实现对患者的实时监测，根据需求可画出患者监护系统状态图。

5 功能模型

5.1 功能模型表示变化的系统的“功能”性质，它指明了系统应该“做什么”，因此更直接地反映了用户对目标系统的需求。通常，功能模型由一组数据流图组成。

5.2 从问题陈述可知，本系统的数据源点是“病人”和“护士”，他们分别提供生理信号和要求病情报告的信息。进一步分析问题陈述，从系统应该“定时记录病人情况以形成患者日志”这项要求可以想到，还应该有一个提供日期和时间信息的“时钟”作为数据源点。

从问题陈述容易看出，本系统的数据终点是接收警告信息和病情报告的护士。

系统对病人生理信号的处理功能主要是“接收信号”、“分析信号”和“产生警告信息”。此外，系统还应该具有“定时取样生理信号”，“更新日志”和“产生病情报告”的功能。

为了分析病人生理信号是否超出了医生规定的安全范围，应该存储“患者安全范围”信息。此外，定时记录病人生理信号所形成的“患者日志”显然也是一个数据存储。因此，可画出本系统的功能级数据流图。

6 用例模型

6.1 UML提供的用例图也是进行需求分析和建立功能模型的强有力工具。在UML中把用用例图建立起来的系统模型称为用例模型。

通常，软件系统的用户数量庞大，每个用户只知道自己如何使用系统，但是没有人准确地知道系统的整体运行情况。因此，使用用例模型代替传统的功能说明，能够更好地获取用户需求，它所回答的问题是“系统应该为每个（或每类）用户做什么”。

用例模型描述的是外部行为者所理解的系统功能。用例模型的建立是系统开发者和用户反复讨论的结果，它描述了开发者和用户对需求规格所达成的共识。

6.2 一幅用例图包含的模型元素有系统，行为者，用例和用例之间的关系。

用例（Usecase）就是“使用待开发的软件的过程案例”；用例模型反映了站在使用者的角度看到的，未来的软件要被怎样地使用的全部信息。

6.3 用例特征

（1）用例代表某些用户可见的功能，实现一个具体的用户目标；

（2）用例总是被行为者启动的，并向行为者提供可识别的值；

（3）用例必须是完整的。

6.4 用例是一个类，它代表一类功能而不是使用该功能的某个具体实例。

6.5 上述患者监护系统的用例图可根据问题陈述画出。

7 结束语

UML是一种建模语言，通过对上述问题的对象模型，动态模型，功能模型