背景

作为集成平台厂商，在医院同其它系统联调的时候所做的事情中，多的不是开发代码而是查消息。我先演示一下目前我正在使用的IRIS查消息的方式：

例子1：

需要看【个人信息注册服务】

我只需要在框中输入【个人信息注册】回车

点击【查看消息】，显示的是消息里面的内容,如图所示：

点击【查看流程】，显示的是IRIS消息可视化的页面，如图所示：

例子2:

    需要查询患者ID为【2874621】这患者在集成平台调用了哪些服务

    我只需要选择下拉选择【患者ID】，然后输入【2874621】,回车

这个是我们以用户需求的角度直观的查询到指定的消息,IRIS也有这个功能—消息查看器，它是如何使用的呢？首先，我们得知道这条消息使用了哪些Production组件，其次我们需要了解这个消息使用的实体类的结构。比如同样查这个人的消息，我需要输入request.Body.PatientID=“2874621”，选择消息类。如果我需要查多个服务的我还需要多选消息类 …… 本文不是来介绍如何使用消息查看器的，各位大概知道就好。

程序分析与设计思路

    原始消息查看器的使用

我们先使用IRIS自带的【消息查看器】查患者ID为【2874621】个人信息注册服务，如图所示：

    选时间，输入图中所示的条件去检索。步骤上好像也挺简单的，但是这里有两个前提条件，一是我得知道每个服务对应的消息类是哪个。

在医院但凡接触“数据”和“指标”的人，对以下场景应该是深有感触。同样的指标、同样的时间，有可能是同一个部门出的，最后“数据不一致”。除了“匪夷所思”，更有“深恶痛绝”。那么，如何解决这个问题？我的答案是商业智能(BI)。随着技术和市场的发展，有很多公司开始研发直接面向业务用户的敏捷BI工具，FineBI就是这样的一款BI工具。这个也是我接触的第一款国产BI。

项目的前提条件和设置

50. 操作系统：Windows 64
50. IRIS产品：HealthConnect 2020
50. BI工具：FineBI
50. JDK: JDK1.8

FineBI、JDK、HealthConnect、FineBI的相关安装步骤网上有很多，在此就暂时略过。要在FineBI上创建仪表板，我们需要一点数据，在此我使用的是开发过程中的一些测试数据，相关测试数据和互联互通的69个交互服务息息相关，有需要可以自己模拟的造。

将FineBI和IRIS连接

       我们首先找到HealthConnect的安装文件，我们需要找到intersystems-jdbc-3.2.0.jar这样一个文件。

        关注FHIR的大侠们估计都注意到了，FHIR更新了它支持的互操作范式，除了消息、文档、服务、API这4种，增加了2个：资源仓库、订阅。前面4个好理解，为什么资源仓库和订阅会成为FHIR的新的互操作范式？互操作与应用集成是什么关系？

        这里借FHIR的新互操作范式，聊聊应用集成，看看集成平台是什么？有什么样的集成方案？以及怎么评价不同的方案。

应用集成技术是市场上被广泛使用的，也是充斥着术语和概念的一个技术领域。集成平台、消息引擎、消息中间件、集成引擎、集成中间件、企业服务总线(ESB)、API网关、API管理… 很多概念与名词。到底它们是什么意思？有什么区别？哪种技术适合解决哪种集成问题？

业务集成的需求和技术的演进是紧随业务系统的软件架构发展而发展的。通过小结软件架构的发展，我们更容易梳理业务集成技术的演进、更容易看清楚各种集成架构的优势和未来发展方向。

国务院于2022年12月19日发布了《中共中央 国务院关于构建数据基础制度更好发挥数据要素作用的意见》（后简称《数据二十条》），如何有效利用数据已经成为下一步的趋势。另一方面，无论是基于数据中台还是数据编织理念，两者也都对如何利用数据提出了构想。因此医疗行业数字化建设的目标已不能再局限于如何收集数据，建立医疗行业数据的流通机制将会是为越来越普遍的需求。

时钟拨回几年前，数据中台概念开始火爆。人们对数据中台的定义、诠释尽管有诸多差异，通过数据中台降低数据共享和利用的成本则是共同的期望。但经过这几年的探索之后，中台已死的观点也在涌现。究其原因，除去中台概念在技术上的不确定，数据流通过程中的责权益的不清晰也是严重的制约因素。毕竟，数据中台自身作为一套技术框架并不能代替法律法规与市场自动将数据转变为商品从而创造出流通价值。

那么，如何能够使数据的流通合规合法，使数据能够如货币和商品一般自由流动，则是我们需要思考和探索的主题，这次《数据二十条》的出现，无疑为医疗信息技术工作者提供了一个明确的思考方向。

各位领导、老师大家好。非常荣幸有机会参加这次由中国数字医学杂志社组织的陕西省医院数字化转型研讨会。

IT这个行业很有意思，就是大家都很喜欢造词。这几年有一个词特别火，叫做数智化底座，很多厂商都先后推出了自己的数智化底座解决方案。结合最近对整个行业的一些观察，今天借这个机会，跟各位领导和老师探讨一下，医疗行业的数字化有什么特点，到底什么样的底座或者平台比较符合我们医疗行业，以及我们在建设数智化底座的时候需要考虑哪些问题。结合我们最近的一些观察和思考，有不当之处，欢迎各位老师批评、指正。

首先一点就是我们做任何工作，首先要解决“为什么”的问题？第一个核心思路，我想数字化转型是为智慧医院服务的，归根结底，还是要通过数字化的手段，来实现医院的高质量发展。针对这一目标，国家卫健委制定了智慧医院发展的三大目标，就是智慧医疗、智慧管理和智慧服务，我想说白了，无非就是让医院、医护人员以及我们的患者过的更好，提高我们治疗和护理水平、降本增效，同时能够让我们的患者得到更好的服务。所有的数字化建设，不管是平台还是应用，都应该围绕这一核心目标。

第二个核心思路，我们认为软件要为人服务所谓的数字化转型，就是用软件来开展一切可以开展的业务，而软件是为人服务的，目的是提高我们的工作效率、认知水平和实现我们仅仅靠人力做不了的事情。

++ 更新：2018 年 8 月 1 日

使用内置于 Caché 数据库镜像的 InterSystems 虚拟 IP (VIP) 地址有一定的局限性。特别是，它只能在镜像成员驻留在同一网络子网时使用。当使用多个数据中心时，由于增加了网络复杂性（ 此处有更详细的讨论），网络子网通常不会“延伸”到物理数据中心之外。出于类似的原因，当数据库托管在云端时，虚拟 IP 通常无法使用。

负载均衡器（物理或虚拟）等网络流量管理设备可用于实现相同级别的透明度，为客户端应用程序或设备提供单一地址。网络流量管理器自动将客户端重定向到当前镜像主服务器的真实 IP 地址。自动化旨在满足灾难后 HA 故障转移和 DR 升级的需求。

简介

最近完成了针对IRIS医疗版2020.1版本的性能及可扩展性基准测试，重点关注HL7v2的互操作性。本文介绍了在各种工作负载下观察到的吞吐量，并提供了IRIS医疗版用作HL7v2消息传输互操作性引擎时的系统常规配置和调整准则。

基准测试模拟了与实际环境接近的工作负载（详细信息请参见“工作负载说明和方法”部分）。本次测试的工作负载包括HL7v2患者管理（ADT）和生命体征结果（ORU）数据，并包含数据内容转换和路由。

IRIS医疗版2020.1版本可以表明，采用第二代Intel®Xeon®可扩展处理器和Intel®Optane™SSD DC P4800X系列SSD存储的商用服务器，每天的持续消息吞吐量超过23亿条（入站和出站总量），与此前的Ensemble 2017.1 HL7v2吞吐量基准测试相比，扩展性提高了一倍多。

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

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

什么是 FHIR？

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

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

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

我们如何与 FHIR 合作？

一般来说，最简单的方式是拥有一个FHIR服务器，我们将使用诸如GET（从服务器获取数据）、PUT（更新数据）、POST（保存数据）和DELETE（删除数据）等HTTP调用与其通信。

FHIR处理了“资源”（Resource）的概念，用于在服务器和客户端之间发送和接收数据。这些资源旨在涵盖系统间80%的互通性需求。在这里，我们可以看到默认情况下可用的资源图示。

如您所见，每个资源都附带一个表示资源成熟度的数字或字母（其中N = 正式）。如果您访问官方的FHIR文档，您将能够获取到众多示例。

一. 企业信息库简介

企业信息库（MessageBank）是一个可选的远程归档设施，可以从多个来自不同实例的互操作性Production中收集信息、事件日志项目和搜索表项。如下图所示：

这套环境由两种角色的实例构成： 企业信息库服务器，它本身也是一个Production，完全由Message Bank服务组成，接收来自任何数量的客户Production提交的消息、日志等。

客户端Operation（Message Bank Operation），将其添加到一个正在运行的Production中，并用企业信息库服务器的地址进行配置。如连接通畅，消息和日志即可自动转发到Message Bank并在其中存储。

为了使你能方便地看到信息库中的信息，InterSystems IRIS®提供了以下附加选项。

对于企业信息库实例，管理门户自动包括企业监控器页面，在那里你可以监控客户端Production的状态，浏览消息库，并对被监控客户的消息进行检索。

对于每个客户端实例，你在消息库实例中配置一个到企业监控器的链接。

如下所示：

二. 常见应用场景

消息归档

在使用IRIS互操作性时，对于生产环境，为保障其有充足的磁盘空间和即时查询的效率，通常会采用消息和日志过期策略。在生产环境中只保留近期（如一个月）的信息以备回溯，过期数据将定期被清除。

我们继续使用FHIR适配器的示例，在本文中，我们将回顾如何在我们的IRIS实例中进行配置以及安装的结果。

配置项目的步骤与官方文档中所示的相同，您可以直接在此处查看。好吧，让我们开始工作吧！

安装

正如您在与本文相关的项目中看到的，我们将 IRIS 实例部署在 Docker 中，因此初始配置的主要部分将在 Dockerfile 中完成。别担心，我们不会详细介绍 Docker 配置。

要安装 FHIR 适配器，我们只需：

1. 在我们的 IRIS 实例中使用互操作性功能创建一个名为ADAPTER的命名空间。
2. 从 IRIS 终端访问我们的命名空间并执行以下命令。

 set##class"/Adapter/r4"

在我们的例子中，我们定义了将接收 REST 请求的 IRIS 端点的 URL 为/Adapter/r4 。

安装结果

FHIR 适配器安装完成后，我们可以查看 IRIS 实例中发生的情况。为此，我们首先查看 Web 应用程序菜单（系统管理 -> 安全 -> 应用程序 -> Web 应用程序）

正如我们所看到的，一个新的 Web 应用程序已添加到列表中，表明它对应于我们的 ADAPTER 命名空间。让我们访问它以更详细地查看其配置。

正如我们所看到的，创建的 Web 应用程序启用了 REST 调用的接收，并且负责管理这些调用的类是HS.

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

一. 在Message Bank中查询消息的特殊之处

大家如果使用过消息查看器，则能够了解IRIS自动持久化消息并提供界面让大家能够根据消息头中（如发生事件、来源、目标等）或消息体中（如患者姓名、诊断名称等消息的具体属性）来查询消息。 而在Message Bank上进行查询时，如果直接使用消息查看器，能够查询的是Message Bank的Production中传输的消息，而若不是在源系统中出现的消息，这一点一定不要混淆。

** 2018 年 2 月 12 日修订

虽然本文是关于 InterSystems IRIS 的，但它也适用于 Caché、Ensemble 和 HealthShare 发行版。

介绍

内存以页为单位进行管理。 Linux 系统上的默认页面大小为 4KB。 Red Hat Enterprise Linux 6、SUSE Linux Enterprise Server 11 和 Oracle Linux 6 引入了一种根据系统配置提供 2MB 或 1GB 大小的增加页面大小的方法，称为 HugePages。

起初 HugePages 需要在启动时分配，如果管理或计算不当可能会导致资源浪费。因此，各种 Linux 发行版引入了默认启用 2.6.38 内核的Transparent HugePages。这是一种自动创建、管理和使用 HugePages 的方法。以前的内核版本也可能具有此功能，但可能未标记为 [always] 而是设置为 [madvise]。

Transparent Huge Pages (THP) 是一种 Linux 内存管理系统，它通过使用更大的内存页面来减少在具有大量内存的机器上进行Translation Lookaside Buffer (TLB) 查找的开销。然而，在当前的 Linux 版本中，THP 只能映射单个进程的堆栈空间。

您的应用程序已部署，一切运行正常。 很好，击个掌！ 然后电话突然响个不停 – 用户投诉应用程序有时很“慢”。 这是什么意思？ 有时？ 您有哪些工具，查找和解决这个缓慢问题应查看哪些统计数据？ 您的系统基础架构是否能承担用户负载的任务？ 在投入生产之前，应该询问哪些基础架构设计问题？ 如何自信地为新硬件规划容量，而不会过度规定？ 如何停止电话铃声？ 如何一开始就不让它响？

    大家应该都已经很熟悉 InterSystems Ensemble（一个集成和应用程序开发平台），每个人都知道 Ensemble Workflow 子系统是什么以及它对于自动化人类交互的作用。 对于那些不了解 Ensemble Workflow 的人，我将简要介绍它的功能（已经熟悉的朋友可以直接跳过这一部分并学习如何使用 Angular.js 中的 Workflow 接口）。

InterSystems Ensemble

  InterSystems Ensemble 是一个集成和应用程序开发平台，旨在集成异构系统、自动化业务流程和创建新的复杂应用程序，这些应用程序通过新的业务逻辑或新的用户界面增强集成应用程序的功能：EAI、SOA、BPM、BAM 甚至 BI （感谢 InterSystems DeepSee：一种用于开发分析应用程序的内置技术）。

    Ensemble 具有以下关键功能：

    适配器：与应用程序、技术和数据源交互的组件。 Ensemble 提供技术和应用程序集成适配器（Web 和 REST 服务、文件、FTP、电子邮件、SQL、EDI、HL7、SAP、Siebel、1S Enterprise 等）。 您可以使用适配器 SDK 创建自己的适配器。

    业务服务：将来自外部系统的数据转换为 Ensemble 消息并启动业务流程和/或业务运营的组件。

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

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

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

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

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

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

推荐一篇文章，南方医院HIS系统的更换与建设探索！

企业需要快速有效地扩展和管理其全球计算基础设施，同时优化和管理资本成本及支出。 Amazon Web Services (AWS) 和 Elastic Compute Cloud (EC2) 计算和存储服务提供高度稳健的全球化的计算基础设施，可满足最苛刻的基于 Caché 的应用程序的需求。Amazon EC2 基础设施使各公司能够迅速预置计算能力和/或快速灵活地将其现有内部基础架构扩展到云端。 AWS 针对安全、网络、计算和存储提供了一套丰富的服务和强大的企业级机制。

AWS 的核心是 Amazon EC2。 它是支持各种操作系统和机器配置（例如 CPU、RAM、网络）的云计算基础设施。 AWS 提供预先配置的虚拟机 (VM) 映像（称为 Amazon 系统映像或 AMI），客户操作系统包括各种 Linux® 和 Windows 发行版及版本。 可以将其它软件用作 AWS 中运行的虚拟化实例的基础。 您可以将这些 AMI 用作实例化以及安装或配置其他软件、数据等的起点，以创建特定于应用程序或工作负载的 AMI。 

与任何平台或部署模式一样，必须留心以确保考虑到应用程序环境的各个方面，例如性能、可用性、操作和管理程序。 

本文将详细介绍以下每个方面。

• 网络设置和配置。

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

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

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

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

InterSystems IRIS 2021.1 的发布引入了自适应分析(Adaptive Analytics)的介绍。 为了开始使用和熟悉 InterSystems IRIS BI cube示例，我们创建了一个用于自适应分析的 HoleFoods 应用程序示例模版。 此示例应用程序可在 Open Exchange 上获得， 还有一个学习服务课程learning services course 可用于了解有关自适应分析的更多信息。

Google Cloud Platform (GCP) 为基础架构即服务 (IaaS) 提供功能丰富的环境，其作为云提供完备的功能，支持所有的 InterSystems 产品，包括最新的 InterSystems IRIS 数据平台。 与任何平台或部署模型一样，必须留心以确保考虑到环境的各个方面，例如性能、可用性、操作和管理程序。 本文将详细阐述所有这些方面。

供应商或内部团队要求说明如何为 VMware vSphere 上运行的_大型生产数据库_进行 CPU 容量规划。

总的来说，在调整大型生产数据库的 CPU 规模时，有几个简单的最佳做法可以遵循：

• 为每个物理 CPU 核心规划一个 vCPU。
• 考虑 NUMA 并按理想情况调整虚拟机规模，以使 CPU 和内存对于 NUMA 节点是本地的。
• 合理调整虚拟机规模。 仅在需要时才添加 vCPU。

通常，这会引出几个常见问题：

• 由于使用超线程技术，VMware 创建的虚拟机的 CPU 数量可以是物理 CPU 数量的两倍。 那不就是双倍容量吗？ 创建的虚拟机不应该有尽可能多的 CPU 吗？
• 什么是 NUMA 节点？ 我应该在意 NUMA 吗？
• 虚拟机应该合理调整规模，但我如何知道什么时候合理？

我以下面的示例回答这些问题。 但也要记住，最佳做法并不是一成不变的。 有时需要做出妥协。 例如，大型生产数据库虚拟机很可能不适合 NUMA 节点，但我们会看到，其实是没问题的。 最佳做法是指必须针对应用程序和环境进行评估和验证的准则。

门为医疗行业打造，深度整合国内外医疗行业标准，专有技术服务医疗行业44年，可能是全球最早从事医疗信息化的公司；

耕细做打磨数十年的稳定、可靠、易用、可扩展的数据平台；

色鲜明，不唯技术、终生负责、以解决客户问题为核心的特色企业文化；

一代混合一体化架构，一个平台同时支持混合事务处理、传统架构、容器化、云原生等多种应用场景；

Intersystems IRIS 是开发、运行和消耗数据科学服务的绝佳平台。 IRIS 可以使用适配器从任何类型、格式、协议和时间提取数据。 这些数据集可以通过 BPL、DTL 和 Object Script 准备，并存储为 SQL 或 NoSQL 数据。 最后，它可以被 IRIS 内部的开放 ML 算法所消耗，并在 IRIS 仪表板中可视化。 了解详情：https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=PAGE_data_science。

Hello 家人们，

    InterSystems 学习网站有许多非常棒的课程。 因此，如果您想了解 InterSystems 并开始使用 InterSystems，希望这些资源可以帮到你：

什么是 Data Fabric？

“这是一套用于在公司中实施、管控、管理和执行数据操作的硬件基础架构、软件、工具和资源，功能包括跨所有数据存储平台的数据采集、转换、存储、分发、整合、复制、可用性、安全性、保护、灾难恢复、演示、分析、保存、保留、备份、恢复、归档、召回、删除、监视和容量规划，并可使应用程序的使用满足公司的数据需求”。 
(Alan McSweeney)

Data Fabric 是一种可利用包括多模型数据库、Analytics、AI、ESB/SOA、微服务和 API 管理在内的所有可用资源和技术创新来获取商业价值的新型数据操作方法。

2022年8月22日，中国 北京 —— 致力于帮助客户解决最关键的可扩展性、互操作性和速度问题的创新数据技术提供商InterSystems今日宣布在中国推出InterSystems IRIS医疗版互联互通套件2.0版，更好地满足用户对数据利用的需求。

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

#Open Exchange

您可能已经看到邀请分享您的 Open Exchange 应用程序的演示：Share a Demo of Your Open Exchange Application
它背后的服务——InterSystems Online Demo Server (ODS)——这不是什么新事物

作为奖励积分，我在 21 年 3 月的 InterSystems 开发者工具大赛：InterSystems Developer Tools Contest 中第一次看到它。
在后来的比赛中成为一个固定的奖励项目。实际是#24。
到今天，我们已经看到 OEX 中列出了 80 个可在 ODS 上使用的软件包：80 packages listed in OEX as available on ODS 

对我来说，开发人员的优势是显而易见的：

• 给予您的“客户”直接访问您产品的渠道。
  • 视频也是一个很好的推广工具。
  • 但是您知道使用自己的产品并没有那么令人印象深刻。
• 您的 Docker 容器是在“规范”安装中构建的。
  • 毫无疑问，Docker 是一个令人印象深刻的工具。
  • 在 Win、MAC 和 Linux 上有各种可能会让人头疼的版本。
  • 我跳过关于特殊功能和设置的个人赘述。
  • 您的“客户”可以节省时间来快速查看您提供的方案。
  • 您可以确定他会看到您计划让他看到的内容。