区域医疗数据平台

区域医疗数据平台（精选8篇）

区域医疗数据平台 第1篇

目前,各级医疗机构大部分均已经部署实施了相应的医疗信息化系统,如:(1)HIS(hospital information system,医院信息系统);(2)EMR(electronic medical records,电子病历系统);(3)PACS(picture archiving and communication system,医学影像存档与通信系统);(4)LIS(laboratory information system,检验信息系统);(5)UIS(ultrasound information system,超声信息系统);(6)ECGIS(ECG network information system,心电网络信息系统)。

这些医疗信息系统由不同的系统集成商开发并实施,采用了不同的技术进行实现,有着不同的数据定义。这给区域医疗数据交换平台建设带来了一定的技术困难,主要有:(1)各系统的开发语言及工具的多样性;(2)各系统运行平台的多样性;(3)各系统数据存储方式的多样性;(4)实现同样功能的系统可能由不同的系统集成商开发。

区域医疗数据交换平台是实现区域医疗信息化的核心环节。通过从各级医疗机构进行信息采集、传输,在医疗监管机构中心建立综合数据库和应用支撑系统,制定相关医疗信息标准,构建区域医疗数据交换、汇集平台,实现医院管理网络信息系统相关信息的自动采集、传输、整合与存储。实现区域医疗数据交换平台需要重点考虑以下技术难点:(1)多平台、多网络情况下的数据传输交换技术;(2)适应医疗机构复杂信息化系统的数据采集技术。

1 系统的设计

1.1 系统结构设计

区域医疗数据交换平台通过对各类医疗服务机构现有业务信息数据的实时采集、传输、存储、处理、分析,形成服务于区域医疗信息数据中心的中心数据库群,动态掌握区域地区内医疗资源的配置情况、医疗服务机构的运行状况。

系统按照功能划分为信息采集与传输、医疗机构信息综合数据库,并可以扩展出区域医疗服务监管、区域医疗公众服务等应用(见图1)。

1.2 信息采集与传输系统设计

基于各医疗机构建设的各类HIS、LIS、PACS、RIS等医疗业务子系统和财务管理系统是区域医疗数据交换平台的数据源,信息采集除需要支持区域医疗救治机构信息汇集外,还需要支持这些机构医疗服务对象信息、卫生统计信息、规费财务信息、职能管理信息、卫生科教信息的报送和接收[1]。

信息类型主要是医疗机构的基础数据、动态产生的门诊信息、住院信息、财务信息、科教信息等数据,采用增量更新的方式从各家医院采集这些数据[2]。并且需要对上传的数据进行数据转换。

医疗数据交换平台通过在各医疗机构中设置的数据采集终端直接从HIS、LIS、PACS、RIS等医疗业务系统和财务系统里提取的数据,通过医疗信息交换平台传输到卫生局数据中心;或在医院现有系统数据库中建立中间表,由医院把符合标准要求的数据从各类系统里提取后,再导入中间表,系统自动从这些中间表提取数据,通过医疗信息交换平台传输到数据中心。

1.3 医疗机构信息综合数据库群设计

医疗机构信息综合数据库群是区域医疗数据交换平台的直接结果,也是区域医疗信息化的基础数据支撑。根据卫生主管部门医疗监管的需要,综合数据库群可以分为6大类,分别是医疗资源数据库、医疗服务数据库、卫生统计数据库、规划财务数据库、医务管理数据库、卫生科教数据库等(见图2)。

医疗机构信息综合数据库群的建立,将为整个区域医疗信息化应用提供基础数据。

医疗机构信息综合数据库包括:

(1)医疗资源信息库:记录医疗救治机构及其专业技术人员、大型医用设备(消毒产品储备、医疗器械等)、医疗救治专家等信息。

(2)医疗服务数据库:记录医疗救治机构门急诊人次、床位使用率、平均住院日、业务收入等信息。

(3)卫生统计数据库:记录医疗救治机构药品单价信息,各类药品使用情况等。

(4)规划财务数据库:管理医疗救治机构财务数据,包括资产、收支、基金、基建等财务信息,以及医院收费标准等信息。

(5)医务管理数据库:记录卫生行政部门上行下发文件、各类评比、制度汇编、年度总结、患者意见反馈等信息。

(6)卫生科教数据库:记录医疗救治机构科研信息,包括科研立项、科研获奖、各级各类人才、科研论文等。

1.4 数据分布模式

数据分布由3部分组成:业务数据区(数据源)、数据交换区、决策支持区(见图3),其中包括:

(1)业务数据来源于医院、社区卫生服务中心等各类医疗机构现有的信息系统;数据交换区按照一定的规则,从业务数据中抽取、过滤、清洗后生成交换数据库;从交换数据库中抽取统计决策数据,形成统计决策数据库。

(2)建立区(县)、市二级数据中心,分别管理、存储辖区内各类医疗卫生交换数据库、决策数据库。

(3)区(县)数据中心定时向市级数据中心上传数据。

(4)市级数据中心的交换数据库同时作为提供公众查询服务的后台数据中心。

(5)市级数据中心满足向省、国家卫生数据中心上传数据的要求。

2 关键技术的实现

2.1 技术架构

区域医疗数据交换平台由医院业务系统、医疗信息交换平台、数据中心平台和统一应用平台等部分组成,技术体系架构见图4。

医院交换前置机部署数据发布的源适配器,实现数据的抽取、转换、过滤和发布等功能,并支持数据的定时发布或实时发布等策略。医院交换前置机和中心交换服务器可配置为集群,数据将先发布到医院交换前置机,再正确地传送到中心交换服务器,该模式称为“集群模式”。

也可在医院交换前置机上安装一个数据库,作为交换数据库使用。通过部署数据复制适配器,实现共享数据从医院业务系统到交换数据库的数据转移任务。数据复制适配器可配成定时导入或实时导入,并支持数据的增量抽取或同步更新等多种模式。然后在医院交换前置机中部署数据发布源适配器,实现定时或实时的数据发布,将数据进一步发布到中心交换服务器。该模式称为“交换数据库模式”。

在中心交换服务器中部署数据订阅目的适配器,订阅来自各医院业务系统的共享数据,并存贮到数据中心数据库中(ODS,可操作数据存储)。医院业务系统的可共享数据,就可以定时或实时集成到中心数据库中,形成数据中心的基础数据库。反之,也可以将数据中心的数据根据访问权限要求,按主题发布给政府各部门。

2.2 多平台、多网络情况下的数据传输交换技术

在复杂的多平台、多网络下进行数据传输是一项严峻的考验,结合目前的需求,数据传输交换技术要考虑到以下特点:

(1)多操作系统平台支持,能运行于Window/Linux/Unix等多种不同的操作系统平台。

(2)多硬件平台支持,能运行于X86架构的个人计算机或者服务器上,也能运行于基于POWERPC的小型机上。

(3)数据传输高效稳定可靠,不会出现数据丢失情况。

(4)多种开发语言支持,能支持目前主流的C/C++、JAVA、Power Builder、Delphi等各种系统集成领域开发语言。

(5)支持面向对象的开发方法,支持面向对象设计。

Web Services的标准化进程非常缓慢,多年以来一直停留在技术层面的实现上。在这样的背景下,面向对象的网络通讯中间件开始逐步流行。

ICE,是一种适用于异种环境的面向对象中间件平台,支持分布式的部署管理、消息中间件、网格计算等,ICE API提供了一个向下调用接口。通过此调用接口来实现本地和远程的数据交换。在实际应用中,我们将系统设计成一个节点对象,将数据交换所需的操作全部定义为服务接口,供其他节点对象进行远程调用,采用ICE中间件作为通信平台,隐藏了通过网络远程调用的细节,使得数据交换像是非远程进行的。系统的上下级不影响对系统的管理。通过ICE将系统和设备共有的操作抽象出来作为抽象构建角色,将系统与系统之间的数据交换以及系统与设备之间的数据交换统一起来,大大简化了设计的复杂度,使得结构更为清晰。

2.3 适应医疗机构复杂信息化系统的数据采集技术

由于各级医疗机构采用了不同的医疗信息化系统,而系统集成商在设计实施这些医疗信息化系统时对开发技术掌握、系统架构设计和业务理解等各方面有着千差万别,从而导致对相同业务采取了各种不同数据定义、组织和存储。为了屏蔽这些区别,必须对这些医疗数据进行统一数据定义和组织。

通过对医疗业务的分析整理,定义出医疗业务信息交换标准,该标准以HL7标准和XML标记语言为基础,对医疗业务中的各种信息进行定义,统一了医疗业务信息数据的定义和数据组织模式,规范了医疗业务数据交换标准[6]。

HL7是不同医疗信息系统间标准的通讯协议,它使得医院各型医疗信息系统、医院间不同医疗信息系统之间能够进行数据交流与交换,允许医疗机构不同的应用系统间进行一些重要资料的沟通[7]。

XML即可扩展标记语言,通过此种标记,计算机之间可以处理包含各种信息的文章等。它既可以根据用户要求进行自定义,也可以具有特定的标准格式,是一种很抽象的语言。

通过符合HL7标准的XML可扩展性的标记语言作为数据传输介体,为将来其他应用系统直接与区域医疗数据交换平台交换数据提供标准数据接口(见图5)。

注:(1)代表对HL7消息的解析,并转换成HIS数据;(2)标书对HIS数据进行HL7消息构造

按此概念模型可以分别在客户端构造消息1,在客户端发送消息1后,服务器端接收,并解析消息1为本地HIS数据结构,与此同时构造消息2,发送确认消息2给客户端。

3 交换平台的部署策略

医疗信息交换平台采用星形结构部署,以前置交换服务器为中心,通过各种适配器与现有的系统通信交换数据。前置交换服务器的部署原则是不影响原有系统的正常运行,所以前置交换服务器提供开放的交换接口和通用的各种适配器接入原有系统,尽量不在原有系统上安装任何软件或者客户端程序。

4 结论

区域卫生信息化中的数据交换平台作为基础架构,支撑了区域性医疗卫生信息服务,是集业务、管理、协调为一体的综合医疗信息服务平台的体系架构。通过建立数据交换平台,实现各类医疗机构间的业务流与信息流的有机融合,加强医疗资源整合,整体提高区域性医疗服务、医疗救治、疾病预防、卫生监督执法管理水平和应对突发公共卫生事件的能力。

数据交换平台建设中遵循了以下原则:

(1)使用开放的先进的技术标准。如IT领域的SOA技术,公共医疗领域的MPI等。

(2)尽可能遵循国际标准,以便未来与国际信息的交互,如HL7,CDA,IHE。

(3)具有可扩展性,随着需求的增加能扩展其交互能力。

(4)对接入到信息化网络的信息提供者和信息获取者,不需要改变其原有的内部信息系统,只需要增加接入接口和信息编码转换程序。

(5)拥有严格的安全控制机制,保证相关信息不会被未授权者获取或修改。

因此从技术上讲,区域卫生信息化中数据交换建设的重点在于“高效、稳定、安全”,这是一个信息系统设计的必然要求。而作为新领域的重大项目,同时还要确保所采用技术的先进性,南京市医疗数据交换平台的建立对其他地区的卫生行政单位和医疗卫生单位具有一定的借鉴意义。

摘要：目的:运用先进的信息技术解决医疗信息化过程中的区域医疗数据交换问题,搭建适应于广域网络、异构软硬件环境的区域医疗数据交换平台。方法:通过ICE开放源代码中间件,按照数据注册-发布模型,设置区域数据交换中心,实现市级医疗单位间各系统的数据交换共享。结果:实现了市级医疗单位部分系统的数据交换共享,为区域医疗信息系统深入应用的具体实践进行了尝试。结论:区域医疗数据交换平台的结构设计被证明是可行、可靠和有效的,为构建全民健康电子信息档案打下坚实基础。

关键词：医疗信息系统,数据交换,数据交换中心,区域医疗,中间件技术

参考文献

[1]陈平.RFID技术在医院新生儿管理的应用[J].医疗卫生装备,2006,27(6):35.

[2]崔怡.基于WEB的远程视频监控系统在自动化中的设计与应用[J].微计算机信息,2006,22(28):286-287.

[3]齐国隆,孔令人,邹宗峰.HL7在公共卫生信息系统中的应用[J].现代预防医学,2006,33(6):41-44.

区域医疗数据平台 第2篇

关键词 区域文献 文献资源建设 特色数据库 数据库建设

地方文献是指以任何载体形式记录某一特定地区政治、经济、文化、教育、社会、历史及宗教信仰、民俗风情等各方面知识信息的文献。借助于图书、情报、文献学、管理科学、传播学、社会学等学科理论，建立据有地方特色的文献数据库，可以保存和发展地区文化，推动当地经济发展，为政府决策部门提供科学的依据。

1 区域文献的采集与分类

1.1 确立文献收集范围

(1)地方性文献的收集范围并不局限于现行的行政区域划分，而应根据本地区地理区域的历史沿革及变迁等实际情况来确定文献的收藏范围。如我馆以有关唐山市建设发展文献信息为收藏中心，外延到河北、北京、环渤海、大东北、珠三角、长三角、西部，以及国外的如德国鲁尔工业区、英国伯明翰工业区、美国五大湖工业区等等相关区域。(2)以经济、科技类文献信息为主，兼顾政治、文化、教育等其它学科门类文献信息。(3)所有本地出版的报纸杂志、地方政府公报、专报、文件、档案统计数据以及直接反映当地政治、经济、文化教育状况等数据。(4)地方籍名士的作品及事迹也是地方性文献的组成部分。(5)收藏时以近期文献信息为主要收藏范围，逐步回溯。

1.2 文献信息采集途径

信息资源分散、类杂，除了信息工作人员的不懈努力，还需要社会各方及相应制度的支持。(1)与社会各个方面建立直接的联系，如出版社、各政府机构与组织、考古单位、文联以及著作人等等，创造广泛、及时地获得文献资源的途径。(2)挖掘地区各馆内现有资源，对馆藏相关文献信息资源重新配置，如与当地有关的地方志、地方年鉴、地方统计资料、地方大事记等。(3)按照藏书结构与采集范围，抓好现期文献的采集工作，适时制订文献补配工作，同时制订文献补配计划，逐步补配缺藏文献。制定本馆书刊采购计划时，对特藏部分实行特殊政策，从采购数量到质量给予保障。(4)建构规模化的网上虚拟文献信息资源体系，通过馆际互借、资源共享的形式弥补馆藏相关文献信息资源的不足。(5)加大宣传，向社会广泛征集。如我馆在现有馆藏资源的基础上，加重了区域文献类馆藏的投入力度，新订期刊有《环渤海经济了望》(国内区域类)、《东南亚论坛》(国际区域类)、《区域经济参考》、《人大复印报刊资料城市经济、区域经济》(专题学术类)等等。并拟择其精要，进行数字化处理，以便于远程网络查询、共享，并从互联网上下载及自行数字化扫描处理。

1.3 地方文献的分类

区域医疗数据平台 第3篇

随着人民对医疗服务水平的关注, 社会医疗服务高歌猛进, 中国卫生医疗从体制着陆到技术手段, 都在进行着不断的改革创新。无锡市医院管理中心的成立, 启航了中国卫生医疗体制"管办分离"的破冰之旅。无锡市医管中心成立之初, 就把建设数字化医院、构筑区域医疗信息平台作为改革的重要战略突破口, 坚持以信息技术为支撑、以信息资源为动力, 以数字化推动现代化、国际化, 为管理拓展内涵、挖掘潜力, 为医院的发展插上腾飞的翅膀。

作为我国首家管办分离的试点单位, 无锡市医管中心凭借自身区域管理优势, 整合辖区内各医院的信息资源, 设计并构建区域医疗信息管理平台。我们根据当前IT国内外发展方向和全系统信息化建设现状, 设计了"一个中心三个平台"的信息化建设总体项目, 该项目核心功能的实现, 主要围绕数据交换整合技术展开。

2 管理平台与交换整合技术

区域医疗信息管理平台作为国家科技攻关项目的核心组件, 由无锡市医管中心主持研发。该产品意在通过全局优化设计, 整合辖区内各医疗机构信息资源, 使无锡地区的医疗卫生信息, 成为有机整体, 实现可管理、可交换、广覆盖, 提高主管部门的指挥决策能力, 最终提升区域医疗服务水平。交换机制与整合能力, 外化为这一核心平台的形式, 演绎着区域协同医疗的严肃构思。

2.1 数据交换技术

内部数据交换发生在医疗机构之间、医疗机构与上级主管部门之间, 以实现医疗机构之间协同工作, 主管部门有效布控、实时监管。

外部的数据交换发生在卫生系统与其他社会机构之间, 与医保机构、金融结算机构开展即时业务;也可以通过SP增值服务, 向社会团体、商业团体提供数据查询, 向个人提供健康咨询。

交换管理平台采用多层结构实现。各层次与模块之间的定义和相互的关系从软件层次来看, 信息资源交换管理平台分为三个层:最底层为数据资源层, 包括所有交换管理平台内部配置和状态管理数据所需要的数据库等数据载体, 也包括交换管理平台接入的医疗信息资源及其他数据的接入。

中间层, 是实现数据整合、分布式环境数据接入、访问和通信的支撑软件层。这部分重点完成数据的接入、转换、和通信, 实现不同部门前置节点的接入, 数据的接入, 以及数据的处理。通过这一层的实现, 提供平台的交换服务功能。这一层由消息中间件和应用集成中间件来实现。交换管理平台的数据接入, 采用数据适配器来实现。适配器部署在前置交换节点, 通过适配器分布式的部署, 实现对分步异构数据的访问和抽取, 完成数据的生产和消费。

上层, 是交换管理平台的核心层。这一层的模块, 利用已经存在的数据交换服务和接入能力, 针对医疗信息在定向服务、交换监控等方面的需求, 实现平台的目录管理、平台管理、安全管理等众多平台核心功能。

2.2 数据整合技术

数据整合技术, 不仅仅表现为对各医疗机构业务数据的汇总, 更表现为灵活主动的数据抓取, 以及计算分析、自动预警等。所有的整合工作在异构系统之间进行, 这些独立分布的应用系统, 要求系统整合平台具有平台无关性;此外, 现有的应用系统开发方式各异, 开发语言多种多样, 要求整合平台能够以极小的修改, 快速缝合差异, 满足信息访问简洁快速的需要。

3 交换与整合的客观要求

3.1 基层信息建设

区域医疗信息管理, 是全面全局的信息建设。对区域内医疗资源的整合以及优化配置, 需要令核心平台的采集触手深入到基层的每个角落。捕捉能力是否深入全面, 直接决定数据交换整合质量的好坏。此外, 当核心平台建立之后, 核心平体的数据交换标准应上升为区域标准。后续的基层信息建设应自觉参照该标准执行, 以降低系统接入的成本。

3.2 主题应用

区域医疗信息管理平台最终的价值落实为"是否推动医疗服务水平的进步"。其交换整合范式的确定, 需要围绕其服务目标, 具备明确的主题应用。

核心平台的主题应用, 表现为满足社会对医疗服务水平的需求。这也恰恰是核心平台的生命力所在。由主题应用衍生开去, 具体业务才实现了服务体系的正统。

3.3 图形界面

图形界面使维护和使用都显得直观简便。尽管在异构系统之间完成整合及交换具有难度, 而图形界面的使用无疑增加了这种难度。但从长期应用的角度而言, 必须令使用者具备独立操作的可能。无需编写命令的使用方式, 使管理者更专注于对区域信息的管理;使核心平台的功能得到更精彩的呈现。

3.4 面向服务

传统的专用交换方式是, 针对每一个具体系统, 开发出专用的交换接口。这种点对点的强耦合方式, 要求每一系统都为异构系统开发特定接口。接口数目按n× (n-1) 的速度增长, 日后还要穷于应付诸如管理需求多变和基层信息系统的种种变化等复杂情况, 不利于复杂系统之间的数据交换。

因此, 考虑到核心平台的长远发展, 必须由面向应用转为面向服务。所谓面向服务是指, 指定一组实体, 用以定义如何生产和消费服务。作为核心的服务之间, 呈现松耦合, 消息传递以文本为载体, 不考虑逻辑和数据类型, 以避免兼容性要求的责难。

4 交换与整合的主观要求

4.1 流程再造

区域医疗信息管理平台, 并非软硬件的合集, 是对辖区医疗行为进行的流程整合。而另一方面, 在新的技术条件下, 流程必然发生改变。基于新技术的流程跨越, 可缩简工作环节, 提高工作效率。因此, 在实施核心平台之前, 认真分析并再造流程, 是兑现平台优势的需要。

4.2 支持功能

尽管在实现了交换与整合之后, 核心平台的智能作用大大加强。但是, 根据实践体会, 笔者认为, 核心平台应仍然只是支持系统而非决策系统。交换机制、整合功能, 最后缔造的是评价而不是判断。评价尽管只是一个范围, 但其要素是清晰的。相反, 判断的要件总是在改变。在这种情况下, 人比计算机更擅长于作出判断决策。因此, 应充分利用核心平台的支持功能, 使人与计算机各尽所长。

5 总结

无锡市医院管理中心的区域信息管理平台, 已经实现了以主动和有限实时的方式, 对下属医院的跨机构、业务数据进行查询和汇总分析, 以此提高管理决策能力, 为医院发挥最好的经济和社会效益提供优化方案, 也为我国医疗健康信息更大范围的共享和利用作探索性研究。下一步, 我们将按照项目总体设计目标, 逐步拓展深化基层数据资源的采集, 在条件满足时将平台的应用推向更高的目标, 最终使管理中心、下属医院、人民群众共同受益。区域医疗信息化, 必将成为提升社会医疗服务水平的重要路径。

参考文献

[1]李胡希等.医院分级管理与区域医疗技术关系的研究.中国医院管理.1998.18 (8) :461-463.

[2]陈金雄等.构建基于标准化和中间件平台的区域医疗信息系统.中国医疗器械杂志.2006.30 (4) :250-252.

建立区域性医疗信息共享平台初探 第4篇

本文主张以建立基于电子病历的个人健康档案为重点, 将公共卫生信息系统、医学科教信息系统、医疗服务信息系统、社区健康服务系统等各系统相联结, 用创新的模式来实现规模互联, 减少信息孤岛, 建立统一的核心数据库、应用数据库、共享交换平台, 从而真正实现区域医疗信息的交换与共享, 成功打造满足未来实际发展需要的数字化区域协同医疗平台。

1. 系统设计

(1) 设计目标。

建立区域协同医疗平台及信息交换和医疗卫生的信息平台, 实现区域内医疗卫生行政部门、医疗卫生服务机构的互联互通、资源共享;促进区域内卫生资源在信息环境下的优化组合, 共享卫生和信息资源, 增强防疫监控、应急处置和救治能力, 实现公共卫生 (包括疾控、监督、妇幼保健等) 与医疗相结合的疫情监测和卫生监督的信息平台, 提供与健康紧密相关的区、镇、村、家庭卫生保健及网络信息服务。

推进医疗服务信息化, 加快居民个人健康档案和电子病历的应用推广, 实现将个人健康档案与病人临床信息融为一体的个人生理信息真正意义上的终身保存与共享服务;促进医疗、医药、医保机构的信息共享和业务协同, 在提供医疗质量的同时, 降低病人的费用支出, 支持医疗体制改革。

(2) 设计原则。

(1) 业务决定数据 (信息) , 数据是系统核心。

“区域协同医疗平台”的首要建设目标是合理、高效地完成相关业务。集中体现业务需求的是数据。数据描述、数据组织、数据获取、数据传输、数据存储、数据交换、数据调用、数据加工、数据分析、数据展现、数据更新等过程环节, 必须围绕当前和长远的应用需求来设计、构建和实现。系统的总体设计和具体功能设计, 要按照应用数据的静态和动态关系来表达。系统与功能设计的合理性首先取决于应用数据关系的表达是否合理、数据描述与组织的形式是否合理和数据处理的流程是否合理。

(2) 系统结构和设备运行可靠、性能适度。

“区域协同医疗平台”最主要的应用是卫生信息的。在现有的网络条件和投资许可下, 系统的结构设计和设备选配要充分保证关键业务的可靠操作。有关软、硬件的性能配备应留有适度余地, 更好地发挥投资效力。

(3) 梯度推进、确保质量。

基本网络、核心计算设备与存储设备、安全设备的集成必须及时配套完成, 承建商必须要有严格有效、科学合理的梯度和质量管理能力。建设过程要受用户及其代理的监督, 建设阶段结果和最终结果应通过严格的内部和外部验收。

(4) 遵循现行标准, 建立技术规范。

“区域协同医疗平台”是一个跨部门、跨地域、跨系统的分布式应用, 数据表示和交换必须规范和遵循统一的标准。对项目涉及到的有关规范与技术标准要梳理和做必要补充。系统的基本功能包括统一的代码维护机制, 以适应目前有关标准不完备, 应用超前于标准的状况。必要时, 在项目建设的基础上形成多个专业标准。

(5) 系统运行效率与安全并重。

应用是目的, 安全是保障。整体安全方案须经过权威评审认证, 系统的安全性能须通过权威测试。

(6) 在实际条件下逐步提高区域内卫生系统信息化程度。

“区域协同医疗平台”的设计与实施中还需要注意充分利用区域公共卫生体系现有的信息化成果、软硬件资源和网络资源。特别是医疗机构的HIS系统、各社区卫生服务中心的公共卫生与应急信息系统和特定专业领域的业务信息系统。整合资源、逐步统一、条块结合、信息共享。

2. 系统建设

(1) 符合行业数据特点的存储技术。

临床医疗信息数据和传统数据库应用中的普通数据有非常大的差别, 数据存储和应用都有其独特性。这些特殊性表现在: (1) 法律严肃性。要求进行长期的保管, 向后兼容至少15年。 (2) 数据交换的广泛性。需要进行非常广泛的共享和交换。 (3) 高度原始性。不允许对数据升级处理, 及任何形式的修改。 (4) 高度保密性。需要加密存储和传输。 (5) 权限复杂性。符合各种临床医疗权限要求。 (6) 海量存储特征。需要进行符合医疗需要的压缩存储。 (7) 面向文档特性。需要保持临床医生确认的原始文档外观。 (8) 历史性特征。保留历史记录, 不能进行任何的覆盖。因此, 必须进行顺应性调整。在数据完整性、统一性、安全性方面, 要进行特殊设计;在数据库结构方面, 著名的数据库表结构设计的第三范式不适应临床医疗信息的需求。

在数据存储结构方面的设计, 采用类似于面向对象的方式, 进行类似于属性、方法、事件的结构存储, 充分考虑数据的可扩展性和可移植性, 并且可对医疗信息进行跨平台访问, 而不需要更改现有系统的内容。

(2) 异构数据采集。

异构数据采集, 需要进行一些数据格式和数据类型的分类, 对于各种不同的数据和数据来源, 分别进行数据采集和交换的策略和方式方法制定。这些方式方法, 和数据采集逻辑定义设计器进行关联, 使得可以进行自定义的数据采集工作, 并且在统计、分析、汇总的时候, 也可以通过设计器, 自定义数学模型, 进行作需要的运算, 而不是按照传统方式的固定模式的统计分析处理。

(3) 医学标准封装。

在美、日、德、英等发达国家, 在医疗机构之间进行转诊的过程, 已经发展得比较成熟, 整个转诊过程几乎毫无障碍, 这归功于一些医疗信息交换标准的制定和遵从。在美国, 至少有4个相关的标准跟转诊相关, 而这些协议基本上都是美国民间技术组织制定并得到广泛支持的。

在国内目前的医院信息系统中, 对DICOM的实现多采用现成的软件组件, 以及对ICD的实现多采用对中文版ICD分类的自编程的支持和扩展, 因此, 对于DICOM和ICD标准的支持, 已经比较普遍。而在另一方面, 对HL7和CPT的支持, 缺乏实用性支持。

(4) 医学信息抽取。

信息抽取 (IE, Information Extraction) 是以一个以未知的自然语言文档作为输入, 产生固定格式、无歧义的输出数据的过程。这些数据可以直接向用户显示, 也可作为原文信息检索的索引, 或存储到数据库、电子表格中, 以便于以后的进一步分析。

(5) 消息系统设计。

区域协同医疗平台的消息体系, 包括两部分组成:消息服务器和消息客户端。作为消息平台, 就是可以让所有的区域协同医疗平台体系中的应用程序都能够通过消息服务平台, 进行相应的工作, 构造和定制不同的工作流程。消息平台是以服务器端和客户端组件库的形式进行平台发布的, 任何软件系统只要引用这个组件库里面的方法、属性、事件, 就可以获得消息服务。

(6) 系统安全和法律有效性设计。

在医疗信息数据安全性方面, 必须考虑加密的传输过程, 以及加密的存储过程, 保证在一般情况下, 应用程序和用户只有在医疗权限的控制下, 合理查看和使用医疗信息, 在非法获取医疗信息之后, 无法正常查看和获取原始医疗信息数据。数据安全性设计, 主要考虑:在数据传输中, 使用证书颁发机构CA的证书和数字签名验证;对医疗信息进行硬盘的加密和压缩储存;对医疗信息进行数据库的加密和压缩储存;在临床医疗权限中, 采用安全授权机制, 限制非医务人员的访问和医务人员之间的非法访问等。

(7) 以提高XML查询效率为目的的数据展开逻辑维护。

很多临床医疗数据是采用XML文档形式存储的。这种存储方式和传统数据库表形式的存储方式相比, 有一个很大的缺陷, 那就是对于很多数据, 在统计分析时候的效率会很差。解决这个问题的方式, 是在文档或者对象存储之前, 利用通用的数据库展开逻辑, 将文档或者数据对象中比较有统计分析意义的信息, 提出来进行数据库表形式的展开, 形成冗余数据, 这些冗余数据在需要进行简单数据统计分析的时候, 参与传统数据库方式的统计分析。这种逻辑的维护是自动进行的, 也就是展开过程是自定义的, 而且, 在展开以后, 如果要添加新的展开内容, 区域协同医疗平台的展开维护服务会在系统比较空闲的时候, 进行以往数据的补充展开。

(8) 支持封闭式数据的路由和冗余技术。

这项技术的目的是将各种区域协同医疗平台和各种数据服务器, 连接成一个具备整体数据服务概念的网络, 在这个网络中的任何一台服务器上访问数据, 即使该数据不在该服务的本地数据库中, 也能从这个网络的其他服务器中找到目标数据, 并返回给访问客户端。这类服务建立在服务器之间的消息应答基础之上, 同时每个服务器本地的路由表, 将帮助进行数据的路由, 以帮助找到本地没有的数据, 并将信息从其他服务器上取回并且返回给客户端。分布式数据存储, 一般情况下, 存储在本地服务器中, 并且通过服务器之间的路由应答, 通知其他的服务器, 访问或获取这些本地数据的方式和方法。

在各种区域性的分系统中, 电子病历会分布在各种电子病历数据库和区域协同医疗平台里, 在电子病历路由的过程中, 还会产生各种数据的冗余和重复存储。路由表和路由运算, 可以分布到各服务器中的PC群集中去运算, 以减轻主硬件服务器工作负荷。

3. 应用系统架构设计

(1) 双向转诊。

双向转诊信息交换平台基于消息中间件实现共享服务平台与各个社区卫生服务机构和专科、综合性医院之间的双向转诊信息的实时、定时交换。使用消息中间件可以实现数据集成和转换、业务过程协调、大范围的信息传递等功能。各转诊单位业务数据发送到各自交换前置机之后, 由交换中间件负责把交换数据发送到市信息中心的交换前置机。数据交换的方式采用“先交易、后交换”的“松耦合”方式, 达到各转诊单位的业务系统处理业务时并不需依赖信息交换服务平台的效果。

(2) 远程会诊。

远程会诊和远程医疗所需的区域协同医疗平台体系的基础设施支持包括:专用的高速宽带网络;电子病历数据平台;点对点消息系统实时通讯;区域协同医疗管理部门行政协调支持等。

(3) 远程家庭护理。

社区家庭远程医疗监护系统作为远程医疗系统中的一部分, 它是将采集到被监护者的生理参数与视频、音频以及影像等资料通过通讯网络实时传送到社区监护中心, 用于动态跟踪病态发展, 以保障及时诊断、治疗。随着数字电视、电话、Internet在家庭中的普及, 远程医疗将迅速拓展到家庭和社区, 如开展远程心电监护、远程助产护理、对慢性患者进行远程家庭护理、远程医疗随访, 患者可以在社区医院进行疾病治疗、身体保健、饮食等方面的咨询。

医疗监护中心端可通过网络与家庭患者建立联系, 实现定时监护数据的采集和数据库存档;也可以实现对患者的远程观察和交互诊断:医生在医疗中心端通过计算机操作遥控制家庭端监护设备的转动和摄像头镜头的变焦, 从而实现对患者的远程观察, 同时通过语音交互进行远程诊断, 并且可将诊断结果和处方传送给患者。

(4) 疾病监测系统。

此平台系统可实现基于电子病历系统的自动疾病监测, 改进目前现有的疾病上报模式, 提高疾病监控的准确性和效率。新的模式可以对临床医疗信息进行实时或准实时的自动监控, 在第一时间, 将疾病发生的信息汇集到数据中心进行提醒和疾病的统计分析。这些信息可以是精确的症状、体征、病情的时间变化过程、症状体征相关的临床检验数据、症状体征相关的医学影像报告、症状体征相关的处方和医嘱项等。

(5) 社区医疗服务。

社区医疗服务所需的区域协同医疗平台体系的基础设施支持包括:区域协同医疗平台的数据存储服务;消息系统平台支持;集成电子病历系统等。近年来的社区医疗服务发展异常迅速, 并且可能成为将来普及全民医疗卫生服务的主要方式之一。

(6) 网上虚拟医院。

网上虚拟医院所需的区域协同医疗平台体系的基础设施支持包括:区域协同医疗平台的数据存储服务;消息系统平台;集成电子病历系统;区域协同医疗平台与医保系统的接口等。

总之, 建立区域协同医疗平台及信息交换和医疗卫生的信息平台, 其目的是:利用信息网络等先进技术来建设以病人为中心, 以临床应用及决策支持为主线的数字化医院;规范社区卫生工作信息内容和渠道;应用信息、网络、数字化技术改进大中型医院与社区卫生服务机构之间的信息传递、处理、储存的方式, 有机整合社区医疗诊治和健康保健服务;扩大医疗服务面, 提升医疗服务能力, 提高医疗质量, 降低医疗成本, 逐步实现网上在线健康, 促进各个社区居民提供更广泛、更便捷的社区健康服务, 满足民众的健康需求, 满足卫生系统内不同层次的需求。在满足上述需求的同时, 通过推进信息技术医疗服务、预防保健、卫生监督、科研教育等卫生领域的广泛应用, 建立起功能比较完备、标准统一规范、系统安全可靠、高效便捷, 服务于政府、社会和居民的卫生信息化体系, 加速我国卫生信息化建设和信息技术应用能力与国际先进水平接轨。

基于区域化平台的自助医疗服务系统 第5篇

1 系统总体设计

南京市自助医疗服务系统是在南京区域卫生信息平台的基础上, 由医院、银行、自助设备商三方合作, 共同开发建设的。院方提出符合自身特色和个性的业务需求, 与自助设备商共同确定技术方案, 完成医院信息系统 (HIS) 软件的改造和接口的开发;银行负责修改银行端的系统, 架设银行前置机。

1.1 系统特点

针对目前国内自助医疗服务的应用现状, 南京市自助医疗服务系统的设计与定位有以下特点:

(1) 以二代身份证号为主索引的市民卡为载体, 推行地区医疗“一卡通”, 实现区域内患者身份的统一识别认证, 确保自助医疗服务应用的通用性, 即患者可在任何一家参加该项目的医疗机构的自助服务终端实现相应的自助医疗服务。

(2) 构建覆盖全区域范围的自助医疗服务系统, 实现区域内医疗卫生资源的共享, 整体提高区域医疗服务效率、质量和可及性。

(3) 采用预付费方式, 减少患者就诊过程中反复排队付费的现象;推行预约就诊模式;通过部署在社区卫生服务中心的自助服务终端, 将全市大医院的医疗资源逐步向基层医疗机构延伸和开放。

1.2 系统网络拓扑图

系统网络结构, 见图1。

2 基于二代身份证的就诊卡

本系统就诊卡主要分为三种:南京市市民卡 (A卡) 、金陵通卡 (B卡) 、医达通卡 (C卡) 。A卡和B卡主要是针对南京市民的, 而C卡主要是针对非南京市民的。就诊卡以二代身份证号为主索引, 作为患者的唯一身份标识, 在就诊的各个环节中起着至关重要的作用。主要体现在以下三个方面:

(1) 唯一身份证明。无论A、B、C卡的哪一种, 在开卡时都必须绑定身份证号码。身份证号是由位于自助设备上的身份证读卡器读取的, 并由银行端联网公安部进行认证, 保证了正确性和安全性。开卡的同时, 亦完成了在市民卡中心的注册, 这就为在全区域内统一部署奠定了基础。在区域内任何一家医疗机构完成了注册的就诊卡, 今后在整个区域内便可以方便的使用。

(2) 一卡通的功能。就诊卡号在就诊的各环节均可以被读取, 患者持就诊卡便可在自助设备上完成挂号、缴费、打印检验单、查询等一系列操作。同时, 就诊卡号还关联了病人的复诊号, 代替了过去的纸质复诊券。

(3) 金融绑定功能。就诊卡在开卡注册时, 可以选择绑定中国银行的借记卡账户或者中行开发的一种“无卡无折”的医疗行业专用的个人电子钱包账户。通过银联的借记卡或现金进行充值, 也可以通过中行借记卡或是人工窗口进行退费。就诊卡通过金融绑定功能, 采用预付费方式, 减少患者就诊过程中反复排队付费的现象, 简化了医疗流程。

3 系统与区域化平台的对接

医院与南京市卫生信息平台之间铺设了专线, 为医院提供固定IP。院方通过专门的路由将院内局域网同平台相连, 同时架设防火墙。

平台的对接是以市民卡的应用为核心的。市民在医院进行开卡操作时, 自助系统会调用平台方提供的相应的接口函数, 将市民的基本信息保存至全市统一的卫生信息数据库。市民卡中记录的市民身份证号作为区域卫生信息平台中的区域病人主索引 (EMPI) 。自助服务系统与市民卡数据库中心、卫生局数据中心、医疗机构数据中心之间实现数据共享、交换, 实时比对整合市民卡数据中心的最新发卡、挂失、注销以及黑名单等信息, 确保系统使用者的身份真实有效。市民持卡在其他医疗机构就诊时, 市民卡作为身份识别的工具, 供医疗机构在卫生信息数据库中调取该市民的相应医疗信息。

医院与平台对接后, 可以通过相应的接口向平台传输患者的检验数据。患者通过自助系统即可查询自己在区域内医疗机构的检验结果。同时患者可以通过自助系统接入南京市12320预约挂号平台, 预约区域内任何一家医疗机构的专家号。

相关医疗信息区域共享的实现, 有效地避免了患者在各医疗机构间就诊时的重复检查, 也为同城互认、远程会诊、居民健康档案建立奠定了基础。

4 自助服务系统的功能

自助设备系统采用了向导式的操作模式, 用户界面友好、操作简便。同时, 系统具有较强的抵御非法用户侵入和操作人员误操作的能力。

自助设备系统主要功能包括:自助发卡 (指C卡) 、院内注册、自助挂号、自助缴费、自助充值、自助退费、自助打印化验报告、自助预约 (南京市12320平台) 、自助预约取号、自助医保查询、自助查询历次就诊信息、自助账户管理等。

自助设备系统主要模块包括:主控模块、显示模块、输入模块、身份证识别模块、磁卡/IC卡识别模块、打印模块、自助发卡模块、现金充值模块、监控摄像模块、电源模块、通信/维护模块、信息发布模块、声效模块等。

5 系统与HIS的接口

自助医疗服务系统与医院HIS的对接主要采用了Web Services模式, 可获取相应的门诊信息、患者诊疗数据, 同时向HIS提交相应的业务请求。接口规范由医院和自助设备商共同讨论制定, 各方的交易信息格式必须遵循此接口的定义。接口同时规定了每个交易的意义及不同交易之间的逻辑关系。

Web Services技术是基于XML (可扩展标记语言) 和SOAP (简单对象访问协议) 的。之所以采用Web Services的接口模式, 主要是考虑到各家医院的HIS多半是相对独立的信息系统, 数据结构设计的个性化较强。但院方只要遵循双方共同确定的接口定义, 将HIS中的相关医疗信息转化成相应的XML报文格式, 便可实现自助医疗系统和HIS间的信息互通。而这样的接口定义, 几乎不用做多少调整, 便可直接应用于其他医疗机构, 这对于自助医疗系统的发展和医疗信息在区域化平台的传输都是十分有利的。

自助医疗系统主要的接口内容定义, 见表1。

6 HIS的改造

自助服务系统作为现有HIS的功能增强或应用领域的拓展, 离不开HIS这个载体[2,3,4]。为了响应卫生部“先诊疗后结算”的服务模式, 对现有HIS需要完成以下改造:

(1) 建立专家和科室的排班模块。每日分上下午维护当日坐诊的专家及科室信息, 同时维护每位专家的信息。如果遇到临时停诊等特殊情况, 需要及时更新。

(2) 在排班系统中, 为电话预约等形式留出专门的号源, 以防其他患者在自助机上挂完所有号。

(3) 提供补打发票程序, 并能修改相应的报表。每台自助机应采用独立的收费账号, 在每日业务结束后, 统一打印相关报表。

(4) 增加专门的就诊卡退费、挂失、销卡功能模块。

(5) 在诊间、药房和医技科室配备读卡系统。

7 对账系统

对账是自助医疗服务系统中的最后一个环节, 对账模块中的所有数据均来自系统其他业务模块。无论在系统测试还是在正式运行环境中, 该模块都是对其他模块稳定性和正确性的检验与检查[5,6,7,8]。

银行交易数据来源于银行。银行每天凌晨会将前一天的交易明细放在指定ftp (软件) 上。自助机对账程序会每天将银行端交易数据下载到本地。院方挂号缴费数据来源于HIS。自助机对账程序每天凌晨获取HIS方交易记录。对账业务主要分3块:卡费对账、挂号缴费对账、退费对账。

依据卡费对账结果、挂号缴费对账结果、退费对账结果生成报表。文件报告格式为.txt文本格式。报表结果上传银行ftp, 告知银行对账结果。同时也保存在自助机数据表中。在自助机提供的中心监控管理平台上, 医院财务科、信息科可登录查看对账结果。

8 结束语

我院在建设自助医疗服务系统的过程中, 以基于二代身份证号为主索引的市民卡为介质, 对接南京市卫生信息平台, 运用Web Services技术确定了一套自助系统与HIS的接口协议, 对HIS进行了相应改造, 并开发了对账系统, 最终顺利完成了该项目。系统上线以来, 运行稳定, 优化了就诊流程, 为医院的科学管理开辟了新思路, 有效缓解了病人看病难的“三长一短”现象, 为区域化医疗打下了基础, 受到了广大患者的认可。其设计与应用方案值得其他医院借鉴。

摘要：基于二代身份证的储值就诊卡, 架设医院与银行、市民卡中心的数据交换通道, 规范各系统间的通讯接口标准, 建立自助医疗服务系统。自助医疗服务系统的应用优化了就医流程, 提升了服务效率, 改善了服务质量, 推进了区域化医疗进程。

关键词：医院信息系统,自助医疗服务系统,区域化医疗平台,二代身份证,就诊卡,Web Services接口

参考文献

[1]张甜.自助就医系统需求分析[J].科技信息, 2011, (5) :74.

[2]刘敏超.301模式一卡通整体设计与实现[J].中国数字医学, 2012, 7 (7) :5-9.

[3]李明, 刘跃平, 王超, 等.LIS系统中自助取单模块和一卡通就诊系统的联合应用[J].中国医疗设备, 2012, 27 (12) :70-72.

[4]黄钊, 唐凯, 陈平.南京市区域医疗一卡通架构及接口设计[J].中国医疗设备, 2012, 27 (2) :34-37.

[5]郭旭.301模式一卡通对账模块的设计与实现[J].中国数字医学, 2012, 7 (7) :16-18.

[6]李铁, 黄天培, 彭逢安.区域医疗共同体信息系统架构[J].医学信息, 2010, (4) :797-799.

[7]李清.基于HL7和SOA的区域医疗协同系统研究与实现[D].成都:电子科技大学, 2010.

医疗数据集成平台的扩展功能和设计 第6篇

目前国内医疗信息化的建设已经取得了显著的成果,HIS(医院信息系统)、EMR(电子病历系统)、LIS(临床检验管理系统)、UIS(超声图文信息系统)、PACS(医学图像存档和通信系统)、ECGIS(心电信息系统)等各类信息化系统已建设完成或在逐步建设中。这些子系统体积庞大,内容繁杂,大多由不同软件公司开发。它们所处的平台、语言、协议、数据格式等存在极大的不兼容性,彼此之间共享信息的交换是一个重要的课题。

由此,医疗数据集成平台这一特殊的信息系统应运而生。以实用性、安全性、稳定性和先进性为基本原则,采用面向服务的体系结构(service-oriented architecture,SOA),基于企业服务总线架构(enterprise service bus,ESB)实现全院所有医疗信息系统两两之间的数据共享和信息交互。平台采用基于元数据的、统一的交换协议标准,以XML作为描述格式,扩展支持HL7、SNOMED、DICOM、ICD10等国际标准,具有组件化、松耦合、扩展性良好的特点。

通过集成患者信息查询、药品查询、检验检查电子申请单、检验检查电子报告单等服务,完成业务的跨系统整合,使各子系统整合成一个整体的医疗信息系统,实现医疗服务流程的无纸化操作。规范医疗服务流程,实现业务流程的优化和重组。支持子系统的“热插拔”,方便新系统的进入和旧系统的改造,降低开发和维护成本。

各信息系统以组件的形式加入到医疗数据集成交换平台中来,成为整体信息系统中的一个模块,通过前置服务器连接到数据交换平台应用服务器(或通过网络直连部署在应用服务器上的前置服务),通过基于Zero C ICE中间件技术的适配器服务(或FTP、Web Services等技术),与应用服务器进行同步/异步的数据交互。

2 功能实现

2.1 适配服务

为各种操作系统和程序语言提供适配接口,使它们可以用统一透明的方式与平台通信,信息交互采用标准的XML格式字符串,便于将数据和消息从复杂的业务逻辑当中抽象出来,屏蔽了上层实现的技术细节。

2.2 发送/接收传输服务

采用高效的ICE中间件或其他网络编程技术完成和适配服务间的网络传输任务。

2.3 消息通讯服务

采用基于ICE STORM的消息机制提供同步/异步的主题订阅和发布功能,完成各个服务流程中的消息传递任务。

2.4 高级服务

(1)转换服务。进行一些必要的数据转换和业务逻辑处理。

(2)安全服务。通过认证和权限控制保证服务器和数据的安全,并备有详细的日志。认证和权限控制分为用户权限控制和子系统权限控制。

(3)管理服务。为系统管理员提供功能强大的后台管理Web程序,具备配置、监控、管理和统计分析功能。

利用中间件系统完成数据同步,将业务流程整合在中心层的中间件处理层,为将来业务流程修改提供极大方便;可提供中心数据监控以及业务流程调度等功能的良好操作界面;另一方面,中间件采用了轻量级构架,并采用可调节的数据包压缩算法提高网络传输速度,这样就极大提高了运行效率,使全院医疗系统工作流程更加流畅快速。

3 新需求和功能扩展

目前,医疗数据集成平台(DIP)已在我院正式投入运行,担负着全院所有医疗信息系统的底层数据托盘作用,精确实现了上述各项基本功能。随着业务流程的进一步数字化、医疗数据的充分运用以及科研教学的需要,我们对医疗数据集成平台提出了新的需求,要求DIP的功能得到更大的扩展和提升,以适应数字化医院的快速发展。

3.1 医院医疗系统

3.1.1 工作流程拓展

根据业务和管理需求,充分利用信息技术手段,不断优化和完善门诊、住院等信息系统,建立以DIP为纽带,整合HIS、EMR、LIS、USS、PACS等,进一步实现医疗工作流程的数字化。

目前门诊预约挂号、门诊医技结果上传、住院电子医嘱、住院电子处方、门诊随访、输液中心管理等功能模块还没有充分实现,需要进一步强化扩大DIP功能,使就诊信息快捷有效地传递和共享。

从长远看来,健康咨询、心理咨询、健康检查、康复指导等服务项目将得到普遍开展。既为患者就诊服务,也为健康人群咨询服务;医院逐步向预防、医疗、保健、康复等多功能延伸,DIP将在其中担负着举足轻重的作用。

3.1.2 数据功能扩展

我们这里讨论的数据功能扩展包括两方面的含义:

(1)DIP的正式运行尚未涵盖全院所有科室,在运行范畴中的科室工作状态良好而稳定,这为继续加大投入和运行力度打下了良好的基础。我们需要进一步扩展医疗数据集成平台涵盖的范畴,最终将全院所有科室部门一起归纳进来。

(2)现在平台上集成的数据越来越多,规模越来越大,其中有相当一部分只经过了一次传递阅读,从某一个系统上传,被另一个系统下载,并没有实现真正意义上的多系统数据共享,仍然在浪费着资源、影响着效率。从这一点看,进一步开拓平台数据的运用空间势在必行。

3.2 教学和科研

我院的科研信息系统中包括电子病历报告表和数据管理系统、药物临床试验管理系统、实验室数据管理系统等,这些系统的运作都离不开海量且准确的数据。DIP数据库随着医疗工作的流程逐步充实完善,将为科研信息系统和教育信息系统提供丰富的有效数据,促进我院教育科研进一步发展。

3.3 数据挖掘整理

数据挖掘是从大量不完全的、有噪声的、模糊的、随机的数据中,提取隐含在其中人们事先不知道但又潜在有用的信息和知识的过程。挖掘的对象是数据库和数据仓库,其目的是通过对数据的统计、分析、综合、归纳和推理,揭示事件间的相互关系,预测未来的发展趋势,起到辅助实际工作问题的求解。它是对医院现有信息系统强有力的补充,可以对大量的医院历史数据分析处理,发掘潜在信息,对医院领导决策起着重要作用。

3.3.1 医疗数据统计

DIP作为基层数据库,其工作过程中将其他所有信息系统的相关业务数据都收集整理起来,集中保存在DIP数据库中。在此基础上进行统计分析,既避免了直接从各个信息系统数据库中寻找所需数据、造成资源浪费,又可从中得到长期、系统、综合的数据。使医院信息系统的信息资源由只面向医院的联机事务处理,变成了可以进行分析、挖掘以得到辅助决策信息的信息资源。这份数据资料全面实时,是现成的有效数据源,对我们利用数据挖掘的各种手段来进行医疗业务数据统计有着重要而宝贵的意义。

根据不同的统计需要确定主题,从DIP的数据库中提取有用数据,并进行微观或宏观的统计、综合和推理,如:患者的分类结构、患者的就诊时间区间,患者的费用类型结构、患者病种分析,以及时间轴上横向和纵向的对比。进而发现各项数据指标之间深层次的关联,对未来的医院业务进行预测,更好地为医院管理决策提供支持。

3.3.2 临床资料检索

各信息系统直接面对一线临床,其数据资料繁杂琐碎,尤其在出错并纠正状况下,冗余废弃数据占了相当比例,这对于临床数据的快速有效检索是一个阻碍。

DIP的出现在一定程度上解决了这个问题。各个系统都将自身的有效正确数据上传至DIP,这些数据还将进一步在业务流程的推进中接受其他系统的检验核对,最终DIP数据库将为临床资料的检索提供准确精炼的数据资料。

4 设计思想和方案

随着数据交互所采用的软件技术日益发展,现代信息系统软件的设计模式引入了一个全新的概念面向服务的体系结构(service-oriented architecture,SOA)。

SOA支持将业务转换为一组相互链接的服务或可重复业务任务,可在需要时通过网络访问这些服务和任务。通过对来自不同网络的服务进行组合,完成特定的业务任务,从而让业务快速适应不断变化的客观条件和需求。

在SOA中很重要的一个概念是“企业服务总线”(enterprise service bus,ESB)。ESB是传统中间件技术与XML、Web服务等技术结合的产物,作为SOA中的一种体系结构模式发挥了根本性的作用。ESB是实现成功SOA采用的重要入口点,并且是任何面向服务的解决方案的关键成功因素。

如图2所示,将各子系统需要交互的模块作为“服务”集成到总线中来,一个服务可以被多个系统调用,如患者档案查询服务和电子申请单查询服务等。

同样采用信息系统与DIP的构架模式(如图3所示),医疗服务流程中的各个节点以“服务”的形式加入到医疗数据集成交换平台建立的医疗服务总线ESB中来,可以为系统提供更高的灵活性。

设计好各个模块之间的接口,把众多功能复杂的系统模块集成到总线上并使其能够协调工作。这种模式避免了重复开发,一旦出错便于管理排查,既全面又安全,将大大提升开发效率,有利于医疗数据集成平台功能模块的进一步扩展和深化。

摘要：目的:实现医疗数据集成平台的功能扩展,结合业务流程实现医院业务的跨系统整合。方法:在为医院内部各信息系统之间提供高效数据交互的基础上,继续添加整合平台的更多功能模块。结果:新的功能模块使平台满足医院业务的多种需求,功能更加强大。结论:这些扩展功能的添加完善了平台项目整体的合理性和应用性。

关键词：数据集成平台,架构设计,功能

参考文献

[1]曹晋军.医院数据综合查询和统计分析系统设计[J].医学信息,2004,17(6):322-323.

[2]汪涛.医院信息系统中的数据挖掘[J].医学信息,2008,21(2):184-185.

[3]李怀庆,张文东.数据挖掘技术在医院信息系统中的应用[J].医疗设备信息,2007,22(12):48-49.

[4]刘琛玺,彭传薇,李涛.数字化医院条件下医疗统计数据质量的意义[J].解放军医院管理杂志,2008,15(1):51-53.

[5]李华才.依托门诊信息系统优化就诊工作流程[J].中国数字医学,2008,3(2):1.

[6]张志宏.ICE:挑战CORBA的新的面向对象中间件平台[J].计算机教育,2004(9):30-33.

医疗数据集中查询平台的开发研究 第7篇

当前,信息化建设在卫生改革发展中担当着重要角色,新医改方案已经把卫生信息化建设作为深化医药卫生体制改革的八大支撑之一,强调逐步建立统一高效、资源整合、互联互通、信息共享、透明公开、使用便捷的医药卫生信息系统。

近年来,我国卫生信息化建设发展迅速,取得了显著成效。目前已经有90%以上的县及县以上医院建立了医院管理信息系统,优化了资源配置,提高了工作效率和管理水平,方便了患者就医。但需要指出的是,由于各家医院信息化建设程度与周期存在差异,所以各个子系统的建设有可能是在不同的时间段由不同的IT厂商完成的[1]。虽然各子系统间使用接口互相通讯,从数据交换层面实现了共享,但从数据查询层面来说,患者在医院产生的各种数据仍然分散于门诊、住院等各个子系统中,依旧存在“信息孤岛”现象。尤其是医技部门或者职能部门在了解患者的相关信息时,需要从不同系统、不同界面进行查询,十分不便,更重要的是医疗数据仍然以私有格式分散在多个信息系统中[2]19。以我院为例,放射科、病理科曾向信息科提出希望能够调阅住院患者电子病历,这样在进行检查及书写报告时能够更有针对性,同时也方便进行病例统计,为学术研究提供依据。感染管理科也曾提出希望能够调阅住院患者微生物培养情况,以便及时掌握病菌耐药性及院内感染的分布情况。可见,医疗数据集中查询平台的开发是非常必要,而且极为急迫的。

1 项目建设

1.1 前期准备

医疗数据集中查询平台(以下简称“查询平台”)的开发研究是“南京医科大学科技发展基金面上项目”,预计52周完成。项目启动前需要制定出进度表及流程图(如图1所示),并且还要与普外科、老年医学科、检验科、超声室、心电图室、病理科、放射科进行合作,为项目的顺利完成打下基础。

1.2 实施

1.2.1 开发内容

从前期调研可以看出:临床科室从科研角度出发,希望能够大量获取病例资料,尤其是某一时间段内某种诊断、某类手术所有出院患者的诊疗信息;医技科室希望浏览检查检验患者在院病程记录、医嘱,便于充分了解病情,更准确地得出相应结论;行政职能科室从医院管理角度出发,需要掌握类似抗生素使用情况、院内感染情况、微生物培养等信息;医院管理部门则关注医疗运营过程中的主要指标运行、医疗质量的持续改进、医疗安全事件的规避[2]699等。基于此,查询平台的内容包含门诊处方信息、检查检验结果、住院医嘱、入院记录、住院病程记录、出院小结、住院费用、病案首页信息、科研查询等(如图2所示)。

1.2.2 开发方法

查询平台基于Windows 7操作系统开发,采用C/S架构,使用Delphi 7.0编写前端查询界面(如图3所示)。通过Active X Data Objects(ADO)与主服务器的SQL Server2000软件相连,分别从HIS、LIS、RIS 3个数据库中提取数据。主要使用ADOConnection组件(Microsoft OLE DB Provider for SQL Server)连接数据库,因为ADOConnection组件起到了一个共享桥梁的作用,其他各个组件都可以通过它来操作数据库[3]。ADOTable组件作为数据表来源,Data Source作为数据转接件,ADOQuery作为条件查询组件。为了编写程序更加便利,将以上4个组件统一使用数据模型Data Module(DM)装载。

HIS数据库使用的数据表主要有:ZY_BRSYK(住院患者首页库)、ZY_BRJSK(住院患者结算库)、BQ_YS_BCJL(病程记录库)、BQ_YS_CYXJ(出院小结库)、BQ_YS_RYJL(入院记录库)、BQ_CQYZK(长期医嘱库)、BQ_LSYZK(临时医嘱库)、SF_BRXXK(门诊患者信息库)、SF_BRJSK(门诊患者结算库)。其中,住院患者通过病历号与病案首页序号作为关联字段,门诊患者通过病历号与发票号作为关联字段。LIS数据库使用的数据表主要有Lis_List(检验患者信息库)、Lis_Result(检验结果库)。RIS数据库使用的数据表主要有RIS_List(检查患者信息库)、RIS_Result(检查结果库,包含超声、心电图、内镜、病理等类别)。

1.2.3 编写代码

查询平台在编写过程中需要着重考虑2个方面:一是登录模块,二是科研查询模块。需要注意的是,由于我院数据库有登录保护措施,为了避免在运行查询平台时反复出现登录对话框,需要将ADOConnection组件的Login Prompt属性设为False。另外,查询平台仅仅提供数据展示,不允许对后台数据库进行任何修改,所以将DBGrid组件的Read Only属性设为True。

从数据安全角度考虑,用户必须使用事先分配的账号登录查询平台。在登录时系统需要自动判断账号是否存在,密码是否正确,并给予对话框提示。登录模块代码(部分)如下:

科研查询的难度在于需要根据时间、科室、诊断名称、手术名称、检查项目名称等条件进行多种组合判断,以满足临床不同需求。代码(部分)如下:

1.2.4 应用效果

临床科室在进行医疗工作的同时,还需要完成各级各类科研课题,因此,从海量病例数据中快速定位与获取所需资料是课题成功推进的前提之一。科研查询模块包含了“组合项目”、“手术项目”、“门诊诊断”、“出院诊断”、“科室”5个关键字段,并且可以进行组合(如图4所示),在提供明细数据的同时,还可以自动统计数量。医护人员可以根据查询结果中的病历号进一步获取患者的其他信息。

根据《中华人民共和国传染病防治法》[4],医疗机构必须每天上报发现的传染病病例。查询平台提供了患者基本信息模块(如图5所示),检验科在掌握标本结果的同时,还可以及时获取患者的身份证号、联系电话、地址等信息并按规定程序上报,既提高了效率,又便于当地疾病预防控制中心跟进。

2 使用反馈

目前,我院已经安装查询平台的科室有老年医学科、检验科、超声室、病理科、核医学科。从使用人员的反馈信息来看,查询平台能够基本满足需求,并且查询速度较快,支持导出功能,使用较为便利,大家不必反复往来于科室与病案室之间,节省了许多时间。

但是,各科室在查询平台的实际使用中也发现了一些缺陷:一是由于考虑网络带宽,PACS的图片尚未接入查询平台,这对于很多医生尤其是外科医生来说不是十分便利;二是基于数据安全的考虑,我院实时在线数据只保留1 a,在这之前的所有数据均存放在历史库中,目前尚未将历史库接入查询平台,给医务人员查询历史数据带来不便;三是使用人员希望查询平台能够按照固定样式提供报表功能并直接打印。

3 结语

实践证明,对查询平台的开发研究是比较成功的,它秉承了“大一统”的思想,将各类数据筛选、分类、整合,并采用友好人机界面对外呈现,能够较好地满足临床科室、职能部门的需求,解决他们在工作中的困难,使一线医护人员更方便地获取患者的各类信息[5]。在医疗信息化蓬勃发展的今天,它可以作为医院信息部门与其他部门充分沟通合作的范例,当然,我们仍然需要对查询平台不断改进、完善功能、加强安全,使之成为准确、高效、便捷的信息化工具。

参考文献

[1]刘谦.基于DOP技术的临床信息的数据整合与检索[J].中国医疗器械信息,2009,15(11):75-77,87.

[2]李书章,褚健.数字化医院建设理念与实践[M].北京:人民军医出版社,2011:19.

[3]杨长春.Delphi程序设计教程[M].2版.北京:清华大学出版社,2008:247.

[4]中华人民共和国卫生部.中华人民共和国传染病防治法[EB/OL].(2004-08-28)[2013-02-11].http://www.moh.gov.cn/mohjbyfkzj/s3576/200804/29124.shtml.

区域医疗数据平台 第8篇

基于居民健康档案的区域卫生信息平台是根据卫生部在《全国卫生信息化发展纲要(2003-2010年)》中所提出的:"建立区域卫生信息化示范区,实现区域内各卫生系统信息网上交换、区域内医疗卫生信息集中存储与管理、资源共享;在城市地区基本实现预防保健机构与卫生行政部门之间互联互通、资源共享;在有条件的农村地区,逐步将网络延伸到乡镇卫生医疗机构"等精神,以居民个人电子健康档案(Electronic Health Record,EHR)为基础数据而建立的一种医疗资源共享信息系统。该区域卫生信息平台与各医院基本医疗系统、城镇职工和居民基本医疗保险信息系统、传染病报告信息系统、免疫接种信息系统、妇幼保健信息系统、新型农村合作医疗信息系统等医疗卫生系统内部各种不同功能的医疗卫生应用系统之间互联互通,建立以居民个人电子健康档案为核心的医疗卫生数据中心,按照卫生部新数据交换标准将各种不同功能的医疗卫生应用系统中需要进行数据共享的部分,定时挖掘抽取到区域卫生信息平台的中心数据库,并进行健康医疗信息共享数据的整合、存储与管理,从而实现居民个人健康信息的共享,为临床辅助诊断、双向转诊、协同与远程医疗、居民自助检查等提供服务。为将来导入新的医疗卫生信息系统和同公安、民政和计生等政府相关部门的信息交换制定新的接入规范。该区域卫生信息平台的技术架构如图1所示。

基于健康档案的区域卫生信息平台的技术架构按功能分为:应用业务层、共享数据层、信息服务层和服务展现层。其中,信息服务层实现并提供各项信息资源和业务应用服务。服务展现层由门户网站来体现和实施;门户网站是平台的统一服务门户,实现单点登录和统一身份认证,提供浏览、查询、搜索等一站式的服务。应用业务层由医疗卫生系统各种业务处理应用系统组成,在这一层面上各类应用为了完成业务处理建立了为本部门工作所需的业务资源数据库,沉淀了大量的居民健康信息,形成各种可供全局共享的源数据。共享数据层建立在应用业务层之上,其核心是中心数据库,它的数据来源于各种业务应用系统,可以是冗余的,但不是业务应用系统数据的完整拷贝,需要对业务应用系统的数据进行抽取、综合、归类和统计。我们采用数据挖掘技术完成这一过程,建立共享数据中心。

2 数据挖掘技术

数据挖掘(Data Mining)就是从由不同IT应用系统产生大量的、不完全的、有噪声的、模糊的、随机的实际应用数据中,提取隐含在其中人们事先未知的、但又是潜在有用的信息和知识,并将其整合表示成既能被人理解,又便于存储和应用的模式。这些知识可以用在信息管理、查询响应、决策支持及过程控制等许多领域。数据挖掘是一种决策支持过程,它基于数据库、统计学、人工智能、机器学习、模式识别、数据可视化等多种技术,能自动地分析历史数据,并从中挖掘出供决策使用的高层次知识,帮助决策者提高决策质量和效率。数据挖掘通常分为描述型数据挖掘和预测型数据挖掘。描述型数据挖掘一般是对数据中存在的规则做出描述,通常通过对现有数据的概括、精炼和抽象反映同类事物的共同性质。预测型数据挖掘通过对现有数据的分析、处理,得到某种元组中某些属性的内容,或是预测出某些信息资源未来形成、使用的规律等。常用的数据挖掘方法有:1)关联分析。主要挖掘隐藏在数据间的相互关系,包括时序关联和因果关联等。2)序列分析。它与关联分析相似,但是侧重点在于分析数据间的前后(因果)关系。

3)分类分析。通过分析具有类别的样本的特点,以便能够分类识别未知样本的归属或类别。4)聚类分析。把数据分到不同的组中,搜索数据对象之间所存在的有价值联系。一般要使得到的分析结果更科学、更真实,可综合使用几种挖掘技术。

3 数据挖掘技术在区域卫生信息平台中的应用

基于居民电子健康档案的区域卫生信息平台的核心是居民个人电子健康档案数据中心,由于医学领域存在着大量的居民健康信息记录数据,包括完整的人类遗传密码的信息,大量关于病人的病史、诊断、检验和治疗的临床信息,药品管理信息和辅助管理信息等等。所以,居民个人电子健康档案的所有数据除了居民的基本信息由管理人员录入以外,其他各项健康数据都必须来自于医疗卫生系统各种不同功能的业务处理应用系统,其关键是如何抽取这些健康数据。考虑到目前各级卫生管理机构和医疗服务机构所使用的各种业务处理应用系统运行情况良好,为了不影响业务部门各关键业务应用的正常运行,充分地利用和发现各种业务处理应用系统中的现有资源,我们在开发设计岳阳楼区区域卫生信息平台时,采用数据挖掘技术,对居民个人健康数据进行抽取(Extract)、转换(Transform)和加载(Load)(简称为ETL),构建一个基于ETL的数据交换平台,定期更新居民个人电子健康档案中的各种健康数据。ETL的简单体系结构如图2所示。

(1)数据抽取。是指从各种业务处理应用系统数据库中,挖掘抽取与居民个人电子健康档案的项目相匹配的数据。在此系统中我们主要是采取增量抽取的方法,定时抽取各种业务处理应用系统数据库中要抽取的表中新增或修改的数据。

(2)数据转换。是指将挖掘抽取的数据按照业务需求,转换成电子健康档案数据库所要求的形式,并对错误、不一致的数据进行清洗和加工。在此系统中我们采取在ETL引擎中进行数据转换加工和在数据库中进行数据转换加工相结合的办法;首先在数据库中由SQL、函数来进行数据的加工,对于SQL语句无法处理的交由ETL引擎处理。

(3)数据加载。是指将转换和加工后的数据装载到电子健康档案中心数据库中。在此系统中我们采取直接SQL语句进行insert、update、delete操作和批量装载相结合的方法。

4 结束语

数据挖掘技术是近年来伴随着人工智能和数据库技术的发展而出现的一门新兴技术,它在企业决策、电子商务、医疗卫生、公安信息处理、高校管理等领域得到了广泛的应用。数据挖掘理论应用于医学,对医学数据进行分析,提取隐含在各种业务处理应用系统中有价值、有意义的信息,可以辅助各种行政管理者做出明智决策,医生通过这些共享的信息可以对病人做出更加正确的诊断和治疗,对人类疾病和健康的遗传规律的分析研究同样可起到极为重要的作用。数据挖掘技术在基于健康档案的区域卫生信息平台中的应用是其中的一个范例。随着大中型医院信息化程度的不断提高,电子病案系统已日益普及,如何利用电子病历数据库中的海量数据,将其转换成区域平台共享的居民电子健康档案信息已经成为当前医疗卫生领域研究的一个热点问题。

摘要：数据挖掘技术是近年来伴随着人工智能和数据库技术的发展而出现的一门新兴技术。文章结合作者开发岳阳楼区基于居民健康档案的区域卫生信息平台的实践,研究运用数据挖掘技术从各种现有医疗应用系统中抽取居民个人的诊疗记录,实现了居民个人健康信息的共享,并为临床辅助诊断、双向转诊等提供服务。

关键词：区域卫生信息平台,数据挖掘,电子健康档案

参考文献

[1]Han Jiawei,Micheline K.数据挖掘:概念与技术[M].范明,孟小峰,译.北京:机械工业出版社,2001.

[2]吴炜,杨梅瑰,唐飞岳.基于数据挖掘技术的辅助医疗诊断研究[J].医学信息学杂志,2010(12):22-26.

[3]郭东升,武彤.基于需求的威客网站数据挖掘技术应用研究[J].电脑知识与技术,2011(1):7-8,19.

[4]韩璐,孙蕾,施惠娟,等.基于SOA的数据挖掘原型平台的设计与实现[J].计算机应用与软件,2011(2):159-162.