InterSystems 已更正导致在使用特定 $LIST 语法时引入无效数据库和日志记录的缺陷。 遇到此缺陷的可能性非常低，但它对操作的影响可能会很大。

受影响的产品

• InterSystems IRIS® 数据平台：2023.3、2024.1.0、2024.1.1、2024.1.2、2024.2、2024.3 版
• InterSystems IRIS® for Health：2023.3、2024.1.0、2024.1.1、2024.1.2、2024.2、2024.3 版
• HealthShare® Health Connect：2023.3.0、2024.1、2024.1.1、2024.1.2、2024.2、2024.3 版
• HealthShare® Unified Care Record and Suite：2024.2 版
• 基于上述产品的所有产品组合

该问题仅影响 Unicode 安装。

使用以下语法在 global 中向列表附加新元素时，会出现此问题：

SET $LIST(<global reference>, *+1) = value.

当此调用的结果列表超出最大字符串长度时，正确的行为是返回 <MAXSTRING> 错误。此错误会出现在 InterSystems IRIS、InterSystems IRIS for Health 和 Health Connect 2023.3 之前的版本中。 在 2023.3 及后续版本中，无效值会保存到数据库而不是生成 <MAXSTRING> 错误.

任何后续引用 global 节点的尝试都会导致出现 <MAXSTRING> 错误。

global 更新也会产生日志记录（假设对此 global 的更新通常都会记录）。任何尝试应用生成的日志记录（包括启动时恢复、日志恢复和镜像操作）都会失败并出现 <MAXSTRING> 错误，同时停止对日志文件的进一步处理。

如果此缺陷给您带来了影响，请联系全球响应中心 (WRC) 寻求帮助。

此缺陷的更正标识为 DP-437169 。在从 InterSystems IRIS、InterSystems IRIS for Health 和 Health Connect 2024.1.3 与 2025.1.0 开始的未来所有版本中，都将包含此更正。 您也可以通过临时分发获取。 HealthShare Unified Care Record 2025.1 版与产品套件会在发布时包含该更正，但在先前版本的维护版中将不包含该更正。 如果您对此提醒有任何疑问，请联系全球响应中心。

Hi 开发者们，

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

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

目的

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

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

安装

从 GitHub 下载 PerfTools.RanRead.xml 和 PerfTools.RanWrite.xml 工具 点击这里。

将工具导入 USER 命名空间。

USER> do $system.OBJ.Load("/tmp/PerfTools.RanRead.xml","ckf")

USER> do $system.OBJ.Load("/tmp/PerfTools.RanWrite.xml","ckf")

运行帮助方法以查看所有入口点。所有命令都在 USER 中运行。

USER> do ##class(PerfTools.RanRead).Help()

• do ##class(PerfTools.RanRead).Setup(Directory,DatabaseName,SizeGB,LogLevel) 创建具有相同名称的数据库和命名空间。日志级别必须在 0 到 3 的范围内，其中 0 是“无”，3 是“详细”。

• do ##class(PerfTools.RanRead).Run(Directory,Processes,Count,Mode) 运行随机读取 IO 测试。模式参数，1（默认）代表时间，以秒为单位 ，2是循环次数，用前面的 Count 参数控制。

• do ##class(PerfTools.RanRead).Stop() 终止所有后台作业。

• do ##class(PerfTools.RanRead).Reset() 删除先前运行的统计信息。在测试之间运行这个很重要，否则之前运行的统计数据将平均到当前运行的统计数据中。

• do ##class(PerfTools.RanRead).Purge(Directory) 删除同名的命名空间和数据库。

• do ##class(PerfTools.RanRead).Export(Directory) 将所有随机读取测试历史的摘要导出到逗号分隔的文本文件。

USER> do ##class(PerfTools.RanWrite).Help()

• do ##class(PerfTools.RanWrite).Setup(Directory,DatabaseName) 创建具有相同名称的数据库和命名空间。

• do ##class(PerfTools.RanWrite).Run(Directory,NumProcs,RunTime,HangTime,HangVariationPct,Global name length,Global node depth,Global subnode length) 运行随机写入 IO 测试。除目录外的所有参数都有默认值。

• do ##class(PerfTools.RanWrite).Stop() 终止所有后台作业。

• do ##class(PerfTools.RanWrite).Reset() 删除先前运行的统计信息。

• do ##class(PerfTools.RanWrite).Purge(Directory) 删除同名的命名空间和数据库。

• do ##class(PerfTools.RanWrite).Export(Directory) 将所有随机写入测试历史的摘要导出到逗号分隔的文本文件。

配置

创建一个名为 RAN 的空（预扩展）数据库，其大小至少是要测试的物理主机内存的两倍。同时确保这个空数据库至少是存储控制器缓存大小的四倍。数据库需要大于物理内存以确保读取的数据不会缓存在文件系统缓存中。您可以手动创建或使用以下方法自动创建命名空间和数据库。

USER> do ##class(PerfTools.RanRead).Setup("/ISC/tests/TMP","RAN",200,1)

Created directory /ISC/tests/TMP/  
Creating 200GB database in /ISC/tests/TMP/  
Database created in /ISC/tests/TMP/

注意：RanRead 和 RanWrite 可以使用相同的数据库。如果需要一次测试多个磁盘或用于特定目的，也可以使用分开的数据库。 RanRead 代码允许指定数据库的大小，但 RanWrite 代码不允许，因此最好使用 RanRead Setup 命令来创建所需的任何预先确定大小的数据库，即使要创建 RanWrite 做测试的数据库也可以。

方法论

从少量进程和 30-60 秒运行时间开始测试。然后增加进程数，例如从 10 个作业开始，然后增加 10、20、40 等。继续运行单个测试，直到响应时间始终超过 10 毫秒或计算出的 IOPS 不再以线性方式增加。

该工具使用 ObjectScript VIEW 命令读取内存中的数据库块，因此如果您没有获得预期的结果，则可能所有数据库块都已在内存中。

作为指南，全闪存阵列通常可以接受以下 8KB 和 64KB 数据库随机读取（非缓存）的响应时间：

• 平均 <= 2ms
• 不超过 <= 5ms

运行

对于 RanRead，执行 Run 方法，逐渐增加进程数并在运行时记录响应时间。 RanRead IOPS 的主要驱动因素是进程数。

USER> do ##class(PerfTools.RanRead).Run("/ISC/tests/TMP",5,60)

InterSystems Random Read IO Performance Tool  
--------------------------------------------  
RanRead process 11742 creating 5 worker processes in the background.  
  Prepped RanReadJob 11768 for parent 11742  
  Prepped RanReadJob 11769 for parent 11742  
  Prepped RanReadJob 11770 for parent 11742  
  Prepped RanReadJob 11771 for parent 11742  
  Prepped RanReadJob 11772 for parent 11742  
Starting 5 processes for RanRead job number 11742 now!  
To terminate run:  do ##class(PerfTools.RanRead).Stop()  
Waiting to finish...............................................................  
Random read background jobs finished for parent 11742  
RanRead job 11742's 5 processes (62.856814 seconds) average response time = 1.23ms  
Calculated IOPS for RanRead job 11742 = 4065 

Run 命令的 Mode 参数默认为模式 1，它使用 Count 参数（上例中的 60）作为秒。将 Mode 设置为 2 会将 Count 参数读取为每个进程的循环次数，因此如果将其设置为 100,000，则 5 个作业中的每一个进程都将从数据库中读取 100,000 次。模式2是该软件最初使用的模式，但定时运行允许与监控工具（例如^SystemPerformance）和 RanWrite 工具进行更精确的协调，因为这些工具也是定时运行的。

对于 RanWrite，执行 Run 方法，逐渐减少 Hangtime 参数。该参数代表每次写入之间的等待时间（以秒为单位），并且是 RanWrite IOPS 的主要驱动因素。您也可以增加进程数作为 IOPS 的驱动因素。

USER> do ##class(PerfTools.RanWrite).Run("/ISC/tests/TMP",1,60,.001)

RanWrite process 11742 creating 1 worker processes in the background.  
  Prepped RanWriteJob 12100 for parent 11742  
Starting 1 processes for RanWrite job number 11742 now!  
To terminate run:  do ##class(PerfTools.RanWrite).Stop()  
Waiting to finish...............................................................  
Random write background jobs finished for parent 11742  
RanWrite job 11742's 1 processes (60 seconds) had average response time = .912ms  
Calculated IOPS for RanWrite job 11742 = 1096 

RanWrite 的其他参数通常可以保留默认值（除了极特殊情况）。这些参数是：

• HangVariationPct：Hangtime参数的方差，用于模拟不确定性；它是Hangtime参数的百分比
• Global name length：RanWrite 随机选择一个Global名称，这个参数是该名称的长度。例如，如果它设置为 6，Global可能会是 Xr6opg
• Global node depth and Global subnode length：最上层的Global不是真正会填充数据的，实际填充的是它的子节点，因此将这些值设置为 2 和 4 将产生类似“set ^Xr6opg("drb7","xt8v") = [value]”的命令。这两个参数和 Global name length 的目的都是为了确保不会一遍又一遍地填充相同的Global，填充相同的Global会导致最少的 IO 事件。

为了能一起运行 RanRead 和 RanWrite，不要使用“do”命令。使用“job”命令在后台运行它们。

结果

为了获取保存在 USER命名空间 SQL 表 PerfTools.RanRead 和 PerfTools.RanWrite 中的每次测试运行的结果，请对每个工具使用Export命令，如下所示。

要将结果集导出到逗号分隔的文本文件 (csv)，请运行以下命令：

USER> do ##class(PerfTools.RanRead).Export("/ISC/tests/TMP/ ")

Exporting summary of all random read statistics to /usr/iris/db/zranread/PerfToolsRanRead_20221023-1408.txt  
Done.

分析

建议使用内置的 SystemPerformance 工具来获取被分析的系统的真实情况。 SystemPerformance 的命令需要在 %SYS 命名空间中运行。要切换到那个命名空间，请使用 ZN 命令：

USER> ZN "%SYS"

要查找系统瓶颈的详细信息，或者如果需要系统如何以目标 IOPS 运行的更多详细信息，则应创建具有高频率数据采集的 SystemPerformance 配置文件：

%SYS> set rc=$$addprofile^SystemPerformance("5minhighdef","A 5-minute run sampling every second",1,300)

然后运行该配置文件（从 %SYS）并立即切换回 USER 并使用“job”而不是“do”来启动 RanRead 和/或 RanWrite：

%SYS> set runid=$$run^SystemPerformance("5minhighdef")

%SYS> ZN “USER”

USER> job ##class(PerfTools.RanRead).Run("/ISC/tests/TMP",5,60)

USER> job ##class(PerfTools.RanWrite).Run("/ISC/tests/TMP",1,60,.001)

然后可以等待 SystemPerformance 作业结束，并使用 yaspe 等工具分析生成的 html 文件。

清理

运行完测试后，需要删除历史记录：

%SYS> do ##class(PerfTools.RanRead).Reset()

   TrakCare Lab是TrakCare产品中，属于检验科专用的系统，也就是LIS(Laboratory Information System)，LIS在实验室中主要处理检验科以下的作业：标本签收、采血管卷标打印、检验仪器联机、仪器结果接收、仪器数据判读、报告验证、危险值通知与警示等诸多作业，而TrakCare Lab也同时将各流程间的运作，串联得相当规律且正确，使得医检师们得以有条不紊的工作。

检验报告核发的正确性在于一开始的标本采集及采血管的正确使用，若一开始便贴错病患或是用错采血管，不仅会让检验报告张冠李戴外，错误的采血管亦会让检验数据有所偏差，导致医嘱错误，进而发生病安事件，故标本正确采集的重要性可想而知。

    门诊病患大部份是直接到检验科采检，在专业医检师及TrakCare Lab的签收检核机制及自动备管机的运用之下，出错率相当低。据临床上统计，贴错病患标签或采血管错误，来源多为住院或急诊，故降低检验科外部单位在采检上的错误率便成为开发护理站自动备管采检系统(NSAD)的主要目的。

    我们试着延伸TrakCare Lab的检核机制至医院的护理站，在与客户商讨后，决定同时从硬件及软件两方面双管齐下：

硬件方面：

在这篇文章中，我试图找出多个领域来开发我们能够使用python和机器学习的功能。

每家医院都在努力利用技术和服务来提高其服务质量和效率。

医疗保健部门是一个非常大的、可供选择的服务领域，而python是做机器学习的最好技术之一。

在每个医院里，人们都会有一些感觉，如果这种感觉能够被计算机理解，使用技术就有机会提供更好的服务。

在这里，我们可以把这两者结合起来，在医疗部门，我正试图理解/识别各种选择，以提供更好的服务。

首先，我们可以尝试使用python的机器学习来识别人并了解他们目前的感受。比如，在医院信息系统中，每个病人至少有一张照片，使用该照片我们可以识别病人，然后一旦病人到达医院，使用视频监控和机器学习技术需要识别这个人的感觉。

在医院设施中会看到多种类型的感觉。

1）紧张

2）平静和冷静

3)   哭泣

4)  暴力的病人/亲属

5)  生病的病人

6)  高烧鉴定

像上面的情况，我们可以看到多种不同的类型。

如果一个已经登记的病人发高烧，那么使用闭路电视识别这个病人的情况，并捕捉温度热像仪，护理人员可以给予更好的支持，这在接待服务领域是非常大的区别。

如果这个发高烧的人已经是一个登记的病人，如果利用现有的照片识别这个病人，那么我们可以做多件事情。

1)如果该病人今天有预约，我们可以自动到达该病人处。

“过敏”是生活中常见的病理表现，大众所熟知的荨麻疹、过敏性鼻炎、花粉症等都是常见的过敏性疾病。“过敏”在医学上归类为变态反应，是机体对外界有害物质（过敏原）的免疫应答，通常发挥保护作用。当变态反应过于激烈，以至于正常身体组织连同被攻击和损害时，则会对健康造成不利。本文将针对临床最为关心的医学信息系统如何支持“药物过敏”的识别、记录和管理进行探讨。

1. 详尽记录

因为变态反应的发生既取决于外因（过敏原），也取决于内因（遗传和基因缺陷），这就导致了不同的人暴露于不同的环境和接触不同的物质时，是否发生过敏反应以及过敏反应的表现和程度存在很大差异。及时、准确、详尽的过敏记录，可以为医务人员提供一手材料，从源头上遏制与“可避免的”药物过敏相关的医疗事件发生。

几乎所有医学信息系统都具备过敏记录功能，但部分系统仅提供自由文本录入。这种方式虽然给予医务人员极大的自由度，用自然的文字描述过敏相关信息，更贴合语言习惯；却带来了过敏信息难以复用、难以触发诊疗决策支持功能等弊端。

手术室是医疗机构最重要和最紧缺的医疗资源之一，也是节奏最快、强度最高、人员最密、责任最大的临床场景之一。传统基于人工和纸质的手术申请、手术排期、手术记录和交接转移等耗费了医务人员大量的时间和精力，导致手术室资源运用效率欠佳，且数据时限性与准确性均有待提高。医学信息系统问世和应用后，手术室系统的实施与优化一直是临床用户与医学信息工作者共同热议的话题。

手术室系统既可以作为整体医学信息系统的一部分，也可以作为单独的产品／模块与其他系统对接。鉴于手术室系统过于庞大和精细，本文只挑选其中的“临床记录表”功能进行探讨。

1. 化零为整– 临床记录表

手术过程中会产生诸多数据，这些数据可能来自于患者（生命体征、出入量等）、仪器（心电监护仪、呼吸机、麻醉机、、输液泵等）或者其他系统（电子病历系统、医嘱系统、耗材系统等），分别由不同角色（医生、护士、麻醉师、药剂师等）进行录入和传输。为了让手术核心参与人员方便的获取全部所需数据，手术室系统首先应该做到“化零为整”的前端展示。图1中的“临床记录表”大体分为4个部分：

①行动栏：医务人员通过行动栏中的行动项目，可以清晰的获知在当前场景下需要完成的工作内容，手术医生、麻醉医生、手术室护士等角色均可根据自己的职责和任务单独创建行动栏。

②搜索栏：医务人员通过搜索栏中的预设选项，可以自由切换数据类别，并根据临床需要，查看不同时间段的不同颗粒度的数据。

众所周知，医生和护士是临床一线最主要的决策者和执行者，二者的紧密衔接与顺畅合作是医疗质量和患者转归的重要决定因素。其中，医生更侧重于病例分析、诊断确认和方案制定，护士则在医嘱执行、任务管理和患者教育方面更胜一筹。将上述临床工作内容映射到医疗信息系统的使用时，我们不难发现，护士与系统的交互更为频繁、复杂和多样。因此，尽管本系列标注为“临床医生与信息系统”，本文则主要探讨如何应用便捷、清晰、高效、完整的系统功能给予护士更多支持。

本文将以“护士任务列表”为例，说明医学信息系统如何助力护士临床工作。这里要说明的是，此功能在已经实施移动护理、已经购买移动护理车或移动设备（包括平板电脑、手持机）的医疗机构，效果更为显著。

1. 总揽全局

在开始一天的护理工作前，护士需要对当日所管辖病区所有患者的医嘱进行回顾，以确保按时、按质完成；并在需要时，根据实际临床情况与主管医生商议，及时调整该患者的诊疗方案。如图1显示，护士可以通过“护士任务列表”页面的筛选栏，定位病区和日期，从而获得该病区、该时段所有患者的医嘱信息。所有医嘱应该按照预设分类（包括药品、护理、检验、检查、其他等），以醒目且直观的图标显示，且图标与患者信息和预期执行时间必须存在准确的对应关系。

图1 护士任务列表（按病区）

2. 细化任务

多学科协作诊疗（Multidisciplinary Team，MDT）是当今医学领域的重要医学模式之一，其主要目的在于：通过不同专业的医务人员共同参与、联合决策，针对特定患者和疾病，提供临床最佳、管理最细、资源最整、效率最高的诊疗方案。该模式起源于20世纪80年代，在欧美国家已运行多年，尤其在肿瘤和重症领域应用较为广泛和成熟。近些年，越来越多的中国医疗机构（包括公立和私立）也开始尝试和完善MDT。虽然在具体实施形式和细节角色流程上仍有争议，但是多数报道患者满意度和诊疗结果综合评分提升。因此，值得长期探索和实践。

本文以典型的MDT工作方案（图1）作为模版，阐述医学信息系统如何助力MDT的管理和运行。图中数字编号即为章节题目，将流程与系统功能结合，进行深入探讨。

图1 MDT工作方案

1. 开展MDT的必备资源

门诊医生工作站是帮助医生规范和高效的完成日常处方、病历书写、结果查询、会诊转诊等一系列诊疗行为的综合应用平台。该平台以电子病历为中心，内置常用模版和术语库；与医嘱系统、实验室系统、影像系统等相联通，为医生提供便捷、快速的辅助工具。

然而，日渐增长的患者数量、逐步扩大的职责范围和频繁添加的系统功能，都对医生的工作密度和强度造成影响。传统模式化的交互页面无法精准应对复杂多变的临床场景，且难以满足医生的个性化需求。

说到医院信息系统（EHR）的“个性化需求”，就不得不提到国际知名调研组织KLAS在2019年发布的The Arch Collaborative项目报告。该项目在179家已经部署EHR的医疗机构中，采取问卷和访谈的形式，通过对收集到的八万余份回复进行分析，得出如下结论：1）决定EHR应用功效的首要因素是医务人员（占所有因素的60%），2）决定医务人员EHR满意度的首要因素是可否满足个性化需求（占所有因素的32%）；3）医务人员EHR满意度高的医疗机构无一例外的开展了严格的用户培训、进行了充分的上线前交流、实施了细致的个性化配置；4）部分在上线初期医务人员EHR满意度较低的医疗机构，采纳上述改进方案后，满意度提升了80%以上。

提到临床医生与信息系统的交互，除外“病历书写”，恐怕最常见的临床场景就是“医嘱开具”了。医嘱是临床医生根据患者病史、体征、检验检查结果下达的医学指令，是医疗过程的重要环节和医疗质量的决定因素。在传统纸质医嘱时代，医生每天花费在医嘱开具、修改和确认等环节上的时间甚至接近于其与患者沟通的时间；且尽管上级医生、药剂师、护士等角色都会在不同阶段参与医嘱审核，依然难以避免医嘱差错的发生。因此，医学信息系统被广泛应用后，提升医嘱开具的便捷性和准确性成为其首当其冲的职责。那么，哪些系统功能是临床医生眼中的医嘱“助力神器”呢？

前言

着手书写“临床医生与信息系统的‘爱恨情愁’”系列文章的初衷是，希望从终端用户的视角阐述我们所期待的信息系统，为医学信息工作者提供参考，助力医学信息系统不断改进，最终迎来医疗品质的完美提升。在这个系列中，笔者会以临床常见疾病为例，用真实的临床场景说明亲身经历过的信息系统的优势和不足。其中肯定有思虑不周全或逻辑不严谨之处，望各位读者按需审阅，取其精华、弃其糟粕。同时，文中不涉及机构管理、收银财务、耗材库管等环节对临床工作的影响。此外，本系列更多在于探讨信息系统在临床应用场景中的“可能性”，而非“可行性”；文中部分图片尚处于设想模拟阶段，并非真实系统图片，请知悉。

正文

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

着手书写“数据应用方案分享”系列文章的初衷是，希望从终端用户的视角阐述我们所期待的数据应用方式及其可能为医疗领域带来的获益，为医学信息工作者提供参考。在这个系列中，笔者会以临床常见疾病和流程为例，用真实的数据录入、获取、展现和使用场景说明需求；尤其是如何细致、精准的构建数据源头，以确保现代医学信息技术“有数可用”、“数用必达”。其中肯定有思虑不周全或逻辑不严谨之处，望各位读者按需审阅，取其精华、弃其糟粕。此外，本系列更多在于探讨数据应用的“可能性”，而非“可行性”。文中部分图片尚处于设想模拟阶段，并非真实系统图片，请知悉。