【毕业学位论文】（Word原稿）移动临床助理信息系统的设计与实现-软件工程

职业型硕士博士（打印时删除） 硕士学位论文 （专业学位） 移动临床助理信息系统的设计与实现 姓 名： 学 号： 所在院系： 职业类型： 专业领域： 指导教师： 副指导教师： 二 一三年三月 in 2012 动临床助理信息系统的设计与实现 姓名 同济大学 位论文版权使用授权书 本人完全了解同济大学关于收集、保存 、使用学位论文的规定，同意如下各项内容：按照学校要求提交学位论文的印刷本和电子版本；学校有权保存学位论文的印刷本和电子版，并采用影印、缩印、扫描、数字化或其它手段保存论文；学校有权提供目录检索以及提供本学位论文全文或者部分的阅览服务；学校有权按有关规定向国家有关部门或者机构送交论文的复印件和电子版；在不以赢利为目的的前提下，学校可以适当复制论文的部分或全部内容用于学术活动。 学位论文作者签名： 年 月 日 济大学学位论文原创性声明 本人郑重声明：所呈交的学位论文，是本人在导师指导下，进行研究工作所取得的成果。除文中已经注明引用的内容外，本学位论文的研究成果不包含任何他人创作的、已公开发表或者没有公开发表的作品的内容。对本论文所涉及的研究工作做出贡献的其他个人和集体，均已在文中以明确方式标明。本学位论文原创性声明的法律责任由本人承担。 学位论文作者签名： 年 月 日 硕士学位论文 摘要 I 摘要 临床医疗过程是指患者在住院、手术、复苏、 院的一系列疾病处理过程，是医院业务的重要环节，一般占医院业务的 75%以上。一般医院的信息化项目仅仅限于 临床医疗领域都是空白。 2012年是卫生部推行临床应用系统的开局之年，作为临床领域的重要工作环节之一，移动临床助理信息系统必将成为各大医院在信息化领域建设的重中之重。 天津市儿童医院是我市的一所三级甲等医院，全院共有 18 张 、 8 张和近 100 张普通病房床位。明年，医院将计划搬迁至新院址，同时实现医院临床医疗信息化的全覆盖，将原有临床医疗领域的所有工作流程全部建立新的信息化管理系统。作为医院在“十二五”期间的重点建设项目，该项目将完全实现医院在临床治疗过程中信息处理的自动化与无纸化，是医院推动临床应用系统信息化建设的重要一环。 本文围绕围绕移动临床助理信息系统的项目实施，系统地阐述了系统所涉及的技术知识、临床医疗领域知识，并从业务流程、功能描述、数据流、数据字典四方面对系统各个子系统均进行了详尽的分析。从设计 流程、软件结构、程序设计对系统的主要功能模块进行了详尽的设计，将系统设计为“数据交换子系统”和“临床医疗管理子系统”两个子系统。“数据交换子系统”主要负责对临床医疗设备数据的自动采集功能；“临床医疗管理子系统”主要完成医生在临床环节的查房、监测、诊疗等全过程。论文的最后对系统进行了总结，并对其进一步的完善提出了展望。 关键词： 床医疗、监护、I he is to in a of in is an of 5%. is in 2012 is of of of of as of of in s is s of 8 00 to to at to of of of As a in in be in of is an of a of in in is in of of of is of is to in of At of is CA,硕士学位论文 目录 录 第 1章 引言 . 1 1 1 概述 . 1 1 2 国内外的研究现状 . 1 1 3 论文的主要研究内容 . 2 1 4 论文的章节结构 . 3 第 2章 系统开发环境 . 5 2 1 . 5 2 1 1 . 5 2 1 2 000 . 6 2 2 . 6 2 3 1 . 6 2 3 2 . 8 第 3章 系统需求分析 . 10 3 1 基本功能需求 . 11 3 1 1 围术期基本业务功能 . 11 3 1 2 临床医疗设备数据采集功能 . 13 3 2 可行性研究 . 21 3 2 1 经济可行性分析 . 21 3 2 2 技术可行性分析 . 21 3 3 需求分析 . 错误 !未定义书签。 3 3 1 数据交换子系统的需求分析 . 14 3 3 2 临床医疗管理子系统需求分析 . 17 3 4 非功能需求 . 22 3 5 运行环境需求 . 26 3 5 1 软件环境 . 26 3 5 2 硬件环境 . 27 第 4章 数据交换子系统设计 . 28 4 1 系统设计思路 . 28 4 2 系统设计目标 . 错误 !未定义书签。 4 3 系统设计原则 . 错误 !未定义书签。 4 4 系统开发平台及架构设计 . 29 4 4 1 系统开发平台 . 29 4 4 2 系统体系架构设计 . 29 硕士学位论文 目录 5 系统模块设计 . 30 4 5 1 设备自动识别功能设计 . 30 4 5 2 设备及参数动态配置功能设计 . 31 4 5 3设备在线管理功能的设计 . 32 4 5 4 数据在线申请与撤销功能的设计 . 33 4 5 5 数据发送服务功能的设计 . 33 4 6 数据架构设计 . 34 4 6 1 设备配置文件架构设计 . 34 4 6 2 数据传输文件架构设计 . 37 第 5章 临床医疗管理子系统设计 . 39 5 1系统开发平台及架构设计 . 39 5 2 临床医疗管理子系统模块设计 . 39 5 2 1 患者入室模块主要功能设计 . 39 5 2 2 体征数据监护模块主要功能设计 . 40 5 2 3 医生查房模块主要功能设计 . 42 5 2 4 患者出室模块主要功能设计 . 43 5 2 5 医生交班模块主要功能设计 . 43 5 2 6 医疗文书管理模块主要功能设计 . 44 5 2 7 系统管理模块主要功能设计 . 44 5 3 临床医疗管理子系统数据库设计 . 44 5 3 1 数据库的设计规范 . 44 5 3 2 核心数据表设计 . 45 第 6章 系统实现 . 49 6 1 数据交换子系统核心功能实现 . 49 6 1 1 网络通信接口的实现 . 49 6 1 2 数据通信实现 . 50 6 1 3 数据解析的实现 . 51 6 1 4 服务器在线管理的实现 . 53 6 2 临床医疗管理子系统核心功能的实现 . 54 6 2 1 坐标轴的绘制 . 64 6 2 2 加药图形的绘制 . 64 6 2 3 辅治疗图形的绘制 . 66 6 2 4 数据波形的绘制 . 67 第 7章 系统测试及绩效分析 . 68 7 1 测试方法 . 68 7 2 数据交换子系统测试 . 68 硕士学位论文 目录 V 7 3 临床医疗管理子系统测试 . 69 7 4 结果分析 . 70 7 5 系统性能测试 . 70 7 6 数据交换子系统绩效分析 . 71 7 7 临床医疗管理子系统绩效分析 . 72 7 8 总体绩效分析 . 73 第 8章 结论和展望 . 74 8 1 结论 . 74 8 2 进一步工作方向 . 74 致谢 . . . . . . . . . . . . . . . . . .考文献 . 76 附录 A 个人论文发表情况 . 77 个人简历、在读期间发表的学术论文与研究成 果 . 错误 !未定义书签。 章 引言 1 第 1章 引言 1 1 概述 临床医疗过程是指患者在住院、手术、复苏、 院的一系列疾病处理过程，是医院业务的重要环节，一般占医院业务的 75%以上。一般医 院的信息化项目仅仅限于 系统，在临床医疗领域都是空白。 2012 年是卫生部推行临床应用系统的开局之年，作为临床领域的重要工作环节之一，移动临床助理信息系统必将成为各大医院在信息化领域建设的重中之重 1。 天津市儿童医院的前身是妇婴医院， 1951 年更名为天津市儿童医院，经过几十年的发展壮大，它已经成为我市唯一一所三级甲等综合性儿科医院。它集医疗、教学、科研、预防、保健、康复为一体，是我国儿科医疗保健中心之一，其服务辐射华北地区。医院总面积 55173平方米，其中医疗用房 43864 平方米。 全院开放床位 521张，年收治住院患者约 2万余人，门诊量 140余万人。医院始终坚持 “ 以患者为中心，全心全意为患儿服务 ” 的办院宗旨。 2000 年改扩建后，就医环境得到了明显改善。 2001 年获全国首批 “ 百姓放心医院 ” 称号， 2007 年顺利通过三甲医院复审。医院拥有较强的专业技术力量，内科 0以上；心脏内科应用介入疗法治疗动脉导管未闭、单纯性肺动脉瓣狭窄、房（室）间隔缺损及复杂性先天性心脏病的诊断，居国内先进水平；微创外科是全国儿童医院中建立最早的学科之一，目前开展的手术种类 有 30 余种，治疗病种及手术例数居国内首位，在全国小儿微创外科占主导地位；心脏外科应用经胸膜外手术结扎未闭动脉导管、急症手术救治先天性心脏病合并心力衰竭的高危新生儿，最小年龄为生后 14 小时，获得卫生局科技进步奖；耳鼻喉科在全国儿童医院中最早获得开展儿童人工耳蜗植入手术资质，现已利用该技术帮助 20余位聋儿重获听力和语言功能，效果良好。 目前全院共有 18张 8张 和近 100张普通病房床位。明年，医院将计划搬迁至新院址，同时实现医院临床医疗信息化的全覆盖，将原有临床医疗领域的所有工作流程全部建立新的 信息化管理系统。作为医院在“十二五”期间的重点建设项目，该项目将完全实现医院在临床治疗过程中信息处理的自动化与无纸化，是医院推动临床应用系统信息化建设的重要一环。 1 2 国内外的研究现状 章 引言 2 随着我国医疗信息化建设的逐渐深入， 而代之的则是临床应用系统建设的逐步展开 1。今年是卫生部推行临床医疗信息化建设的第二个年头，全国各大医院都在极力建设部署各类临床医疗应用系统。作为临床信息化应用的重要环节，移动临床助理系统已经成为了各大医院建设的重点对象。 在国外， 由于医院信息化建设思路不同（率先进行临床应用系统建设，而非在临床应用系统的开发方面实施的较早，尤其是法国、芬兰、英国、美国等国家在上世纪 90 年代就已经开始涉及临床应用系统的开发研究，目前已经有了比较成熟的产品，最著名的是奥迪玛手术管理系统、奥迪玛临床助理系统。但是，由于与我国的临床医疗工作在管理模式上存在较大的差别，这些产品很少在国内得要应用 2 3。 近两年 ，我国 一些医疗软件开发商也开始研发临床应用系统，但是由于起步较晚，技术相对落后。目前国内在临床应用系统的开发上主要存在以下问题 ： a) 系统结构存在缺陷：术中患者的体征参数数据记录是临床应用系统的一项核心功能，很多系统为了保证数据的完整性，将医疗设备发送的数据完整的记录下来并且实时保存到数据库当中。一般情况下，医疗设备发送数据的频率是500多台手术同时进行的情况下，将会造成数据库服务器负载严重，00%，使得系统运行效率降低，甚至出现错误。 b) 系统灵活性差：不同的医院在业务流程上往往存在差异，而且各种医疗文书的种类样式也不尽相同。在医院的业务的不断发展过程中，也经常会出现业务流程变化的情况，同时也可能会 出现各种新型的医疗文书。这就需要系统拥有较高的灵活性，可以针对不同的医院对业务流程和权限进行动态调整，同时对于医疗文书模板可以进行灵活的配置。 c) 系统兼容性问题：国内很多的临床应用系统往往只针对一种品牌的设备进行连接，很大程度上是为了配合医疗设备的销售来进行的。这样对于医院原有的其他品牌的设备获取数据将需要进行二次开发，兼容性较差 5。 d) 盲目开发，缺乏重点：国内市场上流行的临床应用系统往往只将重点放在辅助记录的环节上，有很多功能都和医院的 者更接近于电子病历系统。殊不知临床应用 系统最重要的部分在于其体征数据的采集和利用，应该利用计算机超强的计算能力对体征数据进行分析，描绘体征变化趋势，根据医学公式进行计算，以辅助医生对患者病情的变化和治疗。 1 3 论文的主要研究内容 章 引言 3 本课题是基于 C/设计的过程中，使用而制定出可行的开发方案对系统进行设计与开发，并在系统部署后通过测试和绩效分析对系统进行进一步的评估。 本文的主要工作包括： 1. 深入天津市儿童医院 利用 行分析，完成了移动临床助理信息系统的需求分析，并画出了相关的用例图。 2. 对相关的技术进行学习和分析，掌握了微软的 台开发技术，掌握了C#语言以及 据库的开发技术。 3. 对移动临床助理信息系统进行了总体结构设计以及功能设计。决定采用 C/把该系统划分为“数据交换子系统”和“临床医疗管理子系统”两个子系统进行设计。其中“数据交换子系统”负责对临床医疗设备的连接、数据自动采集等进行管理；“临床医疗管理子系统”负责对医生查房、监测、诊疗等信息进行处理。 4. 对该系 统进行了详细设计，包括数据库设计、各模块的处理逻辑设计以及数据通讯 进行了详尽的描述。 5. 对系统按照功能设计进行编码实现，并在论文中论述了各功能的关键实现代码。 6. 对系统进行部署和测试，并经过一段时间的使用，对系统进行绩效分析并给出系统进一步改进的建议。 1 4 论文的章节结构 针对以上研究内容，论文分为五大章节，每个章节内容如下： 第 1 章：引言。主要说明了论文的研究背景、研究内容和方向等。 第 2 章：系统开发环境。主要描述了移动临床助理系统的架构和研发过程中所涉及的开发工具、开发平台以及相关的理论 依据等。 第 3 章：系统需求分析。按照移动临床助理的实际工作流程，系统说明业务管理流程，阐述客户化需求，充分使用用例图说明系统的实现要求和目的。 第 4 章：数据交换子系统设计。依据各类监护设备数据输出的行业规范，结合临床医疗流程和特点，设计出系统最核心的无线数据采集模块。 第 5 章：临床医疗管理子系统设计。 第 6 章：系统的实现。挑选具有代表性的关键代码和后台过程， 章 引言 4 能模块的实现方法。 第 7 章：系统的实施和绩效分析。选择典型功能界面，测试程序的运行情况和执行结果。 第 8 章：结论和展望。章 系统开发环境 5 第 2章 系统开发环境 本章 主要介绍移动临床助理系统（ 以下简称 系统架构和研发过程中所用到的软件工具、系统平台以及相应的数据库后台等技术条件。 2 1 软件开发工具 统主要包括数据交换和 户端两个子系统。系统的主要工作在于对硬件接口的访问、高强度的数据处理、稳定的网络数据传输，以及在监控过程中完成大量的图形绘制工作，这就需要我们选择功能完善、具有强大类库支持的开发工具。为此，我们采用了美国微软公司的 008 基于 行设计开发。 在通常的软件设计模式中，往往可以很方便的利用数据库软件来实现结构化数据的运算。但是在 统中，需要处理的数据量极大，如果靠数据库系统来完成则很容易使其成为瓶颈。为了保证系统运行的稳定性和高效性，我们在设计系统结构的时候将大量的数据处理功能都放在了客户端。因此，在数据库开发方面，为了保证系统运行具有更高的稳定性和兼容性，我们选择了具有高效的数据通信能力且同样为微软公司旗下产品的 000 进行设计开发 6。 2 1 1 架（ 是由微软开发，一个致力于敏捷软件开发（ 快速应用开发（ 平台无关性和网络透明化的软件开发平台。 微软为下一个十年对服务器和桌面型软件工程迈出的第一步。 含许多有助于互联网和内部网应用迅捷开发的技术。 架是一个多语言组件开发和执行环境，它提供了一个跨语言的统一编程环境。 架的目的 是便于开发人员更容易地建立 用程序和 务，使得 的各应用程序之间，可以使用 务进行沟通。从层次结构来看， 架又包括三个主要组成部分：公共语言运行时（ 服务框架（ 上层的两类应用模板 传统的 用程序模板（ 基于 章 系统开发环境 6 公共语言运行时（ 是一个运 行时环境，管理代码的执行并使开发过程变得更加简单。 一种受控的执行环境，其功能通过编译器与其它工具共同展现。 在 上的是服务框架，它提供了一套开发人员希望在标准语言库中存在的基类库，包括集合、输入 /输出、字符串及数据类 6。 2 1 2 000 000 是 司推出的 据库管理系统的一个版本。 000 关系数据库引擎支持当今苛刻的数据处理环境所需的功能。数据库引擎充分保护数据完整性，同时 将管理上千个并发修改数据库的用户的开销减到最小。 000 分布式查询使您得以引用来自不同数据源的数据，就好象这些数据是 000 数据库的一部分，同时分布式事务支持充分保护任何分布式数据更新的完整性。复制同样使 程序 得以维护多个数据复本，同时确保单独的数据复本保持同步。可将一组数据复制到多个移动的脱接用户，使这些用户自主地工作，然后将他们所做的修改合并回发布服务器。 其优点主要包括： 充分利用 优势。 持 形化管理工具，支持本地和远程的系统管理和配置。 用各种方法保证数据的完整性。 储过程、 具有自主的 言。 其内置的数据复制功能、强大的管理工具、与 紧密集成和开放的系统结构为广大的用户、开发人员和系统集成商提供了一个出众的数据库平台 7。 2 2 计模式及实施环境 2 3 1 计模式 在传统的计算机软件体系结构中，最主要的软件设计结构有 C/。 C/S 结构软件（即客户机 /服务器模式）分为客户机和服务器两层，客户机不是毫无运算能力的输入、输出设备，而是具有了一定的数据处理和数据存储能力，通过把应用软件的计算和数据合理地分配在客户机和服务器两端，章 系统开发环境 7 低网络通信量和服务器运算量。由于服务器连接个数和数据通信量的限制，这种结构的软件适于在用户数目不多的局域网内使用。国内目前的大部分 务）软件产品即属于此类结构 14。 B/S（浏览器 /服务器模式，即 随着 术的兴起，对 C/S 结构的一种改进。在这种结 构下，软件应用的业务逻辑完全在应用服务器端实现，用户表现完全在 务器实现，客户端只需要浏览器即可进行业务处理，是一种全新的软件系统构造技术。这种结构更成为当今应用软件的首选体系结构。 e 通管理系列产品即属于此类结构 14。 两种数据结构的区别主要包括： a) 数据安全性比较。由于 C/S 结构软件的数据分布特性，客户端所发生的火灾、盗抢、地震、病毒、黑客等都成了可怕的数据杀手。另外，对于集团级的异地软件应用， C/S 结构的软件必须在各地安装多个服务器，并在多个服务器之间进行数据同步。如此一来，每个数据点上的 数据安全都影响了整个应用的数据安全。所以，对于集团级的大型应用来讲， C/S 结构软件的安全性是令人无法接受的。对于 B/S 结构的软件来讲，由于其数据集中存放于总部的数据库服务器，客户端不保存任何业务数据和数据库连接信息，也无需进行什么数据同步，所以这些安全问题也就自然不存在了。 b) 数据一致性比较。在 C/S 结构软件的解决方案里，对于异地经营的大型集团都采用各地安装区域级服务器，然后再进行数据同步的模式。这些服务器每天必须同步完毕之后，总部才可得到最终的数据。由于局部网络故障造成个别数据库不能同步不说，即使同步 上来，各服务器也不是一个时点上的数据，数据永远无法一致，不能用于决策。对于 B/S 结构的软件来讲，其数据是集中存放的，客户端发生的每一笔业务单据都直接进入到中央数据库，不存在数据一致性的问题。 c) 数据实时性比较。在企业级应用里， C/S 结构不可能随时随地看到当前业务的发生情况，看到的都是事后数据；而 B/S 结构则不同，它可以实时看到当前发生的所有业务，方便了快速决策，有效地避免了企业损失。 数据溯源性比较。由于 B/S 结构的数据是集中存放的，所以总公司可以直接追溯到各级分支机构（分公司、门店）的原始业务单据，也 就是说看到的结果可溯源。大部分 C/S 结构的软件则不同，为了减少数据通信量，仅仅上传中间报表数据，在总部不可能查到各分支机构（分公司、门店）的原始单据。 d) 服务响应及时性比较。企业的业务流程、业务模式不是一成不变的，随着企业不断发展，必然会不断调整。软件供应商提供的软件也不是完美无缺的，所以，对已经部署的软件产品进行维护、升级是正常的。 C/S 结构软件，章 系统开发环境 8 应用是分布的，需要对每一个使用节点进行程序安装，所以，即使非常小的程序缺陷都需要很长的重新部署时间，重新部署时，为了保证各程序版本的一致性，必须暂停一 切业务进行更新（即“休克更新”），其服务响应时间基本不可忍受。而 B/S 结构的软件不同，其应用都集中于总部服务器上，各应用结点并没有任何程序，一个地方更新则全部应用程序更新，可以做到快速服务响应。 e) 网络应用限制比较。 C/S 结构软件仅适用于局域网内部用户或宽带用户（ 1兆以上）；而我们的 B/S 结构软件可以适用于任何网络结构（包括 号入网方式），特别适于宽带不能到达的地方（例如迪信通集团的某些分公司，仅靠电话上网即可正常使用软件系统）。 在监控过程中，需要处理大量的患者体征数据、加药信息，有些数据可 以通过临床医疗设备获取，有些则需要医护人员通过 户端进行录入。监护过程是一项非常紧张而又复杂的工程，尤其在抢救过程中。因此，系统必须采用C/S 的设计模式，在系统界面中实时描绘患者的体征数据，并为医护人员提供便捷的交互操作界面 14 15。 2 3 2 施环境 客户端主要部署在 房及各普通病房中，按科室进行部署。一般的医院都是一个科室的病房占一层楼甚至于两层楼。因此， 设计时采用了病房内通过无线网络覆盖，病房外通过有线网络进行数据传输的方式，这样各病房床位之间的无线网络 可以稳定运行，并且不会互相干扰，从而保证了系统既具有较高的稳定性、灵活性和便捷性，同时也在医生监护和家属陪护过程中尽量避免有线连接给医护人员带来的干扰。 为了保证 设计的时候，我们将 数据库服务器和数据交换服务器部署在 过局域网与各病房及床位进行连接。而数据库服务器通过医院主干网同 统连接进行数据交换。 章 系统开发环境 9 图 章 系统需求分析 10 第 3章 系统需求分析 顾名 思义，系统需求分析就是针对所要完成工作任务或者达到某些目标的具体分析。它从客户的使用方角度出发，依据规定的计划和目标，逐渐创建和完善系统，尤其注重系统的性能、参数、动作等。最开始的应该是可行性分析，其中的需求调研最为基础，包括：调研对象和调研方法。调研对象指人与人、人与事物、事物与事物等。调研方法关键是明确业务流程和知识点，需要咨询行业专家或专业顾问。良好的调研人员解决问题的同时还能获取更丰富的知识，最终成为业内专家。程序的设计开发必须具有坚实的系统需求调研和分析，细致入微的需求分析会使程序设计更加合理和人 性化 7。 按照软件工程的标准，需求分析应该是较为重要的环节。如果没有务实的需求调研和详细的系统分析，根本不能符合用户的实际要求，更谈不上编程和使用了。软件工程的目标是提高系统程序的质量与生产率，最终实现软件的工业化生产。质量是软件需求最关心的问题，而生产率是软件供应方最关心的问题。软件工程的步骤分为：人员管理、项目管理、可行性与需求分析、系统设计、程序编码、测试、维护等 15。 图 件工程的组织环节和线性模型 软件工程指导软件开发和维护。软件的开发模型包括：快速原型模型、增量模型、螺旋模型 、喷泉模型等。针对投产系统的智能化改良和升级都有稳定的系统基础和扎实的实践基础，所以采用了最为稳妥的增量模型 8。 章 系统需求分析 11 图 型的增量模型 3 1 基本功能需求 天津市儿童医院将于 2013 年正式迁入新院址，在新院址的建设过程中，对原先的 统进行了升级改造，同时也将逐步开展各类临床应用系统的建设，实现全院业务的信息化、自动化。 为天津市儿童医院在“十二五”期间的重点建设项目，对于医院提高整体信息化水平有着极其重要的意义。 设计将比床旁设备具有更高的可控性，设置功能更加齐全，更有效地保 障患者的生命安全和健康恢复。 设计将立足于医院监护室的实际业务流程，实现患者体征数据、加药信息的自动描记，患者体征数据分析计算，全面实现临床医疗信息的电子化，工作流程的自动化。 下面，我们将从临床医疗业务领域对系统功能进行提取，并对临床医疗的基本业务功能和数据采集业务功能进行解构，并从功能架构上将系统分为“数据交换子系统”和“临床医疗管理子系统”，并对两个子系统进行需求分析的确定。 3 1 1 临床医疗基本业务功能 临床医疗管理的基本对象是患者的监护，用户包括主治医生及护士。主治医生在临床医疗管理的主 要工作包括以下几个方面： a) 患者入室 章 系统需求分析 12 如果患者是在经过门诊或急诊后确诊需要入院治疗，医生将会为患者开去住院申请单，护士站的护士将根据病房的床位情况为患者安排床位入住；如果患者是手术后需要转入 行监护治疗，则是从普通病房转入，流程和门诊入院稍有不同，但统称为“入室”。入住后，护士站将根据患者的情况填写一系列医疗文书，并为患者建立住院病历档案。 患者入室后，医生将根据患者的病情下医嘱，护士站接收医嘱后进行配药、执行的过程。 b) 患者体征数据监护 患者的体征数据监护原则上应该从患者入院开始。对于普通病房，有的医院由于没有足够的监护设备，且患者的病情相对稳定的情况下，只对体温、血压等体征数据进行采集，而且采样周期较长，一般为一天两次或一天一次。但是在 院必须进行持续的体征数据监测。数据监测采用的设备主要包括监护仪、输液泵、呼吸机等，数据采样周期也将保持在 5 分钟采集一次，对于危重患者甚至为 1 分钟采集一次，并派专人在床旁进行实时监护。 实际上，患者体征数据的监测并非简单的记录而已，在现代医疗迅猛发展的今天越来越多的医疗科研成果是基于患者体征监测的结果进行统计、分析、计算而得 来的，尤其是在患者发病、术后等阶段的数据尤为重要，是进行病情分析和病理研究极为重要的参考资料。 c) 医生查房 在患者入院后，医生需要每日定时进行例行查房诊断，根据患者病情的变化开具医嘱。医嘱的内容主要包括用药、化验、检验、会诊、护理等项目，各医院在查房的流程上基本是一样的。但是在查房过程中，主治医生需要查阅一天来病人的体征变化、各项检验、化验结果、用药情况、护理监测情况等一系列资料，一般需要有 2助手负责查阅和记录。像儿童医院这样级别的三甲医院，一般进行一次查房往往需要 3小时，需要耗费医生大量的精力。 随着医院新院址的落成，患者容量必将继续增加，那么在查房工作中，医生将需要投入更多的时间和精力。 d) 患者出室