标签：cti 本地 cli 办公室 而且 port 存储空间 entity 存储
IHE与区域医疗信息共享交换
集成医疗环境（ Integration Healthcare Enterprise，IHE）是众多医学专家和厂商共同倡议，1999年由美国医疗信息和管理系统学会（HIMSS）及北美放射学年会（RSNA）共同讨论建立，目标是提供更好的方法实现医疗信息系统之间信息的共享交换。IHE根据已有医疗信息和IT领域的规范和标准（例如DICOM、HL7、ebXML等），优化不同层次医疗服务流程，推动不同医疗信息系统之间实现信息共享。
IHE根据当今各国发展区域医疗信息共享交换的需求，于2004年颁布了跨企业级文档共享技术框架（Cross-Enterprise Document Sharing, XDS）。XDS技术框架文件详细定义了同一个“医疗联合体”（Clinical Affinity Domain）中的不同机构如何共享和交换病人医疗信息。“医疗联合体”是指若干个医疗机构形成的文档共享域，这些医疗机构同意通过协作共享的方式分享病人的医疗文档。XDS技术框架的基本理念就是通过ebXML标准实现共享文档的注册、查询和提取，其基本技术框架示意如图1所示。
1 . 主要角色（ Actors ） 及其相关事务（Transactions）
（1）文档注册中心（Document Registry）“文档注册中心”集中存放区域医疗文档的元数据信息。医疗文档元数据由“文档存储池”注册到“文档注册中心”（事务ITI-14），“文档注册中心”索引这些信息后提供给“文档用户”查询（事务ITI-16）。
（2）文档存储池（Document Repository）“文档存储池”存储病人医疗文档，文档由“文档源”提供/注册（事务ITI-15），并提供给“文档用户”提取（事务ITI-17）。
（3）文档源（Document Source）“文档源”负责生成医疗文档，并提供/注册到“文档存储池”（事务ITI-15）。医疗文档的信息可以来源于医院PACS、HIS或EMR等信息系统。
（4）文档用户（Document Consumer）医生通过“文档用户”查询感兴趣病人的文档索引（事务ITI-16），然后可以根据查询结果从对应的“文档存储池”提取病人医疗文档（事务ITI-17）。
（5）病人标识源（Patient Identity Source）为了在一个“医疗联合体”中统一管理来自各个不同医疗机构的病人标识，IHE颁布了病人标识交叉引用技术框架（Patient Identity Cross-referencing，PIX）。病人标识源是PIX中的一个组成部分，负责注册病人信息到PIX服务器（病人身份管理中心），并获取该病人在此“医疗联合体”中的唯一全局标识号（Unique Global ID）。图1中，“病人标识源”负责同步PIX和“文档注册中心”的病人标识（事务ITI-8）。
随着IT技术的发展，原有XDS技术架构需要及时更新。IHE保留2004年颁布的XDS技术框架文件的基础上，2007年颁布了一个新的跨企业级文档共享交换集成文件XDS.b，同时旧的XDS技术框架改称为XDS.a。XDS.b对XDS.a进行了升级和优化，主要改进内容有以下几点：
（1）ebXML元数据（metadata）格式升级，从ebXML Reg/Rep注册中心信息模型2.1版本升级到3.0版本。
（2）优化查询方式，更新了Stored Query方式进行文档查询时的数据绑定。
（3）优化文档提取效率，修改XDS.a中文档提取（事务ITI-17）为文档集（Document Set）提取。
（4）优化“文档存储池”在文档索引中的表达方式，在文档元数据中使用唯一标识号代表相应的“文档存储池”。
XDS.b基本技术框架示意如图2所示。XDS.b中增加了一个角色，集成文档源的文档存储池（IntegratedDocument Source/Repository）。该角色组合了“文档源”与“文档存储池”的功能，并减少了“提供/注册b型文档集”流程（事务ITI-41）。XDS.b中定义“集成文档源的文档存储池”是对“文档源”和“文档存储池”具体实现的一种补充，在医疗机构只有单个“文档源”的情况下可以考虑实现该角色，达到简化系统的效果。
IHE以XDS技术框架文件为基础，根据医疗文档的具体应用，又分别制定了放射影像共享交换（Cross-enterprise Document Sharing for Imaging,XDS-I）、扫描文档共享交换（Cross-EnterpriseSharing of Scanned Documents, XDS-SD）、医学概述共享交换（Cross Enterprise Sharing of MedicalSummaries Integration Profile, XDS-MS）和检验信息共享交换（Laboratory Report Document Sharing, XDSLab）技术框架文件，分别优化了影像信息、医学概述和检验报告的共享交换架构与流程。
区域影像共享交换技术框架XDS-I
IHE根据影像信息共享交换的需求，在XDS技术框架的基础上，于2005年提出了XDS-I技术框架。XDS-I的共享文档采用DICOM清单文档格式，可以清楚地描述病人的放射检查（Study）信息以及提供DICOM提取服务的AE Title。XDS-I对XDS定义的角色和事务做了适当的扩展，其基本技术框架如图3所示。
相对于XDS.a和XDS.b，XDS-I增加了“影像文档源”和“影像文档用户”两个角色。“影像文档源”负责生成和注册影像信息文档；“影像文档用户”能够根据提取到的文档信息从“影像文档源”提取到DICOM实体，包括影像、影像显示说明（Presentation States）、报告、关键图像注释（KeyImage Note）和证据文档（Evidence Documents）。
XDS-I的架构核心是分布式存储和集中式影像文档索引，该架构可以减轻数据中心建设成本和系统压力，并能充分使用医疗机构原有影像信息系统。除了医学影像分布式存储之外，医疗文档一般也采用分布式部署，即拥有“影像文档源”的医疗机构部署自己的“文档存储池”。
PACS与XDS-I的集成方法
PACS是医疗机构影像数据的主要存放点和服务提供者，实现PACS与XDS-I的集成是实现区域影像共享交换的关键。图4是基于XDS-I技术框架的区域影像共享交换示意图，该“医疗联合体”由三家医疗机构（医院A，癌症中心和医生办公室）和一个数据中心组成。
影像文档发布注册的流程为：医院PACS服务器首先通过“病人身份标识源”注册/获得病人在“医疗联合体”中的全局ID；然后，结合影像信息生成共享文档（DICOM清单文档），并使用ebXML标准服务提供/注册到“文档存储池”；最后由“文档存储池”注册文档元数据到“文档注册中心”发布。
影像文档的查询提取流程为：医院PACS客户端首先要获取病人的全局ID，全局ID可以从PIX服务器查询得到；然后，使用病人的全局ID作为查询条件通过ebXML标准服务查询“文档注册中心”；接着，根据查询结果从对应的“文档存储池”提取影像信息文档，并解析文档得到影像信息清单；最后，根据清单信息去对应的PACS服务器提取DICOM影像或报告，提取方式可以是DICOM C-Move或者WADO。
首先，“医疗联合体”中参与区域影像共享交换的PACS系统需要互相注册DICOM服务（包括C-Move、WADO等）。
然后，PACS服务器要成为影像数据源，必须具备以下功能：
（1）病人身份标识注册功能。PACS服务器需要通过“病人标识源”把本院病人身份信息注册到PIX服务器中，并获取病人在“医疗联合体”中的全局ID。
（2）影像信息文档生成功能。根据XDS-I定义，影像信息文档的格式是DICOM清单（Manifest）文档：关键对象选择（Key Object Selection, KOS）。KOS对象里包含了所描述DICOM影像的元数据，包括影像检查（Study）信息和影像所在PACS的AETitle。根据这些信息“影像文档用户”就可以从其他医疗机构的PACS中提取到感兴趣的影像。
（3）影像信息文档集的提供/注册功能。PACS服务器根据接收到的DICOM影像元数据生成影像信息文档后，把影像信息文档作为附件，通过ebXML服务提供/注册到“文档存储池”。该功能优先支持XDS.b中b型文档集提供/注册事务（ITI-41），选择支持XDS.a文档集提供/注册事务（ITI-15）。
最后，PACS客户端（显示工作站）除了具备传统的DICOM C-Move和WADO影像提取功能之外，必须具备以下功能：
（1）病人全局ID查询功能。跨区域提取病人影像需要事先知道该病人的全局ID,获取病人全局ID的方法就是查询PIX服务器。
（2）影像信息文档查询功能。根据用户需求，通过ebXML服务查询“文档注册中心”。该功能优先支持XDS.b中推荐的Stored Query方式查询（ITI-18），选择性支持XDS.a的文档查询事务（ITI-16）。
（3）影像信息文档提取功能。从“ 文档注册中心” 查询得到文档信息之后，根据查询结果，从对应的“ 文档存储池” 提取文档。该功能优先支持XDS.b的文档集提取事务（ITI-43），选择支持XDS.a的文
档提取事务（ITI-17）。
（4）DICOM清单文档解析功能。解析DICOM清单文档可以获得病人检查（Study）信息和所在PACS的AE Title，结合已经注册的该区域其他医疗机构提供的DICOM服务，就可以提取到病人影像。
当完成上述功能之后，医院的PACS系统就可以无缝集成到基于XDS/XDS-I的区域影像共享交换平台中。
区域医疗影像共享交换方案比较
目前，市场上除了XDS/XDS-I技术架构方案之外，还有其他两种比较主流的区域医疗影像共享交换方案：
中心化PACS方案采用集中存储和发布各医院影像的方式达到区域医疗影像共享交换的目的。各个医疗机构的影像设备或者信息系统直接把影像发送到数据中心；各医疗机构的显示工作站通过数据中心查询/提取感兴趣的影像。数据中心提供整个区域影像的注册、发布、查询和提取服务，这要求数据中心能够存储大容量影像数据、拥有高性能磁盘I/O和高网络数据吞吐量。为了满足这些要求，数据中心往往需要昂贵的大型存储、高带宽网络和高性能服务器，这导致整个系统的建设和维护成本巨大。而且作为传统的影像归档和传输解决方案，中心化PACS架构封闭、扩展困难，又通常使用DICOM或者厂商私有通讯协议，与非影像类信息系统（例如化验、医护、医疗保险等系统）的集成比较困难。
数据网格PACS方案采用分布式存储和集中式索引架构，较好地解决了中心化PACS集中存储和发布影像造成的系统性能问题。在数据网格PACS架构中，医疗机构各自存储本地影像，只需要注册影像元数据到“中心注册/存储池”中，并通过“中心注册/存储池”发布。医生在显示工作站上查询/提取其他医疗机构病人影像就像操作单一PACS一样简单。首先，医生使用显示工作站去“中心注册/存储池” 查询感兴趣病人的影像信息；然后发送影像提取命令给“中心注册/存储池”，“中心注册/存储池”会计算影像提取的最佳“路径”，并把用户影像提取请求定向到最佳提取“路径”的服务提供者（可能是本院PACS，也可能是其他医院PACS），完成影像提取流程。这种直接提取影像的方式对网络带宽要求小，不容易造成系统应用瓶颈。而且，数据网格PACS可以通过网格节点间数据互相备份，杜绝单点失败，并提供容灾功能。数据网格PACS解决了区域影像的存储、共享和管理问题，架构灵活、易扩展，但是主要针对影像应用范畴，通讯协议和信息模型未标准化，较难与其他非影像类信息系统集成。
在基于XDS/XDS-I技术框架的区域医疗影像共享交换方案中，上层信息（文档）的共享交换采用OASIS组织制定的电子商务全球化标准ebXML，即使用ebRIM （ebXML Registry Information Model）作为文档注册中心的信息模型，使用ebRS （ebXMLRepository/Registry Service） 作为文档注册、查询和提取服务的通讯标准。这使得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实现医疗信息文档的注册、发布和使用，解决了医学影像在区域中的共享交换问题，以及与非影像类信息系统的集成问题，可以为国家建设区域、地区性电子病历/电子健康记录共享交换系统提供有益的借鉴和指导。
标签：cti 本地 cli 办公室 而且 port 存储空间 entity 存储
原文地址：https://www.cnblogs.com/changzhp/p/13718309.html
