概述

快捷式医疗服务互操作资源 (FHIR) 是一个由 HL7 International 开发的标准化框架，旨在以灵活、对开发者友好且现代的方式促进医疗数据的交换。 它利用现代网络技术来确保在医疗保健系统间实现无缝集成与通信。

关键 FHIR 技术

• 用于资源交互的 RESTful API
• 用于数据表示的 JSON 和 XML
• 用于安全授权和身份验证的 OAuth2

FHIR 围绕着称为资源的模块化组件构建，每个组件代表特定的医疗保健概念，包括：

• 患者 – 受众特征和标识符
• 观察数据 – 临床测量数据（例如，生命体征、实验室检测结果）
• 诊疗 – 患者与医疗服务提供者的互动
• 药物、过敏不耐受、健康状况等

资源单独定义，并且可以引用其他资源，以构成一个完善的数据模型。

InterSystems IRIS for Health：FHIR 支持

InterSystems IRIS for Health 是一个专为医疗保健行业设计的统一数据平台。 它包含对 HL7 FHIR 的原生支持。 它提供内置工具与服务，能够实现 FHIR 资源的存储、检索、转换和交换。IRIS 通过三大 FHIR 处理组件提升系统的互操作性：

1.FHIR 仓库服务器

IRIS 可以快速部署符合 FHIR 标准的服务器，并支持以下功能：

本演示程序用于展示如何采用自定义FHIR profile来验证数据合规性。自定义FHIR实施指南基于FHIR R4版本开发，在本例中实现了对Organization资源的扩展并用于验证数据的合规性。

安装

1. 通过Git clone下载本项目。
2. 执行docker-compose up -d构建并启动容器，初次执行时需执行需10～15分钟（视配置变化）。将构建InterSystems IRIS for Health镜像，安装FHIR服务器，导入自定义FHIR规范，使自定义FHIR 规范可用于验证数据。
3. 在Postman中导入TestCases中的测试用例文件，查看各类FHIR约束的测试效果
4. 容器启动后可查看自定义IG内容

项目代码结构

各位开发者好

欢迎观看InterSystems Bilibili官方频道的最新视频 InterSystems Developers Bilibili:

⏯ Understanding the Structure of HL7 FHIR Resources

<iframe allowfullscreen="true" border="0" frameborder="no" framespacing="0" scrolling="no" src="//player.bilibili.com/player.html?aid=1953056184&bvid=BV1iC411G74J&cid=1506782787&p=1"></iframe>

在医疗行业中，处方是个非常重要的临床工作数据概念。因此，在考察用FHIR能如何构造我国所需医疗行业数据模型时，就会需要考虑如何用FHIR表达处方。

在2019年，FHIR的工作组已否认需要使用特定的资源来表达处方（不是药嘱）这个概念，见：

https://jira.hl7.org/browse/FHIR-24905

奇妙的是，IHE规范中却明确有处方（Prescription）的定义并需要引用药嘱（Medication Treatment Plan Item）。

https://www.ihe.net/uploadedFiles/Documents/Pharmacy/IHE_Pharmacy_Suppl_PRE.pdf?#page=12

FHIR官网指出这种复合式的request有三种表达方式：

• Shared requisition id

• "Based on" chain

• RequestOrchestration

https://build.fhir.org/request.html#compound

在FHIR实际应用中，则可以见到多种形态使用容器类资源表达处方并包含药嘱的表达形式，例如：

1. 中国2023 FHIR Connectathon中使用消息Bundle来进行处方流转

CDS Hooks是FHIR生态下一个决策支持架构，是SMART(Substitutable Medical Applications and Reusable Technologies, 可替代的医学应用和可复用技术)下的一个项目。

FHIR标准下也有一个决策支持相关的模块 - FHIR的Clinical Reasoning模块。它和CDS Hooks是有区别的：

FHIR的Clinical Reasoning模块提供一系列资源模型和工件，用于构建决策支持相关的规则、医嘱集、临床协议和质量指标，并基于此对特定患者和人群进行评估，进而产生决策行为。它构建的是本地决策支持体系。

而CDS Hooks提供一个决策支持架构，打通外部决策支持系统和本地的决策数据源、业务流程。

CDS Hooks是开源的，基于知识共享 CC BY 4.0，因此也获得了广泛采纳。

CDS Hooks的架构

CDS Hooks是打通外部决策支持系统和客户端应用的决策支持架构，完整的架构包括：

CDS客户端：通常是用户的业务系统，如HIS或电子病历

CDS服务：这是CDS Hooks提供的核心组件，向客户端发布的决策支持服务

FHIR服务器：这是用户侧的FHIR服务器，保存的是用户侧的FHIR资源数据。CDS服务通过访问FHIR服务器获得用户侧的决策依据的完整数据

FHIR标准提供灵活的扩展与再约束机制 - Profile。到底Profile机制如何工作？什么样的扩展需要用到Profile？怎么建立Profile？

FHIR核心资源模型  - FHIR Core

FHIR发布的资源模型是按80/20原则设计的 - 最常用那80%的用例中需要的数据会被涵盖在FHIR核心资源模型中，这些数据需求可能只是所有用例需要数据的20%；通过对核心资源的扩展和再约束，可以让它们适用于不常见的20%用例和未被涵盖的80%的数据需求。

FHIR发布的资源模型是FHIR核心资源模型(FHIR Core)，它们有如下特点：

1. 对象模型 - 有继承关系。所有资源都继承自DomainResource

2. 为了保证最大的适用度，资源中的绝大多数属性的最小基数都是0，意味着它们都可以为空

3. 资源的属性可以通过code(值集）、coding、CodeableConcept（术语）进行取值范围约束

4. 为了防止医疗错误，所有的属性都没有且不能有默认值

当需要对核心资源模型进行扩展和再约束时，FHIR提供了profile机制对所做的扩展和再约束进行画像（描述），这就是profile的意思。

这里把对FHIR资源模型的用户自定义扩展区分为“扩展”和“再约束”，差异是：

• 扩展指需要要增加新的资源属性
• 再约束指修改核心资源模型的属性的基数、值集绑定、必须支持、切片等

卫生信息和其它信息化一样，经历了数码化、数字化到当今的数字化转型，卫生信息互操作一直伴随左右。

数码化(digitization)：国内90年代开始，HIS全面铺开，卫生信息进入数码化时代。数码化初期业务集中在HIS上，互操作需求不高，点对点接口可以满足绝大多数需求。

数字化(digitalization)：在2000年之后，各种专科系统、尤其是电子病历的诞生，医保和新农合的实施，要求卫生信息共享交换，以提高流程自动化水平。互操作需求爆发，2007年集成平台开始进入市场，卫生信息化进入数字化时代。

数字化转型(digital transformation)：2014年，国内正式进入移动互联网时代；次年《全国医疗卫生服务体系规划纲要（2015—2020年）》发布，卫生信息化的服务对象（服务于医护技到服务于患者）和业务形态（临床管理到患者服务）都发生了翻天覆地的变化，开始步入数字化转型的时代。它对互操作提出了更高的要求 - 利用互操作，增强全员参与，为卫生服务创造新价值、发展新业务，推动医疗机构持续数字化转型。

可以说，卫生信息互操作在整个的卫生信息产业中愈发重要。

国际卫生信息互操作发展了30年，国内也发展了20年，但卫生信息互操作依然是一个挑战。

知史而明鉴，识古而知今。我们看看国际卫生信息互操作发展的历程，对未来的卫生信息互操作有什么借鉴。

卫生信息互操作标准的要素

医院拥有丰富的CDA文档库，如何实现数据的有效利用和共享？

前不久，北京市人民政府印发了《关于更好发挥数据要素作用进一步加快发展数字经济的实施意见》的通知。其中提到要“率先探索数据跨境流通”。今年1月，北京市互联网信息办公室也发文公示，首都医科大学附属北京友谊医院与荷兰阿姆斯特丹大学医学中心合作研究项目成为全国首个被北京网信办批准的数据出境安全评估案例（编号20220001）。可以预见，为更好发挥数据要素作用将来可能出现越来越多的跨境数据流通。那么我们今天仅仅看下，在医疗领域国际主要流行的数据标准都有哪些。

以下是国际数字医疗合作组织的主要统计（该组织协同了世界卫生组织WHO，OECD和33个不同的国家和地区）

从上表可以看出,数据共享领域 DICOM，HL7 v2, CDA, FHIR,v3 是主要的标准，在临床术语方面 ICD9/10/11， SNOMED 和Lionc是目前国际上各个国家和地区最主流的医疗数据标准。供大家参考。

相关阅读

FHIR标准和国际基于FHIR的互联互通实践

论集成标准的选择对医院信息集成平台建设的影响

对话：“数据二十条”与FHIR标准

原文链接：https://www.healthit.gov/topic/global-digital-health-partnership

#Embedded Python #HL7 #InterSystems IRIS for Health

写在回复社区帖子《Python能否动态创建HL7消息》中。

前提条件和设置

使用一个启用了集成的命名空间。
注意：USER命名空间默认不启用互操作性。
如果以下建议创建一个新的互操作性命名空间来探索功能。

# 切换到
ZN "[互操作性名称空间名称]"

# 启动交互式Python shell：
Do $SYSTEM.Python.Shell()

启动脚本

#Load dependencies

import datetime as dt
import uuid

# Cache current time in CCYYMMDDHHMMss format
hl7_datetime_now=dt.datetime.now().strftime('%Y%m%d%H%M%S')

# Create HL7 Message
hl7=iris.cls("EnsLib.HL7.Message")._New()

# Set the doc type
# 2.5.1:ORU_R01 - Unsolicited transmission of an observation message
hl7.PokeDocType("2.5.1:ORU_R01")

这些信息的结构可以从管理门户中获取

Hi 开发者们，

欢迎观看视频，以了解 InterSystems TrakCare 创新工具包（ Innovation Toolkit），该工具包可免费下载，使 TrakCare 用户能够快速访问标准 HL7® FHIR® 格式的数据，使记录系统成为转型系统：

⏯ TrakCare 创新工具包介绍 @ 2022 年全球峰会

医院管理者、信息中心、业务骨干，每个角色都有独特的业务诉求，InterSystems IRIS医疗版互联互通套件专为国内用户设计，可助力医院用户释放数据价值，推动应用创新！截至目前，InterSystems技术已助力150余家医院通过四级及以上医院信息互联互通标准化成熟度评测，其中，五级乙等用户近30家。

好不好玩，能当真吗？

最近几个月，大型语言模型GPT正在激起一些现象。因此，上周末我不可避免地也在玩 ChatGPT，以探究它是否会成为我正在敲打的一些基于 BERT 的“传统”AI 聊天机器人的补充，或者更确切地说，它是否会淘汰它们。
玩的时候脑子里冒出一个念头。通过略微理论化或哲学化，最终互操作性标准（如 HL7 和 FHIR 等）是一种“语言”，对吗？ HL7 有自己的语法、规则、词汇甚至方言——每个系统都有自己的语调。这就是为什么当一台机器与另一台机器对话时，它们需要翻译器（例如 DTL 转换）来实现相互理解。
所以环顾四周，似乎一切都是语言：编码是语言：python，javascript和COS也是语言。 HL7、FHIR 甚至 XML 或 JSON 都是语言，只是它们比自然语言更结构化，那么 GPT 应该更容易上手吗？
那么，我们可以从简单地重用 GPT 的预训练编码语言模型来模拟 DTL 开始吗？我们还没有进行调整，以下是初步结果：

测试

模式：完整
型号：code-davinci-002
温度：0
最大长度：1989
其他：默认
停止序列：###
1、将HL7 ADT A01转A05？

输入:  

A "big" or a "little" ask for ChatGPT?

几周前我尝试了 OpenAI GPT 的编码模型，看看它是否可以在医疗保健系统之间进行一些消息转换。它肯定可以，在相当大的程度上。
已经将近 3 周了，对于 ChatGPT 来说是很长很长的时间，所以我想知道它现在成长得有多快，以及它是否可以为我们做一些集成工程师的工作，例如它是否可以创建一个 InterSystems COS DTL将 HL7 转换为 FHIR 信息？

在不到一两分钟的时间内，我立即得到了一些答案。

测试

首先我想测试一下我是在和它背后的正确“人”说话

问题一：如何将HL7 V2.4报文转为FHIR STU3？

ChatGPT：

将 HL7 V2.4 消息转换为 FHIR STU3 涉及多个步骤，因为这两个标准具有不同的数据模型和结构。以下是该过程的高级概述：

在上一篇文章中，我们看到了最常用的HL7消息类型之一--ADT（入院、出院、转院）的结构，以及ADT^A04的例子和它所有字段的描述。现在让我们来看看另一个数据流，它与测试订单的订购和履行有关。我说的是ORM（从2.5版本开始，你应该使用特定的消息来订购测试，如OMG、OML、OMD、OMS、OMN、OMI和OMP），ORL和ORU消息。在一个非常简化的情况下，数据的交换可能看起来像这样。

让我们更详细地看一下这些消息。

国务院于2022年12月19日发布了《中共中央 国务院关于构建数据基础制度更好发挥数据要素作用的意见》（后简称《数据二十条》），如何有效利用数据已经成为下一步的趋势。另一方面，无论是基于数据中台还是数据编织理念，两者也都对如何利用数据提出了构想。因此医疗行业数字化建设的目标已不能再局限于如何收集数据，建立医疗行业数据的流通机制将会是为越来越普遍的需求。

时钟拨回几年前，数据中台概念开始火爆。人们对数据中台的定义、诠释尽管有诸多差异，通过数据中台降低数据共享和利用的成本则是共同的期望。但经过这几年的探索之后，中台已死的观点也在涌现。究其原因，除去中台概念在技术上的不确定，数据流通过程中的责权益的不清晰也是严重的制约因素。毕竟，数据中台自身作为一套技术框架并不能代替法律法规与市场自动将数据转变为商品从而创造出流通价值。

那么，如何能够使数据的流通合规合法，使数据能够如货币和商品一般自由流动，则是我们需要思考和探索的主题，这次《数据二十条》的出现，无疑为医疗信息技术工作者提供了一个明确的思考方向。

在上一篇文章中，我们讨论了标准 HL7v2 的起源、结构和消息类型。现在让我们看一下最常用的消息类型之一及其结构示例。我说的是 ADT。

HL7 ADT 消息（入院、出院、转院）用于在医疗机构传达基本患者信息、就诊信息和患者状态。 ADT 消息是使用最广泛且容量最大的 HL7 消息类型之一，因为它为许多触发事件提供信息，包括患者入院、注册、取消、更新、出院、患者数据合并等。

HL7（Health Level 7）是一套技术规范，用于医院信息系统（HIS）之间临床、财务和管理数据的计算机互交换。这些规范被不同程度地被纳入美国（ANSI）和国际（ISO）正式标准的语料库中。

HL7的L7表示它是在OSI模型的第7层，换句话说，在应用层运行的标准。这意味着HL7不需要考虑交换的安全性，也不需要考虑信息传输的安全性（这一点由较低层次的层来保证，例如用于安全的SSL/TLS或用于数据传输的TCP）。更准确地说，第7层支持终端用户进程和应用的通信，以及面向用户的软件应用的数据展示。作为OSI模型的最高层，也是最接近最终用户的层，第7层提供特定的应用功能，如识别通信伙伴和它们之间的服务质量，确定资源可用性，考虑隐私和用户认证，以及同步通信，并将应用与OSI模型的较低层连接起来。

回到HL7标准，HL7第二版标准（也称为Pipehat）最初创建于1989年，但目前仍在使用并定期更新，形成了2.1、2.2、2.3、2.3.1、2.4、2.5、2.5.1、2.6、2.7、2.7.1、2.8、2.8.1、2.8.2和2.9版本。v2.x标准是向后兼容的（例如，基于2.3版本的信息将被支持2.6版本的应用程序所理解），在更高的版本中，你会看到一些字段是专门为它而留的。

集成平台的关键在于解决系统之间的互联互通和互操作性的问题，是一个多厂商、多协议的体系结构。医院在集成平台实施的过程中，面临的第一件重要的事情就是交互标准的选择，目前的建设中，分为两队：非标准队和标准队。非标准队一般采用视图抓取、xml格式、json等等的自定义格式，标准队一般采用HL7 V3、HL7 V2、FHIR、DICOM等医疗领域标准，下面会简单介绍一下各种方式以及实施落地的难易程度。（以下内容中将以难易程度总分5★来表示，星数量越多代表难度越高）

1、非标准队

与其说非标准，不如定义为院内交互标准，交互仅限于院内，是一种很有限的互操作，而且定制程度很高，需要很好地把握系统的内部知识。方案缺乏通用性，难以规模推广。但由于其技术门槛较低，学习成本较低，在集成系统数量较少时不失为一种经济快速的方法。

      1.1 视图-★

视图可以说是一种"古老"的交互方案了，几乎传统的系统交互都是用视图的方式，有实施周期短，上线速度快的优点，但提供视图一方数据库，在大量数据查询的时候，将面临系统压力过大，数据库速度变慢等问题。在集成平台建设中，使用视图形式，可以由集成平台定时轮询视图，将数据发送给需要的系统。这样可以减轻源系统的压力。但是无论进行怎么样架构设计，视图这种形式的最大的弊端：无法保证数据的实时性。落地难度：1星。

      1.2 XML-★★

1. 从消息查看器看到清除周期以外的消息没有被正常清除

这种情况先抽查这些消息所处的会话中是否有未完成操作周期的消息（状态为除“Completed”“Error”“Discarded”之外的状态）。如有，且定期清除任务配置了“KeepIntegrity”，且该环境并不需要保留这些消息，可通过关闭清除任务中的“KeepIntegrity”配置清除这些会话和包含的消息。如果有这类消息，但是定期清除任务未配置“KeepIntegrity”，可能是定期清除任务的逻辑或消息数据问题导致清楚任务查找的时候没有覆盖这些消息，请联系WRC帮助排查具体原因。

有关定期清除任务的更多信息请参见文档

Purging Production Data | Managing Productions | InterSystems IRIS for Health 2022.1

2. 从消息查看器看不到清除周期之外的消息，但是^%GSIZE显示有global占据了很大的磁盘空间

这种情况需要具体排查每个较大的global。可能有以下原因：

• 系统定义的global占用很大空间。您可以联系WRC帮助排查具体原因。
• 自定义的global占用很大空间。这可能是消息中嵌套的持久化数据或流数据，或者是和消息没有直接关系的独立的表里面的数据。请对创建这种global的代码进行复盘，找到创建逻辑并增加相应的数据管理逻辑。

这篇文章是上一篇文章的延续https://cn.community.intersystems.com/post/首次使用intersystems-iris-互操作性-一个production是什么？

在上一篇文章：https://cn.community.intersystems.com/post/首次使用intersystems-iris-互操作性-一个production是什么？  我们查验了什么是Production. 我们运行了示例代码，并在Visual Trace 页面查验了如何将流动消息的内容引入进Production中。

本文将回顾消息messages的概念和定义，和消息如何在系统集成所需的开发内容中用于组件之间发送和接收数据。

• Production生产http://[https://cn.community.intersystems.com/post/首次使用intersystems-iris-互操作性-一个production是什么？  
• Message消息
• Components组件
  
  • Business Services业务服务
  • Business Processes业务流程
  • Business Operations业务操作

在创建一个Message消息之前，让我们回顾一个案例研究。

一家公司经营着一个购物网站，并且正在为了适应季节而改变显示的产品信息顺序。

IRIS Healthtoolkit Service 软件即服务

轻松实现HL7v2 转 FHIR, CDA 转 FHIR, FHIR 转 HL7v2 即服务.

这个项目的目标是提供 REST API 可以轻松转化不同的医疗行业格式。 在Rest body 发布需要的格式，在答案中获得新的格式。

• InterSystems 消息转换公有云服务: https://aws.amazon.com/marketplace/pp/prodview-q7ryewpz75cq2

• 视频（油管） : https://youtu.be/lr2B7zSFkds

安装

克隆这个 repository

git clone https://github.com/grongierisc/iris-healthtoolkit-service.git

Docker

docker-compose up --build -d

使用

• 访问 : http://localhost:32783/swagger-ui/index.html

API 细节

• HL7 转 FHIR

POST http://localhost:32783/api/hl7/fhir

• FHIR 转 HL7 ADT

POST http://localhost:32783/api/fhir/hl7/adt

• FHIR 转 HL7 ORU

这是一个我开发的名为NiPaRobotica Pharmacy的小应用。 从附件可以看到一个界面，能够接收药房配药请求，并将订单上的行项目转换为发送给机器人的配药对话 。我在3家医院的药房部署了这个接口，其中两家药房有6个机器人被安排来将药物从分配槽配送到药剂师的窗口，每天能服务1200个病人。这些机器人能够将病人平均等待时间从2小时减少一半到1小时.接下来我把这个接口部署到专门为慢病病人建的6个配送点，例如如结核病、艾滋病毒、糖尿病、癫痫、高血压和哮喘等等。这个项目的目标是“把药物带给病人”。 这些点有六个6 ATM形式的药房配药设备 (Pharmacy Dispense Units ，PDU)，可以让病人直接与呼叫中心的药剂师沟通。在每个PDU

如何做到处方审核便捷性与安全性共存，一直是个“鱼与熊掌”的情形。开始正文前，先说个故事——

简介

最近完成了针对IRIS医疗版2020.1版本的性能及可扩展性基准测试，重点关注HL7v2的互操作性。本文介绍了在各种工作负载下观察到的吞吐量，并提供了IRIS医疗版用作HL7v2消息传输互操作性引擎时的系统常规配置和调整准则。

基准测试模拟了与实际环境接近的工作负载（详细信息请参见“工作负载说明和方法”部分）。本次测试的工作负载包括HL7v2患者管理（ADT）和生命体征结果（ORU）数据，并包含数据内容转换和路由。

IRIS医疗版2020.1版本可以表明，采用第二代Intel®Xeon®可扩展处理器和Intel®Optane™SSD DC P4800X系列SSD存储的商用服务器，每天的持续消息吞吐量超过23亿条（入站和出站总量），与此前的Ensemble 2017.1 HL7v2吞吐量基准测试相比，扩展性提高了一倍多。