1. 通用RESTful业务服务和业务操作

InterSystems IRIS 提供了一组通用的RESTful 业务服务和业务操作类，用户无需开发自定义的业务服务和业务操作类，就可以直接向外提供RESTful服务和调用外部的RESTful API。

2. 通用RESTful 消息

通用的RESTful 业务服务和业务操作类使用一个通用的RESTful消息类 - EnsLib.REST.GenericMessage，它是EnsLib.HTTP.GenericMessage的子类，二者数据结构都是

我们继续使用FHIR适配器的示例，在本文中，我们将回顾如何在我们的IRIS实例中进行配置以及安装的结果。

配置项目的步骤与官方文档中所示的相同，您可以直接在此处查看。好吧，让我们开始工作吧！

安装

正如您在与本文相关的项目中看到的，我们将 IRIS 实例部署在 Docker 中，因此初始配置的主要部分将在 Dockerfile 中完成。别担心，我们不会详细介绍 Docker 配置。

要安装 FHIR 适配器，我们只需：

1. 在我们的 IRIS 实例中使用互操作性功能创建一个名为ADAPTER的命名空间。
2. 从 IRIS 终端访问我们的命名空间并执行以下命令。

 set status = ##class (HS.FHIRServer.Installer).InteropAdapterConfig( "/Adapter/r4" )

在我们的例子中，我们定义了将接收 REST 请求的 IRIS 端点的 URL 为/Adapter/r4 。

安装结果

FHIR 适配器安装完成后，我们可以查看 IRIS 实例中发生的情况。为此，我们首先查看 Web 应用程序菜单（系统管理 -> 安全 -> 应用程序 -> Web 应用程序）

正如我们所看到的，一个新的 Web 应用程序已添加到列表中，表明它对应于我们的 ADAPTER 命名空间。让我们访问它以更详细地查看其配置。

想必大家都听说过 FHIR 是解决系统间所有互操作性和兼容性问题的灵丹妙药和解决方案。就在这里，我们可以看到他手持一份 FHIR 资源，愉快地享受其中：

但对于我们这些普通人，我们将做一个小小的介绍。

什么是 FHIR？

让我们直接进入定义：FHIR（Fast Healthcare Interoperability Resource）是由HL7（Health Level 7标准组）开发的一种互操作性标准，旨在实现医疗行业中不同系统之间的电子医疗数据交换。

FHIR 从根本上基于哪些技术？

主要是通过 REST API 和 JSON 格式进行 HTTP 调用的结合（尽管它可以是 XML 以及我们可用的任何其他通信，具体根据我们的使用情况）。

我们如何与 FHIR 合作？

一般来说，最简单的方式是拥有一个FHIR服务器，我们将使用诸如GET（从服务器获取数据）、PUT（更新数据）、POST（保存数据）和DELETE（删除数据）等HTTP调用与其通信。

FHIR处理了“资源”（Resource）的概念，用于在服务器和客户端之间发送和接收数据。这些资源旨在涵盖系统间80%的互通性需求。在这里，我们可以看到默认情况下可用的资源图示。

如您所见，每个资源都附带一个表示资源成熟度的数字或字母（其中N = 正式）。如果您访问官方的FHIR文档，您将能够获取到众多示例。

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资源数据。

2023年6月底，世卫组织(WHO)和HL7签署了合作协议，利用HL7 FHIR提供互操作性，来支撑WHO的SMART指南(SMART Guideline)愿景 - 使用数智化的方式推动并加速一致化的健康干预措施建议，让世界上每个人都能立即从临床、公卫和数据使用建议中充分受益。

作为WHO的《2020-2025 年全球数字卫生战略》的一部分，SMART 指南使用 FHIR 、HL7的临床质量语言 (CQL) 和ICD标准以表达 WHO 的各种健康和临床指南，实现数据互操作、决策支持与指标、术语的一致性。这些标准被进一步利用来为各国及其合作伙伴开发一个由软件库、服务和工具组成的支持生态系统，并作为数字公共产品服务全球卫生健康事业。

为什么世卫组织会采用FHIR作为卫生信息互操作的标准在全球推广其一致化的健康干预措施建议？因为FHIR不仅标准成熟适用，而且还具有一个极具生命力的生态。

一个有生命力的标准会吸引生态的构建，而完善的生态将促进标准的成熟和演进。HL7 FHIR作为新一代的卫生信息互操作标准，其生态已经初具规模并蓬勃发展。

HL7 FHIR的知识产权类型

HL7 FHIR的知识产权是CC0，也就是知识共享。任何机构、组织和个人都可以无需向HL7申请而免费使用、扩展FHIR的标准。

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

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

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

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

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

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

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

执行SQL语句查询数据时，提示unexpected status code, unable to process HyperEvent:Gateway timeout（504）

大家好。

在上一篇文章中，我们了解了如何配置 EMPI 来接收 FHIR 消息。为此，我们安装了 InterSystems 提供的 FHIR 适配器，该适配器配置了一个可以向其发送 FHIR 消息的 REST 端点。然后，我们将获取消息并将其转换为 %String，我们将通过 TCP 将其发送到 HSPIDATA 命名空间中配置的 EMPI 的输出。

好吧，是时候看看我们如何检索消息、将其转换回 %DynamicObject 并将其解析为 EMPI 用来存储信息的类。

TCP消息接收

正如我们所指出的，从配置了 FHIR 资源接收的生产中，我们已将消息发送到我们有业务服务侦听的特定 TCP 端口，在我们的例子中，该业务服务将是一个简单的EnsLib.TCP。 PassthroughService的目标是捕获消息并将其转发到业务流程，我们将在其中执行所需的数据转换。

这里有我们的商业服务：

这是它的基本配置：

FHIR 消息的转变

正如你所看到的，我们只配置了通过 TCP 接收消息的端口以及我们将向其发送消息的组件，在我们的例子中我们将其称为 Local.BP.FHIRProcess，让我们看一下说类来看看我们如何从 FHIR 资源中检索信息：

 Class Local.BP.FHIRProcess Extends Ens.

InterSystems 已纠正了两个缺陷。

第一个缺陷可能导致 ECP 应用程序服务器挂起。此缺陷仅与 ARM 和 IBM Power 处理器相关；存在于 InterSystems IRIS®、InterSystems IRIS for Health™ 和 HealthShare® Health Connect 版本2022.1.2和2022.1.3中。该修复被标识为 DP-423661。该缺陷将在所有未来版本中得到解决。

在极少数情况下，第二个缺陷可能会导致dejournaling挂起。此缺陷存在于 InterSystems IRIS®、InterSystems IRIS for Health™ 和 HealthShare® Health Connect 版本2020.4 、 2021.x 、 2022.x和2023.1中。该修复被标识为 DP-423505。该缺陷将在所有未来版本中得到解决，并已在2023.1.1中得到纠正。

InterSystems 已发布版本2022.1.3的更新发行版，以便快速提供这些修复。相关的版本标识符是：

• 原发布：2022.1.3.668.0
• 更新发布：2022.1.3.670.1

这些修复也可以通过 Ad hoc 分发获得。

如果您对此警报有任何疑问，请联系 全球响应中心。

在之前的文章中，我们已经了解了如何配置和自定义我们的 EMPI，我们已经了解了如何通过 HL7 消息传递将新患者纳入我们的系统中，但当然，并不是所有的东西都是 HL7 v.2！我们如何配置 EMPI 实例以使用 FHIR 消息传递？

什么是FHIR？

对于那些不太熟悉 FHIR 这个术语的人，只需指出它们是Fast Healthcare Interoperability Resource的首字母缩写即可。 FHIR是HL7制定的医疗保健互操作性标准，基于JSON格式和REST通信，建立了一系列不同类型信息（患者数据、医院中心、诊断、医疗预约......）的“资源”。您可以在他们的官方页面上查看所有这些资源

InterSystems 和 FHIR

从 InterSystems 中，我们了解到 FHIR 为医疗保健互操作性领域提供的实用程序，因此我们拥有广泛的产品和功能，使我们能够充分利用并发挥其全部潜力：

• InterSystems FHIR 服务器允许存储和管理 FHIR 资源。
• InterSystems FHIR SQL Builder使用户可以通过 SQL 查询使用 FHIR 存储库中存储的所有信息。
• InterSystems FHIR 适配器允许在我们的产品中发送和接收 FHIR 消息。

好吧，在我们的文章中，我们将利用适配器提供的功能来接收

InterSystems 已纠正导致进程内存使用量增加的缺陷。

具体来说，在对局部变量执行$Order 、 $Query  或 Merge时，会出现本地进程分区内存消耗增加的问题。虽然这对大多数运行环境没有不利影响，但支持大量进程或严格限制每个进程最大内存使用的环境可能会受到影响。某些进程可能会遇到<STORE> 错误。

该缺陷存在于2023.1.0.229.0中，但它被重新发布为2023.1.0.235.1，并包含了修复程序，以加快修正，而无需客户等待维护版本。

此缺陷的更正标识为 DP-423127 和 DP-423237。这些将包含在所有未来版本中。

该缺陷出现在 InterSystems IRIS ® 、InterSystems IRIS for Health ™ 和HealthShare ® Health Connect 的版本 2022.2、2022.3 和 2023.1（内部版本 229）中。如果您运行的是这些版本之一，我们建议升级到 2023.1（内部版本 235）。

此修复也可通过 Ad hoc 分发获得。

如果您对此警报有任何疑问，请联系全球响应中心。

我们客户的一个共同需求是配置 HealthShare HealthConnect 和 IRIS的高可用性模式。

市场上的其他集成引擎通常被宣传为具有“高可用性”配置，但事实并非如此。通常，这些解决方案与外部数据库一起使用，因此，如果这些数据库未配置为高可用性，当发生数据库崩溃或与它的连接丢失时，整个集成工具将变得不可用。

对于 InterSystems 解决方案，这个问题不存在，因为数据库是工具本身的一部分和核心。 InterSystems 如何解决高可用性问题？深奥的配置会把我们拖入异化和疯狂的漩涡？不！在 InterSystems，我们倾听并处理了您的投诉（正如我们一直努力做的那样 ;)），并且我们已将镜像功能提供给所有用户和开发人员。

镜像

镜像如何工作？这个概念本身非常简单。如您所知，IRIS 和 HealthShare 都使用一个日志系统，该系统记录每个实例的数据库上的所有更新操作。这个日志系统是后来帮助我们在崩溃后恢复实例而不会丢失数据的系统。好吧，这些日志文件在镜像中配置的实例之间发送，允许并保持镜像中配置的实例永久更新。

架构

让我们简要解释一下在 Mirror 中配置的系统架构是什么样的：

• 在故障转移模式下配置的两个实例：
  • 主动节点——接收所有常规的读/写操作。
  • 被动节点：在读取模式下，它同步接收主动节点产生的任何变化。

InterSystems 已修复了一个缺陷，该缺陷可能会导致使用 IBM POWER8 或更高版本的 POWER 处理器的 AIX 系统上的数据库和Journal日志文件损坏。只有在使用数据库或Journal日志加密时才会触发此缺陷。

当满足以下条件时，会触发此缺陷：

• 该环境使用数据库或Journal日志加密
• 该环境还使用数据元素加密
• 用于数据元素加密的加密密钥已停用

如果环境满足所有这些条件，则用于数据库或Journal日志加密的密钥计划可能会被损坏。

该缺陷存在于以下产品和基于这些产品的任何 InterSystems 产品中：

• InterSystems IRIS ® –除 2022.1.3 和 2023.1 之外的所有版本
• InterSystems IRIS for Health ™ ——除 2022.1.3 和 2023.1 之外的所有版本
• HealthShare ® Health Connect –除 2022.1.3 和 2023.1 之外的所有版本
• HealthShare ®解决方案——所有版本

请注意，此缺陷不会直接影响 HealthShare 解决方案，因为它们不使用数据元素加密功能。但是，如果 HealthShare 环境有一个使用上述数据元素加密功能的客户化定制，则它们必须遵循此警报中提供的补救措施。

随着生活水平的提高，人们越来越注重身体健康。 而孩子的健康成长也越来越成为家长关心的话题。 孩子的身体发育可以从孩子的身高和体重反映出来。 因此，及时预测身高和体重具有重要意义。 通过科学的预测和比较，关注孩子的发育状态。

该项目使用InterSystems IRIS Cloud SQL通过输入大量体重和身高相关数据来支持，并建立基于IntegratedML的AutoML进行预测分析。 根据输入的父母身高，可以快速预测孩子未来的身高，并根据当前的身高和体重状况判断孩子的体重指数。 在正常范围内。

功能：

通过应用该程序，可以快速预测处于正常发育状态的儿童的身高。 通过结果，家长可以判断孩子发育是否正常，是否需要临床干预，有助于了解孩子未来的身高; 通过当前体重状态判断当前孩子的BMI是否正常，了解孩子当前的健康状况

应用场景

1.儿童身高预测

2. 监测儿童发育

InterSystems已修复一个缺陷，该缺陷在罕见情况下会导致ECP客户端不稳定。

该缺陷存在于以下产品和基于这些产品的任何InterSystems产品中。

受影响的版本是2022.1.x、2022.2和2022.3：

InterSystems IRIS®

InterSystems IRIS for Health™

HealthShare® Health Connect

受影响的版本是2022.2（只针对部署ECP的客户）：

InterSystems HealthShare®

这个问题只发生在ECP客户端系统中。当这个问题被触发时，进程可能遇到<SYSTEM>或<DATABASE>错误。出错后，ECP客户端会出现不稳定；在某些情况下，实例可能会挂起。对数据没有影响，ECP数据库服务器不受影响。

要清除不稳定性，必须重新启动ECP客户端实例。

如果您的 IRIS、IRIS for Health 或 Health Connect 实例受到影响，补救措施是升级到版本 2023.1 或 2022.1.3，这两个版本都将很快发布。

如果您有受影响的 HealthShare 实例，一组单独的警报文档和补救建议将很快发布。

InterSystems 已修复一个导致SQL查询返回不正确结果的缺陷。

该缺陷存在于以下产品和基于这些产品的任何InterSystems产品中。

受影响的版本是 2021.2、2022.1.x、2022.2 和 2022.3：

• InterSystems IRIS®
• InterSystems IRIS for Health™（医疗版）
• HealthShare®Health Connect

受影响的版本是 2022.2：

• InterSystems HealthShare®

  当启用 SQL 运行时计划选择 (RTPC) 被启用（默认），并且查询包含一个“truth value”“WHERE ?=? 时，该缺陷会被触发，当被触发时，一些判断可能不会被正确评估；这导致了不正确的查询结果。

注意：通过查看SQL语句，无法完全评估一个查询的脆弱性。这是因为InterSystems SQL查询优化可以在查询的内部表示中增加“truth value”。

如果你的环境使用 InterSystems SQL，那么你可以通过禁用RTPC 功能来补救这个问题。

注意：关于 InterSystems HealthShare® 缓解措施的其他信息将很快发布。

好不好玩，能当真吗？

最近几个月，大型语言模型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？

输入:  

##### Translate this function from HL7 V2.8 ADT_A01 to HL7 V2.4 ADT_A05
### HL7 V2.

正式名称为Class Query 的意思可以追溯到 Caché 的早期。
使用CLASS是因为它嵌入在 COS 类中。
尽管官方文档中有精确的描述，但它仍然相当抽象。
我的教程应该通过 COS 中的一个简单示例逐步指导您，使您有直观的体会

我们很高兴地宣布我们的抢先体验计划的最新成员 - Health Data De-ID工具。

该工具将根据 *HIPAA 安全港* 对结构化临床数据进行去标识化处理，并允许在需要时进行重新标识。它使用 InterSystems 的 *SDA* 规范格式，该格式用于我们从一种格式到另一种格式的所有标准转换，例如 *HL7* 到 *CDA*、*HL7* 到 *FHIR* 等。虽然该工具使用 XSLT 转换来提高性能原因，它提供了辅助方法，您不需要成为 XSLT 专家的情况下更轻松地调整开箱即用的去标识化规则。

Health Data De-ID 适用于任何 InterSystems 产品，从 InterSystems IRIS for Health 到 Health Connect 再到 Unified Care Record。

您可以在此处加入抢先体验计划 - [如何注册抢先体验计划 (EAP)]？我们需要您的反馈，因此请在您完成整个过程或遇到任何问题时与我们联系。

嗨，InterSystems 开发人员！

最近我更新了FHIR 开发模板，它发布了一个 IPM 包fhir-server ，使 InterSystems FHIR 服务器的设置成为一个微不足道的手动或自动或编程的程序，只需一条命令。

请参阅下文，了解如何从中受益。

TLDR

USER>zpm "install fhir-server"

以下所有详细信息。

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 涉及多个步骤，因为这两个标准具有不同的数据模型和结构。以下是该过程的高级概述：

1. 识别 HL7 消息中需要映射到 FHIR 资源的相关数据元素。这将取决于具体用例和交换的数据。
2. 为每个数据元素定义映射规则。这涉及识别对应于 HL7 数据元素的等效 FHIR 资源和元素，以及任何必要的转换或翻译。
3. 编写一个程序或脚本，可以从 HL7 消息中提取数据，应用映射规则，并创建相应的 FHIR 资源。这可能涉及使用正则表达式、解析库和 FHIR 资源创建库的组合。

InterSystems 纠正了一个可能导致 InterSystems IRIS® 和 Caché 无法在 Windows 上利用大页共享内存的问题，即使这些产品得到的信息是已分配到了大页内存。这会对系统性能产生不利影响。

该问题是由于 Windows 10 中的一个更改引起的，该更改需要 InterSystems IRIS® 和 Caché做相应的修改。请注意，此问题还会影响所有基于 InterSystems IRIS® 或 Caché 的 InterSystems 产品。以下版本的 Windows 会出现此问题：

Windows 10（版本 1703 及以上）

Windows 11

Windows Server 2019

Windows Server 2022

Windows Server 2016 不受影响。

作为参考，此问题的更正标识为 RJF533。此更正将包含在所有未来的 InterSystems IRIS® 和 Caché 发行版中。该更正也作为受支持产品版本的补丁提供。

InterSystems 建议采取以下措施以避免潜在的严重系统性能下降：

• 对于使用大页内存的系统，推迟升级到受影响的 Windows 版本，直到实施更正。
• 对于已经运行受影响的 Windows 版本并使用大页内存的系统，在任何有计划的系统负载增加之前实施更正。

InterSystems 宣布其首个开发人员预览版，作为2023.1 版开发人员预览计划的一部分。 2023.1 中添加了许多更新和增强功能，还有全新的功能，例如对列存储Columnar Storage 的生产就绪支持、使用Bulk FHIR 的能力以及对MacOS 13 Ventura的支持。当前的开发人员预览版可能不提供其中一些功能或改进。

未来的预览版本预计每两周更新一次，我们将在功能准备就绪时添加它们。请通过开发者社区分享您的反馈，以便我们共同打造更好的产品。

可以在下面的这些链接中找到初始文档。它们将在接下来的几周内更新，直到正式宣布发布（一般可用性 - GA）：

• InterSystems IRIS
• InterSystems IRIS医疗版
• HealthShare HealthConnect

此外，查看此链接以获取与此版本相关的升级信息。

与往常一样，扩展维护 (EM) 版本附带适用于所有受支持平台的经典安装包，以及 Docker 容器格式的容器映像。有关完整列表，请参阅支持的平台文档。

安装包和预览密钥可从 WRC 的预览下载站点或通过评估服务网站获得（使用标记“显示预览软件”以访问 2023.1）。

目的

这两个工具（RanRead 和 RanWrite）用于在数据库（或一对数据库）内生成随机读写事件，以测试每秒输入/输出的操作数 (IOPS)。它们可以一起使用或分开单独使用，以测试 IO 硬件容量、验证目标 IOPS 并确保系统拥有可接受的磁盘响应时间。从 IO 测试中收集的结果将因配置而异，具体取决于 IO 子系统。在运行这些测试之前，请确保相应的操作系统监控和存储级别监控已配置，这些捕获的 IO 性能指标可以为以后的分析提供帮助。我们推荐使用 IRIS 中捆绑的系统性能工具，例如^SystemPerformance。

请注意，这里使用的工具是对先前版本的更新。之前的版本可在这里找到。

InterSystems 很高兴地宣布，InterSystems IRIS、InterSystems IRIS for Health 和 HealthShare Health Connect 2022.1.2 的扩展维护版本现已推出。这些版本为 2022.1.0 和 2022.1.1 版本提供了一些选定的功能和错误修复。

您可以在这些页面上找到有关更改内容的更多信息：

• InterSystems IRIS
• InterSystems IRIS 医疗版
• HealthShare HealthConnect

请通过开发者社区分享您的反馈，以便我们共同打造更好的产品。

如何获得软件

该软件以经典安装包和容器镜像的形式提供。有关可用安装程序和容器映像的完整列表，请参阅支持的平台网页。

每个产品的完整安装包都可以从 WRC 的软件分发页面获得。

安装包和预览密钥可从 WRC 的预览下载站点或通过评估服务网站获得。

InterSystems IRIS 和 IRIS for Health 的企业版和社区版的容器镜像以及所有相应的组件都可以从InterSystems Container Registry获得。

此版本中所有套件和容器的数量为2022.1.2.574.0 。

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

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

动机

这个项目是在我考虑如何通过Embedded Python让Python代码自然地处理IRIS globals所提供的可扩展的存储和高效的检索机制时想到的。

我最初的想法是使用globals创建一种Python字典的实现，但很快我就意识到，我应该首先处理对象的抽象问题。

所以，我开始创建一些可以包装Python对象的Python类，在globals中存储和检索它们的数据，也就是说，在IRIS globals中序列化和反序列化Python对象。

它是如何工作的?

像 ObjectScript 的%DispatchGetProperty(), %DispatchSetProperty() 和%DispatchMethod()一样, Python 有委托对象的属性和方法调用的方式。

当你设置或获取一个对象属性时，Python 解释器让你通过方式 __setattr__(self, name, value) 和 __getattr(self, name)__来截获这个操作。

请看这个相当基本的例子。

>>> class Test:
.         def __init(self, prop1):
.                 self.prop1 = prop1
.

在InterSystems 2022年全球峰会上，InterSystems HealthShare 产品管理总监 Jonathan Teich 及其团队解读了医疗与医疗IT行业的趋势，并分享了HealthShare的最新产品策略与路线图，演示了一些易用且具有前瞻性的功能和用例。

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

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

 在AES的加密过程中,存在HEX和Base64的输出，目前在HEALTHSHARE自带有Base64的加解密规则，现在针对HEX的加解密进行对应的处理，实现和网上ASE加解密工具进行互相加解密。
在Ensemble的AES的CBC加密主要用到的是这俩个方法
$system.Encryption.AESCBCManagedKeyEncrypt(Plaintext,KeyID)
Plaintext是需要加密的字符串，需要进行$ZCONVERT(字符串,"O","UTF8")转换
KeyID是密钥的ID。
或者是
$SYSTEM.Encryption.AESCBCEncrypt(text,key,IV)
text是需要加密的字符串，需要进行$ZCONVERT(text,"O","UTF8")转换
Key 是密钥 键的长度必须为16、24或32个字符
IV  是偏移量 如果存在此参数，则必须为16个字符长。

第一个方法是在本地生成对应的密钥,暂时还不能和网站上的进行互相加解密的处理。
目前主要是针对第二个方法
$SYSTEM.Encryption.