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

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

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

对于那些在某种程度上需要测试ECP的水平可扩展性（计算能力和/或用户和进程的并发性），但又懒得建立环境、配置服务器节点等的人来说，我刚刚在Open Exchange上发布了OPNEx-ECP部署的应用/示例。

关于 "智慧医院 "的真正内涵，有很多误解在流传。术语 "智慧Smart "已经成为 "自动化 "或 "数字设备 "的同义词。然而，事实是，增加技术、设备和传感器并不一定能使建筑或者医院变得'智慧'。而且，在某些情况下，数字创新被强加于医院，而没有真正考虑到其效果。

这种情况导致了一系列的复杂性和矛盾。例如，一方面，人们对医院采用数字技术的期望越来越高，但另一方面，人们越来越担心数字医疗解决方案正在创造更多离散的、孤岛的生态系统。同样，尽管医院面临着实现实时医疗系统的更大压力，但往往受制于其运营模式的孤岛性质或围绕各种医疗信息系统的互操作性问题。

这些相互冲突的压力表明，需要一种更协同、更集成、更综合、更全面的数字化转型方法--一种将系统整合在一起并从各个角度考虑影响的方法。

智慧医院数字孪生的出现，证明了这一技术为解决这些日益严峻的挑战提供了可行的手段。

在过去的几年里，数字孪生已经有了很大的发展，成为一项值得期待的技术。然而，尽管数字孪生被炒得沸沸扬扬，但对于数字孪生是什么（不是什么）以及它是否能实现其承诺，仍然存在相当大的困惑。像许多新技术一样，数字孪生正在 "幻觉破灭 "中挣扎并且在某些情况下被错误地描述。

在本文中，我们将通过回答这六个关键问题来正面解决这种困惑。

这是一个我开发的名为NiPaRobotica Pharmacy的小应用。 从附件可以看到一个界面，能够接收药房配药请求，并将订单上的行项目转换为发送给机器人的配药对话 。我在3家医院的药房部署了这个接口，其中两家药房有6个机器人被安排来将药物从分配槽配送到药剂师的窗口，每天能服务1200个病人。这些机器人能够将病人平均等待时间从2小时减少一半到1小时.接下来我把这个接口部署到专门为慢病病人建的6个配送点，例如如结核病、艾滋病毒、糖尿病、癫痫、高血压和哮喘等等。这个项目的目标是“把药物带给病人”。 这些点有六个6 ATM形式的药房配药设备 (Pharmacy Dispense Units ，PDU)，可以让病人直接与呼叫中心的药剂师沟通。在每个PDU 背后是一个存放上千种药物的大型的机器人。我的应用可以发送指令给机器人，机器人将药物分配到传送带上，送到一个打印机下面。这个打印机已经收到药房标签的内容，包括病人姓名、剂量说明和其他信息等。然后打印机把标签放下并贴在药品包装上。这包药再往前走一点就有一块海绵压住标签，使其更牢固地贴在包装上。然后，传送带将物品传送到PDU中的一个盒子里，一旦所有药物都被分发出去，病人就能打开PDU上的一个盖子，取出他的药品。这个项目最重要的意义是让病人少跑腿，不需要请假，还要长途跋涉到他们平时看病的医院，再取药回家。

以下步骤展示如何显示 /api/monitor 服务提供的指标列表示例。

在上个帖子中，我概述了以 Prometheus 格式显示 IRIS 指标的服务。 该贴介绍了如何在容器中设置和运行 IRIS 预览版 2019.4，然后列出了指标。

本帖假定您已安装 Docker。 如果未安装，现在就为您的平台安装吧 :)

步骤 1. 下载并运行 docker 形式的 IRIS 预览版

按照预览发行版的下载说明下载预览版许可证密钥和 IRIS Docker 映像。 例如，我选择了 InterSystems IRIS for Health 2019.4。

(ECP) Caché 出色的可用性和扩展特性之一是企业缓存协议 (ECP)。 在应用程序开发过程中，如对使用 ECP 的分布式处理加以考虑，可以横向扩展 Caché 应用程序的架构。 应用程序处理可以调整为非常高的速率，处理能力从单个应用程序服务器扩展到最多 255 个应用程序服务器，并且不需要任何应用程序更改。

在我参与的 TrakCare 部署中，ECP 已广泛使用多年。 十年前，主要供应商之一的一台“大型”x86 服务器可能总共只有八个核心。 对于大型部署来说，ECP 是横向扩展商业服务器处理能力的方式，不适合单台昂贵的大型企业服务器。 即使是高核心数的企业服务器也有限制，因此 ECP 也用于扩展这些服务器上的部署。

如今，大多数的新 TrakCare 部署或升级到当前硬件不需要 ECP 即可扩展。 目前的双插槽 x86 生产服务器可以拥有数十个核心和巨大容量的内存。 我们看到，在最近的 Caché 版本中，TrakCare 以及许多其他 Caché 应用程序具有可预测的线性扩展能力，能够随着单台服务器中 CPU 核心数量和内存的增加而支持逐渐增多的用户和事务。 在现场，我看到大多数的新部署都是虚拟化的，即使如此，虚拟机也可以根据需要扩展到主机服务器的规模。 如果资源需求超过单个物理主机可以提供的资源，则使用 ECP 进行横向扩展。

InterSystems 数据平台包括了用于系统监视和警报的实用程序及工具，但对于不熟悉构建于 InterSystems 数据平台（又名 Caché）的解决方案的系统管理员来说，他们需要知道从何处下手以及需要配置什么。

本指南以在线文档和开发者社区帖子为参考，介绍了实现最低限度的监视和警报解决方案的途径，以及如何启用和配置以下组件：

这是一个系列的第一篇文章。我将使用bpmn符号提供细节，如何开发、部署、保护、运营和消费IRIS数字服务，并与IRIS文档相联系。每一个子流程都将用一个单独的bpmn图来描述。这就是宏观过程。

Documentation links:

作为一个软件架构师，如果要设计一个企业级的架构来满足当前的业务需求时，你需要达到5级的水平，这是一个巨大的挑战。有了InterSystems IRIS。
这是有可能的。通过1个产品，你可以得到SQL + NoSQL + ESB + BI + Open Analytics + Real Time Virtual cubes + NLP + AutoML + ML（使用Python）和高级云支持 + Sharding支持。

。之前我展示了如何运行 pButtons 来收集我们在下列帖子中研究的性能指标。

• 第 1 部分 - 入门：收集指标。
• 第 2 部分 - 研究收集的指标。

更新：2020 年 5 月。

在上一篇文章《互操作消息统一管理系列：Message Bank》中，我们了解到在Message Bank中，消息均以半结构化（XML）或非结构化（Stream）的形式保存，因此无法与客户端的结构化消息一样，直接支持基于索引的检索。为此，需要在Message Bank中定义Search Table以支持查询。关于Search Table的定义和作用，请查阅https://docs.intersystems.com/healthconnectlatest/csp/docbook/DocBook.UI...。

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

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

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

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

InterSystems 数据平台和性能 - 第 5 部分 使用 SNMP 进行监控

在之前的帖子中，我展示了如何使用 pButtons 收集历史性能指标。 我首选 pButtons 是因为我知道它随每个数据平台实例（Ensemble、Caché、...）一起安装。 不过，还有其他方法可以实时收集、处理和显示 Caché 性能指标，以进行简单的监视，或进行更重要的并且复杂得多的运营分析和容量计划。 最常见的数据收集方法之一是使用 SNMP（简单网络管理协议）。

SNMP 是 Caché 向各种管理工具提供管理和监控信息的标准方式。 Caché 在线文档包含了 Caché 和 SNMP 之间接口的详细信息。 虽然 SNMP 应该可以直接与 Caché 配合工作，但仍有一些配置技巧和陷阱。 我经历了很多次错误的开始，并且在 InterSystems 其他同事的帮助下，才让 Caché 与操作系统 SNMP 主代理建立对话，所以我写了这篇帖子，希望您可以避免同样的痛苦。

在本帖中，我将介绍如何为 Red Hat Linux 上的 Caché 设置和配置 SNMP，您应该能够对其他 *nix 版本使用相同步骤。 我使用 Red Hat 写这篇文章是因为在 Linux 上进行设置更棘手一些；在 Windows 上，Caché 会自动安装一个 DLL 来与标准 Windows SNMP 服务连接，所以应该更容易配置。

本周，我将关注 CPU - 主要硬件食物群之一 :) 一位客户请我就以下情况提供建议：他们的生产服务器已接近使用寿命终止，是时候更新硬件了。 他们还考虑通过虚拟化来整合服务器，并希望适当调整裸机或虚拟机的容量规模。 今天我们将关注 CPU，在后面的帖子中，我将介绍适当调整其他主要食物群（内存和 IO）规模的方法。

所以问题是：

• 如何将五年多以前对处理器的应用要求转换成针对当今的处理器？
• 目前的处理器有哪些是合适的？
• 虚拟化如何影响 CPU 容量计划？