前言

生产环境下我们部署和使用IRiS引擎，往往采用其主备镜像模式，虽然此架构简单但是往往我们需要持续在电脑前点击或者操作1到2小时，如果中间有个环节出现了问题有时我们可能需要部署一天.

接下来我分享的是IRIS自带的一个功能帮助我们部署---manifest-安装清单。他的主要使用方式是提前通过配置约定好我们期望的安装设置，在安装的过程中由IRIS程序直接执行脚本，简化IRIS集群的部署，减少运维人员的操作步骤，让我们有更多的精力放在实际项目和业务上。

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

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

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

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

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

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

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

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

HIMSS把信息互操作/集成定为4个不同的级别：

基础级别，仅仅打通了系统间进行数据通讯的通道；

结构级别，在基础级别上，定义了数据交换的格式和语法；

语义级别，建立在行业通用的基础模型和数据编码上，使用标准化的行业语义来定义数据元素，使用标准的值集。因此语义级别的互操作是全行业可以理解并有确定行业意义的互操作级别。或者说语义级别的互操做才是基于标准的互操作。

组织级别，通常都是由国家、行业协和和行业标准开发组织开发的。它加入了政策、社区、法律等方面的考虑，分析了通用的业务流程和工作流，在此基础上设定了参与互操作各方的角色、权限，服务和知情同意策略等。我们的互联互通，就是组织级别的互操作。

目前的卫生信息互操作项目多数停留在结构级别。只有达到语义级别的信息互操作/集成，才是标准化的信息互操作/集成，才能降低实施成本和提高实施效率。

做到语义级别的互操作标准并不容易，首先是消除语义歧义、其次行业普遍认可、再次是要覆盖行业用例并具有适应行业不断变化需求的弹性。

图片来源：EuroVulcan Conference 2023

先说消除语义歧义。要在信息交换时消除语义歧义，需要在语言、语法、词义、句法等多方面努力，而且涉及到数据的颗粒度。尤其在医疗行业，完整、消除歧义才能保障卫生信息准确和医疗行为安全！

HIMSS认为要消除语义歧义、达到语义级互操作性，需要基于五位一体的语义标准，包含：

• 词汇/术语标准：依靠结构化的词汇、术语、代码集和分类系统来表示健康概念。例如ICD-10、SNOMED-CT、LOINC、 RxNorm是行业里典型的词汇和术语标准。
• 内容标准：描述信息交换中，数据内容的结构和组织。而HL7 CDA、HL7 V2、C-CDA都是行业内容标准。
• 传输标准：定义了计算机系统、文档架构、临床模板、用户界面和患者数据链接之间交换的消息格式和传输方式。传输方式确定了卫生信息交换的“推”和“拉”方式。DICOM、IHE等都是传输标准。
• 隐私和安全标准：是确定谁、何时、出于何种目的、使用哪种个人健康信息的权利，以及如何护健康信息的机密性、可用性和完整性的标准。美国的HIPAA和欧洲的GDPR都是关于隐私和安全的标准。
• 标识符标准: 是用来唯一标识患者、机构、医护技、设备等实体的方法。例如咱们互联互通里用到的OID和美国的护士标识NCSBN ID …

并非消除了语义歧义的标准就能被广泛接受和认可，需要行业标准化组织的推动，实现厂商中立，毕竟互相竞争的厂商很难接受对方的企业标准。回顾一下行业里流行的标准，无论是术语标准、还是消息和文档标准，都是行业里标准化组织发布的，其中最有名的就是HL7。

从这个行业标准发展史可以看到，毫无例外的，标准先从术语标准开始，例如ICD、SNOMED，历史都非常久远。而我们常用的HL7 V2有30多年历史了，CDA和V3也20年左右了。从2014年，HL7推出了FHIR。这些标准是为何以及如何演进的？

互操作标准发展要满足不断变化的行业需求和用例

先看看90年代初的互操作的业务环境，就像下图那么简单：医疗机构还处在数码化向数字化转换的时代 - HIS等业务系统开始大规模部署以实现流程和数据的数码化，同时产生了非常有限的跨业务系统的流程自动化 – 信息集成需求。实时卫生信息交换的需求基本都在医疗机构内部（局域网，那时候WWW刚诞生），而院内的业务系统数量非常有限、且系统边界清晰，使用的用户基本就是医护技和管理人员，需要的互操作流量规模可以准确预测。而且系统互操作的技术手段非常有限，基本就是文件传输、串并口、socket，而SOAP（2000年）、RESTful（2000年）、甚至HTTP（1996年）等协议都还没有产生。

HL7 V2

这就是HL7 V2消息交换标准产生的时代，和所面临的互操作业务需求：它将业务事件和业务事件的上下文封装在消息结构中，在系统边界中传递这些消息。

业务系统边界清晰，一般用消息引擎来路由和转发这些消息，从而不打破系统边界。各个业务系统只要能接收/发送并处理这些标准化的消息即可。

近距离看一个HL7 V2消息示例，它是一个由多种分隔符分割的字符串，由区段和字段构成：区段是一组分类的数据，例如PID是患者信息区段；而字段是每个数据项，例如患者标识（在PID区段里）是“1182594^^^系联医院&1^^系联医院&1”，它本身也是一个结构，用于放标识符（1182594）和标识分配机构（系联医院）等信息。

而事件就是消息头区段里的ORM^O01，其中ORM代表业务域”通用医嘱消息”，O01代表事件“医嘱请求”。

消息头区段 MSH|^~\&|HIS|系联医院|系联实验室|系联医院|202302160002||ORM^O01|demo22903||2.5|382|||||UTF8

患者区段 PID||1182594^^^系联医院&1^^系联医院&1|||李小明||19570320|M|||北京市朝阳区建国门外大街乙12号2702

就诊区段 PV1|22903|O|心内科||||35030099^唐^南|||MED|||||||35019964^郑^顾樽||22903|||||||||||||||||||||||||202302160002^M

保险区段 IN1|1|65110116^城镇职工医保|

医嘱区段 ORC|NW|MS:1182594:1|||SC||||202302160002^M||||||||||||||||||||LAB

医嘱明细区段 OBR|1|MS:1182594:1||4548-4^糖化血红蛋白^loinc

为什么HL7 V2会是这种难读的格式？因为它是窄带时代的产物，当时通讯带宽有限，数据格式需要紧凑，通常仅用分隔符分割，以减少传输的数据量（相较与XML，通常能减少80%以上的数据），如今在一些检验检查设备的通讯协议中还能看到类似的设计。同时，从早期直到现在，多数HL7 V2消息是通过socket交换的。这些特征都是90年代互操作的历史印记。

HL7 V2是按模式复用的角度设计的颗粒度，也就是说它的颗粒度是信息区段。但并不是所有的信息区段都有独立的含义和复用的价值，例如区段TQ1、TQ2定义服药时间和用药途径，没有单独存在的可能和直接复用的价值。

另外，V2消息的字段随意性很大，相同内容可以放在不同的字段甚至区段里面；用户还被鼓励创建自定义的Z区段进行消息体扩展。也就是说它标准化程度不高，需要实施的双方事先约定好数据具体怎么放才能实现信息交换。同时V2术语约束机制很弱。

HL7 V3 和 CDA

世纪之交，卫生信息化发展提速，电子病历和各种专科系统崛起，更极大推动了卫生信息的交换和流程自动化的需求，同时对交换的语义标准化程度有了更高的要求。这需要更严谨的互操作业务抽象和术语约束。卫生信息正式进入数字化时代，也正是在这一时期，诞生了包括IHE、CDA、HL7 V3在内的众多互操作标准。

从模型抽象的角度看，应该全面包含用例模型、信息模型和交互模型，但V2的关注点基本在交互层面，对其它层面的抽象很弱。

由此，携着其著名的参考信息模型(RIM)方法论，V3在2005年横空出世，对业务场景进行分析，抽象交互逻辑，从参考信息模型到领域信息模型，再到精细化消息信息模型，最终产生需要的消息模型。模型以XML进行序列化，相较于V2，进步了许多。

这套方法论产生的V3消息标准化程度很高。但为了覆盖所有业务需求，RIM是高度抽象的（难于理解的）；同时V3方法论是“按约束设计”(design by constraint)，试图涵盖所有应用场景，避免自定义扩展，这使其越来越复杂、越来越庞大，而且用户没有RIM基础很难自己对其扩展，从一个极端走向另一个极端。

V3的高复杂性和高使用门槛，造成了它事实上的失败，没有成为V2的替代者，就像一些专家评论的 – “RIM创建了语义互操作性，但没有创建临床互操作性“。

注意，国内有一些实践中，甚至没有严格遵循V3发布的XML schema，直接用代码拼出XML字符串，也不做消息校验，这不算标准的V3。

同样在世纪之交，很多业务需要即时性不那么强、但数据更完整的交换 - 小结性质的临床文档交换。在这个领域，最主流的是CDA临床文档架构标准。CDA源于 1996 年就开始的临床文档中结构化标记工作，并在1997年并入HL7，随后使用V3参考信息模型来完善和发展。大家可能注意到前面的图上CDA早于V3发布，就是这个原因。

CDA临床文档架构，用于描述结构化文档，同时允许插入供人类解读的非结构化部分。它产生的文档具有上下文完整、可持久保存、可管理、可认证等特性。CDA文档和衍生的CCD文档广泛用于医疗机构边界间和医疗系统边界间的文档交换，或作为具有法律效力的临床文档依据保存在文档仓库。

CDA是成功的，可能是V3基础上唯一成功的部分，但它不能解决细数据颗粒度访问的需求。

IHE

虽然RIM基于业务场景、角色、触发事件等分析，但它的交付物 – 消息模型并无法执行流程与角色的约束。

服务用于业务场景里流程、角色的表达，功能内聚，可以通过企业服务总线(ESB)来协同，比消息路由规则更直观、更灵活，更适合实现业务流程的自动化。通常服务是比较大尺度的业务表达，服务标准广泛采纳的难度在于它实际上是规范业务流程和业务方法，而实际上多数机构的业务并不那么一致。

IHE(Integrating the Healthcare Enterprise)是国际上比较流行而成功的卫生信息交换服务规范。它是1998年，由HIMSS 和RSNA（北美放射学协会）发起，由一帮放射学和IT技术专家创建的。它最初为放射影像信息共享提供技术框架，以解决即便有了DICOM后在不同厂商系统间放射影像信息交换的标准和流程上的困难，后面逐步涵盖了越来越多的业务场景。IHE使用已经发布的卫生信息内容标准和术语标准，例如DICOM、HL7、LOINC等，来构建自己的服务框架，利用企业服务总线来协同这些服务，可以实现比消息交互更功能内聚的互操作架构：

• 服务本身封装了事件、上下文

• 服务针对于场景定义了流程和角色

• 适合跨清晰的业务系统边界间信息交换

• 服务有多种互操作模式：

• Web 服务本身是可互操作的，这意味着任何客户端都可以直接调用 Web 服务

• 服务可以通过企业服务总线(ESB)来协同，比消息路由规则更直观、更灵活

IHE分析每个业务场景(Profile)，将业务场景中参与方定义为角色(Actors)，场景中角色的交互定义为事务(Transactions)。例如跨机构的文档共享业务场景中，有4个不同的角色：文档源、文档注册器、文档使用者和文档仓库。而交互事务有注册、查询、获取等

IHE能在服务标准上取得成功，在于它先在参与的用户基础上规范业务，然后再基于规范的业务发布相应的服务，也就是说，使用IHE需要先认同它的规范出的业务。

IHE一直随着业务、技术和互操作标准的发展而不断演进，从最初使用DICOM + HL7 V2，到最新基于FHIR；从最初的影像信息交换到最近的患者穿戴设备的数据交换。例如在2007年，IHE创建了基于HL7 V3的跨机构档案共享的Profile – XDS.b，之后又推出了基于FHIR的诸多移动端服务。

前言

对于第三方接口进行交互的时候，往往需要大量的进行参数合法性校验。以前的方法就是对每个参数进行验证。如下截图：

上图的会存在大量的if else if else..,如果字段很多，那导致一个方法存在大量的验证的代码，那我们考虑是否可以进行统一的验证参数的合法性。

思路

平时建立类的时候我们可以写参数MAXLEN=100，TRUNCATE=1 是否截取等，那找找这些参数的定义地方。如截图：

那我们想要定义自己的参数，该如何定义呢？根据面向对象设计原则之一：

[toc]

第三十三章 Objects - OREFs

OREFs

对象类的 %New() 方法创建一个内部内存结构来包含对象的数据，并返回指向该结构的 OREF（对象引用）。 OREF 是 IRIS 中的一种特殊值。应该记住以下几点：

• 在终端中，OREF 的内容取决于所使用的语言：
  • 在 ObjectScript 中，会看到一个由数字、@ 符号和类名称组成的字符串。
  • 在 Python 中，会看到一个包含类名和内存中 18 个字符的唯一位置的字符串。

例如：

如今，关于大语言模型、人工智能等的消息不绝于耳。向量数据库是其中的一部分，并且已经有非IRIS的技术实现了向量数据库。

为什么是向量？

• 相似性搜索：向量可以进行高效的相似性搜索，例如在数据集中查找最相似的项目或文档。传统的关系数据库是为精确匹配搜索而设计的，不适合图像或文本相似性搜索等任务。
• 灵活性：向量表示形式用途广泛，可以从各种数据类型派生，例如文本（通过 Word2Vec、BERT 等嵌入）、图像（通过深度学习模型）等。
• 跨模态搜索：向量可以跨不同数据模态进行搜索。例如，给定图像的向量表示，人们可以在多模式数据库中搜索相似的图像或相关文本。

还有许多其他原因。

因此，对于这次 pyhon 竞赛，我决定尝试实现这种支持。不幸的是我没能及时完成它，下面我将解释原因。

第三十章 Classes - 方法生成器

方法生成器

方法生成器是类编译器在类编译期间调用的程序。它的输出是该方法的实际运行时实现。方法生成器提供了一种继承方法的方法，可以生成根据继承类或属性的需要定制的高性能、专用代码。在 IRIS 库中，方法生成器广泛用于数据类型和存储类。

Class Queries

类可以包含类查询。类查询定义可由该类使用的 SQL 查询，并指定用作查询容器的类。下面显示了一个示例：

InterSystems 还发布了容器化部署的IRIS。这篇文章旨在演示 InterSystems IRIS 和依赖 IRIS 后端的应用程序如何打包到镜像中并在容器中的其他计算机中运行，以及这样做有多么简单。

容器运行包含所有必需的可执行文件、二进制代码、库和配置文件的镜像。镜像可以从一台机器移动到另一台机器，像 Docker Hub 这样的镜像存储库可以简化这个过程。

我在本演示中使用了 Open Exchange 的应用程序。

演示视频： https://www.loom.com/share/93f9a760b5f54c0a8811b7a212387b9d

IRIS 数据平台社区版的镜像（image)可以在 InterSystems 容器注册表中找到：

第二十七章 Classes - 引用其他类成员

引用其他类成员

在方法中，使用下面的语法来引用其他类成员:

• 要引用ObjectScript中的参数，使用如下表达式:

 ..#PARAMETERNAME

只能使用ObjectScript直接访问参数。要从Python访问参数，请使用ObjectScript包装器方法返回参数，并在需要时调用此方法。例如:

第二十六章 Classes - Methods

Methods

方法有两种：实例方法和类方法（在其他语言中称为静态方法）。

指定方法关键字

在方法定义中，可以包含影响方法行为的可选编译器关键字。以下列表显示了一些最常见的方法关键字：

Language

在 IRIS 中，可以用 ObjectScript 或 Python 编写方法。要指定编写方法所用的语言，请使用以下语法：

第二十四章 Classes - 指定属性关键字

指定属性关键字

在属性定义中，可以包含影响属性使用方式的可选属性关键字。以下列表显示了一些最常见的关键字：

Required

指定可以将此类实例之前设置的属性值存储到磁盘。默认情况下，属性不是必需的。在子类中，可以将可选属性标记为必需，但不能执行相反的操作。

InitialExpression

指定属性的初始值。默认情况下，属性没有初始值。子类继承InitialExpression关键字的值并且可以覆盖它。指定的值必须是有效的 ObjectScript 表达式。

Transient

指定该属性不存储在数据库中。默认情况下，属性不是瞬态的。子类继承 Transient 关键字的值并且不能覆盖它。

Private

指定该属性是私有的。子类继承 Private 关键字的值并且不能覆盖它。

第二十二章 Classes - 调用类方法的快捷方式

调用类方法的快捷方式

使用 ObjectScript 调用类方法时，在以下情况下可以省略包（或更高级别的包）：
- 引用是在一个类内，并且被引用的类在同一个包或子包中。
- 引用位于类内，并且该类使用 IMPORT 指令导入包含引用的类的包或子包。
- 该引用位于方法内，并且该方法使用 IMPORT 指令导入包含引用的类的包或子包。

从 ObjectScript 或 Python 调用类方法时，在以下情况下可以省略包（或更高级别的包）：

嗨，开发者们！

今天我想谈谈一个让我感到困难的话题。我相信你们中的很多人一定已经遇到过这种情况（所谓的“瓶颈”）。由于这是一个广泛的主题，因此本文将仅重点关注识别可能导致缓慢问题的传入 HTTP 请求。我还将向您提供我开发的一个小工具来帮助识别它们。

我们的软件变得越来越复杂，处理来自不同来源的大量请求，无论是前端还是第三方后端应用程序。为了确保最佳性能，必须有一个能够记录一些关键测量的日志系统，例如响应时间、global引用的数量以及每个 HTTP 响应执行的代码行数。作为工作的一部分，我参与了 EMR 软件的开发以及事件分析。由于用户负载主要来自 HTTP 请求（REST API 或 CSP 应用程序），因此在发生普遍缓慢问题时进行此类测量的需求变得显而易见。

第十八章 ObjectScript - 使用例程

例程

可以将例程视为 ObjectScript 程序。例程可以从头开始编写，也可以在编译类时自动生成。

Procedures, Functions, and Subroutines 过程、函数和子程序

在 ObjectScript 例程中，标签定义以下代码单元之一的起点：

• Procedures过程（可选地返回一个值）。过程中定义的变量是该过程私有的，这意味着它们不可用于其他代码。对于函数和子例程来说，情况并非如此。

过程也称为过程块。

• 函数（返回值）。
• 子例程（不返回值）。

建议使用过程Procedures，因为这可以简化控制变量范围的任务。然而，在现有代码中，可能还会看到函数和子例程，并且能够识别它们非常有用。以下列表显示了所有这些形式的代码的外观。

对于即将到来的Python 竞赛，我想制作一个小型演示，介绍如何使用 Python 创建一个简单的 REST 应用程序，该应用程序将使用 IRIS 作为数据库。使用这个工具

• FastAPI框架，高性能，易学，快速编码，可用于生产
• SQLAlchemy 是 Python SQL 工具包和对象关系映射器，为应用程序开发人员提供 SQL 的全部功能和灵活性
• Alembic 是一个轻量级数据库迁移工具，可与 SQLAlchemy Database Toolkit for Python 一起使用。
• Uvicorn 是 Python 的 ASGI Web 服务器实现。