第二章 $ZF Callout函数概述

IRIS $ZF系统功能是一套相关功能的容器。$ZF套件中的大多数函数都由函数调用的第一个参数标识，该参数将是一个负数，-100或-3到-6。例如，调用操作系统命令的函数具有$ZF(-100， <oscommand>)的形式，其中<oscommand>是包含要执行的命令的字符串。当讨论这个函数时，它将被称为$ZF(-100)。以同样的方式，其他函数将被称为$ZF(-3)到$ZF(-6)，只使用实际函数调用的第一个参数。也可以在不带负数参数的情况下调用$ZF()函数，在这种情况下，它调用名为iriszf的特殊Callout库中的函数。

第四十章 其他特殊主题 - 处理导入时意外的元素和属性

处理导入时意外的元素和属性

由于源 XML 文档可能包含意外的元素和属性，因此支持 XML 的类提供两个参数来指定导入此类文档时如何反应。例如，考虑以下类定义：

Class GXML.TestImportParms.Person Extends (%Persistent,%XML.Adaptor) 
{

Property Name As %Name [ Required ];
Property DOB As %Date(FORMAT = 5, MAXVAL = "+$h") [ Required ];
}

另请考虑以下 XML 文档：

最近在多家现场都遇到了备机长时间宕机导致镜像日志写满磁盘的问题。在这里我将对这个问题发生的原因、发生后的处理、和如何预防这类问题发生进行一些讨论。

问题的发生一般始于一些原因导致的主机（如，01）宕机，进而触发镜像的主备切换。切换后备机（如，02）成为主机，并无缝接管业务。由于业务不受影响，如果不注意监控环境的话，很可能现场技术人员长时间都注意不到镜像的备机（01）是宕机状态。

备机长时间宕机会导致如下问题：

1. 这种情况下如果主机（02）再次遇到问题宕机，镜像将无法发挥其高可用性，无法保持业务稳定运行。

2. 主机（02）产生的镜像日志将无法同步到备机（01）。未同步的日志将一直被保存在主机（02）上不被删除。长此以往镜像日志磁盘将被写满，同样导致主机（02）宕机。

问题发现时切记不要手动从文件夹直接删除主机（02）上的镜像日志。未同步的日志一旦手动删除，镜像将无法自动同步，需要重做主备镜像。

问题发现时如果主机（02）还未宕机，此时尝试解决备机（01）问题，启动备机（01），等待镜像自动同步即可。同步完成之后镜像日志将可以被定时任务定时清除。如果遇到较为复杂的情况，现场请第一时间联系您的软件供应商，软件供应商将协同系联软件全球响应中心一起来解决您遇到的具体问题。

第三十七章 XML 模式的高级选项 - 超类如何表示为类型

超类如何表示为类型

如果需要 XML 架构来显示特定的类型层次结构，则需要了解映射如何解释 IRIS 类层次结构。

类层次结构代表了有意义的数据组织等。该层次结构尽可能地反映在相应的 XML 类型定义中。

例如，假设有以下类：
- 名为 Base 的类，定义了三个公共属性（Property1、Property2 和 Property3）。
- 名为 Addition1 的类，它扩展 Baseand 并定义一个附加公共属性 (Addition1)。
- 名为 Addition2 的类，它扩展 Addition1 并定义一个附加公共属性 (Addition2)。

第三十五章 XML 模式的高级选项 - 创建子类型的选择列表

创建子类型的选择列表

根据 XML Schema 规范，复杂类型可以由类型（特别是相关类型）的选择列表组成。假设我们希望架构允许使用 <Person>, <Patient>, or <Employee> 元素，而不是 <Person> 元素。要定义这样的架构，我们会将 Person 属性的 XMLTYPECONSTRAINT 属性参数设置为等于“CHOICE”，如下所示：

第三十三章 控制到 XML 模式的映射 - 其他支持 XML 的类到 XML 类型的映射

其他支持 XML 的类到 XML 类型的映射

对于支持 XML 的类或基于支持 XML 的类的属性，XML 类型按如下方式确定： 如果该类具有 XMLTYPE 参数的值，则该值将用作类型名称。否则，短类名将被视为 XML 类型名。

例如，考虑以下类定义：

第三十一章 控制到 XML 模式的映射 - %ListOfDataTypes

%ListOfDataTypes

本部分显示从支持 XML 的类生成的 XML 架构的一部分，该类包含中定义为%ListOfDataTypes 的属性。例如，考虑以下属性定义：

Property PropName As %ListOfDataTypes(XMLITEMNAME = "MyXmlItemName");

如果此属性位于名为 Test.DemoList 的启用 XML 的类中，则该类的 XML 架构包含以下内容：

TCP作为OSI 7层的传输层的通信协议，其使用上不像更上层的通信协议那么方便，因为TCP操作的不是数据包，它操作的是数据流。因此有多种将TCP数据流“解释”为数据包（消息）的方法。

InterSystems IRIS提供了多种TCP适配器，用于不同的“解释”，例如EnsLib.TCP.FramedInboundAdapter使用特定的首尾字符做为分隔、EnsLib.TCP.CountedInboundAdapter使用固定的长度进行分隔...

同时，InterSystems IRIS提供了多种开箱即用的TCP业务服务和业务操作，方便接入和发送TCP数据。这里我们介绍常见的使用特定的首尾字符做为分隔的TCP业务服务和业务操作。

• 前言

随着网络安全日益被重视，特别是等级保护制度的大环境下，SSL加密传输越来越被重视，本文介绍如何使用支持SSL的ODBC连接IRIS数据库。

数据库版本：IRISHealth-2023.1

• 1. 服务器端配置

1）新建SSL服务器配置。

2）开启超级端口的SSL支持，这里我们选择启用即可，如所有超级端口的连接都支持SSL可选要求。

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

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

什么是 FHIR？

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

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

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

浅谈一下个人基于IRIS后端业务开发框架的理解

现状

由于国内使用基于M语言IRIS平台几乎都在医疗行业。医疗系统又非常的庞大和复杂。前期由于快速占领市场，系统数量越来越多，到了临界点后就产生了质变，所以前期基于功能的线性开发注重效率，所以导致大量的产品业务代码有如下集中情况：
- 系统交互乱如麻，各系统的交互关系变成了网状。
- 系统规模庞大，内部耦合严重，牵一发而动全身，后续修改和扩展困难，开发效率低。
- 关键功能逻辑复杂，容易出现问题，出现问题后很难排查和修复，开发成本高。
- 功能越来越多，导致系统复杂度指数级上升。

- 重复造轮子，相似的功能不断重复开发。

如上图所示，这仅仅是展示了五个模块之前的交互，在此基础上继续增加模块则复杂度成指数级上升，并且如果每个模块之间如果没有做好接口管理，维护起来也是地狱级别。

这是Java 编程比赛的相关文章。

我决定推出一个基于 IRIS Native API for Java 的 CRUD++ Global编辑器。
++因为它不仅仅是C reate、 R ead、 U pdate、 D elete
Global可视化对于立即查看结果始终很重要。

• 为此，我使用模仿 ZWrite 的树查看器扩展了 API，并且还允许检查子树。
• $Query Style Navigator 正向和反向操作可轻松找到感兴趣的全局节点。
• 最后，ZKill 添加了一个选项，可以删除全局节点的内容而不删除下面的子树。

这需要在服务器端有一个小的帮助器类作为默认 API 的扩展

我的策略是拥有一个可从命令行使用的相当适度的界面
就像在 Docker 控制台或终端上一样，并使其尽可能简单。
花哨的图形界面只会分散示例的基本内容。

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

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

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

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

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的意思。