搜索​​​​

WIN SQL是大多数用户使用的普通编辑器。但是我们不能使用winsql下载大量数据。所以我写了一个教程如何连接一个新的基于 Java 的编辑器，叫做 Squirrel SQL，它可以很容易地下载或导出 excel 或任何其他格式的数据。我还包括一个 Java JCBC 连接程序来连接 IRIS 数据库，尤其是镜像/故障转移服务器。 基于 SQL Java 的编辑器导出大量数据和用于 IRIS 连接的 Java JDBC 程序 基于 SQL Java 的编辑器导出大量数据 WinSql 是通常用于从 Iris 数据库中提取数据的编辑器，但是，如果没有许可的 winsql，则无法导出大量数据。 解决方案是使用基于 java 的编辑器，称为 Squirrel SQL。这是一个基于 java 的编辑器，您可以在从 IRIS 数据库执行 fetch 从编辑器中导出大量数据。这是用 Java 构建的开源 SQL 客户端，它使用 JDBC 连接到 IRIS 数据库。 Squirrel SQL 的特点 Java 19 兼容性 多个插入符/光标编辑 全局首选项和新会话属性搜索 Saved Sessions 的多项改进（用于保存和恢复 Session 的所有 SQL 编辑器的特性） 可配置的鼠标右键菜单 重新设计的添加/编辑 JDBC 驱动程序对话框 安装 Squirrel SQL 的步骤 Squirrel SQL 可以从 Squirrel 官网下载https://squirrel-sql.sourceforge.io/ 连接 IRIS 数据库的步骤 向 Squirrel Sql 添加驱动程序 点击“+”图标创建一个新的驱动程序，如下图所示 在“添加驱动程序对话框”中，选择“额外类路径”并单击“添加”，为“Intersystems-jdbc-3.2.0.jar”（jdbc 驱动程序jar 文件）添加一个新条目，如下所示。如果您在本地计算机的 C 盘上安装了 IRIS，这将是基于 IRIS 版本的正常路径 C:\InterSystems\IRISHealth2\dev\java\lib\JDK18\intersystems-jdbc-3.2.0.jar。 如下图所示， 输入驱动程序的名称“Intersystems IRIS”（选择任何有意义的名称） 输入示例 URL 作为 jdbc:IRIS://<host>:<port>/<database> 网站 URL 是可选的。 单击右侧的“List Drivers”按钮并选择“com.intersystems.jdbc.IRISDriver”，如下图所示。 单击“确定”保存驱动程序条目。现在您可以在驱动程序下的左侧菜单栏中看到驱动程序。 添加基于驱动程序的别名（连接） 选择squirrel sql左侧的“别名”选项卡，点击“+”添加新别名，如下图。 在“添加别名”窗口中，为别名输入一个有意义的名称。 从下拉菜单中选择我们新创建的 IRIS 驱动程序。选择驱动程序后，URL 格式将填充为新创建的驱动程序配置。通过添加正确的主机名或 IP 地址、端口号和数据库命名空间来编辑 URL。 例如：jdbc:IRIS://00.00.00.00.00:12345/TEST-TRAK 输入具有 SQL 权限的 IRIS 数据库的用户名和密码 单击测试按钮并验证连接是否成功。 单击“确定”保存新别名 连接到 IRIS 数据库 双击新创建的别名连接到数据库，squirrel 编辑器将打开，您可以尝试使用 sql 查询。 用于编写程序的 IRIS 数据库的 JDBC 连接 import java.sql.*; import com.intersystems.jdbc.*; import java.util.logging.*; import java.io.IOException; import java.util.*; public class Extract { public static Connection TrakCache () throws Exception { IRISDataSource ds = new IRISDataSource(); Connection conn = null ; ds.setURL( "jdbc:IRIS://1.12.333.444:12345/NAMESPACE-TRAK" ); ds.setUser( "username" ); ds.setPassword( "Password" ); try { conn = ds.getConnection(); } catch (Exception e) { System.out.println( "catch" +conn); //You can write another connection here if automatically fail over to another server. } return conn; } }

基于InterSystems的集成ML技术和Dashboard，根据上传的CSV文件自动生成相关预测和BI页面。前端和后端在Vue和Iris中完成，使用户可以通过简单的操作生成所需的数据预测和分析页面，并根据这些页面做出决策。 # ZPM 安装 zpm:USER>install IntegratedMLandDashboardSample # 部署流程 使用或创建新的命名空间 将代码导入相应的命名空间 在终端中执行： Do # # class (customizemashinelerningandaanalysis. Util. Tool) Deployment() 前端是Vue文件夹下的dist文件夹。在使用它之前，请打开dist-static config.js并修改后端服务器要使用的IP和端口。然后您需要将iframeUrl的测试修改为“Analysis”+后端使用的命名空间，例如“AnalysisUSER” 然后启动前端文件（可以将dist文件夹放在tomcat中开始使用） 访问地址为： Ip: port/dist # 如何使用 以women.csv为例 1.选择要上传的CSV文件，CSV文件名和数据列名不得包含空格等其他符号 2.填写需要预测的列名，如“高度” 3.单击“确定”按钮，等待界面返回 成功返回后，刷新当前页面，然后单击“模型列表”下的辅助选项。新生成的项目将出现 ① 填写完其他值后，点击②确定，在③处生成预测值 ④ 嵌入式虹膜仪表板显示以前导入CSV的一些数据 # 其他 CSV 展示 # 单元测试 Set ^UnitTestRoot=your modules dir +"\src"+namespace+"\integratedmlanddashboardsample\src" (such C:\InterSystems\HealthConnect\mgr\.modules\USER\integratedmlanddashboardsample\src) do ##class(%UnitTest.Manager).RunTest("UnitTests") #注意 由于页面上嵌入了iris的仪表板，如果您遇到无法正确显示的跨域问题，可以访问iris查看图表 非常棒的应用！那csv中的数据能不能是非数字呢？

# 第十六章 调用Callout Library函数 `Callout` 库是一个共享库（`DLL` 或 `SO` 文件），其中包含 `$ZF Callout` 接口的挂钩，允许各种 $ZF 函数在运行时加载它并调用其函数。 `$ZF Callout` 接口提供了四种不同的接口，可用于在运行时加载 `Callout` 库并从该库调用函数。这些接口的主要区别在于如何识别库并将其加载到内存中： - 使用 `$ZF()` 访问 `iriszf` 标注库描述了如何使用名为 `iriszf` 的特殊共享库。当该库可用时，可以通过 `$ZF("funcname",args)` 形式的调用来访问其函数，而无需事先加载该库或指定库名称。 - 使用 `$ZF(-3)` 进行简单库函数调用描述了如何通过指定库文件路径和函数名来加载库并调用函数。它使用简单，但虚拟内存中一次只能有一个库。与其他接口不同，它在调用库函数之前不需要任何初始化。 - 使用 `$ZF(-5)` 通过系统 `ID` 访问库描述了一种可用于一次有效维护和访问多个库的接口。可以同时加载和使用多个库，每个库所需的处理开销比 `$ZF(-3)` 少得多。内存中的库由加载库时生成的系统定义的 `ID` 来标识。 - 使用 `$ZF(-6)` 按用户索引访问库描述了处理大量标注库的最有效接口。该接口通过`Global`定义的索引表提供对库的访问。该索引可供 `IRIS` 实例中的所有进程使用，并且多个库可以同时位于内存中。每个索引库都被赋予一个唯一的、用户定义的索引号，并且可以在运行时定义和修改索引表。当库文件被重命名或重新定位时，与给定库 `ID` 关联的文件名可以更改，并且此更改对于按索引号加载库的应用程序来说是透明的。 # 使用 `$ZF()` 访问 `iriszf` 标注库 当名为 `iriszf` 的 `Callout` 库在实例的 `/bin` 目录中可用时，可以通过仅指定函数名称和参数的 `$ZF` 调用来调用其函数（例如，`$ZF("functionName",arg1, arg2))`.。无需事先加载库即可调用 `iriszf` 函数，并且实例中的所有进程都可以使用 `iriszf` 函数。 自定义 `iriszf` 库是通过创建标准 `Callout` 库、将其移动到实例的 `/bin` 目录并将其重命名为 `iriszf`（具体为 `iriszf.dll` 或 `iriszf.so`，具体取决于平台）来定义的。 以下是编译 `simplecallout.c` 示例（请参阅“创建 `Callout` 库”）并将其设置为 `iriszf` 库的步骤。这些示例假设实例在 `Linux` 下运行，安装在名为 `/intersystems/iris` 的目录中，但所有平台上的过程基本相同： 1. 编写并保存 `simplecallout.c`： ```java #define ZF_DLL #include "iris-cdzf.h" int AddTwoIntegers(int a, int b, int *outsum) { *outsum = a+b; /* set value to be returned by $ZF function call */ return IRIS_SUCCESS; /* set the exit status code */ } ZFBEGIN ZFENTRY("AddInt","iiP",AddTwoIntegers) ZFEND ``` 2. 生成`Callout`库文件（`simplecallout.so`）： ```java gcc -c -fPIC simplecallout.c -I /intersystems/iris/dev/iris-callin/include/ -o simplecallout.o gcc simplecallout.o -shared -o simplecallout.so ``` 3. 从 `IRIS` 终端会话中使用 `$ZF(-3)` 测试库： ```java USER>write $ZF(-3,"/mytest/simplecallout.so","AddInt",1,4) 5 ``` 4. 现在安装该库以与 `$ZF()` 一起使用。将 `simplecallout.so` 复制到 `/bin`中，并将其重命名为 `iriszf.so`： ```java cp simplecallout.so /intersystems/iris/bin/iriszf.so ``` 5. 确认可以从 `IRIS` 会话中使用 `$ZF()` 调用代码： ```java USER>write $zf("AddInt",1,4) 5 ``` `iriszf` 库在首次使用时加载一次，并且永远不会卸载。它完全独立于本章前面描述的其他 `$ZF` 加载和卸载操作。 注意：静态链接库 `$ZF Callout Interface` 的早期版本允许将代码静态链接到 `InterSystems` 内核并使用 `$ZF()` 进行调用。不再支持静态链接，但 `irisz` 库提供相同的功能，无需重新链接内核。

VR ICU® 是 InterSystems FHIR 创新孵化器 Caelestinus 的参与者。这篇文章将向您介绍我们利用 InterSystems FHIR Server 为医疗保健提供的 VR 解决方案。 我们是一家技术初创企业虚拟实验室，利用先进的 VR/AR 技术开发解决方案。VR ICU® 是一个针对重症监护室医务人员的培训平台，是在 Covid 时代为满足医院需求而创建的。 与InterSystems合作的优势 我们的 VR ICU® 解决方案符合实践需求，是与医院合作开发的。 除了技术解决方案和技能学习本身，记录培训课程、培训进度和成功率对于医院或麻醉学和重症监护部门的有效管理也至关重要。医务长可以通过了解谁在何时接受了培训，清楚地掌握能够在重症监护室使用设备的人员数量，从而有效地对他们进行培训，以保持技能、有控制地规划人员技能储备并提高他们的能力。 在这方面，与 InterSystems 的合作对我们来说至关重要，它使我们能够在应用程序中存储每次培训期间的数据。目前，我们会记录参与者的姓名、培训日期和时长、培训类型、设备类型、错误数量和类型，必要时还会记录培训成功完成的信息。 如何使用？用户登录应用程序并选择一个账户。 根据 HL7 标准，该账户作为从业人员存在于数据库的资源下。培训课程开始时，会在应用程序中创建一个新的 "任务"--在这里输入培训课程的开始时间和培训课程的类型，课程结束时，再次输入培训课程的结束时间。错误会写入输出表。培训完成后，任务中的数据将序列化为 JSON 格式，并使用 FHIR API 发送到云端。为了使 VR 应用程序之外的数据可视化，我们开发了一款平板电脑应用程序。该应用程序与存储在云端的数据相连，并显示特定用户的个人训练课程。 人力资源部门通过培训数据了解受训人员完成培训的总体情况和水平，从而有效地规划他们的进一步培训，并跟踪了解员工的能力及其在重症监护室护理过程中的替换性。您可以点击这里：https://www.youtube.com/watch?v=3oO0uuHy0kg&t=8s 如今，医院、大学和模拟中心都在使用 VR ICU®。 虚拟现实技术将教育和培训提升到了一个新的水平。通过体验学习，可以提高培训效果和记忆力。 在 VR ICU® 中使用 InterSystems 的 FHIR 云服务器作为存储培训进度数据的工具，并使用 FHIR API 进行通信，这也对我们进军国外市场产生了积极影响，尤其是在德国，FHIR 标准是一种广为接受的解决方案，用于与人力资源部门传输信息，并与第三方调度系统进行通信。 麻醉学和重症监护审查参考：https://www.youtube.com/embed/Qve5xEm89cU?feature=oembed 它是如何开始的？ 2020 年，一场大流行病袭击了我国。医院人满为患，人手短缺，尤其是重症监护室。麻醉、复苏和重症医学科主任在晚间新闻中解释说，如果更多的医生被隔离或生病，他就没有足够的合格人员来操作肺部呼吸机。其他医院也证实了同样的情况。我们萌生了制作一个专门用于培训的肺部呼吸机数字拷贝，帮助医院培训其他科室医生的想法。 我们找到了麻醉复苏部（ARO）的负责人、模拟中心的专家。医生们支持我们的想法，有些人还参与了开发工作。我们还得到了医疗设备制造商的支持，他们看到了虚拟现实培训的附加值。 我们是如何开展项目的，解决方案的重要性何在？ 1. 我们评估了重症监护室的现状： - 在没有真实病人和/或医疗设备的情况下，50% 以上的重症监护室程序无法进行培训。 - 医疗设备制造商难以将医务人员集中到一处进行培训（只有 30% 的受训人员能坚持到培训结束） - 过去两年中，麻醉学和重症监护部门的人员流动率约为 20%。 2. 问题的解决方案： - 虚拟现实自动培训平台 - 模拟重症监护室的手术过程，无需真实病人，也无需使用真实医疗设备 - 节省技术和医疗用品 - 也可用于远程培训，从不同地点/工作场所进入同一个虚拟空间 - 在安全的环境中进行风险情况演练 - 将人为错误的风险降至最低 3. 潜力： - 利用人工智能（AI）模拟和练习危急情况，确定正确的程序 - 人工智能可模拟病人-设备-病人之间的互动 - 制造商的设备集中在一个虚拟空间，使医院的培训更加容易 愿景 VR ICU® 的目标是作为一个平台，让医院从实际使用的设备目录中选择 3D 设备，并从中创建培训环境。 我们向医疗设备制造商提出的愿景最初得到了 BBraun、费森尤斯和 Linet 的支持。随后，其他公司也纷纷效仿这些大胆的先行者。我们还根据所进入的市场扩大我们的设备组合。目前，我们在美国、亚洲和南美都有合作伙伴，他们正在补充信息并与制造商进行谈判。 我们正在全球会议上展示 VR ICU®，我们很高兴能成为 Caelestinus 孵化器的一部分。由于我们与 InterSystems 的合作，我们有机会参加在西雅图举行的 InterSystems 2022 年全球峰会，现在我们正在拉斯维加斯参加 HLTH 2022。 VR ICU® 已经赢得了许多奖项，最近在奥地利林茨，我们凭借该解决方案赢得了最佳初创企业奖。 这些成功的展示吸引了投资者的关注。我们欢迎那些希望进一步开发我们产品的人向我们推荐他们。我们计划在 2023 年向捷克、斯洛伐克和德国的医院出售许可证。我们欢迎商业合作伙伴以及能够加快 VR ICU® 实际应用--市场进入进程或希望为人工智能/VR 版本的开发做出贡献的合作伙伴。 原文来自这里：https://community.intersystems.com/node/529381

视频文字版。点击查看视频。 CHIMA主任委员：王才有 老卢，你好。疫情三年我们没见，中国发生了很大的变化，你回来会感觉到。特别是在信息化和数字化方面，确实中国的这三年可以说是政策和制度设计上都有了很大的一些调整和进步，特别是去年政府发布了关于数据基本制度的设计方案，我们管它叫“数据二十条”。 这个制度呢，实际上是避开了数据的所有权的问题，如果说我们在数据的所有权和使用权上长期去争论的话，它的价值就很难发挥。所以说中国这次首次提出了一个“三权”，数据“三权分立”的新的战略设计，不再强调数据是谁的，我们强调数据的控制权——就是数据现在在谁手里；数据的开发权——他这些数据可以用来干什么；数据的受益权——他把这数据再分享给别人，再创造二次价值，或者再创造三次价值，这样数据的资源就得到充分的利用。 所以说一方面要对这种数据基本制度的建立，为今后数据资源市场化是开了一道新的大门。中国是一个数据资源的大国，那这些资源怎么利用好，怎么用在生产，怎么用在服务，怎么用在改善我们医院的管理，给我们患者服务，给这个居民服务，这项我想是一个很大的一个制度上的创新。 当然这个制度的创新也给我们提出了很多新的要求：数据安全的要求，个人信息保护的要求，数据标准的要求…… 我国基础制度的形成，将促进数据合规高效流通使用。今后，医疗健康数据将在更大空间交换和共享，这就需要新一代标准体系了，例如FHIR。 我想这方面你也许知道了，在这方面有什么体会呢？咱们可以做做交流。 InterSystems 亚太区总经理卢侠亮（Luciano Brustia）： 好的，谢谢。 您所说的这些让我感到很兴奋，谢谢您的发言。因为我同意，当我们在谈论标准、谈论专业术语的时候，每个人都会立即想到FHIR标准。在这方面，InterSystems在全球绝对是领先的。 你可能知道，在过去的这些年里，我们做了许多工作，我们的IRIS数据平台，在全球范围内得到了大范围部署，同时，我们在中国持续地进行本地化创新，构建了中国版的互联互通平台（内嵌FHIR资源仓库），我们称之为“互联互通套件”，用来实现基于FHIR标准的互联互通 。 当谈到专业术语（统一语义）是我们的目标时，FHIR绝对可以作为一个最佳标准选择，我们已经帮助150多家医院通过了国内互联互通标准化成熟度等级评测，其中有近30家医院通过了最高级别的认证（五级乙等），值此（“数据二十条”颁布的）重要时机，我们肯定还会继续加大投入，在这些方面（打通互联互通和FHIR两大生态）开展更多活动。我们现在已经发布了互联互通套件的第三版，目前正在计划进行更多升级。 CHIMA主任委员王才有： 卢总，您刚才讲的系联在中国的一些做法，我很认可。因为系联公司（InterSystems）在中国已经多年，特别是在推进互联互通，推进信息标准的应用方面发挥了很重要的作用。 对这个FHIR来讲，它是针对的移动互联网出现之后，这信息在更大的范围里面交换共享和随时的调用的时候，随机调用的时候，它只有利用这个标准，它才可能实现信息的动态的、语义互操作的这种交换。 而HL7 2.X它面对的是语法层面的交换，语义层面的这个能力呢，它是比较弱的。所以说如果要做得更好，信息在互联网和移动互联网时代，特别是数字，我们说的数字时代，你在更大的空间里面交换和共享信息的时候，同时保持信息理解上的一致性，那我们只有选用FHIR才可能实现得会更好一些。这一方面是技术上的进步，一方面是应用上的需求。 那当然这种技术上的提供和应用上的需求是必须要依赖于工具，依赖于产品。那系联公司这方面的平台支撑和工具支撑上，我想对于促进FHIR在中国的应用还是发挥了很好的作用的。 系联过去确实做得不错，但是我们看到了FHIR的应用还不是特别地普及，原因是多方面的，可能也有一些新的制约和一些新的挑战。我想系联公司在这方面也会进一步地做出努力，推进FHIR在中国的应用。 这方面，卢总下一步你有什么打算呢？ InterSystems 亚太区总经理卢侠亮（Luciano Brustia）： 是的，当然有。我们已经将FHIR作为我们所有开发部署的核心，包括我们所有医疗平台。首先，我很高兴在今年CHIMA大会上（HL7中国）将发布《FHIR白皮书》 ，明确界定HL7、CDA和FHIR之间的区别。因为医院采用CDA标准，他们拥有一个庞大的临床数据中心，但我们还需要一个额外的步骤来实现FHIR。 为了让大家更容易理解，我经常举这样一个例子：我总是把FHIR的重要性比作普通话的重要性，因为普通话可以作为人们互相交流的一种共同语言。我也总是喜欢这样说，我看到了一张图片，上面是一匹带着黑色条纹的白马，大家都明白它是什么。你也可以说，你看到了一张图片，上面是一匹带着白色条纹的黑马，大家也都明白它是什么。FHIR不会告诉你这是一匹白马还是一匹黑马，而是会说这是一匹“斑马”——只用一个词，就确切指出了图片内容的唯一标识，以及我们在谈论的是什么。这是深层次的主要区别。 我很高兴《FHIR白皮书》即将在CHIMA上发布，这将有助于理解这一点。InterSystems作为FHIR标准在全球范围的推广者，已经在美国和亚太地区拥有众多成功案例，并且帮助越来越多的国家部署并遵循这种标准，为当地居民提供更多价值，我们很高兴能在中国做同样的事情。 CHIMA主任委员王才有： 刚才没想到您作为一个总裁，对技术细节了解得这么清楚。确实我们要把技术细节搞清楚，把关键的概念搞清楚，这样才能使我们的行动走到正确的轨道上来。对FHIR，它到底是适用于什么场景，什么场景下应该用哪些标准解决什么问题，这我觉得是一个非常重要的一个考虑。任何一个企业、任何一个用户都应该考虑你选用标准的适宜性，我们不能说哪个标准好，哪个标准不好。所以说我们CHIMA，刚才老卢也提到了，我们要在下一次CHIMA大会上发一个白皮书，而这个白皮书实际上就是我们对这些标准的基本概念，它的用途，在什么场景下应用，我们要做一个比较清晰的这种引导，让大家在选择标准和使用标准上，使标准能真正解决自己互联互通上的问题。 那我们CHIMA跟系联一样，也是在推进标准的应用和标准的采纳，实现我们互联互通的目标。前年，我们也组织了专家，在中国的医院编了一个中国医院里边的关于FHIR的应用的一些案例的分享，我们是请的北京友谊医院的专家来共同承担这个课题，也非常感谢系联的专家对这个项目给予了很好的支持。 卢总，我们系联今后在这个信息互联互通和促进，我们叫数字时代的健康场景下，我们公司还有什么好的想法和建议？ InterSystems 亚太区总经理卢侠亮（Luciano Brustia）：谢谢。我认为此时来到中国，这是一个非常令人兴奋的时机，因为我们能够带来许多在世界各地获得的经验。我们在日本群马大学建立了日本首个FHIR数据库；我们正在与印度尼西亚的一家超大型医疗集团合作，该医疗集团拥有40多家医院，（借助InterSystems技术）采用FHIR标准，将他们的数据汇聚起来，并在此基础上进行分析。毫无疑问，InterSystems一直都在采用、推广FHIR标准，在FHIR成为互操作性标准之前就是如此，而且我们将带来更多的创新，以确保中国始终与国际最前沿的标准接轨，因为最终真正重要的是，我们这样做是为了确保所有中国居民的利益，而且我认为这对像你我这样从事IT行业，特别是从事医疗IT领域的从业者来说，才是最重要的。我们不仅仅是在做生意，更多的是在提供价值。在人口不断增长的情况下助力全民健康水平提升，中国居民的寿命越来越长，这是一件非常好的事情。但也带来了很多问题，特别是人口老龄化的问题，建设高质量的数据库，采用先进的标准，可以有效地预防更多的慢性疾病发生，我认为这是非常有价值的，也让我们所做的事情更有意义，以上是我的看法，非常感谢。CHIMA主任委员王才有：非常高兴看您为中国医疗信息化做出的贡献。系联公司把国际上的一些标准引用到中国，我们也看到中国自身医疗信息化发展也是非常地快，特别是中国具有一个独特的优势——就是数据资源丰富、应用场景非常之多，所以中国的经验呢，我想也在逐渐地积累和形成。所以说我认为系联公司将来的更重要的任务，把中国的经验引向世界，为全球的人民的健康共同做出贡献。InterSystems 亚太区总经理卢侠亮（Luciano Brustia）：是的，当然。我的意思是，就像我一直在说的，我很荣幸来到中国，这已经是我在中国的第15个年头了，而系联来到中国已经不止25年了，我们打算再呆上另一个20年、25年……如果我还能再活二十年，（我会）继续留在这里，继续为各位和所有聪明睿智的中国居民服务。毫无疑问，InterSystems一直致力于把我们的先进技术带到中国，助力中国本土企业做大做强，当然，我们也会将在中国获得的经验，作为一种资源共享给世界其他地方。所以我真的很高兴再次回到中国，我认为这是最好的时候，非常感谢大家！

JWT Authentication 原理及验证流程 原理 JWT 是一种结构紧凑、URL 安全的身份验证、授权或信息交换方式。在身份验证的情况下，服务器会向已通过身份验证的客户端提供一个 JWT，这样客户端在 JWT 过期之前就无需再提供密码来访问服务器上受保护的资源。 验证流程： 客户端发送Login到服务端 服务端返回 JWT给客户端 客户端校验JWT签名 客户端发送带有JWT签名的request到服务端 服务端检查JWT签名的有效期，在有效期内，则返回response给客户端，不在有效期内，返回error JWT 配置步骤 创建REST服务 配置Web Application 安全配置 客户端发送Login，从服务器获取JWT 配置成功，发送带有JWT的request 1. 创建REST服务 在InterSystems IRIS中，可以使用/api/mgmnt自动创建REST的 .disp .impl 和 .spec 类，本篇文章不介绍具体创建REST服务的流程，具体内容请参考社区文章创建REST 服务。 2. 配置Web Application IRIS管理门户：系统管理 -> 安全 -> 应用程序 -> Web 应用程序 选中 ‘Use JWT Authentication’ 复选框，并设置‘JWT Access Token Timeout’ 和‘JWT Refresh Token Timeout’， 其中，JWT Access Token Timeout 为JWT 令牌超时秒数，如果你打算长时间测试 API，建议将此值设为 1 小时（3600 秒），JWT Refresh Token Timeout（令牌刷新超时的秒数）设为 900 秒。 3. 安全配置 IRIS管理门户：系统管理 -> 安全 -> 系统安全 -> 身份验证/Web 会话选项 ‘JWT Issuer field’用于签名和验证 JWT 的签名算法。‘JWT Issuer field’将出现在 JWT 的声明部分，其目的是告知是谁给了你这个令牌。您可以将其设置为 "InterSystems"。 4. 客户端发送Login，从服务器获取JWT 使用基本 HTTP 身份验证或在请求正文中使用有效凭证发送POST请求到http://<api>/login端点，服务器端会返回一个访问令牌和一个刷新令牌，可在后续请求中使用。 body样例: { "user": "superuser", "password": "iris" } 5.配置成功，发送带有JWT的request 到此为止，您已经成功配置JWT，可以发送带有JWT的请求了。只需要在Header中添加Authorization，如下所示： -H "Authorization: Bearer {access_token}"

# 第四十五章 管理镜像 - 使用 ^MIRROR 状态监视器 # 使用 ^MIRROR 状态监视器 `^MIRROR` 例程提供基于字符的镜像状态监视器。 `^MIRROR Status Monitor` 选项显示镜像成员的状态，包括类型、状态、日志传输延迟和 `dejournal` 延迟（请参阅镜像成员日志传输和 `Dejournaling` 状态）。监视器可以在任何镜像成员上运行，但在故障转移成员上运行它会提供有关仲裁器配置和所有连接的异步成员的信息，而在异步成员上运行它则不会。 要启动状态监视器，请打开终端窗口，在 `%SYS` 命名空间中运行 `^MIRROR` 例程（请参阅使用 `^MIRROR` 例程），然后从镜像状态菜单中选择状态监视器。以下是在故障转移成员上运行时监视器的输出示例： ```java Status of Mirror MIR25FEB at 17:17:53 on 02/27/2018 Member Name+Type Status Journal Transfer Dejournaling -------------------------- --------- ---------------- -------------- MIR25FEB_A Failover Primary N/A N/A MIR25FEB_B Failover Backup Active Caught up MIR25FEB_C Disaster Recovery Connected Caught up Caught up MIR25FEB_D Read-Only Reporting Connected Caught up Caught up Arbiter Connection Status: Arbiter Address: 127.0.0.1|2188 Failover Mode: Arbiter Controlled Connection Status: Both failover members are connected to the arbiter Press RETURN to refresh, D to toggle database display, Q to quit, or specify new refresh interval ``` 当在异步成员上运行状态监视器时，仅列出故障转移成员和该异步成员，并且还会显示异步（正在运行或已停止）上的 `dejournaling` 状态，例如： ```java Status of Mirror MIR25FEB at 17:17:53 on 02/27/2018 Member Name+Type Status Journal Transfer Dejournaling -------------------------- --------- ---------------- -------------- MIR25FEB_A Failover Primary N/A N/A MIR25FEB_B Failover Backup Active Caught up MIR25FEB_C Disaster Recovery Connected Caught up Caught up Dejournal Status: running (process id: 12256) Press RETURN to refresh, D to toggle database display, Q to quit, or specify new refresh interval ``` 默认情况下，不显示有关镜像数据库的信息。在提示符处输入 `d` 以列出有关镜像中每个数据库的信息，包括名称、目录、状态和要取消的下一条记录，如使用镜像监视器中所述，例如： ```java Mirror Databases: Last Record Name Directory path Status Dejournaled ------------- ----------------------------------- ----------- ----------- MIR25FEB_DB1 C:\InterSystems\20182209FEB25A\Mgr\MIR25FEB_DB1\ Active Current,c:\intersystems\20182209feb25a\mgr\journal\MIRROR-MIR25FEB-20180227.001,40233316 MIR25FEB_DB2 C:\InterSystems\20182209FEB25A\Mgr\MIR25FEB_DB2\ Active Current,c:\intersystems\20182209feb25a\mgr\journal\MIRROR-MIR25FEB-20180227.001,40233316 ``` # 监控镜像通信进程 每个系统（主要和备份故障转移成员，以及每个连接的异步成员）上运行的进程负责镜像通信和同步。 ## 主要故障转移成员上的镜像进程 在主要故障转移成员上运行系统状态例程 (^%SS) 会显示下表中列出的进程。 注意：本节的 `^%SS` 输出中有意省略了 `CPU`、`Glob` 和 `Pr` 列。 #### 主要故障转移成员上的镜像进程 Device| Namespace| Routine| User/Location ---|---|---|--- /dev/null| %SYS |MIRRORMGR |Mirror Master MDB2| %SYS| MIRRORCOMM| Mirror Primary* 192.168.1.1 |%SYS |MIRRORCOMM |Mirror Svr:Rd* 这些过程定义如下： - `Mirror Master`：该进程在系统启动时启动，负责各种镜像控制和管理任务。 - `Mirror Primary`：这是出站数据通道；这是一个单向通道。每个连接的系统有一个作业（备份故障转移或异步成员）。 - `Mirror Svr:Rd*`：这个是入站确认通道；这是一个单向通道。每个连接的系统有一个作业（备份故障转移或异步成员）。 每个连接的异步成员都会在主故障转移成员上产生一组新的 `Mirror Master`、`Mirror Primary` 和 `irror Svr:Rd*` 进程。 ## 备份故障转移/异步成员上的镜像进程 在备份故障转移/异步成员上运行系统状态例程 (`^%SS`) 会显示下表中列出的进程。 #### 备份故障转移/异步成员上的镜像进程 Device| Namespace| Routine| User/Location ---|---|---|--- /dev/null| %SYS |MIRRORMGR |Mirror Master /dev/null |%SYS|MIRRORMGR| Mirror Dejour /dev/null| %SYS|MIRRORMGR| Mirror Prefet* /dev/null |%SYS |MIRRORMGR| Mirror Prefet* MDB1 |%SYS|MIRRORMGR |Mirror Backup /dev/null| %SYS|MIRRORMGR |Mirror JrnRead 此表中标识的进程也出现在每个连接的异步成员上： - `Mirror Master`：该进程在系统启动时启动，负责各种镜像控制和管理任务。 - `Mirror JrnRead (Mirror Journal Read)`：该过程将备份生成的日志数据读入内存，并将这些更改排队等待 `dejournal` 作业取消。 - 镜像延迟（`Mirror Dejournal`）：这是备份故障转移成员上的延迟作业；它将接收到的日志数据中的 `sets` 和 `kills` 发送到镜像数据库。 - `Mirror Prefet*`（镜像预取）：这些进程负责在`dejournal` 作业实际尝试使用它们之前将 `dejournal` 作业所需的磁盘块预取到内存中。这样做是为了加快 `dejournaling` 过程。系统上通常配置了多个镜像预取作业。镜像备份：这个过程是一个双向通道，将从主服务器接收到的日志记录写入备份的镜像日志文件，并向主服务器返回确认。

文章相关视频参见Synthea生成FHIR测试数据，以及FHIR服务器加载FHIR资源文件 1. 什么是Synthea Synthea是一个开源软件包，可以模拟生成患者就诊数据。他的github地址在这里。 生成的就诊模版从最初的模拟美国前十种常见病、前十种慢性病到现今超过90种不同的模型。详细模型参见这里。 基于当前版本，Synthea的特性包括： 从出生到死亡的全生命周期 可配置的人口统计学信息（默认为美国马萨诸塞州人口普查数据） 模块化规则系统 插入通用模块 用于附加功能的自定义 Java 规则模块 主要医疗事件就诊、急诊室就诊和症状驱动的就诊 症状、 过敏、药品、 疫苗接种、观察/生命体征、实验室、处置、 护理计划 支持格式 HL7 FHIR（R4、STU3 v3.0.1 和 DSTU2 v1.0.2） ndjson 格式的批量 FHIR（设置 exporter.fhir.bulk_data = true 以激活） C-CDA （设置 exporter.ccda.export = true 以激活） CSV （设置 exporter.csv.export = true 以激活） CPCDS （设置 exporter.cpcds.export = true 以激活） 使用Graphviz可视化呈现规则和疾病模块 支持的参数可见下图 比如 -p 5 生成5条测试数据 -g M 生成男性测试数据 -a 60-65 生成年龄在60-65周岁患者测试数据 2. 使用Synthea 生成测试数据 为了方便使用，也将该软件做成了docker，所以你可以简单的执行下面命令行 docker run --rm -v $PWD/output:/output --name synthea-docker intersystemsdc/irisdemo-base-synthea:version-1.3.4 -p 5 该命令会在当前路径的output文件夹下生成5条患者符合FHIR标准的就诊数据，数据相关摘要信息如下面终端输出： 3. 加载生成的 FHIR 数据至 InterSystems IRIS for Health 生成完FHIR数据后，需要加载到FHIR服务器（FHIR资源仓库）中。 我们在输出目录下可以看到生成7条json数据，其中5条患者就诊相关，1条就诊医院信息，一条参与者(就诊医生)信息。 在InterSystems IRIS for health中可以方便的使用DataLoader类中的方法，批量加载FHIR资源数据，进入FHIR 资源仓库命名空间后执行： zw ##class(HS.FHIRServer.Tools.DataLoader).SubmitResourceFiles("/external/fhir/","FHIRServer","/fhir/r4") 该方法中的第一个参数是fhir资源文件路径; 第二个参数服务类型，这里一般是FHIRServer; 第三个参数FHIRServer的service名称。 执行后显示如下： 之后我们可以进入管理门户，或者使用SQL客户端查询相关存储表，表明数据被正确导入

在之前的文章中，我们已经了解了如何配置和自定义我们的 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 消息。 好吧，在我们的文章中，我们将利用适配器提供的功能来接收 FHIR 消息。 EMPI配置 FHIR 适配器安装 我们首先回顾一下独立 EMPI 安装中有哪些服务： 正如您所看到的，在独立模式下安装 EMPI 后，创建了一个注册表服务，其中包含配置 EMPI 所需的所有选项，以及我们称为 HSPIDATA 的命名空间，其中我们有一个产品来管理互操作性功能，需要。 对于我们的案例，我们创建了一个名为 WEBINAR 的新命名空间，我们将在其中部署正常的互操作性生产。我们将在此命名空间中安装FHIR 互操作性适配器，此安装将发布一个 Web 应用程序，我们将向该应用程序发送带有 FHIR 消息的 REST 调用。为此，我们将从终端执行以下命令： zn "WEBINAR" set status = ##class (HS.FHIRServer.Installer).InteropAdapterConfig( "/csp/healthshare/webinar/fhir/r4" ) 安装后，我们将检查从管理门户创建的新应用程序： 让我们在 WEBINAR 命名空间中检查我们的生产： 默认创建了两个新的业务组件： InteropService ：在我们的生产中，我们直接使用其类 HS.FHIRServer.Interop.Service 的名称，它将是负责接收发送到我们端点的 FHIR 消息的业务服务。 /csp/healthshare/网络研讨会/fhir/r4 InteropOperation ：我们已将此名称更改为 HS.FHIRServer.Interop.Operation。对于我们的示例，我们忽略了此业务操作，因为我们将通过 TCP 将 FHIR 消息的信息发送到我们的 EMPI 生产 创建业务组件来管理 FHIR 消息传递 很好，我们已经启用了业务服务来接收 FHIR 消息，现在我们感兴趣的是从消息中提取信息并将其发送到我们的 EMPI 生产。让我们看一下 HS.FHIRServer.Interop.Service 将接收的消息类型： Include HS.FHIRServer /// FHIRServer REST Business Service Class HS.FHIRServer.Interop.Service Extends (Ens.BusinessService, HS.HC.Util.Trace.Helper) { Parameter SETTINGS = "TargetConfigName:Basic:selector?context={Ens.ContextSearch/ProductionItems?targets=1&productionName=@productionId},Timeout:Basic" ; /// Configuration item to which to send inbound messages. Property TargetConfigName As Ens.DataType.ConfigName [ InitialExpression = "HS.FHIRServer.Interop.Operation" ] ; /// Timeout for dispatch (so we don't hold up the HTTP service too long or hang up a production shutdown). Property Timeout As %Integer [ InitialExpression = 25 ] ; /// Process an incoming message into the production; dispatch it to the configured target. /// The Interoperability contract requires that errors be returned as %Status here. Method OnProcessInput(pRequest As HS.FHIRServer.Interop.Request, Output pResponse As HS.FHIRServer.Interop.Response) As %Status 该消息的类型为 HS.FHIRServer.Interop.Request，如果我们查阅文档，我们将看到它有一个名为QuickStreamId的关联属性，我们将使用该属性来提取关联的 FHIR 消息。为此，我们将业务服务中收到的消息重定向到业务流程Webinar.BP.FHIRToHubRequest 该业务流程仅具有将消息重定向到负责通过 TCP 将消息发送到 EMPI 生产的业务操作FromFHIRToMPI的功能。 Method OnRequest(pRequest As HS.FHIRServer.Interop.Request, Output pResponse As HS.FHIRServer.Interop.Response) As %Status { Set tSC = ..SendRequestSync ( "FromFHIRToMPI" , pRequest, .pResponse) Quit $$$OK } 让我们看一下Webinar.BO.ToMPI类，并解释它如何从 FHIR 获取消息并将其转换为我们将发送到 EMPI 生产的字符串： Include HS.FHIRServer Class Webinar.BO.ToMPI Extends Ens.BusinessOperation { Parameter ADAPTER = "EnsLib.TCP.CountedOutboundAdapter" ; Property Adapter As EnsLib.TCP.CountedOutboundAdapter ; Parameter INVOCATION = "Queue" ; Parameter SETTINGS = "FHIRMetadataSet::selector?context={HS.FHIRServer.Util.ContextSearch/FHIRMetadataSets}" ; /// FHIR Metadata Set. These are defined in HS_FHIRServer.FHIRMetadataSet. Property FHIRMetadataSet As %String (MAXLEN = 256 ) ; Method SendFHIRRequest(pRequest As HS.FHIRServer.Interop.Request, Output pResponse As HS.FHIRServer.Interop.Response) As %Status { // Get version of FHIR message configured Set tFHIRMetadataSetKey = $ZStrip ( $Piece ( ..FHIRMetadataSet , "/" , 1 ), "<>W" ) // We can have our FHIR message saved as a QuickStream or a Dynamic Object inside the json property of the request If pRequest.QuickStreamId'= "" { // Recover QuickStream of the FHIR message Set tQuickStream = ##class (HS.SDA3.QuickStream). %OpenId (pRequest.QuickStreamId) // Checking if message is in JSON format or XML If pRequest.Request.RequestFormatCode'= "" { Set tFHIRFormat = pRequest.Request.RequestFormatCode } Else { $$$ThrowOnError ( ##class (HS.HC.Util).GetFormatFromData(tQuickStream, .tFHIRFormat)) Do tQuickStream.Rewind() If tFHIRFormat= "json" { Set tFHIRFormat = $$$FHIRContentCodeJSON } ElseIf tFHIRFormat= "xml" { Set tFHIRFormat = $$$FHIRContentCodeXML } } // Transform QuickStream to DynamicObject Set tDynObj = ..GetDynObj (tQuickStream, tFHIRMetadataSetKey, tFHIRFormat) } ElseIf (( $IsObject (pRequest.Request.Json))&&(pRequest.Request.Json. %GetIterator (). %GetNext ())) { // Could have Json %DynamicObject if this host is called InProc. Set tDynObj = ..GetDynObj (pRequest.Request.Json, tFHIRMetadataSetKey) } Else { $$$ThrowStatus ( $$$ERROR ( $$$GeneralError , "FHIR interop request message missing FHIR content" )) } // Transform Dynamic Object to string set tRequest = tDynObj. %ToJSON () // Send message to EMPI production Set tSC= ..Adapter .SendMessageString(tRequest,.tResponse) $$$ThrowOnError (pRequest.NewResponse(.pResponse)) //Set pResponse.Response = ##class(HS.FHIRServer.API.Data.Response).%New() Set pResponse.Response.ResponseFormatCode = pRequest.Request.ResponseFormatCode set pResponse.Response.Status = 200 set pResponse.ContentType = "text/plain" Quit tSC } ClassMethod GetDynObj(stream As %Stream.Object , fhirVersion As %String , fhirFormat As %String ) As %DynamicObject { set schema = ##class (HS.FHIRServer.Schema).LoadSchema(fhirVersion) if fhirFormat = $$$FHIRContentCodeJSON { set dynObj = {}. %FromJSON (stream) } elseif fhirFormat = $$$FHIRContentCodeXML { set dynObj = ##class (HS.FHIRServer.Util.XMLToJSON).XMLToJSON(stream, schema) } Quit dynObj } XData MessageMap { <MapItems> <MapItem MessageType= "HS.FHIRServer.Interop.Request" > <Method>SendFHIRRequest</Method> </MapItem> </MapItems> } } 让我们一步步分析我们的类： 第一点是了解我们将在业务运营选项中配置的 FHIR 消息的版本。 Set tFHIRMetadataSetKey = $ZStrip ( $Piece ( ..FHIRMetadataSet , "/" , 1 ), "<>W" ) 我们恢复正在处理的 FHIR 消息的类型，在我们的例子中它将是 R4。 接下来我们提取FHIR消息的内容： // We can have our FHIR message saved as a QuickStream or a Dynamic Object inside the json property of the request If pRequest.QuickStreamId'= "" { // Recover QuickStream of the FHIR message Set tQuickStream = ##class (HS.SDA3.QuickStream). %OpenId (pRequest.QuickStreamId) // Checking if message is in JSON format or XML If pRequest.Request.RequestFormatCode'= "" { Set tFHIRFormat = pRequest.Request.RequestFormatCode } Else { $$$ThrowOnError ( ##class (HS.HC.Util).GetFormatFromData(tQuickStream, .tFHIRFormat)) Do tQuickStream.Rewind() If tFHIRFormat= "json" { Set tFHIRFormat = $$$FHIRContentCodeJSON } ElseIf tFHIRFormat= "xml" { Set tFHIRFormat = $$$FHIRContentCodeXML } } // Transform QuickStream to DynamicObject Set tDynObj = ..GetDynObj (tQuickStream, tFHIRMetadataSetKey, tFHIRFormat) } ElseIf (( $IsObject (pRequest.Request.Json))&&(pRequest.Request.Json. %GetIterator (). %GetNext ())) { // Could have Json %DynamicObject if this host is called InProc. Set tDynObj = ..GetDynObj (pRequest.Request.Json, tFHIRMetadataSetKey) } Else { $$$ThrowStatus ( $$$ERROR ( $$$GeneralError , "FHIR interop request message missing FHIR content" )) } 我们从 FHIR 消息中获取 %DynamicObject： ClassMethod GetDynObj(stream As %Stream.Object , fhirVersion As %String , fhirFormat As %String ) As %DynamicObject { set schema = ##class (HS.FHIRServer.Schema).LoadSchema(fhirVersion) if fhirFormat = $$$FHIRContentCodeJSON { set dynObj = {}. %FromJSON (stream) } elseif fhirFormat = $$$FHIRContentCodeXML { set dynObj = ##class (HS.FHIRServer.Util.XMLToJSON).XMLToJSON(stream, schema) } Quit dynObj } 最后，我们将其转换为字符串，并通过 TCP 将其发送到我们的 EMPI 生产，向向我们发送原始消息的系统返回 200： // Transform Dynamic Object to string set tRequest = tDynObj. %ToJSON () // Send message to EMPI production Set tSC= ..Adapter .SendMessageString(tRequest,.tResponse) $$$ThrowOnError (pRequest.NewResponse(.pResponse)) //Set pResponse.Response = ##class(HS.FHIRServer.API.Data.Response).%New() Set pResponse.Response.ResponseFormatCode = pRequest.Request.ResponseFormatCode set pResponse.Response.Status = 200 set pResponse.ContentType = "text/plain" Quit tSC 好吧，我们已经将消息发送到我们的 EMPI 生产中。让我们看一下示例消息的跟踪： 在下一篇文章中，我们将检索提交的字符串，将其转换回 %DynamicObject 并向 EMPI 提供数据以使用新数据执行注册/更新操作。 希望这些内容对你有用！ 致敬原创作者 @Luis Angel

Hi 社区成员们！ 我们非常兴奋地推出一系列全新的公告，展示您在创意门户中所提交的创意的实施情况。通过这个系列，我们将聚焦那些已转化为现实世界解决方案的令人赞叹的想法。 我们的社区一直是创造力、创新和协作的重要中心，这正说明了我们拥有一批非凡的人才。通过这些公告，我们为那些从奇思妙想到代码诞生而庆祝欢呼。本系列中的每个公告都将展示 InterSystems 产品概念的建议想法，并让您亲身体验代码的神奇魅力。 第一批得到实施的创意是： 创意 创意实施者 Global->JSON->Global converter @Robert Cemper Introduce the project of helpful one-liners @Evgeny Shvarov Examples to work with IRIS from Django @Dmitry Maslennikov @Heloisa Paiva 3DES support @yurimarx Marx Include support for gRPC protocol in IRIS @Guillaume Rongier Create a UI for convenient and easy transfer of projects to other system instances for fast deployment. @Sergey Mikhailenko 在下面的投票中投票选出您希望首先展示的想法。 一如既往地欢迎您在评论中提出有关公告内容的建议！

# 第四章 HL7 架构和可用工具 - 查看数据结构 ## 查看数据结构 当单击“数据结构”列中的名称时，`InterSystems` 会显示该数据结构中的所有字段。这是 `HL7` 数据结构页面。显示的以下列是最有用的： - 组件列列出了可用于访问段内字段的数字。 - 属性名称列列出了可用于访问段内字段的名称。 - 单击“数据结构”列中的条目可深入了解详细信息。 - 单击“代码表”列（如果有）中的条目可查看可在此字段中输入的有效代码。 当单击上面段结构页面中名为 `2.3:XCN` 的数据结构项时，将出现以下示例页面。该页面指出类别 `2.3` 数据结构 `XCN` 描述“扩展复合 `ID` 号和名称”并由 `14` 个字段组成。其中，有些是简单值，有些是数据结构，有些是代码。 有了这些信息，就可以为消息结构 `2.3:ADT_A01` 中的复杂 `PR1grp().PR1:Surgeon` 字段创建虚拟属性路径，如下所示： ``` PR1grp().PR1:Surgeon.familyname PR1grp().PR1:Surgeon.degree ``` ## 查看代码表 当单击“代码表”列中的名称时，它会列出并解释该字段的有效代码。这是 `HL7` 代码表页面。当单击上一节中显示的数据结构页面中名为 `2.3:200` 的代码表项时，将出现以下示例页面。 上面的示例示出类别`2.3`代码表`200`描述可以具有值`L`、`O`、`M`、`A`、`C`或`D`的“名称类型”。 这意味着，如果有一条 `DocType` 为 `2.3:ADT_A01` 的 `HL7` 消息，则它具有一个可选虚拟属性，路径为 `PR1grp().PR1:Anesthesiograph.nametype`，可以包含以下值之一：`L`、`O`、`M`、 `A`、`C` 或 `D`。 ## 使用自定义架构编辑器 自定义架构编辑器允许创建新的自定义 `HL7` 架构或编辑现有的自定义 `HL7` 架构。通常，自定义模式具有基本模式，它是标准模式或其他自定义模式。当 `InterSystems` 产品使用自定义架构来解析消息时，如果自定义架构中未定义消息类型、段或其他元素，它将使用基本架构中的定义。因此，只需在自定义架构中定义基本架构中不存在的元素，或者需要与基本架构中的定义不同的元素。无法编辑标准架构。 定义自定义架构的最常见原因是能够解析带有尾部 `Z` 段的 `HL7` 消息。 `InterSystems` 产品可以处理带有架构中未定义的尾部 `Z` 段的消息，但要执行以下任一操作，需要定义自定义架构： - 访问路由规则、数据转换或 `ObjectScript` 代码中尾部 `Z` 段中的字段路径。 - 验证尾部 `Z` 段。 如果`production`当前正在使用标准模式，并且需要访问数据转换或路由规则中的尾部 `Z` 段字段路径，则应执行以下操作： 1. 使用管理门户中的自定义架构编辑器创建新的 `HL7` 架构。输入自定义架构的名称并指定基本架构。请参阅创建新的自定义架构。 2. 定义可以出现在消息中的 `Z` 段。如果 `Z` 段与基础架构中的现有段具有相似的字段，可以从基础复制定义，然后根据需要进行修改。否则，可以创建一个新段。可以添加字段、删除字段或更改字段的顺序。请参阅定义新段。 3. 对于包含尾随 `Z` 段的每个消息类型，在从基础架构复制的自定义架构中创建消息类型和结构类型。将 `Z` 段添加到结构类型的末尾。请参阅定义新消息类型和结构类型 4. 修改`production` 中的业务服务以使用新的自定义架构而不是基本架构。 5. **通过向`production`的业务服务提供带有尾部 `Z` 段的新消息来测试`production`。如果在消息查看器中查看消息，则 `Z` 段（如果它们在架构中定义）将显示为蓝色。无法识别的段显示为黑色。**

这里只讨论Caché和IRIS本身产生的错误和警告。用户在维护工作中通常会需要更多的内容， 那些我们在后面的 “系统性能指标”里介绍。另外， 关于集成平台的告警和日志， 也会在后面单独讨论。集成平台，也就是Ensemble Production，是IRIS系统上运行的应用，它的日志，告警，以及指标，测量，是单独的内容。 ### 控制台日志 控制台日志是系统运行状态的日志文件，在IRIS里是messages.log, 在Cache‘里的名字是console.log，默认放在安装目录的mgr子目录。 用户也可以在管理门户的"系统操作>系统日志>控制台日志"里查看。以下是一个实际的例子： ``` *** Recovery started at Fri Jan 03 16:26:05 2020 Current default directory: c:\intersystems\hsap\mgr Log file directory: c:\intersystems\hsap\mgr\ WIJ file spec: c:\intersystems\hsap\mgr\CACHE.WIJ Recovering local (c:\intersystems\hsap\mgr\CACHE.WIJ) image journal file... Starting WIJ recovery for 'c:\intersystems\hsap\mgr\CACHE.WIJ'. 0 blocks pending in this WIJ. Exiting with status 3 (Success) 01/03/20-16:26:43:627 (8108) 2 Failed to allocate 2880MB shared memory using large pages. Switching to small pages. 01/03/20-16:26:43:627 (8108) 0 Allocated 2880MB shared memory: 2048MB global buffers, 512MB routine buffers 01/03/20-16:26:43:627 (8108) 0 Intel Sandy Bridge AES-NI instructions detected. 01/03/20-16:26:43:731 (8108) 0 Jrn info from prior WIJ (imflags: 0): (Skip multiple records…) 01/04/20-00:00:00:804 (6900) 1 Warning: Alternate and primary journal directories are the same 01/04/20-00:00:00:820 (16272) 0 CACHE JOURNALING SYSTEM MESSAGE Journaling switched to: c:\intersystems\hsap\mgr\journal\20200104.001 01/04/20-10:15:41:703 (16096) 0 DELETE: c:\intersystems\hsap\mgr\journal\20191231.001 01/04/20-10:15:41:734 (12224) 0 Purging old application errors 01/05/20-00:00:00:497 (6900) 1 Warning: Alternate and primary journal directories are the same...(repeated 1 times) 01/05/20-00:00:00:528 (12472) 0 CACHE JOURNALING SYSTEM MESSAGE Journaling switched to: c:\intersystems\hsap\mgr\journal\20200105.001 01/05/20-00:00:01:653 (11436) 1 %SYS.Task.FeatureTracker failed to transfer data 01/05/20-18:18:34:726 (2260) 0 DELETE: c:\intersystems\hsap\mgr\journal\20200101.001 01/05/20-18:18:34:789 (14444) 0 Purging old application errors ``` 控制台日志的记录包括系统的启动停止记录，许可证的使用情况，各种底层资源，网络连接，数据库日志等等的所有内容。记录按严重程度四个等级，分别是 - 0: 一般性消息 (Information/Status) - 1: 警告性错误 (Warning) - 2: 严重错误 (Severe) - 3: 致命性错误 (Fatal) **除了等级为0的一般性消息，剩下的1，2，3个等级的记录都被称为错误**。错误的严重程度从1到3逐渐升高，其中2和3两个级别通常被称为严重错误(Serious Alert)。默认的配置下，它们会被写如另一个警告通知的日志Alert.log，以通知管理员。比如上面例子中的第9行 *“01/03/20-16:26:43:627 (8108) 2 Failed to allocate 2880MB shared memory using large pages. Switching to small pages.”*，就是一个Severe错误，应该被管理员马上知晓。 ### 错误是怎么来的 这里只说控制台日志中呈现的错误，也就是等级1-3的记录，它们的来源有： #### 系统底层直接产生的错误 系统底层产生的基本是严重错误 (Severe)和致命性错误 (Fatal)级别，这里给几个常见的例子，文章z > Write to journal file has failed > ECP client daemon/connection is hung > Failure during PIJ processing - Declaring a crash > Error reading block – recovery read error > Error writing block – recovery write error > ... 这里是[完整的列表的链接](https://docs.intersystems.com/iris20231/csp/docbook/DocBook.UI.Page.cls?KEY=GCM_monitor#GCM_monitor_errors) #### 系统监视器产生的错误 系统运行中默认的系统监视器(System Monitor)和健康监视器(Health Monitor)负责系统的监控工作。他们工作在%SYS命名空间，默认会随系统启动而启动，然后以30秒一次的频率读取系统指标，当指标达到并超过预置的门限值时会触发错误信息写入控制台日志， 级别是Warning(警告)或者严重错误 (Severe)。 > 这里只列出默认情况下什么样的指标会触发错误消息，而背后详细的技术细节会在 “Caché和IRIS的监控器”章节介绍。 **系统监视器产生的错误**针对系统的运行状态和资源，**产生告警的规则不可修改**。注意下图中Warning, Alert对应着Console log里的Waring级别和Severe或者fatal级别。 下表可以在最新版本的IRIS文档中的[这个链接](https://docs.intersystems.com/iris20231/csp/docbook/DocBook.UI.Page.cls?KEY=GCM_healthmon#GCM_healthmon_sysmon_alerts)找到。  #### 健康监视器产生的错误 Health Monitor是另一个评估内部产生的指标的监视器，也是工作在%sys命名空间。它和System Monitor的区别是: **用户可以修改评估的规则，设置适合自己的告警门限值。** Health Monitor默认不激活，因此需要人工启动。但是，如果你发现虽然你没有启动HealthMonitor， 但系统正按照它的规则发送通知，那也不用奇怪，那就是这个监视器的一部分规则不需要启动就自动工作。它的监控项目和规则如下图。 ``` Sensor Base Max Max M Warn Warn M ------ ---- --- ----- ---- ------ CPUPct 50 90 0 80 0 CPUusage 50 85 0 75 0 CSPActivity 100 0 2 0 1.6 CSPActualConnections 100 0 2 0 1.6 CSPGatewayLatency 1000 2000 0 1000 0 CSPInUseConnections 100 0 2 0 1.6 CSPPrivateConnections 100 0 2 0 1.6 CSPSessions 100 0 2 0 1.6 DBLatency 1000 3000 0 1000 0 DBReads 1024 0 2 0 1.6 DBWrites 1024 0 2 0 1.6 DiskPercentFull 50 99 0 95 0 ECPAppServerKBPerMinute 1024 0 2 0 1.6 ECPConnections 100 0 2 0 1.6 ECPDataServerKBPerMinute 1024 0 2 0 1.6 ECPLatency 1000 5000 0 3000 0 ECPTransOpenCount 100 0 2 0 1.6 ECPTransOpenSecsMax 60 0 2 0 1.6 GlobalRefsPerMin 1024 0 2 0 1.6 GlobalSetKillPerMin 1024 0 2 0 1.6 JournalEntriesPerMin 1024 0 2 0 1.6 JournalGrowthRate 1024 0 2 0 1.6 LicensePercentUsed 50 0 1.5 0 0 LicenseUsedRate 20 0 1.5 0 0 LockTablePercentFull 50 99 0 85 0 LogicalBlockRequestsPerMin 1024 0 2 0 1.6 MirrorDatabaseLatencyBytes 20000000 0 2 0 1.6 MirrorDatabaseLatencyFiles 3 0 2 0 1.6 MirrorDatabaseLatencyTime 1000 8000 0 4000 0 MirrorJournalLatencyBytes 20000000 0 2 0 1.6 MirrorJournalLatencyFiles 3 0 2 0 1.6 MirrorJournalLatencyTime 1000 5000 0 3000 0 PhysicalBlockReadsPerMin 1024 0 2 0 1.6 PhysicalBlockWritesPerMin 1024 0 2 0 1.6 ProcessCount 100 0 2 0 1.6 RoutineCommandsPerMin 1024 0 2 0 1.6 RoutineLoadsPerMin 1024 0 2 0 1.6 RoutineRefsPerMin 1024 0 2 0 1.6 SMHPercentFull 50 98 0 85 0 ShadowConnectionsLatency 1000 0 2 0 1.6 ShadowLatency 1000 0 2 0 1.6 TransOpenCount 100 0 2 0 1.6 TransOpenSecsMax 60 0 2 0 1.6 WDBuffers 1024 0 2 0 1.6 WDCycleTime 60 0 2 0 1.6 WDWIJTime 60 0 2 0 1.6 WDWriteSize 1024 0 2 0 1.6 ``` 表格很长，共列有47个sensor。大概的意思都可以从名字看出来，如果要阅读具体的定义，请看[原始文档](https://docs.intersystems.com/iris20231/csp/docbook/DocBook.UI.Page.cls?KEY=GCM_healthmon#GCM_healthmon_overview_api_sensors)。后面的几个字段，Base，Max，Max M，Warn，Warn M定义了这个sensor是怎么确定门限值的。 **第1类：固定的门限值** 也就是定义了Base, Max, Warning字段内容的条目，比如这个条目： ``` Sensor Base Max Max M Warn Warn M ------ ---- --- ----- ---- ------ CPUusage 50 85 0 75 0 ``` - 只要System Monitor已经启动，这个rule就工作，不需要Health Monitor处于激活状态。 - 只用max和warning值来决定是否超门限。连续3次读数超过了max值，产生alert, 连续5次读数超过了warning值，产生warning. 对于这些指标，系统允许用户自己设置告警的门限值，比如把上面CSPUsage的Warn, Max修改为80，90，或其他适合用户自己的数值。 **第2类：动态的门限值** 也就是定义了Base, Multiplier, WarningMultiplier字段内容的条目。例如下面的DBReads： ``` Sensor Base Max Max M Warn Warn M ------ ---- --- ----- ---- ------ DBReads 1024 0 2 0 1.6 ``` 统计学上， 均值(Mean)加3个Sigma是最常用的判断一个采样是否偏离太多的方法。因为是要设置门限值，这里添加了两个乘法系数(Multiplier), MAX M和Warn M，得到一个动态的门限值。当sensor的采样值比均值大的太多了，就会产生错误条目，warning或者alert. 具体的公式是： `产生错误的门限= Max((平均值+3*Sigma)*Multiplier，最大值+Sigma)` 因为大多数情况Max()中第一项的数值都是大的，所以公式可以翻译为：比（平均值+3个sigma)*Multiplier，就是告警的门限。 以上面例子中DBReads说明： Base= 1024, Multiplier=2；WarningMultplier=1.6。监视器开始运行时，会不停的计算这个时段内的平均值，最大值和sigma，产生一个Chart。假如某一刻平均值=2145, sigma=141，最大值为2327，那么根据上面的公式： `Warning门限 = Max((2145+3*141) * 1.6，2327+141) = 4108.8` `Alert门限 = Max((2145+3*141) * 2， 2327+141) = 5136` 也就是说，当您DBReads, 也就是数据库读的平均值是2145/s时，突然来了一个超过4109/s的业务，就会有一个错误信息写到控制台日志，严重级别是1, warning。短时间数据库查询再增加，超过alert门限，就会有严重级别为2的控制台日志被写入，同时这个条目也会写到alert.log文件，用来向管理员发通知。 可以看出，这个设置中base不重要，它只在监视器刚启动时有用，而使这个门限值有意义的是multipler的设置。 这要求用户对自己的业务很熟悉，而且经常的调整才能得到合适的设置，否则就可能在业务波动大的时候得到很多的错误信息，或者得不到自己想要记录的大的业务波动。 重要的一点： 拥有动态门限值的sensor默认是不工作的， 您想要激活Health Monitor。 是这么操作的： ``` %SYS>do ^%SYSMONMGR 1) Start/Stop System Monitor 2) Set System Monitor Options 3) Configure System Monitor Classes 4) View System Monitor State 5) Manage Application Monitor 6) Manage Health Monitor 7) View System Data 8) Exit Option? 6 1) Enable/Disable Health Monitor 2) View Alerts Records 3) Configure Health Monitor Classes 4) Set Health Monitor Options 5) Exit Option? 1 ...后面省略... ``` 用户还可以自定义了Chart，或者修改及自定义默认的14个监控时段(Period)，以得到更准确的错误产生的控制。有关这些内容请参见在线文档。 #### 上层应用产生的错误 上层的应用可以调用代码把它认为的错误写到控制台日志，而且可以任意定义级别。实际情况中，真正使用控制台日志来发送应用层面的错误的不多，如果您的系统中发现有， 那么一定能很清楚的把这部分错误条目和上述Caché , IRIS系统本身产生的区分出来。 ### 维护人员对错误的控制 维护人员对错误的控制最基本就是调整健康监视器的门限值。上面讲了两类门限值的理论，下面给出一个例子，显示是怎么修改固定门限值的设置的： ```bash %SYS>do ^%SYSMONMGR 1) Start/Stop System Monitor 2) Set System Monitor Options 3) Configure System Monitor Classes 4) View System Monitor State 5) Manage Application Monitor 6) Manage Health Monitor 7) View System Data 8) Exit Option? 6 1) Enable/Disable Health Monitor 2) View Alerts Records 3) Configure Health Monitor Classes 4) Set Health Monitor Options 5) Exit Option? 3 1) Activate/Deactivate Rules 2) Configure Periods 3) Configure Charts 4) Edit Sensor Objects 5) Reset Defaults 6) Exit Option? 4 1) List Sensor Objects 2) Edit Sensor Object 3) Exit Option? 1 Sensor Base Max Max M Warn Warn M ------ ---- --- ----- ---- ------ CPUPct 50 90 0 80 0 CPUusage 50 85 0 75 0 CSPActivity 100 0 2 0 1.6 CSPActualConnections 100 0 2 0 1.6 CSPGatewayLatency 1000 2000 0 1000 0 CSPInUseConnections 100 0 2 0 1.6 CSPPrivateConnections 100 0 2 0 1.6 CSPSessions 100 0 2 0 1.6 DBLatency 1000 3000 0 1000 0 DBReads 1024 0 2 0 1.6 DBWrites 1024 0 2 0 1.6 DiskPercentFull 50 99 0 95 0 ...(省略多行) WDWriteSize 1024 0 2 0 1.6 1) List Sensor Objects 2) Edit Sensor Object 3) Exit Option? 2 Sensor? 12 DiskPercentFull Base? 50 => Enter either an Alert Value or a Multiplier Alert Value? 99 => 90 Setting Max Multiplier and Warn Multiplier to 0. Enter a Warn Value Warn Value? 95 => 60 Sensor object DiskPercentFull updated. Base 50 MaxMult 0 AlertValue 90 WarnMult 0 WarnValue 60 1) List Sensor Objects 2) Edit Sensor Object 3) Exit ``` 上面的操作中有一个‘神秘数字’ 12. 怎么知道DiskPercentFull是第12个sensor? 我是从列表里数下来的。 注意在修改senosr会出提示要把System Monitor停掉。修改后再启动System Monitor, 这样如果您的硬盘使用超过了60%, 就会收到类似的控制台日志条目： > 12/12/18-15:32:37:349 (13700) 1 [SYSTEM MONITOR] DiskPercentFull(d:\htp\data\) Warning: DiskPercentFull = 74.52 ( Warnvalue is 60). **重复发生的错误会被再次写入控制台日志吗？** 除了最底层的，关乎系统整体运行的少数错误，大部分错误如果在一个小时内重复发生，只有第一次会被写入日志。这就要求用户必须有实时的通知机制， ### 控制台日志的管理 大多数用户不需要操心控制台日志的管理，少数很老的Caché的用户会拥有一个很大尺寸的console.log， 最大的曾见过80MB的文件，这时候从操作门户的页面去查看，已经出现了显示的延迟。 console.log或者messages.log的大小是由系统设置参数‘MaxConsoleLogSize’设定的。 在IRIS和最近些版本的Caché中， 这个设置的值是5MB(您可以在**操作门户的‘系统>设置>其它设置>启动**‘的列表里查看或者修改这个值。 如果一个控制台日志超过了5MB, 会自动切换， 原来的console.log, message.log，会改名为console.log.old.yyyymmdd, 或者message.log.old.yyyymmdd。

数据平台一直在进化：从数据中心到数据中台，离散的数据资产得到进一步梳理和整合、按业务封装数据和操作数据的方法，并逐步提供了企业统一的访问、更新、检索、查询等数据服务。 然而市场上不乏听到数据平台的成功案例，却鲜见这些案例得到大规模推广。原因是什么呢？ 一. 传统数据平台建设的挑战 传统数据平台的数据模型基于各自厂商的理解，缺乏统一行业数据模型和行业语义。可供参考的国内卫生信息数据元、数据集标准并非完整的行业语义，例如没有业务实体模型和数据元关系定义。传统的数据平台建设通常根据业务域，围绕数据应用需求组织数据。经常看到按业务域划分为CDR（临床数据中心）、ODR（运营数据中心）、RDR（科研数据中心）...... 这造成了几个挑战： 1. 按业务域、而非业务实体来划分数据，虽然方便相应的业务域数据分析，但跨业务域重叠的业务实体数据，例如患者，需要跨数据中心同步。这些同步由于数据模型上的差异，往往非全息拷贝。随着同步次数越多，跨数据中心的数据越失真，造成数据资产多源不统一、数据资产一致性问题和时效性问题。 2. 数据平台产品语义表达上参差不齐，业务用户依赖数据工程师对数据理解和操作，无论是统计分析还是机器学习，海量的实施工作无法满足业务敏捷性要求； 3. 数据平台及数据应用建设依赖单一厂商的能力，而建设成果，包括数据工具、分析指标和应用都无法跨数据平台复用。往往项目都在做低水平重复建设。 4. 数据互操作标准化程度低，数据的同步、迁移困难。在缺乏数据层互操作性的情况下，各类数据中心建设的依然是数据孤岛。 5. 由于数据中心往往忽视互操作建设，数据缺乏流动，进入数据平台后，往往成为死水一潭。 二. 如何应对挑战 如何解决这些数据平台建设困境？应该如何建设数据平台？ 数据资产不是仅为分析服务的，更重要的是作为生产要素在生产全过程中发挥价值- 这就涉及到数据生成、采集、交换、决策… 在这个全过程链条上的数据互操作能力尤为重要。 HIMSS将互操作定义为4级：基础级、结构级、语义级和组织级，并认为只有到达语义级，才是标准的、才能实现广泛的互操作能力。要达到语义级的互操作，需要进行五位一体的标准化：词汇/术语标准、内容标准、传输标准、隐私和安全标准、标识符标准。 随着我们越来越依赖于机器处理数据、发掘数据背后的知识，对数据资产的开放性和互操作性的要求达到了更高的水平 - 实现机器可以理解的互操作。2016年发表在Scientific Data针对科学数据管理和监管，提出了数据的可发现（Findable）、可访问（Accessible）、可互操作（Interoperable）、可复用（Reusable）的FAIR指导原则。 这些原则的核心是让机器可以理解数据所需的语义层面的要求，尤其是可互操作和可复用两部分提到的语义级要求 - 广泛使用的语言、词汇表、元数据引用、符合相关领域的社区标准... 大家都不约而同地指向了统一行业语义。传统数据中心面临的上述挑战，正是因为缺乏统一的行业语义、缺乏统一的语义级互操作。 那什么是统一语义？ 三. 统一语义数据平台 圣经记载人类曾经联合起来兴建能通往天堂的高塔 - 巴别塔、也称通天塔。上帝为了阻止人类的计划，让人类说不同的语言。人类相互之间不能沟通，造塔计划因此失败。 统一语言是数据能够互相理解、并利用数据的前提。 语言包含2个层面： 1. 语义：真实世界事物及其关系的表达方法。例如不同电子病历系统对疑似肺癌的记录，可能记录为以下三种之一： A。问题: 癌症 身体部位:肺 确定程度:疑似 B。问题: 肺癌 确定程度:疑似 C。问题: 疑似肺癌 这三种语义表达不统一。没有统一的语义就像图里的电源插座，每个国家规格都不同，是不可能互联互通的。 2. 语法：语言的结构规则，包括词法和句法。而词法和句法都可能有歧义，就像图中示例的那样。 行业数据需要通过统一语义达到互联互通。对数据而言，统一语义不仅在数据模型（语义）、也在数据使用方式（语法）上。不仅数据语义是统一的，操作/互操作数据的方法也是统一的，并且需要能避免词法和句法歧义，才能达到语义级互操作能力！ 是不是一定要统一语义？要看数据用途：对于特定的、简单的数据任务，简化的数据模型和数据处理方法可能已经足够，但对于复杂的、跨领域的数据任务，如广泛的自然语言处理、知识图谱构建、大规模机器学习等，统一语义是非常有价值的。 显然，对于数据平台这类多用途平台，应该统一数据语义。 四. 如何建设行业统一语义数据平台 数据平台建设向统一语义迈进，而统一的行业语义模型，应该针对行业用户友好：直观、完整、语义简单、没有二义性，易于数据探索与使用。 统一语义是指要统一物理数据模型和操作数据的语言吗？是要限定到特定的技术栈吗？ 先看一下数据库的结构化查询语言（SQL）：众多的关系型数据库、甚至很多非关系型数据库都支持ANSI SQL语言。SQL定义了自己的语义 - 表、字段、视图、存储过程... 和自己的语法 - 数据定义语言（DDL）、数据操作语言（DML），但它并没有定义任何数据的物理存储方案！也正因如此，任何数据库厂商、任何数据物理存储方案，都可以通过自己的SQL编译器来支持SQL和SQL客户端，从而屏蔽数据库物理层差异，使用相同的SQL语言共同建设SQL生态。这也是SQL生态壮大的原因之一。 SQL的成功告诉我们，统一行业语义是对行业数据的逻辑表达层的要求，它不应对任何数据库技术底层做要求，也就是不应限定任何技术栈。 前面提到统一的数据操作/互操作能力是统一语义的一部分，是要用单一的数据操作方法吗？数据有多种操作方式，每种操作方式都有自己适用的场景，如下： 对同一份数据提供多模型的操作能力，会极大提升语义层的操作/互操作的便捷性，是非常重要的统一语义特性。重要的是可以针对同一份语义数据进行多种模型的操作/互操作，而不是建立针对每种模型的多套语义，并进行数据复制。 也就是说统一语义，并不是数据只能有一种操作/互操作方式，而应提供对同一份统一语义数据的多种操作/互操作方式。 五. InterSystems统一语义数据平台建设 基于上面的建设思路，InterSystems的医疗信息统一语义平台通过对行业语义的理解和其智能数据编织能力，提供医疗信息数据基座。 5.1 行业语义选择 - FHIR 行业语义应具有开放性、成熟性、准确性、完整性、灵活性、简单性、非二义性、可互操作性、机器可理解，并被广泛接受与认可。纵观医疗信息行业，虽然有不少通用数据模型，但目前最满足上述条件的是HL7 FHIR。它的资源模型覆盖面广，不仅是临床、还包括管理、科研等；不仅包括通用数据模型 - FHIR资源模型，还有对其统一的互操作方法 - FHIR API；按80/20原则设计，允许对资源模型和API进行扩展；资源模型和API简单、并有详细的用例指南；FHIR资源模型、API、扩展都可以被计算机理解；FHIR拥有庞大的用例，并且其触角不断扩展到医疗信息应用的各个层面和各个方向。 另外，更重要的是，FHIR的定位就是行业语义标准 - 逻辑层的标准，任何厂商只需要提供自己的FHIR服务器，就可以利用任何技术栈发布统一的FHIR资源和FHIR API，而屏蔽底层不同类型的数据存储方案、数据模型和数据操作方法。因而它是一个强大的生态标准，所有厂商和用户都可以参与其中。 InterSystems的解决方案选择FHIR作为统一语义，在支持FHIR的6种互操作范式的基础上，提供对FHIR资源的SQL投射 - 无需数据拷贝，就可以使用SQL大规模查询FHIR资源，对统计分析、机器学习提供简单易用的数据操作能力。 5.2 利用数据编织技术，无需推倒重来 如果正在规划数据平台，应考虑按统一语义建设。如果已经建设有各类数据中心，并不需要将已有的建设成果推倒重来。InterSystems的解决方案通过数据编织技术，将数据源编织在一起，并建立逻辑上的统一语义层。原有数据中心和其各类应用继续运行，通过统一语义层来支撑新的数据利用和应用创新。 InterSystems利用数据编织技术，提供针对所有数据源、数据模型、互操作标准的接入能力和适配器。现有的数据中心被视为数据源，只需接入而无需推倒现有建设成果。 InterSystems的多模型能力，将这些离散的数据源统一转换、表达，将多数据源的数据，以FHIR资源这个统一语义模型，发布多种数据模型的数据服务：包括FHIR JSON模型、FHIR对象模型、FHIR SQL模型，满足多种应用场景对统一语义数据的最佳操作方式。 InterSystems数据引擎，为统一语义层提供高性能、横向可扩展的持久化层，满足不同规模的数据用户所需的性能和弹性。 InterSystems提供FHIR与互联互通、HL7 V2、CDA等通用模型的开箱即用的转换能力和对用户自定义模型的自定义转换能力，提供全方位的统一语义互操作能力。

# 第三章 HL7 架构和可用工具 - 使用 HL7 架构结构页面 ## 使用 HL7 架构结构页面 通过 `HL7` 架构页面，可以导入和查看 `HL7` 版本 `2` 架构规范。要显示此页面，请从主页中选择互操作性 > 互操作 > HL7 v2.x > HL7 v2.x 架构结构。有关使用此页面的一般信息，请参阅在产品中使用虚拟文档中的“使用架构结构页面”。 `HL7` 模式页面提供了一个附加选项卡：消息类型。此选项卡将两个消息结构标识为请求/响应对。 ## 查看文档类型列表 要列出某个类别中的所有文档类型结构，请首先选择该类别，然后单击“`DocType` 结构”选项卡。 ## 查看消息结构 要查看消息结构的内部组织，请从 `HL7` 架构页面上的 `DocType` 结构选项卡单击其名称（选择互操作性 > 互操作 > HL7 v2.x > HL7 v2.x 架构结构）。 `InterSystems` 产品使用以下视觉提示和命名约定在“结构”部分中显示消息的段结构。 - 组成消息结构的段按从上到下的顺序列出。 - 段名称必须全部大写。 - 显示每个消息段的三个字母名称：`MSH`、`NTE`、`PID` 等。该名称指示 `HL7` 消息结构中该位置存在的段类型。包含选项、重复或包含一组其他段的段的名称会在名称中附加特殊字符。 - 绿色虚线包围可选的段、组或字段。 - 可以重复的段在段名称后附加了括号。例如，如果`PID`段可以重复，则出现`PID()`。 - 包含其他段选择的段被视为段的联合。这些联合段的段名称后附加有“`union`”一词。只有联合中包含的段之一可以出现在消息结构内的该位置。 - 包含一组段的段在段名称后附加了字母“`grp`”。要展开或折叠组，请使用组名称旁边的箭头图标。 - 双击段名称可在单独的窗口中打开该段的结构。 ## 查看段结构 要查看消息段的结构，请在与上一节中显示的示例类似的任何页面中单击其名称。 `InterSystems` 产品显示一个表格，其中列出了该段中的所有字段。这是 `HL7` 架构段结构页面。 例如，如果单击 `2.3:ADT_A01` 消息结构中的 `PR1` 段，`InterSystems` 产品将显示以下页面。 各列如下： - `Field` 字段 — 用于访问段内字段的数字。 - `Description` 描述 — 字段的简短描述。 - `Property Name` 属性名称 — 用于访问段内字段的名称。 - `Data Structure` - 对于使用数据结构的更复杂的字段值，需要进一步的语法详细信息才能完成`segment:field` 虚拟属性路径。可以通过单击此列中的名称来获取此信息 - `Symbol` 符号——表示字段的语法规则。此列中的字符指示是否可以预期此字段在消息段中存在、不存在或重复。可能的值 Symbol |Meaning ---|--- `!`| (仅限`1`)该字段为必填字段；它只能出现一次。 `?`| (`0`或`1`)该字段是可选的，但如果发生，则可能只出现一次。 `+`| (`1`个或多个)该字段可以重复一次或多次。 `*`| (`0`或更多)该字段可以重复`0`次或多次。 `&`| 该字段可能存在，并且可能重复，但仅在某些条件下。 `n*`| `0` 到 `n`) 该字段最多重复 `n` 次。 - `Repeat Count` - 该字段可以重复的最大次数（如果重复，并且有最大值）。 - `Minimum Length` - 字段中的最小字符数。该字段的每次重复都必须包含此数量的字符。 - `Maximum Length` - 字段中的最大字符数。该字段的每次重复都可以包含此数量的字符。 - `Required` - 显示 `R` 表示必需，`O` 表示可选。 - `Repeating` - 显示 `1` 表示 `true`，`0` 表示 `false`。 - `Code Table` - 单击条目可查看可在此字段中输入的有效代码。 - `Alternate Description`替代描述 - 该领域的第二个更长的描述。 可以使用此信息（尤其是“属性名称”列）以“段：字段”格式构建虚拟属性路径。以下是涉及 `2.3:ADT_A01` 消息结构中 `PR1` 段的简单字段值的虚拟属性路径示例。 `()` 快捷语法指示重复字段的所有可用实例，而 `(1)` 指示第一个实例： ```java PR1grp().PR1:ProcedureType PR1grp().PR1:ProcedureCode() PR1grp().PR1:ProcedureCode(1) PR1grp().PR1:ProcedureCode(x) PR1grp().PR1:ProcedurePriority ```

大家好！ 我相信很多人都希望出席 2023 年全球峰会，但出于某种原因无法出席。以下是对 6 月 4 日和 5 日发生的事情的简要回顾。 尽管正式的开幕式要到周日晚上才会举行，但峰会前的活动还是很精彩的。亮点之一（特别是对于这里的体育爱好者而言）是早上的高尔夫锦标赛和足球（又名足球）比赛。不能说关于足球的任何事情，因为我不在场（如果你在场，请在评论部分发表评论和照片！），但据我所知，这是一场有趣的比赛。我可以告诉你关于高尔夫的事！ 比赛从早上 6 点开始，一直持续到下午 2 点左右。一开始天气阴沉，雨刚下完。但几个小时后，太阳出现了，防晒霜也随之出现。让我告诉你，50SPF 感觉不够！ 为了让它更有趣，当地的动物群决定也出去玩。 在宣布获奖者并享用午餐后，我们返回 The Diplomat Beach Hotel 参加其他活动。 例如，下午有一场女性活动。 这导致周日的主要活动 - 欢迎酒会！这是看到熟悉的面孔并与同事和朋友取得联系的最佳时机。 例如，英语社区的版主（@Muhammad.Waseem、@Dmitry.Maslennikov、@Irène.Mykhailova）： 和法语社区（@Lorenzo.Scalese、@Irène.Mykhailova、@Dmitry.Maslennikov、@Guillaume.Rongier7183）： 这是“准备”日。主要内容从周一开始！ Terry Ragon 开启了峰会，在他的演讲中提醒大家任何成功的公司都必须创新才能保持相关性。 InterSystems 就是这样的公司之一！ 此外，他祝贺大家 InterSystems 成立 45 周年和第 30 届全球峰会！这不是令人兴奋吗？不知道你怎么想，公司成立的时候我还没有出生呢！ 开场白之后，第一个主题演讲是关于医疗保健的。其中一点 @Donald.Woodlock 谈到了AI 以及它如何拉近开发人员与客户的距离，而不是相反。 在主题演讲（和午餐）之后，每个人都分散到不同的会议、演讲、会议等。我回到了 Tech Exchange 的开发者社区展位。 如果你在峰会上，别忘了顺路过来——我很乐意给你一些礼物作为简单行动的回报 😘 如果你认识一些还不是社区成员的人，鼓励他们过来也得到一些赃物。此外，请查看全球大师赛- 峰会期间可兑换一些奖励： 还有一些新的（和旧的最爱）奖励！有传言说，我们甚至很快就会有笔记本电脑贴纸！ 无论如何，在 DevCom 展位让我有机会与新朋友交谈，并结识其他有空的版主。 @Guillaume.Rongier7183 和@Dmitry.Maslennikov @Lorenzo.Scalese、@Dmitry.Maslennikov 和@Francisco.López1549 如果您对背景中的演示文稿感兴趣，请看这里。 此外，参加 Tech Exchange 意味着我可以关注那里正在进行的所有演示。例如，了解容器 😉 在所有这些兴奋之后，我们都去吃晚餐和演示。 玩游戏，玩得很开心。 这是 2023 年全球峰会的第一个官方日。敬请期待接下来的活动！