IHE技术架构.docx
- 文档编号:10322013
- 上传时间:2023-05-25
- 格式:DOCX
- 页数:18
- 大小:374.85KB
IHE技术架构.docx
《IHE技术架构.docx》由会员分享,可在线阅读,更多相关《IHE技术架构.docx(18页珍藏版)》请在冰点文库上搜索。
IHE技术架构
基于XDS/XDS-I的区域医疗影像共享交换技术架构
IHE与区域医疗信息共享交换
集成医疗环境(IntegrationHealthcareEnterprise,IHE)是众多医学专家和厂商共同倡议,1999年由美国医疗信息和管理系统学会(HIMSS)及北美放射学年会(RSNA)共同讨论建立,目标是提供更好的方法实现医疗信息系统之间信息的共享交换。
IHE根据已有医疗信息和IT领域的规范和标准(例如DICOM、HL7、ebXML等),优化不同层次医疗服务流程,推动不同医疗信息系统之间实现信息共享。
IHE根据当今各国发展区域医疗信息共享交换的需求,于2004年颁布了跨企业级文档共享技术框架(Cross-EnterpriseDocumentSharing,XDS)。
XDS技术框架文件详细定义了同一个“医疗联合体”(ClinicalAffinityDomain)中的不同机构如何共享和交换病人医疗信息。
“医疗联合体”是指若干个医疗机构形成的文档共享域,这些医疗机构同意通过协作共享的方式分享病人的医疗文档。
XDS技术框架的基本理念就是通过ebXML标准实现共享文档的注册、查询和提取,其基本技术框架示意如图1所示。
1.主要角色(Actors)及其相关事务(Transactions)
(1)文档注册中心(DocumentRegistry)“文档注册中心”集中存放区域医疗文档的元数据信息。
医疗文档元数据由“文档存储池”注册到“文档注册中心”(事务ITI-14),“文档注册中心”索引这些信息后提供给“文档用户”查询(事务ITI-16)。
(2)文档存储池(DocumentRepository)“文档存储池”存储病人医疗文档,文档由“文档源”提供/注册(事务ITI-15),并提供给“文档用户”提取(事务ITI-17)。
(3)文档源(DocumentSource)“文档源”负责生成医疗文档,并提供/注册到“文档存储池”(事务ITI-15)。
医疗文档的信息可以来源于医院PACS、HIS或EMR等信息系统。
(4)文档用户(DocumentConsumer)医生通过“文档用户”查询感兴趣病人的文档索引(事务ITI-16),然后可以根据查询结果从对应的“文档存储池”提取病人医疗文档(事务ITI-17)。
(5)病人标识源(PatientIdentitySource)为了在一个“医疗联合体”中统一管理来自各个不同医疗机构的病人标识,IHE颁布了病人标识交叉引用技术框架(PatientIdentityCross-referencing,PIX)。
病人标识源是PIX中的一个组成部分,负责注册病人信息到PIX服务器(病人身份管理中心),并获取该病人在此“医疗联合体”中的唯一全局标识号(UniqueGlobalID)。
图1中,“病人标识源”负责同步PIX和“文档注册中心”的病人标识(事务ITI-8)。
2.XDS.b对XDS.a进行升级和优化
随着IT技术的发展,原有XDS技术架构需要及时更新。
IHE保留2004年颁布的XDS技术框架文件的基础上,2007年颁布了一个新的跨企业级文档共享交换集成文件XDS.b,同时旧的XDS技术框架改称为XDS.a。
XDS.b对XDS.a进行了升级和优化,主要改进内容有以下几点:
(1)ebXML元数据(metadata)格式升级,从ebXMLReg/Rep注册中心信息模型2.1版本升级到3.0版本。
(2)优化查询方式,更新了StoredQuery方式进行文档查询时的数据绑定。
(3)优化文档提取效率,修改XDS.a中文档提取(事务ITI-17)为文档集(DocumentSet)提取。
(4)优化“文档存储池”在文档索引中的表达方式,在文档元数据中使用唯一标识号代表相应的“文档存储池”。
XDS.b基本技术框架示意如图2所示。
XDS.b中增加了一个角色,集成文档源的文档存储池(IntegratedDocumentSource/Repository)。
该角色组合了“文档源”与“文档存储池”的功能,并减少了“提供/注册b型文档集”流程(事务ITI-41)。
XDS.b中定义“集成文档源的文档存储池”是对“文档源”和“文档存储池”具体实现的一种补充,在医疗机构只有单个“文档源”的情况下可以考虑实现该角色,达到简化系统的效果。
IHE以XDS技术框架文件为基础,根据医疗文档的具体应用,又分别制定了放射影像共享交换(Cross-enterpriseDocumentSharingforImaging,XDS-I)、扫描文档共享交换(Cross-EnterpriseSharingofScannedDocuments,XDS-SD)、医学概述共享交换(CrossEnterpriseSharingofMedicalSummariesIntegrationProfile,XDS-MS)和检验信息共享交换(LaboratoryReportDocumentSharing,XDSLab)技术框架文件,分别优化了影像信息、医学概述和检验报告的共享交换架构与流程。
区域影像共享交换技术框架XDS-I
IHE根据影像信息共享交换的需求,在XDS技术框架的基础上,于2005年提出了XDS-I技术框架。
XDS-I的共享文档采用DICOM清单文档格式,可以清楚地描述病人的放射检查(Study)信息以及提供DICOM提取服务的AETitle。
XDS-I对XDS定义的角色和事务做了适当的扩展,其基本技术框架如图3所示。
相对于XDS.a和XDS.b,XDS-I增加了“影像文档源”和“影像文档用户”两个角色。
“影像文档源”负责生成和注册影像信息文档;“影像文档用户”能够根据提取到的文档信息从“影像文档源”提取到DICOM实体,包括影像、影像显示说明(PresentationStates)、报告、关键图像注释(KeyImageNote)和证据文档(EvidenceDocuments)。
XDS-I的架构核心是分布式存储和集中式影像文档索引,该架构可以减轻数据中心建设成本和系统压力,并能充分使用医疗机构原有影像信息系统。
除了医学影像分布式存储之外,医疗文档一般也采用分布式部署,即拥有“影像文档源”的医疗机构部署自己的“文档存储池”。
PACS与XDS-I的集成方法
1.区域影像共享交换的关键
PACS是医疗机构影像数据的主要存放点和服务提供者,实现PACS与XDS-I的集成是实现区域影像共享交换的关键。
图4是基于XDS-I技术框架的区域影像共享交换示意图,该“医疗联合体”由三家医疗机构(医院A,癌症中心和医生办公室)和一个数据中心组成。
影像文档发布注册的流程为:
医院PACS服务器首先通过“病人身份标识源”注册/获得病人在“医疗联合体”中的全局ID;然后,结合影像信息生成共享文档(DICOM清单文档),并使用ebXML标准服务提供/注册到“文档存储池”;最后由“文档存储池”注册文档元数据到“文档注册中心”发布。
影像文档的查询提取流程为:
医院PACS客户端首先要获取病人的全局ID,全局ID可以从PIX服务器查询得到;然后,使用病人的全局ID作为查询条件通过ebXML标准服务查询“文档注册中心”;接着,根据查询结果从对应的“文档存储池”提取影像信息文档,并解析文档得到影像信息清单;最后,根据清单信息去对应的PACS服务器提取DICOM影像或报告,提取方式可以是DICOMC-Move或者WADO。
2.集成PACS与XDS-I实现区域影像共享交换PACS与XDS-I集成实现区域医学影像共享交换需要做到以下几点:
首先,“医疗联合体”中参与区域影像共享交换的PACS系统需要互相注册DICOM服务(包括C-Move、WADO等)。
然后,PACS服务器要成为影像数据源,必须具备以下功能:
(1)病人身份标识注册功能。
PACS服务器需要通过“病人标识源”把本院病人身份信息注册到PIX服务器中,并获取病人在“医疗联合体”中的全局ID。
(2)影像信息文档生成功能。
根据XDS-I定义,影像信息文档的格式是DICOM清单(Manifest)文档:
关键对象选择(KeyObjectSelection,KOS)。
KOS对象里包含了所描述DICOM影像的元数据,包括影像检查(Study)信息和影像所在PACS的AETitle。
根据这些信息“影像文档用户”就可以从其他医疗机构的PACS中提取到感兴趣的影像。
(3)影像信息文档集的提供/注册功能。
PACS服务器根据接收到的DICOM影像元数据生成影像信息文档后,把影像信息文档作为附件,通过ebXML服务提供/注册到“文档存储池”。
该功能优先支持XDS.b中b型文档集提供/注册事务(ITI-41),选择支持XDS.a文档集提供/注册事务(ITI-15)。
最后,PACS客户端(显示工作站)除了具备传统的DICOMC-Move和WADO影像提取功能之外,必须具备以下功能:
(1)病人全局ID查询功能。
跨区域提取病人影像需要事先知道该病人的全局ID,获取病人全局ID的方法就是查询PIX服务器。
(2)影像信息文档查询功能。
根据用户需求,通过ebXML服务查询“文档注册中心”。
该功能优先支持XDS.b中推荐的StoredQuery方式查询(ITI-18),选择性支持XDS.a的文档查询事务(ITI-16)。
(3)影像信息文档提取功能。
从“文档注册中心”查询得到文档信息之后,根据查询结果,从对应的“文档存储池”提取文档。
该功能优先支持XDS.b的文档集提取事务(ITI-43),选择支持XDS.a的文
档提取事务(ITI-17)。
(4)DICOM清单文档解析功能。
解析DICOM清单文档可以获得病人检查(Study)信息和所在PACS的AETitle,结合已经注册的该区域其他医疗机构提供的DICOM服务,就可以提取到病人影像。
当完成上述功能之后,医院的PACS系统就可以无缝集成到基于XDS/XDS-I的区域影像共享交换平台中。
区域医疗影像共享交换方案比较
目前,市场上除了XDS/XDS-I技术架构方案之外,还有其他两种比较主流的区域医疗影像共享交换方案:
1.中心化PACS方案
中心化PACS方案采用集中存储和发布各医院影像的方式达到区域医疗影像共享交换的目的。
各个医疗机构的影像设备或者信息系统直接把影像发送到数据中心;各医疗机构的显示工作站通过数据中心查询/提取感兴趣的影像。
数据中心提供整个区域影像的注册、发布、查询和提取服务,这要求数据中心能够存储大容量影像数据、拥有高性能磁盘I/O和高网络数据吞吐量。
为了满足这些要求,数据中心往往需要昂贵的大型存储、高带宽网络和高性能服务器,这导致整个系统的建设和维护成本巨大。
而且作为传统的影像归档和传输解决方案,中心化PACS架构封闭、扩展困难,又通常使用DICOM或者厂商私有通讯协议,与非影像类信息系统(例如化验、医护、医疗保险等系统)的集成比较困难。
2.数据网格PACS(GridPACS)方案
数据网格PACS方案采用分布式存储和集中式索引架构,较好地解决了中心化PACS集中存储和发布影像造成的系统性能问题。
在数据网格PACS架构中,医疗机构各自存储本地影像,只需要注册影像元数据到“中心注册/存储池”中,并通过“中心注册/存储池”发布。
医生在显示工作站上查询/提取其他医疗机构病人影像就像操作单一PACS一样简单。
首先,医生使用显示工作站去“中心注册/存储池”查询感兴趣病人的影像信息;然后发送影像提取命令给“中心注册/存储池”,“中心注册/存储池”会计算影像提取的最佳“路径”,并把用户影像提取请求定向到最佳提取“路径”的服务提供者(可能是本院PACS,也可能是其他医院PACS),完成影像提取流程。
这种直接提取影像的方式对网络带宽要求小,不容易造成系统应用瓶颈。
而且,数据网格PACS可以通过网格节点间数据互相备份,杜绝单点失败,并提供容灾功能。
数据网格PACS解决了区域影像的存储、共享和管理问题,架构灵活、易扩展,但是主要针对影像应用范畴,通讯协议和信息模型未标准化,较难与其他非影像类信息系统集成。
3.基于XDS/XDS-I技术框架方案
在基于XDS/XDS-I技术框架的区域医疗影像共享交换方案中,上层信息(文档)的共享交换采用OASIS组织制定的电子商务全球化标准ebXML,即使用ebRIM(ebXMLRegistryInformationModel)作为文档注册中心的信息模型,使用ebRS(ebXMLRepository/RegistryService)作为文档注册、查询和提取服务的通讯标准。
这使得XDS/XDS-I技术架构与其他影像和非影像类信息系统的集成变得容易。
由于采用分布式存储和集中式文档索引的架构,基于XDS/XDS-I的区域医疗影像共享交换方案能够优化网络带宽使用、节省存储空间、缓解系统应用瓶颈。
但与数据网格PACS方案不同,XDS/XDS-I技术框架没有提供区域数据备份策略,因此无法参考XDS/XDS-I实现系统容灾、影像最优提取“路径”计算等存储和管理功能。
这是因为XDS/XDS-I技术框架的核心是医疗文档共享,要解决的问题是不同影像信息系统之间,以及影像信息系统与非影像信息系统之间的医疗信息共享交换问题,而不是影像的存储和管理问题。
因此,在整个医疗信息共享交换架构中,基于XDS/XDS-I的区域医疗影像共享交换方案的层次高于中心化PACS和数据网格PACS方案,即中心化PACS和数据网格PACS都可以作为“影像文档源”集成进基于XDS/XDS-I的区域医疗影像共享交换平台。
上述三种区域医学影像共享交换方案的特性比较如表1所示。
结论
随着居民对医疗保健要求不断提高和国家医疗制度改革的不断深化,我国中央和各级地方政府加大了对区域医疗信息系统的投入。
国家推动区域性三级医疗协同服务的目标是创新医疗卫生行业信息化建设和协同医疗服务模式、切实缓解老百姓的“看病难、看病贵”问题,实现目标的关键技术就是要解决不同医疗机构、不同医疗信息系统间的信息共享交换问题。
基于XDS/XDS-I的区域影像共享交换技术以医疗文档共享为核心,使用全球电子商务标准ebXML实现医疗信息文档的注册、发布和使用,解决了医学影像在区域中的共享交换问题,以及与非影像类信息系统的集成问题,可以为国家建设区域、地区性电子病历/电子健康记录共享交换系统提供有益的借鉴和指导。
AGFA医疗中国研发中心 金金
IHE在美国区域卫生网络的应用
2009-07-2111:
14
Tags:
IHE
现状与问题
美国的医疗卫生信息化工作起步早、投入大、历时长、应用范围广、系统繁多,但在医院内部各级部门之间、医院与医院之间形成了大大小小的信息孤岛。
例如,美国CHW医院集团的43家医院共有2000多个异源异构应用系统在运行,这些信息孤岛尽管满足了某些局部业务的功能性需求,但不能形成数据层、应用层以及工作流程相关的协同工作。
这些医院或医院集团信息化建设的发展由于各系统的整合性问题,而步入举步维艰的地步。
在过去几年里,区域卫生信息网络(RHIN)在美国的发展方兴未艾,如何实现异源异构系统之间的医疗信息交互与共享一直是北美卫生行业和政府关注的热点。
基于IHE的医疗信息交换
在过去的十余年,医疗健康信息集成规范(IHE)由北美卫生行业专业人士倡议发起而后得到了全世界同行的广泛关注、认可和采纳,已成为异源异构系统之间的医疗信息交互与共享的标准化的规范,为解决互操作性问题提供有效的方案。
IHE并不是定义新的集成标准,而是首先着眼于支持现有的成熟的标准(例如DICOM和HL7),在现有标准的基础上定义了各集成模型中的角色以及基于标准的事务,为异构信息系统间的工作流集成提供了技术框架(TechnicalFramework)和规范(profiles)以及为实现这些框架的验证过程。
根据IHE集成技术框架和规范,建立信息集成平台,可以有效地在应用级、流程级及数据级进行系统整合与优化,从而将众多的信息孤岛连通,保护原有系统的投资,而不是推倒重来。
如果一些局部系统确实需要更新换代,则采取一步步更换或改造老系统的办法进行。
IHE不仅为医院或医院集团内部信息集成提供标准化的方案而且为解决区域卫生信息网络中互操作性问题提供有效的规范。
基于IHE的医疗信息交换平台有5个关键技术的支撑(图1)。
1.安全管理
IHE审计跟踪和节点认证(ATNA-AuditTrailandNodeAuthentication)技术规范(Profile),要求实现统一用户管理,单点登录,日志服务,审计跟踪和节点认证等安全保障措施,解决异构系统集成的安全问题。
2.病人主索引与医生主索引
异源异构的应用系统的患者和医生用户在不同的系统可能有着不同的用户标识(ID)和名称。
即使在同一个系统里,同一个患者或医生可能有多个ID,同一个ID也可能误用于不同患者或医生。
病人与医生主索引管理是医疗信息交换的另一个基石。
3.文档共享
IHEXDS提供医疗机构间统一的文档管理和分享的标准。
XDS技术框架的核心思想是从逻辑上划分文件存储库和文档注册者,用于共享交换的文件存储库采用分布式存储,而对其索引信息采用集中式发布和注册。
4.动态信息访问
患者基本信息、就诊信息、用药信息、费用信息、过敏信息、检验信息及检查信息等动态信息可能以非文档形式分散在异源异构系统中。
将从不同数据源获取到的零散信息和数据聚集成一个完整的界面呈现给用户,对异源异构的医疗系统实现界面的集成,为信息共享提供简单统一的访问入口,至关重要。
5.流成管理
许多调查表明,医生平均需要到5~7个不同系统(例如HIS、EMR、PACS、LIS、EDM等)才能得到所有相关的病人信息,医务人员约30%的时间用于搜索和整理数据。
实现流程自动化管理,简化了用户操作,提高了操作效率,降低了出错的可能性。
凯歌医疗信息共享解决方案
结合长期以来从事大型医疗信息系统集成的成功经验,我们采用组件化的设计方法,按照面向服务的架构(SOA)原则和WebService协议,建设一个以异构信息系统(如EMR、HIS、LIS、PACS/RIS及CIS)为基础的、一套以人为本、以患者为中心的涵盖病人信息查询、支持医院治疗流程优化及提高社区整体卫生健康水平的信息共享平台。
此信息共享平台,是基于IHE和SOA开放式的构架,基于服务的功能组建化,以服务架构包装现有系统及功能,采用统一的协议、标准化的数据转换、统一的安全保障,无侵入的系统集成,实现医疗机构间信息的“互认”、“互操作”与“共享”,提高流程标准化、自动化,同时达到实用性、可操作性、可靠性、可维护性强的目的。
提供一套具有整合、交互功能的创新工具,从而降低医院信息系统互连的成本,提高医院信息系统之间信息共享的程度(图2)。
1.完善、统一的安全管理
实现数据采集、数据传输、数据访问以及数据备份容灾的安全性。
基于角色管理的设计,也为用户的登录认证以及权限管理提供了充分的安全性和灵活性。
统一管理用户终端,提供单点登录(SSO)等功能。
同时提供完善的审计日志服务,来对系统中的关键操作以及平台运行情况的记录,包括用户登录信息、关键操作的信息和平台的运行状态以及错误记录。
审计日志实现了可配置性,可按照操作的重要性实现分级别的记录或不记录配置。
2.IHE规范主索引与数据索引
基于IHE国际规范,应用特有的算法和技术,建立中央集中的病人主索引、医生主索引与医疗档案存储中心数据索引,能自动将各医院或各部门同一病人的资料链接,以保证患者数据的完全和快速认证与提取。
可以保证无论在任何地方,都可以通过唯一标识索引无缝地、透明地定位到患者的数据。
分布集中构架不需要创建庞大的中心数据库,避免复杂的、多个系统之间数据同步问题,可以使参与机构各自控制数据的分享程度与内容,解决了数据的所有权与安全问题。
3.跨机构文档共享
使用IHEXDS标准规范建立中央集中的医疗档案数据索引,保证患者数据的完全和快速认证与提取。
采用发布和订阅模式,创建文档存储库,建立文档的主索引,支持快速的文档检索和查询。
医疗人员可以方便快捷地找到病人的检查结果和过往病史,有利于及时快速地诊断疾病和确定治疗方案.
4.个性化门户的应用整合
基于JSR168/286标准,提供Portal相关的特性和功能。
Portal为信息共享平台提供了一个简单统一的访问入口,包括应用整合、IT架构整合、文档内容管理和协作服务。
集成视图工具将从不同数据源获取到的零散信息和数据聚集成一个完整的界面呈现给用户。
5.基于HL7CCOW标准的流程自动化管理
通过这种机制,当用户在一个视图中查看患者信息时,其他的视图会自动同步,为用户显示当前患者的相关信息,避免用户频繁切换视图,反复输入查询条件,以查找同一病人基于不同应用的数据或信息,最大限度地简化了用户操作,提高了操作效率,降低了出错的可能性。
成功案例分析
凯歌信息共享平台成功案例包括美国CHW医疗集团、哈佛大学医学院、路易斯安那州、波士顿、英国剑桥大学医学院、英国牛津大学医学院等500多家赫赫有名医院及地区,本文重点讨论IHE在美国波士顿区域卫生网(BostonHealthNet-BHN)信息交互中的应用。
BHN旨在为社区医疗服务网络提供跨机构的信息整合、交互、共享和增值服务,实现同一个病人、同一个健康档案,加强机构之间的协作,提供决策支持和工作流程管理功能(包括自动化双向转诊),提高医护质量。
通过凯歌信息共享平台,IHE为解决BHN社区医疗信息互操作性问题提供标准化的规范和有效的方案。
●按照HL7标准、IHE规范建立中央集中的病人主索引(EMPI)与医疗档案存储中心数据索引,海量医疗数据与影像信息实行分布集中式数据管理模型。
●遵守标准:
C32–ClinicalSummaryusingCCD TP13–DocumentSetManagement TP30–ConsentManagement TP22–PatientIDCross-Referencing(PIX) TP23–PatientDemographicQueryforMPI(PDQ) DICOM HL7CCOW、IHEPSA(患者同步应用集成规范)
●IHEXDS跨机构文档共享
●XML与Webservices
●统一的WebService协议与接口、标准化的数据转换
●统一的用户管理、单点登录(SSO)、审计日志等安全管理功能
●统一的、个性化的门户(Portal)
●无侵入性建立信息共享,保护原有投资
●医疗信息共享平台有利实现与完善增值服务功能-自动化双向转诊系统流程
应用基于IHE和SOA的凯歌信息共享平台,BHN实现了纵向的信息交互与共享,帮助专科医生更加了解病人的情况而且提高社区医生对病人的进一步跟踪治疗。
另外,该平台通过对转诊流程的监控来提高医院设施的使用率以及经济效益,促进专科医院与社区医院的转诊流程自动化,保证系统的开放性、
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- IHE 技术 架构