Interoperability on Python (IoP) 是一个概念验证项目，旨在展示与 Python 优先方式相结合时 InterSystems IRIS Interoperability Framework 的强大功能。IoP 利用Embedded Python（嵌入式 Python，InterSystems IRIS 的一个功能）使开发者能够用 Python 编写互操作性组件，从而可以与强大的 IRIS 平台无缝集成。本指南专为初学者编写，全面介绍了 IoP、其设置以及创建第一个互操作性组件的操作步骤。 阅读完本文，您将能够清楚地了解如何使用 IoP 构建可扩缩、基于 Python 的互操作性解决方案。
您知道当您拿到验血结果时一切看起来都像天书的那种感觉吗？ 这就是 FHIRInsight 要解决的问题。 它最初的理念是，医疗数据不应该令人恐惧或困惑 – 它应该是我们所有人都能使用的东西。 验血是健康检查中十分常见的检查，但说实话，大多数人都很难理解它们，有时甚至对不擅长实验室工作的医务人员来说也是如此。 FHIRInsight 希望整个过程能够变得更简单，信息更富有实用价值。
这一切都始于一个简单而有力的问题：
“为什么验血结果仍然很难读懂 — 有时甚至对医生来说也是如此？”
如果您看过化验结果，您可能会看到一大堆数字、隐晦的缩写和“参考范围”，这些可能适用于您的年龄、性别或身体状况，也可能不适用。 毫无疑问，它是一种诊断工具，但如果没有背景信息，它就变成了一个猜谜游戏。 即使是经验丰富的医疗保健专业人员有时也需要交叉参考指导方针、研究论文或专家意见才能理解所有内容。
这正是 FHIRInsight 的用武之地。
我们不只是为患者而构建，也为一线医护人员而构建。 为轮流值班的医生，为捕捉生命体征细微变化的护士，为每一位试图在有限的时间和巨大的责任下做出正确决定的医护人员而构建。 我们的目标是让他们的工作简单一点，将密集的临床 FHIR 数据转化为清晰、有用、以真正的医学科学为基础的东西， 讲人类语言的东西。
FHIRInsight 不仅仅是解释化验结果。 它还：
想象一下，一位年轻的医生正在查看患者的贫血检查结果。 他们不需要在 Google 上搜索每一个异常值或翻阅医学期刊，而是收到一份报告，上面不仅总结了问题，还引用了最近的研究或世界卫生组织的指导方针来支持这一推理。 这就是将 AI 与针对精选研究的矢量搜索相结合的力量。
那患者呢？
他们再也不用盯着满屏的数字，猜想“胆红素 2.3 mg/dL”是什么意思，或者他们是否应该担心了。 他们会得到简单、周全的解释。 感觉更像是一场对话，而不是一份临床报告。 一些他们能真正理解的东西 — 并与他们的医生进行讨论，让人感觉更有准备，不那么焦虑。
因为这就是 FHIRInsight 的真正意义**：将复杂的医疗数据转化为清晰的见解**，帮助医疗保健专业人员和患者共同制定更好、更自信的决策。
当然，所有这些表面上的简单，背后可能由一些默默运行的强大技术提供支持。
以下是 FHIRInsight 的构建基础：
无论您是查看 30 个患者图表的医生，还是想要理解数字含义的患者，都可以在几秒钟内将原始的化验数据转化为可解释、富有实用价值的医学见解。
在后台，FHIRInsight 的 AI 赋能报告由 LiteLLM 驱动，后者是一个出色的抽象层，可以使我们通过一个 OpenAI 风格的界面调用 100 多个 LLM（OpenAI、Claude、Gemini、Ollama 等）。
但是要想将 LiteLLM 集成到 InterSystems IRIS 中，需要比隐藏在业务操作中的 Python 脚本更持久、更能重复使用的东西。 所以，我们创建了自己的 LiteLLM 适配器。
LiteLLMAdapter此适配器类可以处理您希望从一个强大的 LLM 集成中获得的所有东西：
prompt、model 和 temperature 等参数为了将其嵌入我们的互操作性生产中，我们将其包装在一个专门的业务操作中：
LLMModel 设置处理生产配置以下是简化的核心流程：
set response = ##class(dc.LLM.LiteLLMAdapter).CallLLM("Tell me about hemoglobin.", "openai/gpt-4o", 0.7)
write response
当我们开始构建 FHIRInsight 时，我们的使命很简单**：让验血结果对每个人来说都更容易理解**。 不仅仅是患者，还有医生、护士、护理人员… 任何曾经盯着化验结果苦思冥想的人，“好吧，这到底是什么意思？”
我们都有过这样的经历。
通过融合 FHIR 的结构、InterSystems IRIS 的速度、LLM 的智能，以及通过矢量搜索实现真实医学研究的深度，我们创造了一个可以将令人困惑的数字转化成有意义的叙述的工具。 帮助人们对自己的健康做出更明智的决定，甚至可能及早发现一些被忽视的疾病。
但 FHIRInsight 不仅仅与数据相关。 它还与我们查看数据时的感受相关。 我们希望它给人一种清晰、支持和赋能的感觉。 我们希望这种体验… 有点像**“氛围编程”医疗保健** — 在智能的代码、优秀的设计和人类同理心方面达到最佳平衡点。
我们希望您能尝试它，打破它，质疑它，并帮助我们改进它。
告诉我们您接下来想看到什么。 更多条件？ 更具可解释性？ 更加个性化？
这只是一个开端 — 我们希望您能帮助塑造它的未来。
“一根筷子易折断，十根筷子抱成团”，这句话在青岛大学附属医院（以下简称“青大附院”）的医院信息系统升级换代中得到了淋漓尽致的体现。
人工智能不仅限于通过带有说明的文本生成图像，或通过简单的指示创建叙事。
您还可以制作图片的变体，或为已有图片添加特殊背景。
此外，您还可以获得音频转录，无论其语言和说话者的语速如何。
让我们来分析一下文件管理是如何工作的。
InterSystems IRIS、Health Connect和上一代的Ensemble提供了优秀的互操作架构，但即便有低代码开发能力，很多开发者还是希望能用自己的技术栈语言在InterSystems的产品上开发互操作产品。
考虑到互操作产品本身的开放性要求和各个技术栈背后庞大的生态价值，InterSystems IRIS和Health Connect提供了Production EXtension (PEX)架构，让开发者使用自己的技术栈语言来开发互操作解决方案。目前PEX支持Java、.net、Python。
这里我们介绍使用Java利用PEX进行互操作产品的开发。
在进入PEX主题前，需要简单介绍一下Java在InterSystems IRIS上开发的各种技术选项，因为PEX也是以这些技术选项为基础的。
TCP作为OSI 7层的传输层的通信协议，其使用上不像更上层的通信协议那么方便，因为TCP操作的不是数据包，它操作的是数据流。因此有多种将TCP数据流“解释”为数据包（消息）的方法。
InterSystems IRIS提供了多种TCP适配器，用于不同的“解释”，例如EnsLib.TCP.FramedInboundAdapter使用特定的首尾字符做为分隔、EnsLib.TCP.CountedInboundAdapter使用固定的长度进行分隔...
同时，InterSystems IRIS提供了多种开箱即用的TCP业务服务和业务操作，方便接入和发送TCP数据。这里我们介绍常见的使用特定的首尾字符做为分隔的TCP业务服务和业务操作。
EnsLib.TCP.Framed.PassthroughService和EnsLib.TCP.Framed.PassthroughOperation是一组使用特定的首尾字符做为分隔TCP数据流的通用业务服务和业务操作。EnsLib.TCP.Framed.PassthroughService业务服务会将TCP数据封装在Ens.StreamContainer发送给业务流程或业务操作；而EnsLib.TCP.Framed.PassthroughOperation业务操作发送并接收Ens.StreamContainer类型的数据。
InterSystems IRIS 提供了一组通用的RESTful 业务服务和业务操作类，用户无需开发自定义的业务服务和业务操作类，就可以直接向外提供RESTful服务和调用外部的RESTful API。
| BS | EnsLib.REST.GenericService | 通用REST业务服务 |
| BS | EnsLib.REST.SAMLGenericService | 检查SAML令牌的签名和时间戳的REST业务服务 |
| BO | EnsLib.REST.GenericOperation | 通用REST业务操作 |
| BO | EnsLib.REST.GenericOperationInProc | 用于透传模式的通用REST业务操作 |
通用的RESTful 业务服务和业务操作类使用一个通用的RESTful消息类 - EnsLib.REST.GenericMessage，它是EnsLib.HTTP.GenericMessage的子类，二者数据结构都是
众所周知，人工智能的世界已经到来，每个人都想利用它为自己谋取利益。
有许多平台通过订阅或私人免费提供人工智能服务。然而，由于在计算领域产生的大量“噪音”而脱颖而出的是 Open AI，这主要归功于其最著名的服务：ChatGPT 和 DALL-E。
什么是Open AI？Open AI 是一个非营利性人工智能研究实验室，由 Sam Altman、Ilya Sutskever、Greg Brockman、Wojciech Zaremba、Elon Musk、John Schulman 和 Andrej Karpathy 于 2015 年发起，旨在促进和开发友好的人工智能，造福于人类所有的。
自成立以来，这些人已经发布了一些令人着迷的产品，如果用于良好的目的，可能会成为真正强大的工具。然而，与任何其他新技术一样，它们构成了可能被用来犯罪或作恶的威胁。
我决定测试 ChatGPT 服务，并询问它人工智能的定义是什么。我收到的答案是在互联网上找到的概念的积累，并以人类会回应的方式进行了总结。
简而言之，人工智能只能使用用于训练它的信息进行回复。利用其内部算法和训练期间输入的数据，它可以撰写文章、诗歌，甚至计算机代码片段。
人工智能将对这个行业产生重大影响，并最终彻底改变一切……。也许对人工智能将如何影响我们的未来的期望被夸大了，所以我们应该开始为了共同利益而正确地使用它。
- 设置 HTTP 服务
- 输入 FHIR 服务器的路径
- 输入 FHIR 服务的 URL
- 使用配置的凭证
测试 FHIR 客户端
跟踪测试结果
关于WebService接口采用适配器为
Parameter ADAPTER;
有方式可以获取到调用方的IP地址等信息吗？
调用 Web 服务的过程中，在期望的时间内未返回响应时，后续发生的情况由业务操作的几个设置来控制。（请注意，这也与非 SOAP 简单 HTTP 调用等有关）
3 个主要设置为：
指定从远程 Web 服务器获取响应的超时时间。
尝试与 Ensemble 之外的目标进行连接之间等待的秒数。
尝试与 Ensemble 之外的目标保持连接的总秒数。 经过此秒数时间后，业务操作将丢弃消息数据并返回错误代码。
归纳一下就是这样：
我们将等待 Web 服务器的响应，时间为“响应超时”所用的时间。 如果此时间过后未收到响应，我们将在“重试间隔”时间过后再次调用 Web 服务器。 如此继续尝试，直到时间（从第一次尝试算起）达到“故障超时”设置的时间秒数。
以下举例进行说明：
假定以下设置：
就是说：
响应超时 - 等待 7 秒以响应
重试间隔 - 每 10 秒重试一次
故障超时 – 30 秒后“放弃”重试
假定在 8 秒后返回响应，则情况如下：
以下是上述示例的调用“证据”。
首先是服务器端 [来自 SOAP 日志] – 可以看到，其收到了 4 次调用/请求，均相隔 10 秒，每次在请求发出 8 秒后返回一个响应：
现在，从 Ensemble BO/客户端，可以看到，有 4 次尝试，均相隔 10 秒，每次在 7 秒后记录响应超时错误。
客户端
以下是对 Ensemble 的可视化跟踪：
以下是事件日志条目：
以下为跟踪事件的日志示例[您可能需要放大以更好地读取文字]：
由此，可以看到上述示例的一些“内部运作”：
在日志行 ID #684，执行了首次调用 – 时间：17:09:16。
然后，在 7 秒之后 (09:23)，我们收到响应超时错误 (#685)。 然后，操作记录了此错误 (#687)，并确定等待 3 秒钟，直到达到重试间隔时间；10 秒重试间隔时间减去 7 秒响应超时时间 (#688-#690)。
经过 3 秒等待（ 09:26；＃691）之后，进行第 2 次尝试 (#692)，结果相同，继续重复操作，直到第 4 次尝试 (#704)。 在第 4 次尝试失败（09:53；＃705）之后，由于达到超时时间（30 秒），因此未进行另一次尝试。