我们为什么要关注医疗领域的数字孪生？

环顾四周，你会看到无数的设备监测和收集我们身体状态数据的例子。可穿戴智能手表和健身追踪器、医疗成像设备、数字健康应用程序、温度计等。同样，这些设备本身也在产生关于其当前运行环境和状况的大量数据。但是，我们如何才能理解所有这些数据，并从中获得有意义的洞察？一种可能性是对这些数据进行动态展示，即所谓的数字孪生。

数字孪生是一个物理对象或系统在其生命周期内的虚拟表达。这意味着，数字孪生包含了关于其现实世界对应物状态的最新和历史数据。将这些动态数据纳入不同医疗应用的虚拟表示中，可以实现主动决策、流程优化和医疗领域的完整生命周期管理。

根据日期范围查询的SQL性能让你失望？ 我有一个比较特别的技巧，可能会帮助你解决这个问题! (SQL开发人员讨厌这个!)*

如果你有一个类，在添加数据时记录时间戳，那么这些数据将与你的IDKEY值保持顺序--也就是说，当且仅当ID1<ID2时，表内所有ID和时间戳值的TimeStamp1<TimeStamp2--那么你可以利用这一知识来提高对时间戳范围的查询性能。 考虑一下下面这个表:

Class User.TSOrder extends %Persistent 
{ 

Property TS as %TimeStamp;

Property Data as %String (MAXLEN=100, MINLEN=200);

Index TSIdx on TS;

Index Extent [type=bitmap, extent];

}

用过去30天内的30,000,000条随机行来填充，每天将得到1,000,000条行。 现在，如果我们想查询某一天的信息，你可以这样写：

Caché Shadow

上次介绍了使用InterSystems IRIS/Caché的Reporting类型的异步镜像成员获取数据变更。但早期的Caché并不支持镜像，例如Caché 2008，它只支持Shadow。

在这些早期版本上是否也可以实利用Journal实现类似CDC的功能呢？答案是肯定的，就是利用Shadow服务器的Dejournaling filter routine (Dejournaling过滤器routine)。

Dejournaling filter routine

InterSystems Caché的 Dejournaling过滤器routine是一个用户自定义的routine，用于在Shadow服务器上过滤Journal记录。当配置了Dejournaling 过滤器后，Shadow服务器在redo journal前会自动调用Dejournaling过滤器routine。该routine传入参数以下：

InterSystems IRIS、IRIS for Health和HealthShare Health Connect的2021.1版本的预览版现已发布。

由于这是一个预览版，我们希望在下个月的通用版本发布之前了解您对这个新版本的体验。请通过开发者社区分享您的反馈，以便我们能够共同打造一个更好的产品。

InterSystems IRIS数据平台2021.1是一个扩展维护（EM）版本。自2020.1（上一个EM版本）以来，在持续交付（CD）版本中增加了许多重要的新功能和改进。请参考2020.2、2020.3和2020.4的发布说明，了解这些内容的概况。

这个版本的增强功能为开发人员提供了更大的自由度，可以用他们选择的语言构建快速和强大的应用程序，并使用户能够通过新的和更快的分析功能更有效地处理大量的信息。

第三章 SQL语言元素（一）

命令和关键字

InterSystems SQL命令（也称为SQL语句）以关键字开头，后跟一个或多个参数。其中一些参数可能是子句或函数，由它们自己的关键字标识。

所有源代码均在: https://github.com/antonum/ha-iris-k8s

医疗行业的互操作性在改善病人护理、降低医疗服务提供者的成本以及为提供者提供更准确的情况方面发挥着重要作用。然而，由于有这么多不同的系统，数据的格式也有很多不同的方式。有许多标准被创造出来以试图解决这个问题，包括HL7v2、HL7v3和CDA，但每一种都有其缺点。

FHIR，即快速医疗互操作性资源，是一种新的医疗数据格式，旨在解决这些问题。它是由国际卫生级七组织（HL7）开发的，该组织还开发了HL7v2、HL7v3和CDA。

今天我们将探讨如何在VS代码中借助IntelliSense和自动完成功能，通过使用FHIR Schema 创建和验证FHIR资源。

第 1 步 :从FHIR 官方网站 https://www.hl7.org/fhir/下载 JSON schema file 文件用来做资源校验

近来生成式大语言模型掀起了革命性的AI浪潮。生成式大语言模型是什么原理？我们怎么在业务中利用它？

一. 大语言模型的工作原理

生成式大语言模型是生成式人工智能底层的机器学习模型，是一种用于自然语言处理的深度学习模型。

人工智能、机器学习与大语言模型的关系如下图：

1.1 为什么我们称之为大语言模型？

大语言模型的“大”体现在多个方面：

作为一个12岁的书呆子，我最喜欢的书是斯蒂芬-皮尔写的《英雄失败之书》，这是一本关于人类不足之处的纪事。对我来说，这本书的亮点是佩德罗-卡罗莱纳的故事，一个努力开发葡语-英语短语手册的人。这是一项崇高的事业，但由于他缺乏说英语的能力，也没有一本葡英字典，因此受到阻碍。

然而，他确实拥有一本法英词典，一本葡法词典和一种真正能干的态度。他的劳动成果对葡萄牙度假者毫无益处，却让12岁的我笑得歇斯底里。我经常愉快地回忆起这个故事，但直到我开始工作时，我才开始把自己和卡洛琳娜先生进行比较。

我的工作是一名信息建模师。信息建模师的工作可以轻描淡写地概括为把现实变成可以存储在数据库中的东西。这是通过设计信息模型来完成的。在传统的软件设计中，有三种类型的信息模型。概念性、逻辑性和物理性。你从概念模型开始，它是对我们想要数字化的东西以及它们之间的关系的一个高级描述。然后你转到逻辑模型，描述这些对象如何在数据库中理想地创建。最后，你在物理模型中实现这一点，物理模型是由用户维护数据的数据库的实际实现。

"这是信息建模的传统智慧。但这种方法是否能实现目的有待商榷"。

这是信息建模的传统智慧。但这种方法是否能实现目的有待商榷。佩德罗的短语书的故事之所以有趣，是因为其方法明显不合适，而且客观上结果很差。这在语言学上相当于用叉子喝汤。但是，当主题比较模糊时，就很难推断方法是如何以及何时有缺陷的。

去年，AWS推出了基于ARM架构的AWS Graviton处理器第一代Amazon EC2 A1实例。在2019年AWS re:Invent 大会上，亚马逊宣布了第二代AWS Graviton2处理器和相关的Amazon EC2 M6g实例。相比前一代基于Intel Xeon的M5实例，Amazon EC2 M6g实例的性价比提升幅度高达40%。

在软件开发和业务集成中，规则无处不在：会员折扣的计算规则、根据消息类型和内容将其路由到不同目标系统的路由规则。还有一个规则发挥重要作用的地方- 辅助决策规则，例如临床知识库和医疗质量指标规则。

规则经常需要随业务调整和知识积累进行调整，而规则的调整是业务和行业专家定的。如果规则是以代码硬编码的，这些调整需要程序员改动，一来不直观、需要业务专家与程序员大量的沟通成本，二来硬编码改动会对应用伤筋动骨，甚至带来风险，三来没法控制新规则生效的时间 – 总不能让程序员在新规则生效的那一刻去编译和部署吧。

第十一章 发送和接收IBM WebSphere MQ消息

InterSystems IRIS为IBM WebSphere MQ提供了一个接口，可以使用该接口在InterSystems IRIS和IBM WebSphere MQ的消息队列之间交换消息。要使用此接口，必须能够访问IBM WebSphere MQ服务器，并且IBM WebSphere MQ客户端必须与InterSystems IRIS在同一台计算机上运行。

该接口由%Net.MQSend和%Net.MQRecv类组成，这两个类都是%Net.abstractMQ的子类。这些类使用由InterSystems IRIS在所有合适的平台上自动安装的动态链接库。(这是Windows上的MQInterface.dll；其他平台的文件扩展名不同。)。反过来，InterSystems IRIS动态链接库需要IBM WebSphere MQ动态链接库。

该界面仅支持发送和接收文本数据，不支持二进制数据。

本贴提供了在 VMware ESXi 5.5 及更高版本的环境中部署 Caché 2015 及更高版本时，关于配置、系统规模调整和容量规划等方面的指南。

我假定您已经了解 VMware vSphere 虚拟化平台，所以直接给出推荐。 本指南中的推荐不特定于任何具体硬件或站点特定的实现，也不应作为规划和配置 vSphere 部署的全面指南，而是一份您可以做出选择的最佳实践配置清单。 我希望您的 VMware 专家实施团队能针对具体站点对这些推荐进行评估。

这里是 InterSystems 数据平台和性能系列的其他帖子的列表。

注：本帖更新于 2017 年 1 月 3 日，强调必须为生产数据库实例设置虚拟机内存预留，以保证 Caché 有足够内存可用，并且不会出现内存交换或膨胀而对数据库性能产生负面影响。 更多详细信息，请参见下面的内存部分。

众说周知，EPIC 是电子病历厂商中当之无愧的领导者，本文让我们看看EPIC是如何玩转FHIR的，并进一步了解其互操作性方法、资源和API工具。

几十年来，EPIC和其他主要的EHR供应商一直在围绕着互操作性作斗争，有时候互相容忍，有时也得接受（开放接口）。

今天，大多数电子病历厂商已经针对市场和监管的压力采取了行动，采用FHIR API标准，扩大病人对医疗记录的访问。

但在早期，EPIC和其他竞争对手争先恐后地抢占市场份额，为了成为院内系统的主导者，与其他厂商分享数据、给别人提供数据访问似乎是自我毁灭。

那么今天，EPIC在FHIR API、SMART on FHIR 应用市场、患者访问和互操作性战略方面的立场如何？ 以下是关于EPIC在FHIR API和互操作性上提供的简单介绍和链接。

EPIC 在FHIR API和互操作性上的战略和资源

EPIC互操作性的方法和选择

大多数EPIC集成的重点是通过EPIC系统提供扩展访问，但不一定与其他厂商共享。