基于语义网关的医疗互操作性

基于智能边缘计算的语义网关用于医疗系统互操作性与协作

Tshiamo Sigwele，Yim Fun Hu，Muhammad Ali 和 侯佳辰 University of Bradford 布拉德福德，英国 邮箱：[T.Sigwele1, Y.F.Hu, M. Ali70,J.Hou1]@bradford.ac.uk
Misfa Susanto 和 Helmy Fitriawan 电气工程系工学院 南苏门答腊大学，印度尼西亚 邮箱：misfa@eng.unila.ac.id 邮箱：helmy.fitriawan@eng.unila.ac.id

摘要

信息与通信技术（ICTs）在医疗保健领域的应用具有减少医疗错误、降低医疗成本以及改善医疗系统之间协作的潜力，从而显著提升医疗服务质量。然而，由于缺乏协作和医疗信息的交换，不同医疗系统（诊所/医院/药房）之间的互操作性仍然是一个需要进一步研究的问题。为解决这一问题，需要实现跨医疗系统的协作。本文提出了一种基于物联网（IoT）基础设施的基于语义的医疗协作框架概念模型，该框架能够安全、无缝地在不同医疗系统之间进行设备和人类均可读的信息和知识交换。在所提出的框架中，引入了一个智能语义网关，通过使用带有RESTful应用程序编程接口（API）的Web应用，来发布各个系统的医疗信息以实现协作。论文还进行了一个案例研究，实际演示了在两个不同医疗系统之间共享患者数据的过程，其中药剂师可以访问来自诊所的患者的电子处方。

索引术语 —物联网，医疗保健互操作性，智能网关，语义网，本体，传感器网络

I. 引言

最近，随着许多医疗保健机构通过实施电子健康记录（EHR）系统逐步将基于纸质的患者病历迁移到数字电子记录，医疗领域发生了范式转变。所记录的信息可以包括观察结果、患者的个人详细信息、患者医疗史、临床笔记、实验室检测、治疗、给药情况、信函、X光片和账单。EHR系统可通过在医疗机构之间共享患者信息来避免重复检查，从而必然实现节省成本并提高医疗质量。通过EHR，医疗保健机构可以相互共享患者的医疗保健信息，因此能够做出更好的医疗保健决策。需要共享的信息存储在异构的分布式医疗系统中，采用不同的文件格式，且主要是专有的[2]。这些信息需要以统一且透明的方式被医疗系统相互交互和访问，随时随地进行。然而，即使引入了电子健康记录，医疗系统之间仍然彼此孤立，缺乏协作和互操作性。如图1所示，医疗互操作性可以定义为两个或多个不同的医疗系统（如智能医院、诊所、智能家居、药房等）能够可靠且快速地相互共享信息，并共同对其进行操作，避免错误的发生，从而提高可用性[3]。医疗互操作性具有以下优势[2]：
i) 患者记录的便捷访问
ii) 减少医疗错误，从而降低伤亡
iii) 医疗成本降低
iv) 减少医疗系统的延误

据估计，在未来10年中，当前医疗保健的提供方式将从以医院为中心，首先在2020年转变为医院与家庭平衡，最终在2030[4]转变为以家庭为中心。这一根本性转变要求必须更加积极地考虑用于智能空间和医疗保健领域的物联网（IoT）架构与技术的融合与重叠。医疗保健中的物联网还将加剧大量医疗数据的产生，医疗系统之间需要协作共享这些医疗大数据。

本文提出了一种基于语义的医疗协作框架，能够为不同的医疗系统之间提供无缝的跨系统信息交换平台，该平台可被设备和人类共同读取。所考虑的医疗系统包括异构且地理上分散的药房、智能家居、智能医院和智能诊所，这些系统需要相互交互与协作。在所提出的框架中，每个医疗系统都集成了一个智能语义网关和一个带有RESTful应用程序编程接口（API）的Web应用，用于安全暴露各医疗系统的相关信息以实现协作。为了验证我们的主张，还提供了一个案例研究，展示使用本体实现药房与诊所之间互操作性的概念。

本文其余部分组织如下：第二节讨论医疗领域内的互操作性相关工作以及一些通用医疗标准。第三节提出了基于语义的医疗互操作性框架，同时介绍了所提出的医疗系统架构、语义智能网关功能以及一个基于本体的案例研究。最后，第四节给出了结论，第五节为致谢。

II. 相关工作

为了解决医疗系统之间存在的孤立问题，实现这些系统的互操作性至关重要。尽管在医疗领域已有多项努力致力于解决互操作性问题，但这仍然是一个有待进一步研究的开放性问题。健康数据复杂性、医疗保健安全和标准化导致了医疗系统集成困难和互操作性问题。解决这些问题的一种方法是使用通用数据模型[3]。

医疗标准为不同医疗系统之间的互操作性提供了基础[5]。医疗领域针对不同目的制定了相应的标准。这些标准涉及医疗消息的传递方式、所使用的术语、文档、概念框架、架构和应用，既包括基于通信结构的语法互操作性，也包括定义通信含义的语义互操作性。一些通用医疗标准如下[5]；由健康等级七（HL7）国际组织制定的消息相关标准如HL7、HL7 V2和V3[6]，这些被认为是医疗保健互操作性方面更灵活的标准；术语（医学系统化术语—临床术语SNOMED‐CT[6]）；临床信息和患者记录（openEHR[7]和HL7临床文档架构‐CDA）。

[8]的作者提出了一种基于雾计算的物联网医疗解决方案结构，并探索了在传统云架构基础上扩展的互操作性医疗解决方案中云‐雾服务的集成。通过使用iFogSim模拟器进行模拟评估了相关场景，并针对分布式计算、延迟降低、数据通信优化和功耗等方面分析了结果。然而，这些作者仅在一个医疗系统内集成了多种物联网设备，并未实现不同医疗系统之间的互操作性。[9]的作者提出了物联网中大数据的语义互操作性模型（SIMB‐IoT），以实现医疗领域中异构物联网设备之间的语义互操作性。该模型用于根据从异构物联网传感器收集的不同症状推荐药物及其副作用。然而，该研究仅考虑了一个医疗系统，且互操作性仅限于异构物联网设备之间。

在[10]中提出的Jini健康互操作性框架（HIF‐J）使用基于面向服务的架构（SOA）的Jini技术。HIF‐J的主要目的是交换语义互操作消息。它提供转换服务，作为不同标准之间的中介。这些转换服务可转换HL7、HL7 V2和V3以及openEHR的消息实例。该机制基于可扩展样式表语言转换（XSLT），实现不同标准消息实例之间的转换。由于标准随着新领域的出现而不断发展，因此管理XSLT变得非常困难。在[11]中，作者借助HL7 V3中的交互本体关注语义过程互操作性。交互本体负责处理符合HL7 V3标准的不同医疗系统之间的过程异构性。这项工作仅涉及使用HL7 V3标准的语义过程互操作性，未讨论语义数据互操作性。[15]中的作者使用本体匹配工具解决不同医疗标准之间的数据级异构性，并实现消息模式级转换；然而，该研究仅集中在HL7医疗标准上。[12]中的作者提出了一种智能电子健康网关，能够增强用于医疗应用的物联网架构，将医院的传感器医疗数据集成到云医疗中心，但该框架未提供不同医疗系统之间的互操作性。

从现有文献来看，为医疗系统提供互操作性的研究努力仅集中在单个医疗系统的各个部分，而未能提供与其他不同医疗系统机构集成的方法。此外，当前研究中的互操作性大多集中在信息交换方面，但忽略了信息的语义知识及其关系的共享与交换。

III. 基于语义的医疗互操作性框架提案

在本节中，将介绍所提出的架构，然后解释协作框架，最后通过一个案例研究进行实际阐述，以展示如何利用本体在独立的医疗系统之间共享信息。

A. 医疗系统架构提案

用于互操作性的医疗系统提出的架构如图2 (a)所示。需要交换的患者健康相关信息将从各种来源收集，例如其他医疗系统、网页（如DBPedia、维基百科），或由患者配备的用于多参数个人监测的智能设备或体戴传感器记录。该系统架构包括智能设备、雾层和云层，如图2 (b)所示。

1) 智能设备

智能设备包括智能摄像头、体感传感器、可穿戴设备以及其他各种传感器。这些设备中的大多数，例如可穿戴医疗传感器，无法存储其生成的数据。一种简单的设计方法是将其数据传输到远程云进行处理。鉴于连接设备数量庞大，与云之间的连接延迟可能显著。此外，这些设备在功耗和带宽方面受限，使其难以直接适应云架构。边缘计算是一种向分层系统架构和更快速响应设计转变的关键范式，因此本文采用了该方法。语义智能网关的概念是在智能设备与云之间的网络边缘提供多种服务。智能设备的数据通过有线或无线通信协议传输至网关。

2) 雾层

雾层将智能设备连接到互联网，位于网络边缘。它由语义智能网关组成，是所提出框架的核心部分，所有的业务逻辑都在此处实现，具体内容将在第三节中进一步说明。该网关支持多种无线协议和设备间通信。健康传感器和环境传感器（如温度、光照传感器、水浸传感器等）通过不同标准的无线网络或有线连接（例如 6LoWPAN、LoRa、Sigfox、NB‐IoT、WiFi等）与网关相连。网关的智能化体现在能够轻松集成这些异构网络技术、协议和标准，并通过多个接口实现信息交换和无缝协作。除了支持异构协议并执行协议转换外，语义网关还执行其他功能，包括数据采集、表示和建模，数据处理与知识生成、数据过滤、数据分析等。它还通过 REST API 充当向其他医疗系统传播信息的节点。

3) 云层

这是所有其他医疗系统方都可以访问信息和数据的互联网。它由远程云数据中心组成，这些数据中心托管了所提出框架的知识库。这些数据中心还将生成的语义信息存储在资源描述框架/可扩展标记语言（RDF/XML）文件中，这些文件采用网络本体语言（OWL）编写。OWL文件可以被视为未来的数据库。它们不仅存储系统的数据，还存储称为语义的元数据（关于数据的数据），其中包括概念之间的关系。大量包含类实例的OWL文件构成了知识库，可作为任何应用程序的数据库。云层还包括维基百科、Xively、DBpedia和ThinkSpeak等在线工具和存储库，以及所有互联医疗系统（急诊、药房、国家医疗服务体系（NHS）），这些系统可以通过所提出的框架无缝地与其他系统协作并请求信息。网页客户端被用作最终可视化与反馈的图形用户界面。只有其他医疗系统的授权用户才能访问该网页客户端。

B. 提出的医疗系统协作框架

所提出的医疗系统协作框架如图3所示。该协作框架在医疗保健领域的目的在于：（1）从各种来源（通过网页的传感器或其他医疗系统）采集与表示数据，（2）生成知识，以及（3）与其他外部医疗系统共享和交换信息和知识。数据采集与表示是该框架的第一个组成部分，此处进行原始数据的获取及其建模与表示。这些数据通常会根据专有模式进行建模。下一步是在数据上应用语义上下文和业务规则，将其转化为有用的信息和可操作的知识。最后，处理后的知识可通过应用程序编程接口与外部医疗系统代理进行共享和协作。

1) 数据采集、表示与建模

医疗数据主要从本地传感器网络中采集，但也可以通过应用程序编程接口（API）从存储库中获取（例如Xively）。资产模型以特定于平台的方式处理传感设备和数据的建模与表示，并根据专有模式进行存储。数据可以存储在任何相应的存储介质中，如关系数据库管理系统（RDBMS）、XML文件、逗号分隔值（CSV）文件、Excel文件等。资产模型将数据提供给协作框架的其他组件，以便进一步处理和丰富。访问管理组件负责对希望访问资产模型中存储数据的参与者进行身份验证和授权。这些参与者可以是内部（管理员）和外部（其他医疗系统）。

2) 数据处理与知识生成

一旦数据从本地传感器网络中被捕获或从其他存储库导入，就需要对这些数据进行情境化，以便其能够表示有意义的信息。将原始数据转化为有用信息的过程可以通过多种方法实现。例如，可以对数据片段应用业务规则以生成有意义的信息。比如，从传感器获取的一个数值数据可以通过添加语义上下文，转变为有用的信息，如血压水平或水流水平。整个采集数据并生成、标注以及提供高层级信息的领域被称为知识管理（KM）。对于每个医疗系统，资产模型中的各种数据源都被映射到一个本地本体，使得每个医疗系统都有其本地本体。这些本地本体随后被映射到一个全局本体，所有协作的医疗系统都基于该全局本体构建。这些本体以.owl文件格式存储在互联网上，并可被设备和人类访问与理解。

3) 语义网关附加组件

该网关还集成了若干可在网络边缘执行的附加组件，如下所述：

i) 本地存储 ：网关上的数据存储在网络不可用时尤其能提高系统的可靠性。所提出的网关支持平滑的数据恢复，因为它以压缩或加密形式在本地存储数据。存储库中的数据可根据需要导出为HL7、HL7 V2或HL7 V3等医疗标准格式。网关负责数据分析、压缩、过滤和加密，所有这些功能都需要本地临时存储，而无需将参数发送到云并等待响应。因此，医疗系统能够更快地应对紧急情况，通过实时响应实现更快的处理。此外，还可以将传感器数据和处理结果保存在雾层的本地存储中，并稍后与云同步。

ii) 安全 ：不安全的系统可能存在严重漏洞，因此安全应被视为医疗应用中最关键的需求之一。由于网关在网络不可用时也可充当嵌入式网页服务器，因此可通过超文本传输安全协议（HTTPS）进行安全通信，并对传感器节点进行身份验证，以保障系统的机密性、完整性和真实性。

iii) 数据分析 ：可通过基于Node.js的实时服务器实现对医疗系统的实时监控与分析，如[13]所示，该服务器具备一些额外的关键功能，可实现对网络的实时监控与分析，以及资产的实时采集与发布。通过在边缘进行本地数据分析，可提高系统的敏感性。它能够协助系统检测并预测紧急情况。例如，在智能家居中的跌倒检测场景中，雾层可本地提供与跌倒检测相关的处理。

iv) 数据压缩 ：在数据通信中，数据压缩用于最小化通信延迟以及事务期间消耗的能量。

v) 标准化 ：根据数据发送的目的地，智能网关的标准化模块可在必要时将数据格式化为任何医疗标准，例如 HL7、HL7 V2、HL7 V3。传感器节点无需承担将数据格式化为标准所带来的处理开销。此外，也消除了因随数据发送与标准相关的信息而在通信信道上产生的开销。

4) 协作

在生成高级信息并构建本体之后，信息
医疗系统的知识随后可以暴露给外部医疗系统。开发了应用程序编程接口以实现协作，因为它可以暴露以专有或可互操作方式表示的信息。前端Web应用程序可以托管在Apache Web服务器上，并通过RESTful API（应用程序编程接口）暴露底层功能。Web应用提供图形用户界面，并为语义查询资产等应用暴露语义引擎。

C. 初步本体案例研究

本案例研究考虑了两个使用OWL构建的独立医疗系统以共享信息。OWL是一种语义网语言，旨在表示关于事物、事物组以及事物之间关系的丰富而复杂的知识。在该案例研究中，存在两个彼此不交互的独立医疗系统：1）诊所和2）药房。患者需要首先在本地诊所注册，并提供与患者相关的信息，例如患者的名字、姓氏、患者ID等。注册后，患者可以通过网页、电话或亲自前往的方式在本地诊所预约医生。医生在预约期间诊断疾病，并为患者开具处方。此时患者获得可用于治疗其疾病的处方。由于诊所在处方中并未提供药品清单，因此处方以纸质形式打印出来，患者需持此处方前往药剂师处领取药物。患者可能丢失纸质处方，从而导致治疗延误，进而引发严重的健康风险。在药房，患者将纸质处方提交给药剂师，药剂师在没有更有效的来源证明的情况下即发放药物。有时手写处方使药剂师难以辨认。有时药品可能缺货，导致患者不得不等待几天才能拿到，这可能会使病情恶化。

药房自动从诊所的全科医生/医生处访问电子处方，并提前准备药品清单，以消除纸质处方的上述问题，这将是明智之举。这意味着诊所在患者获得处方后，仅通过安全方式（例如使用登录名和密码）向药房暴露其处方以及患者的唯一标识符（如全名或患者ID），以便药房访问处方通知。

1) 案例研究的本体创建

所提议的待创建本体的图形视图如图4所示。通过使用OWL，可以通过将临床医生的电子处方暴露给药剂师，从而顺利实现诊所‐药房案例研究的互操作性。为了解决此案例研究，诊所和药房医疗系统将基于具有全局词汇表的共享本体，各自拥有用OWL编写的本体。这些本体是使用Protégé创建的，Protégé是一个免费的开源本体编辑器和构建本体的框架。所创建的诊所本体称为clinic.owl（图5），药房本体称为pharmacy.owl（图6）。这些是RDF/XML文件，可上传至互联网。具体而言，诊所本体的统一资源标识符（URI）为 http://www.semanticweb.org/tsigwel1/ontology2/clinic，药房本体的URI为 http://www.semanticweb.org/tsigwel1/ontologies/pharmacy。一个名为 webvowl 的在线本体浏览器可用于在 http://www.visualdataweb.de/webvowl 上图形化查看本体。

全局本体被两个系统共同使用，包含一个称为 Thing 的基础类，所有其他类均从此类派生。药学本体包含 4 个类（Thing、Person、Pharmacist、Patient 和 prescription）。诊所本体包含 8 个类（Thing、Person、Patient、Doctor、Sickness、prescription、Receptionist 和 Appointment）。

类通过对象属性相互关联，例如 Patient（患者）“books”（预约）Appointment（预约），其中 books 是一个对象属性。从图4可以清楚地看到，两个系统之间存在一些共同的概念/类，例如（patient，prescription）。通过本体，这些概念被标准化，使得两个系统的格式一致，从而使共享类的实例如 patient1 和 prescriptionForPatient1 能够被访问、打开并可由对方轻松查看。本体创建完成后，诊所通过网页公开患者的详细信息和“处方名称”。图7(a)和图7(b)展示了药房和诊所本体的RDF/XML格式部分内容。

2) 临床数据传播到药房

图8显示了药剂师从诊所访问电子处方的情况。诊所通过SPARQL端点公开其患者和处方数据，拥有访问权限的药剂师可以查询存储诊所数据的clinic.owl文件。SPARQL端点是使用SPARQL查询语言来搜索在药房侧创建的clinic.owl本体文件中所存储数据的地方，以获取处方信息。SPARQL端点是查询一组通常称为知识库的OWL文件的简便方法。药房区域内的设备（接待处计算机和其他药房设备）能够理解来自诊所的处方请求，并可验证处方来源，因为诊所是受信任的，未来药房的设备甚至可以自动为患者配药，从而减少延误和错误。

IV. 结论

本文提出了一种概念性语义驱动的医疗协作框架，该框架能够实现不同物联网医疗系统之间的无缝信息交换，且信息可被设备和人类共同读取。所考虑的医疗系统包括异构且地理上分布的智能家居、智能医院和智能诊所，这些系统需要相互交互与协作。在所提出的框架中，每个医疗系统都集成了一个智能边缘语义网关，该网关包含一个Web应用及RESTful API，用于安全暴露各医疗系统的医疗信息以实现协作。一项暴露患者数据的案例研究从其他医疗系统访问存储在知识库（OWL文件）中的临床数据已得到实际验证，药剂师可以访问这些数据。该初步工作将通过模拟扩展为一个原型，其中将使用语义网技术，并广泛使用Protégé、Jena、iFogSim等工具来构建多个独立的医疗系统，建立各自的本地本体，然后通过开发一个RESTful API网页应用，实现两个系统之间的信息和知识共享。