我很清楚对于那些完全不熟悉 VS Code、Git、Docker、FHIR 和其他工具的人来说，设置环境时会遇到一些困难。 所以我决定写这篇文章，详细介绍整个设置过程，以便大家能够轻松上手。

如果您能在本文最后留下评论，告诉我说明是否清楚，是否有遗漏，或者是否有其他您觉得有用的东西，我将不胜感激。

设置包括：

✅ VS Code – 代码编辑器
✅ Git – 版本控制系统
✅ Docker – 运行 IRIS for Health Community 的实例
✅ VS Code REST 客户端扩展程序 – 用于运行 FHIR API 查询
✅ Python – 用于编写基于 FHIR 的脚本
✅ Jupyter Notebook – 用于 AI 和 FHIR 任务

准备工作：确保您在系统上拥有管理员权限。

除了阅读本指南，您还可以按照视频中的步骤操作：

如果您是 Windows 系统（请注意：原文是YouTube视频，请跳转至EN原帖查看）

Interoperability on Python (IoP) 是一个概念验证项目，旨在展示与 Python 优先方式相结合时 InterSystems IRIS Interoperability Framework 的强大功能。IoP 利用Embedded Python（嵌入式 Python，InterSystems IRIS 的一个功能）使开发者能够用 Python 编写互操作性组件，从而可以与强大的 IRIS 平台无缝集成。本指南专为初学者编写，全面介绍了 IoP、其设置以及创建第一个互操作性组件的操作步骤。 阅读完本文，您将能够清楚地了解如何使用 IoP 构建可扩缩、基于 Python 的互操作性解决方案。

学习如何使用 LangGraph 设计结合了推理、矢量搜索和工具集成的可扩缩自主 AI 智能体。

概括

• AI 智能体是一种超越简单的聊天机器人的自主系统，它结合了记忆库、上下文，并具有自动完成任务的主动性。
• LangGraph 是一种框架，它使我们能够利用具有内置状态管理的节点（任务）和边缘（连接），构建复杂的 AI 工作流。
• 本指南将指导您构建 AI 赋能的客户支持智能体，该智能体可以划分优先级，识别相关主题，并确定是上报还是自动回复。

那么，AI 智能体究竟是什么？

让我们直面它吧 —“AI 智能体”听起来就像可以接管会议室的机器人。 实际上，它们是您得力的助手，可以简化复杂的工作流，消除重复性任务。 您可以把它们看作是聊天机器人的下一个进化阶段：它们不只是简单地等待提示；它们可以发起行动，协调多个步骤，并随时进行调整。

过去，打造一个“智能”系统意味着兼顾语言理解、代码生成、数据查找等各种不同的模型，然后将它们粘合在一起。 您的一半时间花在了集成上，另一半时间则花在了调试上。

智能体彻底颠覆了这一切。 它们将上下文、主动性和适应性融合在一个精心编排的流程中。 它们不仅实现了自动化，更是肩负使命的智者。 借助 LangGraph 之类的框架，我相信，组建一支自己的智能体团队实际上会很有趣。

LangGraph 究竟是什么？

LangGraph 是一种创新型框架，它彻底改变了我们构建涉及大语言模型 (LLM) 的复杂应用程序的方式。

想象一下，您正在指挥一支管弦乐队：每种乐器（或“节点”）都需要知道何时演奏，声音有多大，顺序如何。 这种情况下，LangGraph 就是您的指挥棒，为您提供以下内容：

• 图结构：它采用具有节点和边缘的图结构，使开发者能够设计适应各种分支和循环的灵活非线性工作流。 它可以反映复杂的决策过程，类似于神经通路的运作方式。
• 状态管理：LangGraph 提供了各种内置工具，可以实现状态保持和错误恢复，简化了应用程序中各个阶段的上下文数据的维护。 借助 Zep 等工具，它可以在短期记忆和长期记忆之间高效切换，提高了交互质量。
• 工具集成：借助 LangGraph，LLM 智能体可以轻松与外部服务或数据库协作，获取真实的数据，从而改进应用程序的功能和响应性。
• 人机协同：除了可以实现自动化外，LangGraph 还可以适应工作流中的人为干预，这对于需要分析监督或伦理考虑的决策过程至关重要。

无论您是在构建具有真实记忆的聊天机器人、交互式故事引擎，还是能够处理复杂问题的智能体团队，LangGraph 都可以将令人头疼的管道工程转变成简单明了、直观的状态机。

开始

要开始使用 LangGraph，您需要进行基本的设置，通常包括安装 langgraph 和 langchain-openai 等必要的库。 然后，您可以定义图中的节点（任务）和边缘（连接），有效地实现短期记忆的检查点，并利用 Zep 满足更持久的记忆需求。

操作 LangGraph 时，请记住以下几点：

• 具有灵活性的设计：利用强大的图结构来解释并非严格线性的潜在工作流分支和交互。
• 以深思熟虑的方式与工具交互：利用外部工具增强 LLM 功能，而不是取而代之。 为每个工具提供全面的描述，以实现精确使用。
• 采用丰富的记忆解决方案：高效地使用记忆库，留意 LLM 的上下文窗口，并考虑集成外部解决方案，以实现自动事实管理。

现在，我们已经介绍 LangGraph 的基础知识，我们来看一个实例。 为此，我们将开发一个用于提供客户支持的 AI 智能体。

这个智能体将接收电子邮件请求，分析电子邮件正文中的问题描述，然后确定请求的优先级和适当的主题/类别/部门。

系好安全带，我们开始吧！

首先，我们需要定义什么是“工具”。 可以把它看作是智能体的专属“助理”，使其能够与外部功能进行交互。

@tool 装饰器在这里必不可少。 LangChain 简化了自定义工具的创建，这意味着首先，定义一个 Python 函数，然后应用 @tool 装饰器。

为了进行说明，我们来创建第一个工具。 这个工具将帮助智能体根据电子邮件内容划分 IT 支持工单的优先级：

    from langchain_core.tools import tool
    
    @tool
    def classify_priority(email_body: str) -> str:
        """Classify the priority of an IT support ticket based on email content."""
        prompt = ChatPromptTemplate.from_template(
            """Analyze this IT support email and classify its priority as High, Medium, or Low.
            
            High: System outages, security breaches, critical business functions down
            Medium: Non-critical issues affecting productivity, software problems
            Low: General questions, requests, minor issues
            
            Email: {email}
            
            Respond with only: High, Medium, or Low"""
        )
        chain = prompt | llm
        response = chain.invoke({"email": email_body})
        return response.content.strip()

太棒了！ 现在，我们有一个提示，指示 AI 接收电子邮件正文，对其进行分析，并将其优先级分为“高”、“中”或“低”。

就是这样！ 您刚刚编写了一个智能体可以调用的工具！

接下来，我们创建一个类似的工具来识别支持请求的主要主题（或类别）：

    @tool
    def identify_topic(email_body: str) -> str:
        """Identify the main topic/category of the IT support request."""
        prompt = ChatPromptTemplate.from_template(
            """Analyze this IT support email and identify the main topic category.
            
            Categories: password_reset, vpn, software_request, hardware, email, network, printer, other
            
            Email: {email}
            
            Respond with only the category name (lowercase with underscores)."""
        )
        chain = prompt | llm
        response = chain.invoke({"email": email_body})
        return response.content.strip()

现在，我们需要创建一个状态，在 LangGraph 中，这一小部分非常重要。

把它想象成图的中枢神经系统。 这就是节点之间的通信方式，就像优等生在课堂上传递纸条一样。

文档中显示：

“状态是表示应用程序当前快照的共享数据结构。”

在实践中呢？ 状态是在节点之间移动的结构化消息。 它将一个步骤的输出作为下一个步骤的输入。 基本上，它是将整个工作流粘合在一起的粘合剂。

因此，在构建图之前，我们必须先定义我们的状态结构。 本例中，我们的状态包括以下内容：

• 用户请求（电子邮件正文）
• 指定的优先级
• 确定的主题（类别）

它简单明了，因此您可以像专业人士一样浏览图。

    from typing import TypedDict

    # Define the state structure
    class TicketState(TypedDict):
        email_body: str
        priority: str
        topic: str
        
    
    # Initialize state
    initial_state = TicketState(
        email_body=email_body,
        priority="",
        topic=""
    )

节点与 边缘：LangGraph 的关键组成部分

LangGraph 的基本要素包括节点和边缘。

• 节点：它们是图中的操作单元，执行实际工作。 节点通常由可以执行任何逻辑（从计算到与语言模型 (LLM) 或外部集成交互）的 Python 代码组成。 从本质上讲，节点就像传统编程中的个别函数或智能体。
• 边缘：边缘定义节点之间的执行流，决定接下来会发生什么。 它们充当连接器，允许状态根据预定义条件从一个节点转换到另一个节点。 在 LangGraph 中，边缘在协调节点之间的序列和决策流方面至关重要。

为了掌握边缘的功能，我们来看一个消息传递应用程序的简单类比：

• 节点类似于积极参与对话的用户（或他们的设备）。
• 边缘代表着用户之间能够促进沟通的聊天主题或连接。

当用户选择一个聊天主题来发送消息时，会有效地创建一个边缘，将他们与另一个用户连接在一起。 与 LangGraph 状态的结构化模式类似，每次交互（无论是发送文本、语音还是视频消息）都遵循预定义的顺序。 它确保了沿边缘传递的数据的一致性和可解释性。

不同于事件驱动型应用程序的动态特性，LangGraph 采用在整个执行过程中保持一致的静态模式。 它简化了节点之间的通信，使开发者可以依赖稳定的状态格式，从而确保无缝的边缘通信。

设计基本工作流

可以将 LangGraph 中的流工程理解为设计一个状态机。 在这个情境中，每个节点代表一个不同的状态或处理步骤，而边缘定义了这些状态之间的转换。 这种方式对想要在 AI 的确定性任务序列与动态决策能力之间取得平衡的开发者特别有用。 我们来使用前面定义的 TicketState 类初始化 StateGraph，开始构建流程。

    from langgraph.graph import StateGraph, START, END
    
    workflow = StateGraph(TicketState)

节点添加：节点是基本要素，用于执行划分工单优先级或识别其主题等特定任务。

每个节点函数均接收当前状态，执行其操作，并返回一个字典以更新状态：

   def classify_priority_node(state: TicketState) -> TicketState:
        """Node to classify ticket priority."""
        priority = classify_priority.invoke({"email_body": state["email_body"]})
        return {"priority": priority}

    def identify_topic_node(state: TicketState) -> TicketState:
        """Node to identify ticket topic."""
        topic = identify_topic.invoke({"email_body": state["email_body"]})
        return {"topic": topic}
        
        
    workflow.add_node("classify_priority", classify_priority_node)
    workflow.add_node("identify_topic", identify_topic_node)

classify_priority_node 和 identify_topic_node 方法将更改 TicketState 并发送参数输入。

边缘创建：定义连接节点的边缘：

    workflow.add_edge(START, "classify_priority")
    workflow.add_edge("classify_priority", "identify_topic")
    workflow.add_edge("identify_topic", END)

classify_priority 确定起点，而 identify_topic 确定到目前为止工作流的终点。

编译与执行：配置节点和边缘后，编译并执行该工作流。

    graph = workflow.compile()
    result = graph.invoke(initial_state)

太好了！ 您还可以生成 LangGraph 流的可视化表示。

graph.get_graph().draw_mermaid_png(output_file_path="graph.png")

如果将代码运行到此点，您就会看到一个与下面类似的图：

这幅图直观地显示了一次顺序执行：开始，然后划分优先级，接着确定主题，最后结束。

LangGraph 最强大的一个方面是它的灵活性，这让我们可以创建更复杂的流程和应用程序。 例如，我们可以修改工作流，使用以下行将 START 中的边缘添加到两个节点：

    workflow.add_edge(START, "classify_priority")
    workflow.add_edge(START, "identify_topic")

这一更改意味着智能体将同时执行 classify_priority 和 identify_topic。

LangGraph 中另一个非常有用的功能是能够使用条件边缘。 它们允许工作流根据对当前状态的评估进行分支，实现任务的动态路由。

我们来增强工作流。 我们将创建一个新工具，分析请求的内容、优先级和主题，以确定它是否为需要上报（例如，为人工团队提交工单）的高优先级问题。 如果不需要，将为用户生成一个自动响应。

    @tool
    def make_escalation_decision(email_body: str, priority: str, topic: str) -> str:
        """Decide whether to auto-respond or escalate to IT team."""
        prompt = ChatPromptTemplate.from_template(
            """Based on this IT support ticket, decide whether to:
            - "auto_respond": Send an automated response for simple/common or medium priority issues
            - "escalate": Escalate to the IT team for complex/urgent issues
            
            Email: {email}
            Priority: {priority}
            Topic: {topic}
            
            Consider: High priority items usually require escalation, while complex technical issues necessitate human review.
            
            Respond with only: auto_respond or escalate"""
        )
        chain = prompt | llm
        response = chain.invoke({
            "email": email_body,
            "priority": priority,
            "topic": topic
        })
        return response.content.strip()
        

此外，如果请求被确定为低优先级或中等优先级（导致“auto_respond”决策），我们将执行矢量搜索来检索历史回答。 然后，将使用此信息来生成适当的自动回答。 不过，这需要两个额外的工具：

    @tool
    def retrieve_examples(email_body: str) -> str:
        """Retrieve relevant examples from past responses based on email_body."""
        try:
            examples = iris.cls(__name__).Retrieve(email_body)
            return examples if examples else "No relevant examples found."
        except:
            return "No relevant examples found."

    @tool
    def generate_reply(email_body: str, topic: str, examples: str) -> str:
        """Generate a suggested reply based on the email, topic, and RAG examples."""
        prompt = ChatPromptTemplate.from_template(
            """Generate a professional IT support response based on:
            
            Original Email: {email}
            Topic Category: {topic}
            Example Response: {examples}
            
            Create a helpful, professional response that addresses the user's concern.
            Keep it concise and actionable."""
        )
        chain = prompt | llm
        response = chain.invoke({
            "email": email_body,
            "topic": topic,
            "examples": examples
        })
        return response.content.strip()

现在，我们为这些新工具定义相应的节点：

    
    def decision_node(state: TicketState) -> TicketState:
        """Node to decide on escalation or auto-response."""
        decision = make_escalation_decision.invoke({
            "email_body": state["email_body"],
            "priority": state["priority"],
            "topic": state["topic"]
        })
        return {"decision": decision}
        
    
    def rag_node(state: TicketState) -> TicketState:
        """Node to retrieve relevant examples using RAG."""
        examples = retrieve_examples.invoke({"email_body": state["email_body"]})
        return {"rag_examples": examples}

    def generate_reply_node(state: TicketState) -> TicketState:
        """Node to generate suggested reply."""
        reply = generate_reply.invoke({
            "email_body": state["email_body"],
            "topic": state["topic"],
            "examples": state["rag_examples"]
        })
        return {"suggested_reply": reply}
        
    
    def execute_action_node(state: TicketState) -> TicketState:
        """Node to execute final action based on decision."""
        if state["decision"] == "escalate":
            action = f"🚨 ESCALATED TO IT TEAM\nPriority: {state['priority']}\nTopic: {state['topic']}\nTicket created in system."
            print(f"[SYSTEM] Escalating ticket to IT team - Priority: {state['priority']}, Topic: {state['topic']}")
        else:
            action = f"✅ AUTO-RESPONSE SENT\nReply: {state['suggested_reply']}\nTicket logged for tracking."
            print(f"[SYSTEM] Auto-response sent to user - Topic: {state['topic']}")
        
        return {"final_action": action}
        
        
        
    workflow.add_node("make_decision", decision_node)
    workflow.add_node("rag", rag_node)
    workflow.add_node("generate_reply", generate_reply_node)
    workflow.add_node("execute_action", execute_action_node)

然后，条件边缘将使用 make_decision 节点的输出来定向流：

    workflow.add_conditional_edges(
        "make_decision",
        lambda x: x.get("decision"),
        {
            "auto_respond": "rag",
            "escalate": "execute_action"
        }
    )

如果 make_escalation_decision 工具（通过 decision_node）产生“auto_respond”，工作流将继续通过 RAG 节点（检索示例），然后是 generate_reply 节点（设计回答），最后是 execute_action 节点（记录 auto-response）。

相反，如果决策是“escalate”，流程将绕过 RAG 和生成步骤，直接转到 execute_action 来处理上报。 要添加剩余的标准边缘来完成图，请执行以下操作：

    workflow.add_edge("rag", "generate_reply")
    workflow.add_edge("generate_reply", "execute_action")
    workflow.add_edge("execute_action", END)

数据集注释：对于此项目，我们用于支持检索增强生成 (RAG) 的数据集来自 Hugging Face 上的 Customer Support Tickets 数据集。 对该数据集进行了筛选，以便只包含分类为技术支持并限制为英语的条目。 它确保 RAG 系统只为技术支持任务检索高度相关的特定领域的示例。

此时，我们的图应当与下图类似：

当您使用一封电子邮件来执行此图，并导致高优先级分类和“escalate”决策时，您将看到以下响应：

同时，被分类为低优先级并导致“auto_respond”决策的请求将触发与下面类似的回复：

那么… 这一路都很顺利吗？

并不完全是。 有一些问题需要注意：

• 数据隐私：小心敏感信息 — 这些智能体需要防护。
• 计算成本：某些高级设置需要大量资源。
• 幻觉：LLM 偶尔也会编造一些内容（不过仍然比大多数实习生聪明）。
• 非确定性：相同的输入可能会返回不同的输出，这对创造力来说是好事，但对严格的流程来说却很棘手。

不过，大多数缺点都可以通过良好的规划、合适的工具和一点点思考加以控制。

LangGraph 将 AI 智能体从流行语变成实实在在的有效解决方案。 无论您是要自动执行客户支持，处理 IT 工单，还是构建自主应用程序，这个框架都让操作变得可行，甚至有趣。

您有任何问题或反馈吗？ 请说出来。 AI 革命需要像您这样的建设者。

FHIR 组件、架构和模式

FHIR 提供了一个灵活的可扩缩框架来实现医疗保健数据的互操作性。 为了有效利用 FHIR，我们需要了解实现数据集成和数据交换所需的关键组件、架构和模式。 概括来讲，FHIR 的功能分为以下几个组成部分：

• FHIR 代理 充当多路由中介，简化了各种系统之间健康数据的流动和交换。 它通过管理事务、协调不同的系统并确保高效安全地移动数据，实现了无缝的互操作性。 对于数字健康解决方案合作伙伴，FHIR 代理充当“交换所”的角色，简化了数据交换过程，这让他们可以更轻松地在复杂的生态系统中集成和扩缩应用程序，无需从数据库中额外检索 FHIR 数据。
• FHIR 装饰充当单一接口，可以降低底层非 FHIR 数据库的复杂性，使开发者能够专注于应用程序功能，而不是低层次的数据管理。 装饰立于非 FHIR 系统“之前”，因此基于 FHIR 的操作能够应用于该系统。
• FHIR 仓库提供了一个集中式数据存储库，用于以 FHIR 格式原生管理和提供健康数据，并确保数据的完整性、安全性和访问控制。 仓库的优点是更容易集成和管理，以及更好的性能和更高效的查询和更新。

同时，这些 FHIR 组件还使开发者能够创建灵活、高性能、安全的医疗保健应用程序，在提高患者治疗效果的同时，还可以减少开发和维护开销。

InterSystems FHIR 栈为 FHIR 实现者提供了一种选择，他们可以利用强大的数据集成和管理专业知识为所有主要的 FHIR 架构模式提供支持，这些模式会以不同的方式组合前述的 FHIR 组件。 InterSystems 提供了一整套全面的 FHIR 功能，这不仅有助于遵守 FHIR 标准，还会增强不同系统之间的数据互操作性。 通过将技术能力与深厚的行业知识相结合，InterSystems 帮助开发者应对 FHIR 应用的复杂性，并实现最适合其需求的 FHIR 解决方案。

安全性是医疗保健数据管理的一个关键因素，InterSystems 提供了强大的工具来确保其 FHIR 接口的安全。 这包括基于角色的访问控制 (RBAC)、对 FHIR 的 OAuth2 支持，以及审核日志记录，以确保符合 HIPAA 等医疗保健法规。

我们来检验一下这些 FHIR 组件如何在 InterSystems 软件中协同工作，帮助您选择最符合您需求的架构模式。

FHIR 代理

FHIR 代理是一个使用 FHIR 标准的多路由中介，它能够促进医疗保健数据的交换。 它充当不同健康信息系统之间的连接器，使它们能够通过转换和路由 FHIR 资源进行有效通信。 在多个系统（如电子健康记录 (EHR)、临床应用程序和患者管理系统）需要无缝共享数据，同时仍需遵守 FHIR 标准的环境中，FHIR 代理必不可少。

InterSystems FHIR 代理功能为数据转换、验证和聚合提供了强大的工具，这些功能共同构筑了 FHIR 架构的基石。 这可以简化基于 FHIR 的解决方案的实现，而这些解决方案可以应对集成多个旧版系统之类的特定挑战。 例如，医院网络可能会整合各种 EHR 系统中的患者数据，而 InterSystems FHIR 代理可以聚合这些系统中的信息，将其标准化为 FHIR 格式并以统一的视图呈现。 然后，临床医生可以实时访问全面的患者信息，从而改善医护协调，降低出错风险。 此外，FHIR 代理还可以促进人口健康管理的安全、可扩缩的数据共享，使医疗保健提供者能够分析趋势，改善不同人群的患者的治疗效果（例如，心脏病、戒烟和儿童肥胖症）。

InterSystems SDA（摘要文档架构）数据模型旨在确保更加高效地将旧版医疗保健数据格式转换为现代标准（如 FHIR）。 SDA 为各种旧版医疗保健数据格式（如 HL7 v2、CDA（临床文档架构）或自定义平面文件格式）提供了统一的数据表示。 这种中间格式弥合了高度结构化的旧版系统与更加模块化、更灵活的 FHIR 结构之间的差距，并将作为 FHIR 代理解决方案的一部分。

SDA 还充当抽象层，将不同来源的数据标准化为通用格式。 这种抽象降低了将每种格式直接转换为 FHIR 的复杂性，因为 SDA 提供了一种规一化的结构。

数据转换为 SDA 格式后，即可在多个系统中重复使用。 对于每种旧版格式，只需进行一次 SDA 格式转换即可。 通过 SDA，数据可以导出为各种现代标准，包括 FHIR，从而减少了多次点对点转换的需求。

InterSystems 提供内置的工具和连接器，可以让您轻松地从旧版格式转换为 SDA 以及从 SDA 转换为 FHIR。 这包括预定义的映射、解析器和转换逻辑。 InterSystems 还支持自定义 FHIR 配置文件，可以将 SDA 数据转换为满足特定组织或监管要求的 FHIR 配置文件。

FHIR 装饰

FHIR 装饰是医疗保健系统中使用的一种架构模式，可以在现有的不兼容 FHIR 的系统之上提供兼容 FHIR 的接口。 它充当实现接口，以标准化的 FHIR 格式公开来自旧版非 FHIR 系统的数据和服务，从而实现与现代医疗保健应用程序的互操作性，而无需对底层旧版系统进行重大更改。 与协调多个系统的 FHIR 代理不同，FHIR 装饰立于非 FHIR 系统“之前”。

许多医疗保健系统都基于早期标准构建，如 HL7 v2、CDA（临床文档架构）或与 FHIR 不兼容的自定义数据格式。 FHIR 装饰通过将旧版格式的数据按需转换为 FHIR，提供了一种满足现代互操作性标准，并与电子健康记录 (EHR) 系统、健康信息交换 (HIE) 和患者应用等新应用程序相集成的解决方案。

通过 InterSystems 和 FHIR 实现客户成功

以色列的一家健康维护组织 Leumit Health Services 试图改善付款人与服务提供者之间的数据共享，使其成员更容易获得医疗护理。

通过与 HL7 FHIR 实现方面的当地专家和当地医疗中心合作，Leumit 开发出一种通过 FHIR 装饰集成其各个系统的解决方案。 此解决方案可以自动登记患者：通过 InterSystems IRIS for Health，立即现场确定是否有资格共享基于 FHIR 的数据。

FHIR 装饰的主要特征

• 实时数据转换 – FHIR 装饰可以实时转换数据，在旧版系统的原生格式与 FHIR 资源之间转换请求和响应。
• 不干扰现有系统 – 底层系统继续像往常一样运行，而装饰会处理 FHIR 交互，最大限度地减少对旧版基础架构进行代价高昂的破坏性更改的需求。
• 逐步实现现代化 – FHIR 装饰可以让组织公开兼容 FHIR 的 API 供外部使用，逐步实现现代化，而不必一步到位地改革旧版系统。
• 互操作性 – 通过将旧版格式转换为 FHIR，FHIR 装饰可以与其他需要兼容 FHIR 的医疗保健系统、应用程序和平台实现互操作性。

InterSystems IRIS for Health 提供了一套理想的工具和技术来实现 FHIR 装饰，因为它原生支持 FHIR 和 FHIR 数据转换。

InterSystems IRIS for Health 支持使用自定义 FHIR 配置文件和扩展，使组织能够根据其特定需求调整 FHIR 装饰。 这种灵活性使 FHIR 装饰能够满足地区或组织的数据交换要求，同时遵守 FHIR 标准。

FHIR 仓库

与 FHIR 装饰相比，FHIR 仓库提供了一种更方便、更高效的医疗保健数据管理方式。 虽然这两种方式都旨在提供互操作性并促进 FHIR 的使用，但 FHIR 仓库在数据管理、性能和易于集成方面具有许多优势。 FHIR 仓库以 FHIR 格式原生存储、管理和展示医疗保健数据，提供了一个可以高效查询和更新数据的集中式平台。 这与 FHIR 装饰形成鲜明对比，后者用作旧版系统的前端，在非 FHIR 格式与 FHIR 格式之间实时转换。

InterSystems FHIR 仓库经过专门设计，支持以 FHIR 格式存储和管理数据，无需实时转换数据。 通过原生存储 FHIR 资源，仓库可以更高效地处理复杂的 FHIR 查询和更新。

无需中间映射，直接对 FHIR 仓库进行查询，这对于复杂搜索特别有用，例如跨多个 FHIR 资源（如患者、病情、观察）的患者记录查询。 所有数据都以 FHIR 格式存储在一个地方。 这提高了数据存储和访问的一致性、效率和可靠性。

InterSystems FHIR 仓库可以随着医疗保健组织的不断发展而高效扩缩并处理越来越多的数据。 由于仓库存储了预转换的 FHIR 数据，在处理来自多个系统的并发请求时，系统会进行性能优化。 InterSystems 具有一个可扩缩性实验室，用于对 FHIR 的性能进行基准测试。 该实验室定期运行一整套 FHIR 基准测试，结果显示在复杂的 FHIR 搜索查询方面取得了显著的进步。 简单的仓库搜索每秒可以检索超过 160,000 个 FHIR 资源，在要求更高的情况下具有类似的性能 (Jamieson & Banand, 2024)。¹

InterSystems 提供了一个开箱即用的完全兼容 FHIR 的仓库。 这使医疗保健机构不必进行复杂的设置即可快速部署符合最新 FHIR 标准的 FHIR 仓库。 此栈支持所有主要的 FHIR 交互，包括资源创建、检索、更新和删除。 InterSystems 确保其 FHIR 仓库与不断发展的 FHIR 标准保持一致，提供对最新的 FHIR 资源和功能支持。 这可以确保与其他基于 FHIR 的系统兼容，并适应不断发展的医疗保健标准。

利用 InterSystems IRIS 扩展 FHIR 仓库的功能

内置的 FHIR 仓库与 InterSystems IRIS for Health 数据平台原生集成，可以实现与其他医疗保健系统和应用程序的无缝交互。 这使摄取、存储和检索 FHIR 资源变得更加容易，不会带来额外的复杂性。

InterSystems IRIS for Health 包含一个多模型数据库，并支持高级分析、AI 和机器学习模型。 此平台的 FHIR 仓库可以用作构建分析解决方案的基础，分析解决方案能够从结构化和规一化的医疗保健数据中提取信息。 InterSystems 独特的 FHIR SQL Builder 工具使开发者能够以关系格式“投射”FHIR 资源，从而轻松使用 ANSI SQL 或 BI 工具进行分析。 由于此平台是一个真正的多模型数据库，它可以实时进行这些投射，分析用户始终具有最新的信息，无需在数据仓库中复制其数据。

InterSystems IRIS for Health 以 FHIR 格式存储和查询数据，使组织能够应用人口健康分析、预测患者治疗效果，以及优化临床操作。

为什么选择 InterSystems FHIR 解决方案

无论您是构建 FHIR 代理、FHIR 装饰还是 FHIR 仓库，技术栈的选择都会对您的成功产生重大影响。 以下是 InterSystems FHIR Stack 应当成为您的首选的原因：

• 全面、可扩缩的 FHIR 支持 – InterSystems 为所有版本的最新 FHIR 标准提供全面的支持。 InterSystems IRIS for Health 拥有处理大量临床数据的可靠记录， 专为可扩缩性而设计。 无论您是开发简单的 FHIR 代理还是复杂的 FHIR 仓库，InterSystems 都可以确保即使在高容量环境中也可以进行高效扩缩，而不会影响性能。 我们独特的 InterSystems Bulk FHIR Coordinator 可以让您从支持批量 FHIR 的其他 FHIR 服务器和 EMR 进行批量导出，从而可以在一个地方轻松管理您的所有 FHIR 数据。
• 与现有系统无缝集成 – 医疗保健 IT 面临的一个最大挑战就是将新解决方案与旧版系统集成在一起。 InterSystems 的 FHIR Stack 在基于 FHIR 的新型应用程序与较早的 HL7 v2、HL7 v3 和 CDA 标准之间提供了无缝衔接。 这种互操作性可以确保在贵组织的 IT 环境中持续通信，而无需调整现有的基础架构，这使其成为 FHIR 装饰和我们独特的 FHIR 转换服务的理想选择。
• 经过验证的性能和可靠性 – 在医疗保健领域，可靠性不容商议。 InterSystems 一直以提供高可用性和低延迟的企业级性能而闻名。 FHIR Stack 基于 InterSystems IRIS for Health 构建，是专门针对医疗保健工作负载而设计的数据平台。 无论您是管理 FHIR 仓库还是充当 FHIR 代理，它都可以确保一致的正常运行时间和高效的实时数据交换。
• 高级数据管理和安全 – 数据安全和患者隐私在医疗保健领域至关重要。 InterSystems FHIR Stack 提供了强大的内置安全功能来保护敏感的医疗保健数据。 它完全符合 HIPAA 和其他全球标准，提供基于角色的访问控制、审核日志和加密功能。 对于构建 FHIR 仓库的组织来说，符合这些标准意味着可以放心地存储和交换大型数据集。
• 广泛的开发和自定义工具 – InterSystems 提供全面的开发环境，包括 API、SDK 和 FHIR SQL Builder，可以帮助您根据特定需求自定义和扩展 FHIR 解决方案。 无论您需要轻量级 FHIR 代理还是功能丰富的 FHIR 仓库，我们的工具和强大的支持服务都可以实现快速定制，加快上市速度。
• 卓越的供应商支持和生态系统 – InterSystems 以其出色的客户支持而闻名，其中包括全天候获取技术资源和广泛的开发者社区。 我们强大的合作伙伴和解决方案生态系统确保您在工作中永远不会孤单。 无论您是要就 FHIR 装饰的最佳做法进行咨询，还是要为您的 FHIR 仓库进行技术故障排除，都可以随时获取帮助。

更多关于此主题的文章

• FHIR-HL7v2-SQL-Demo
• 我的 FHIR 使用经验
• iOS、FHIR 和 IRIS for Health
• fhir-integratedml-example 概述
• Iris FHIR Python 策略
• 一个使用 Python 编写的 FHIR 客户端的简单示例
• 一个使用 C# 编写的 FHIR 客户端的简单示例
• 一个使用 Java 编写的 FHIR 客户端的简单示例
• 使用嵌入式 Python 自定义 FHIR 仓库
• FHIR 环境设置指南

来源：利用 FHIR 简化健康数据集成

数据是席卷医疗保健行业的数字化转型的核心。 要想发生根本性转变，需要一个新的基础来处理现代医疗保健的海量数据需求。

在您开发下一个治疗性突破、基因组见解和智能临床工作流时，上市速度至关重要。 您需要立即交付它们。

这就是我们为何扩展 InterSystems IRIS 数据平台的能力，以应对医疗保健信息的独特特征。 InterSystems IRIS for Health 是世界上第一个也是唯一一个专为快速开发医疗保健应用程序而设计的数据平台，管理着世界上最关键的数据。

没有哪家数据管理供应商对医疗保健有如此大的投入或如此丰富的相关经验。 在全球，有超过 10 亿份健康记录通过基于我们技术的解决方案进行管理。 在 InterSystems 上运行的实验室每天处理着美国近一半的标本 。 最尖端的私有和政府医疗保健提供商依赖于由 InterSystems 提供支持的设备、记录和 IT。

InterSystems IRIS for Health 提供了快速开发数据丰富的医疗保健应用程序所需的一切。

快速实现从白板到生产

InterSystems IRIS for Health 提供了构建复杂的任务关键型数据密集应用程序所需的所有功能。 它是一个综合性平台，涵盖了数据管理、互操作性、事务处理和分析，旨在加快实现价值的速度。

为大而生

医疗保健信息的数量和种类大得惊人，而且呈指数级增长。 InterSystems IRIS for Health 使应用程序能够从头开始高效扩缩（垂直和水平），以更经济高效的方式处理任何规模的工作负载、数据和用户。

加速互联

真正的互联健康需要各种不同来源（现代和传统）的可互换信息流。 由于 InterSystems IRIS for Health 为 FHIR 和每个主要的全球医疗保健消息传递标准提供了原生支持，应用程序可以快速摄取、规一化和共享信息。

更深层次的智能

人工智能和机器学习的成败取决于底层数据的质量。 InterSystems IRIS for Health 提供了先进的数据准备功能，可以创建变革性医疗保健模型并优化学习解决方案的效能。

积极响应的见解

临床决策支持、从实验室到临床的药物以及日益增长的消费者期望都要求实时响应。 InterSystems IRIS for Health 擅长混合事务/分析处理 (HTAP)，能够为满足这些不断增长的需求的解决方案提供支持。

更多关于此主题的文章

• InterSystems IRIS for Health：全面的入门指南
• InterSystems IRIS for Health 中的 FHIR 互操作性

来源：InterSystems IRIS for Health

您知道当您拿到验血结果时一切看起来都像天书的那种感觉吗？ 这就是 FHIRInsight 要解决的问题。 它最初的理念是，医疗数据不应该令人恐惧或困惑 – 它应该是我们所有人都能使用的东西。 验血是健康检查中十分常见的检查，但说实话，大多数人都很难理解它们，有时甚至对不擅长实验室工作的医务人员来说也是如此。 FHIRInsight 希望整个过程能够变得更简单，信息更富有实用价值。

🤖我们为什么要构建 FHIRInsight

这一切都始于一个简单而有力的问题：

“为什么验血结果仍然很难读懂 — 有时甚至对医生来说也是如此？”

如果您看过化验结果，您可能会看到一大堆数字、隐晦的缩写和“参考范围”，这些可能适用于您的年龄、性别或身体状况，也可能不适用。 毫无疑问，它是一种诊断工具，但如果没有背景信息，它就变成了一个猜谜游戏。 即使是经验丰富的医疗保健专业人员有时也需要交叉参考指导方针、研究论文或专家意见才能理解所有内容。

这正是 FHIRInsight 的用武之地。

我们不只是为患者而构建，也为一线医护人员而构建。 为轮流值班的医生，为捕捉生命体征细微变化的护士，为每一位试图在有限的时间和巨大的责任下做出正确决定的医护人员而构建。 我们的目标是让他们的工作简单一点，将密集的临床 FHIR 数据转化为清晰、有用、以真正的医学科学为基础的东西， 讲人类语言的东西。

FHIRInsight 不仅仅是解释化验结果。 它还：

• 提供化验结果是轻度、中度还是重度的情境建议
• 根据临床症状提出潜在病因和鉴别诊断
• 提出下一步行动建议 — 是后续检查、转诊还是紧急护理
• 利用 RAG（检索增强生成）拉取相关科学文章，为分析提供支持

想象一下，一位年轻的医生正在查看患者的贫血检查结果。 他们不需要在 Google 上搜索每一个异常值或翻阅医学期刊，而是收到一份报告，上面不仅总结了问题，还引用了最近的研究或世界卫生组织的指导方针来支持这一推理。 这就是将 AI 与针对精选研究的矢量搜索相结合的力量。

那患者呢？

他们再也不用盯着满屏的数字，猜想“胆红素 2.3 mg/dL”是什么意思，或者他们是否应该担心了。 他们会得到简单、周全的解释。 感觉更像是一场对话，而不是一份临床报告。 一些他们能真正理解的东西 — 并与他们的医生进行讨论，让人感觉更有准备，不那么焦虑。

因为这就是 FHIRInsight 的真正意义**：将复杂的医疗数据转化为清晰的见解**，帮助医疗保健专业人员和患者共同制定更好、更自信的决策。

🔍 表象之下

当然，所有这些表面上的简单，背后可能由一些默默运行的强大技术提供支持。

以下是 FHIRInsight 的构建基础：

• FHIR (Fast Healthcare Interoperability Resources) — 这是健康数据的全球标准。 它是我们接收化验结果、患者病史、受众特征和诊疗等结构化信息的方式。 FHIR 是医疗系统使用的语言，我们将这种语言翻译成人们可以真正使用的东西。
• RAG（检索增强生成）的矢量搜索：FHIRInsight 通过在使用 InterSystems IRIS 原生矢量搜索的矢量数据库中建立科学 PDF 论文和可信 URL 索引，增强其诊断推理能力。 当化验结果看起来模棱两可或差别细微时，系统会检索相关内容来支持其建议，它不是从记忆库中进行检索，而是从真实的、最新的研究中进行检索。
• 医学推理提示工程：我们对提示进行了微调，以指导 LLM 识别各种血液相关疾病。 无论是缺铁性贫血、凝血功能障碍、激素失衡还是自身免疫触发因素，提示都会引导 LLM 了解症状、检验室模式和可能病因的变化。
• LiteLLM 集成：自定义适配器通过统一的接口将请求路由到多个 LLM 提供程序（OpenAI、Anthropic、Ollama 等），从而轻松实现回退、流式传输和模型切换。

无论您是查看 30 个患者图表的医生，还是想要理解数字含义的患者，都可以在几秒钟内将原始的化验数据转化为可解释、富有实用价值的医学见解。

🧩 创建 LiteLLM 适配器：使用一个接口管理所有模型

在后台，FHIRInsight 的 AI 赋能报告由 LiteLLM 驱动，后者是一个出色的抽象层，可以使我们通过一个 OpenAI 风格的界面调用 100 多个 LLM（OpenAI、Claude、Gemini、Ollama 等）。

但是要想将 LiteLLM 集成到 InterSystems IRIS 中，需要比隐藏在业务操作中的 Python 脚本更持久、更能重复使用的东西。 所以，我们创建了自己的 LiteLLM 适配器。

认识 LiteLLMAdapter

此适配器类可以处理您希望从一个强大的 LLM 集成中获得的所有东西：

• 接受 prompt、model 和 temperature 等参数
• 动态加载环境变量（例如，API 密钥）

为了将其嵌入我们的互操作性生产中，我们将其包装在一个专门的业务操作中：

• 通过标准的 LLMModel 设置处理生产配置
• 与 FHIRAnalyzer 组件集成，以实时生成报告
• 作为未来任何需要访问 LLM 的组件的中心“AI 桥”

以下是简化的核心流程：

set response = ##class(dc.LLM.LiteLLMAdapter).CallLLM("Tell me about hemoglobin.", "openai/gpt-4o", 0.7)
write response

🧭 结语

当我们开始构建 FHIRInsight 时，我们的使命很简单**：让验血结果对每个人来说都更容易理解**。 不仅仅是患者，还有医生、护士、护理人员… 任何曾经盯着化验结果苦思冥想的人，“好吧，这到底是什么意思？”

我们都有过这样的经历。

通过融合 FHIR 的结构、InterSystems IRIS 的速度、LLM 的智能，以及通过矢量搜索实现真实医学研究的深度，我们创造了一个可以将令人困惑的数字转化成有意义的叙述的工具。 帮助人们对自己的健康做出更明智的决定，甚至可能及早发现一些被忽视的疾病。

但 FHIRInsight 不仅仅与数据相关。 它还与我们查看数据时的感受相关。 我们希望它给人一种清晰、支持和赋能的感觉。 我们希望这种体验… 有点像**“氛围编程”医疗保健** — 在智能的代码、优秀的设计和人类同理心方面达到最佳平衡点。

我们希望您能尝试它，打破它，质疑它，并帮助我们改进它。

告诉我们您接下来想看到什么。 更多条件？ 更具可解释性？ 更加个性化？

这只是一个开端 — 我们希望您能帮助塑造它的未来。

大家好！

本文主要丰富了上一篇文章的内容，并介绍了应用程序的使用方法。

也许您已经读过上一篇文章，但我还是想说，
在完成初始化操作（包括模型创建和训练）后，Fhir HepatitisC Predict 应用程序将预测丙型肝炎（HepatitisC）。

首先

您需要在应用程序上输入一些信息，当然，只是一些检查结果，不包括隐私数据。

SHOW显示

点击显示按钮，将显示该指标的数据是否在正常范围内，指标是高还是低。当然，每个指标的数据范围都是通过查询信息获得的，可能与实际范围略有不同。

Prediction预测

完成信息输入后，点击预测实际上涉及到应用程序中的许多操作。

1. 将发送的 JSON 格式检查结果转换为 FHIR 资源（对部分患者基本信息和其他隐私数据使用模拟数据）
2. 通过 FHIR Server 提供的 API 接口（ip: port/hir/r4/）将转换后的 FHIR 资源注册到 FHIR 资源库，类似于使用 Postman 进行接口调用。需要注意的是，将内容类型设为 application/JSON+fhir

IRIS 支持开箱即用的 CCDA 和 FHIR 转换，但访问和查看这些功能需要大量的时间设置和产品知识。IRIS Interop DevTools 应用程序旨在弥补这一差距，让实施人员能够立即进入并查看产品的内置转换功能。

除了 IRIS XML、XPath 和 CCDA 转换环境，Interop DevTools 软件包现在还提供：

• FHIR-SDA 转换设置
• SDA-FHIR 转换设置
• 构建 FHIR 错误验证
• 加载 FHIR 转换所需的内容

已经更新仪表板的外观和感触，看起来更加直观和用户友好。在 IRIS 中执行，以便充分利用环境，同时用户界面允许可见性、可重复性以及隔离修改和模块进行测试的能力。

以下是5个功能支持:

1. XPath 评估器： 根据输入 CCD 评估 XPath 并返回结果

2. CCDA 到 SDA 转换： 通过选定的基本 XSL 转换运行输入的 CCD，并显示 SDA 结果。

3. XSL 模板测试器： 针对输入 CCD 应用单个 XSL 模板，并显示生成的 CCD。

4. FHIR 到 SDA 转换： 在输入的 FHIR 资源或捆绑包上运行标准的 FHIR 到 SDA 转换，并显示 SDA 结果或 FHIR 验证错误响应。

5. 5. SDA 到 FHIR 转换： 在输入的 SDA 消息上运行标准的 SDA 到 FHIR 转换，并显示 FHIR 束结果。

Hi 大家好
在本文中,我讲介绍我的应用 iris-AgenticAI .

代理式人工智能的兴起标志着人工智能与世界互动方式的变革性飞跃--从静态响应转变为动态、目标驱动的问题解决方式。参看 OpenAI’s Agentic SDK ,  OpenAI Agents SDK使您能够在一个轻量级、易用且抽象程度极低的软件包中构建代理人工智能应用程序。它是我们之前的代理实验 Swarm 的生产就绪升级版。

该应用展示了下一代自主人工智能系统，这些系统能够进行推理、协作，并以类似人类的适应能力执行复杂任务。

应用功能

• Agent Loop 🔄 一个内置循环，可自主管理工具的执行，将结果发回 LLM，并迭代直至任务完成。
• Python-First 🐍 利用本地 Python 语法（装饰器、生成器等）来协调和连锁代理，而无需外部 DSL。
• Handoffs 🤝 通过在专业代理之间委派任务，无缝协调多代理工作流程。
• Function Tools ⚒️ 用 @tool 修饰任何 Python 函数，可立即将其集成到代理的工具包中。
• Vector Search (RAG) 🧠 原生集成向量存储（IRIS），用于 RAG 检索。
• Tracing 🔍 内置跟踪功能，可实时可视化、调试和监控代理工作流（想想 LangSmith 的替代方案）。
• MCP Servers 🌐 通过 stdio 和 HTTP 支持模型上下文协议（MCP），实现跨进程代理通信。
• Chainlit UI 🖥️ 集成 Chainlit 框架，可使用最少的代码构建交互式聊天界面。
• Stateful Memory 🧠 跨会话保存聊天历史、上下文和代理状态，以实现连续性和长期任务。

社区朋友们好，

传统的基于关键词的搜索方式在处理具有细微差别的领域特定查询时往往力不从心。而向量搜索则通过语义理解能力，使AI智能体能够根据上下文（而非仅凭关键词）来检索信息并生成响应。

本文将通过逐步指导，带您创建一个具备代理能力的AI RAG（检索增强生成）应用程序。

实现步骤:

1. 添加文档摄取功能：
   • 自动获取并建立文档索引（例如《InterSystems IRIS 2025.1版本说明》）
   • 实现向量搜索功能
2. 构建向量搜索智能体
3. 移交至主智能体（分流处理）
4. 运行智能体

1. Create Agent Tools 添加文档摄取功能

Implement Document Ingestion: Automated ingestion and indexing of documents 

1.1 - 以下是实现文档摄取工具的代码：

defingestDoc(self):#Check if document is defined, by selecting from table#If not defined then INGEST document, Otherwise back
        embeddings = OpenAIEmbeddings()	
        #Load the document based on the fle type
        loader = TextLoader("/irisdev/app/docs/IRIS2025-1-Release-Notes.txt", encoding='utf-8')      
        
        documents = loader.load()        
        text_splitter = RecursiveCharacterTextSplitter(chunk_size=400, chunk_overlap=0)
        
        texts = text_splitter.split_documents(documents)
                       
        #COLLECTION_NAME = "rag_document"
        db = IRISVector.from_documents(
            embedding=embeddings,
            documents=texts,
            collection_name = self.COLLECTION_NAME,
            connection_string=self.CONNECTION_STRING,
        )

        db = IRISVector.from_documents(embedding=embeddings,documents=texts, collection_name = self.COLLECTION_NAME, connection_string=self.CONNECTION_STRING,)

向量搜索智能体（Vector Search Agent）能够自动完成文档的摄取（ingest）与索引构建（index）， 该新功能在InterSystems IRIS 2025.1的数据资源文件夹里） 至 IRIS 向量存储， 只有当数据尚未存在时，才执行该操作。

运行以下查询以从向量存储中获取所需数据：

SELECTid, embedding, document, metadata
FROM SQLUser.AgenticAIRAG

1.2 - 实现向量搜索功能

以下代码为智能体提供了搜索能力：

defragSearch(self,prompt):#Check if collections are defined or ingested done.# if not then call ingest method
        embeddings = OpenAIEmbeddings()	
        db2 = IRISVector (
            embedding_function=embeddings,    
            collection_name=self.COLLECTION_NAME,
            connection_string=self.CONNECTION_STRING,
        )
        docs_with_score = db2.similarity_search_with_score(prompt)
        relevant_docs = ["".join(str(doc.page_content)) + " "for doc, _ in docs_with_score]
        
        #Generate Template
        template = f"""
        Prompt: {prompt}
        Relevant Docuemnts: {relevant_docs}
        """return template

分流代理处理传入的用户查询，并将其委托给矢量搜索代理，后者执行语义搜索操作，以检索最相关的信息。

使用 FHIR SQL BUILDER 处理 FHIR 资源以预测患丙型肝炎疾病的概率

随着科技的发展，医疗行业也在不断的进步，人类也往往更加关注自身的健康，
通过计算机学习和处理数据集，可以预测疾病。

前提条件：使用 FHIR 和 ML的能力
首先，我们的数据集从kaggle获得，并根据患者性别、年龄、ALP或ALT转化为FHIR资源，并导入到FHIR资源库中

要导入FHIR资源库，我们可以使用以下命令：

Set sc= ##class (HS.FHIRServer.Tools.DataLoader).SubmitResourceFiles( "/usr/local/src/json/" , "FHIRSERVER" , "/csp/healthshare/fhirserver/fhir/r4" )

其中文件地址和fhir资源库URL可以根据情况进行修改。

完成导入后，下一步是配置FHIR SQL Builder，包括FHIR Analysis、转换规则和Projections

配置转换规则，这一点非常重要。它们可以获得你想要的数据，也可以省略患者的一些敏感信息，保证数据安全

配置完成后，创建一个投影，以查询数据库中的相应表

创建投影后，通过创建表或视图将表汇总成训练所需的结构

在上一篇文章中，我们了解了如何恢复存储在特定 HIS 数据库中的资源，因此今天我们将了解如何在 HIS 中添加新记录，其来源是我们在系统中收到的 FHIR 资源。

FHIR 的 CRUD 操作

FHIR 的主要功能之一是通过 Rest API 支持 CRUD 操作，这意味着任何使用 FHIR 的系统都必须提供对 GET、POST、PUT 和 DELETE 类型的 HTTP 调用的支持。在今天的文章中，我们将了解如何管理对安装 FHIR 适配器时自动配置的端点的 POST 调用。

如果我们回顾资源存储调用的 FHIR 规范，我们会发现它告诉我们，用于调用的 URL 必须遵循以下格式：

http(s)://server_url/{endpoint}/{Resource}

在我们的示例中，我们将不使用安全调用，因此我们的 URL 将如下所示：

http://localhost:52774/Adapter/r4/Patient

由于我们想要记录新患者，因此我们必须在调用正文中使用患者数据进行 POST 调用。在我们的例子中，调用格式将是 application/fhir+json，不过我们也可以使用XML格式的application/fhir+xml，不会有任何问题。

保存患者资源

人工智能（AI）最近受到广泛关注，因为它可以改变我们生活的许多领域。更好的计算机能力和更多数据帮助人工智能完成了许多惊人的事情，例如改进医学测试和制造自动驾驶汽车。人工智能还可以帮助企业做出更好的决策，提高工作效率，这也是人工智能越来越流行和广泛应用的原因。如何将 OpenAI API 调用集成到现有的 IRIS 互操作性应用程序中？

我们继续推出有关可供 HealthShare HealthConnect 和 InterSystems IRIS 用户使用的 FHIR 适配器工具的系列文章。

在前几篇文章中，我们介绍了小型应用程序，并在此基础上建立了我们的工作，并展示了安装 FHIR 适配器后在 IRIS 实例中部署的架构。在今天的文章中，我们将看到一个示例，说明如何执行最常见的 CRUD（创建 - 读取 - 更新 - 删除）操作之一，即读取操作，我们将通过恢复资源来完成此操作。

什么是资源？

FHIR 中的一个资源对应一种相关的临床信息，这种信息可以是病人（Patient）、对实验室的请求（ServiceRequest）或诊断（Condition）等。每种资源都定义了组成它的数据类型，以及对数据的限制和与其他类型资源的关系。每个资源都允许对其包含的信息进行扩展，从而满足 FHIR 80% 以外的需求（满足 80% 以上用户的需求）。

在本文的示例中，我们将使用最常见的资源 "Patient"。让我们来看看它的定义：

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

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

安装

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

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

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

set status = ##class (HS.FHIRServer.Installer).InteropAdapterConfig( "/Adapter/r4" )

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

安装结果

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

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

想必大家都听说过 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文档，您将能够获取到众多示例。

您好！社区的各位老师，

在我的上一篇文章中，我们学习了以下主题：

1. 什么是 Docker？
2. Docker 的一些好处
3. Docker 是如何工作的？
4. Docker 镜像
5. Docker容器
6. Docker 镜像存储库
7. InterSystems 的 Docker 镜像存储库
8. Docker安装
9. Docker 基本命令
10. 使用 Docker 运行 IRIS 社区版
11. Docker 桌面图形用户界面

在本文中，我们将讨论以下主题：

1. 使用 Docker Compose 文件（ YAML 文件）
2. Docker 文件的使用（用于构建 Docker 镜像）
3. Docker 卷的使用

那么让我们开始吧。

嗨，开发者们！

今天我想谈谈一个让我感到困难的话题。我相信你们中的很多人一定已经遇到过这种情况（所谓的“瓶颈”）。由于这是一个广泛的主题，因此本文将仅重点关注识别可能导致缓慢问题的传入 HTTP 请求。我还将向您提供我开发的一个小工具来帮助识别它们。

我们的软件变得越来越复杂，处理来自不同来源的大量请求，无论是前端还是第三方后端应用程序。为了确保最佳性能，必须有一个能够记录一些关键测量的日志系统，例如响应时间、global引用的数量以及每个 HTTP 响应执行的代码行数。作为工作的一部分，我参与了 EMR 软件的开发以及事件分析。由于用户负载主要来自 HTTP 请求（REST API 或 CSP 应用程序），因此在发生普遍缓慢问题时进行此类测量的需求变得显而易见。

VR ICU® 是 InterSystems FHIR 创新孵化器 Caelestinus 的参与者。这篇文章将向您介绍我们利用 InterSystems FHIR Server 为医疗保健提供的 VR 解决方案。

我们是一家技术初创企业虚拟实验室，利用先进的 VR/AR 技术开发解决方案。VR ICU® 是一个针对重症监护室医务人员的培训平台，是在 Covid 时代为满足医院需求而创建的。

与InterSystems合作的优势

我们的 VR ICU® 解决方案符合实践需求，是与医院合作开发的。

除了技术解决方案和技能学习本身，记录培训课程、培训进度和成功率对于医院或麻醉学和重症监护部门的有效管理也至关重要。医务长可以通过了解谁在何时接受了培训，清楚地掌握能够在重症监护室使用设备的人员数量，从而有效地对他们进行培训，以保持技能、有控制地规划人员技能储备并提高他们的能力。

在这方面，与 InterSystems 的合作对我们来说至关重要，它使我们能够在应用程序中存储每次培训期间的数据。目前，我们会记录参与者的姓名、培训日期和时长、培训类型、设备类型、错误数量和类型，必要时还会记录培训成功完成的信息。

如何使用？用户登录应用程序并选择一个账户。

FHIR® SQL Builder或 Builder 是 InterSystems IRIS 医疗版数据平台 的一个组件。它是一种复杂的投射工具，用于将 InterSystems IRIS  医疗版数据平台FHIR 存储库中的数据创建为自定义的 SQL 模式，而无需将数据移动到单独的 SQL 存储库中。 Builder 专门设计用于与 InterSystems IRIS 医疗版数据平台中的 FHIR 存储库和多模型数据库配合使用。

Builder 的目标是使数据分析师和商业智能开发人员能够使用熟悉的SQL分析工具使用 FHIR，而无需学习新的查询语法。 FHIR 数据以复杂的有向图编码，无法使用标准 SQL 语法进行查询。基于图的查询语言 FHIRPath 旨在查询 FHIR 数据，但它是非关系型的。 Builder 使数据管理员能够使用表、列和索引创建其 FHIR 存储库的自定义 SQL 来投射，使数据分析师能够查询 FHIR 数据，而无需学习 FHIRPath 或 FHIR 搜索语法的复杂性。
存储库将加载 FHIR 资源，您所需要做的就是配置 FHIR SQL BUILDER。
对于配置，导航到http://localhost:55037/csp/fhirsql/index.csp# /

有关如何进行配置的更多详细信息，请观看此教程视频

#Embedded Python #HL7 #InterSystems IRIS for Health

写在回复社区帖子《Python能否动态创建HL7消息》中。

前提条件和设置

使用一个启用了集成的命名空间。
注意：USER命名空间默认不启用互操作性。
如果以下建议创建一个新的互操作性命名空间来探索功能。

# 切换到
ZN "[互操作性名称空间名称]"

# 启动交互式Python shell：
Do $SYSTEM.Python.Shell()

启动脚本

#Load dependencies

import datetime as dt
import uuid

# Cache current time in CCYYMMDDHHMMss format
hl7_datetime_now=dt.datetime.now().strftime('%Y%m%d%H%M%S')

# Create HL7 Message
hl7=iris.cls("EnsLib.HL7.Message")._New()

# Set the doc type
# 2.5.1:ORU_R01 - Unsolicited transmission of an observation message
hl7.PokeDocType("2.5.1:ORU_R01")

这些信息的结构可以从管理门户中获取

您好！社区的各位老师，

在本文中，我们将学习以下主题：

1. 什么是 Docker？
2. Docker 的一些好处
3. Docker 是如何工作的？
4. Docker 镜像
5. Docker容器
6. Docker 镜像存储库
7. InterSystems 的 Docker 镜像存储库
8. Docker安装
9. Docker 基本命令
10. 使用 docker 运行 IRIS 社区版
11. Docker 桌面图形用户界面

那么让我们开始吧。

1.什么是Docker？

Docker 是一种虚拟化软件，可以让应用程序的开发和部署变得非常简单。 Docker 通过将应用程序打包到所谓的容器中来实现此目的，该容器保留应用程序运行所需的所有内容，包括应用程序的实际代码、其库和依赖项、运行时和环境配置。

Docker 是一个容器化平台，允许开发人员在容器化环境中创建、部署和运行应用程序。 Docker 提供了一种将应用程序及其依赖项打包到单个容器中的方法，该容器可以在任何支持 Docker 的计算机上运行。这使得创建可快速、轻松部署的可移植、轻量级应用程序变得容易。

2. Docker 的一些好处

您可以在下面找到使用 Docker 的一些好处：

嗨社区，
在本文中，我将演示 InterSystems Embedded Python 的用法，我们将涵盖以下主题：

• 1-嵌入式Python概述
• 2-嵌入式Python的使用
  • 2.1- 从 ObjectScript 使用 Python 库
  • 2.2- 从 Python 调用 InterSystems API
  • 2.3- 一起使用 ObjectScript 和 Python
• 3-使用python内置函数
• 4-Python 模块/库
• 5 个嵌入式 Python 用例
  • 5.1- 使用 python Reportlab 库打印 PDF
  • 5.2-使用Python二维码库生成二维码
  • 5.3- 使用 Python Folium 库获取 GEO 位置
  • 5.4- 通过使用在交互式地图上生成和标记位置  Python Folium 库
  • 5.5- 使用 Python Pandas 库进行数据分析
• 6-总结

我们从概述开始
 

1-嵌入式Python概述

嵌入式 Python 是 InterSystems IRIS 数据平台的一项功能，它允许 Python 开发人员完全直接地访问 InterSystems IRIS 中的数据和功能。

InterSystems IRIS 带有一种名为 ObjectScript 的强大内置编程语言，可在数据平台内部进行解释、编译和运行。

嗨，InterSystems 开发人员！

最近我更新了FHIR 开发模板，它发布了一个 IPM 包fhir-server ，使 InterSystems FHIR 服务器的设置成为一个微不足道的手动或自动或编程的程序，只需一条命令。

请参阅下文，了解如何从中受益。

TLDR

USER>zpm "install fhir-server"

以下所有详细信息。

在上一篇文章中，我们看到了最常用的HL7消息类型之一--ADT（入院、出院、转院）的结构，以及ADT^A04的例子和它所有字段的描述。现在让我们来看看另一个数据流，它与测试订单的订购和履行有关。我说的是ORM（从2.5版本开始，你应该使用特定的消息来订购测试，如OMG、OML、OMD、OMS、OMN、OMI和OMP），ORL和ORU消息。在一个非常简化的情况下，数据的交换可能看起来像这样。

让我们更详细地看一下这些消息。

动机

这个项目是在我考虑如何通过Embedded Python让Python代码自然地处理IRIS globals所提供的可扩展的存储和高效的检索机制时想到的。

我最初的想法是使用globals创建一种Python字典的实现，但很快我就意识到，我应该首先处理对象的抽象问题。

所以，我开始创建一些可以包装Python对象的Python类，在globals中存储和检索它们的数据，也就是说，在IRIS globals中序列化和反序列化Python对象。

它是如何工作的?

像 ObjectScript 的%DispatchGetProperty(), %DispatchSetProperty() 和%DispatchMethod()一样, Python 有委托对象的属性和方法调用的方式。

当你设置或获取一个对象属性时，Python 解释器让你通过方式 __setattr__(self, name, value) 和 __getattr(self, name)__来截获这个操作。

请看这个相当基本的例子。

在上一篇文章中，我们讨论了标准 HL7v2 的起源、结构和消息类型。现在让我们看一下最常用的消息类型之一及其结构示例。我说的是 ADT。

HL7 ADT 消息（入院、出院、转院）用于在医疗机构传达基本患者信息、就诊信息和患者状态。 ADT 消息是使用最广泛且容量最大的 HL7 消息类型之一，因为它为许多触发事件提供信息，包括患者入院、注册、取消、更新、出院、患者数据合并等。

HL7（Health Level 7）是一套技术规范，用于医院信息系统（HIS）之间临床、财务和管理数据的计算机互交换。这些规范被不同程度地被纳入美国（ANSI）和国际（ISO）正式标准的语料库中。

HL7的L7表示它是在OSI模型的第7层，换句话说，在应用层运行的标准。这意味着HL7不需要考虑交换的安全性，也不需要考虑信息传输的安全性（这一点由较低层次的层来保证，例如用于安全的SSL/TLS或用于数据传输的TCP）。更准确地说，第7层支持终端用户进程和应用的通信，以及面向用户的软件应用的数据展示。作为OSI模型的最高层，也是最接近最终用户的层，第7层提供特定的应用功能，如识别通信伙伴和它们之间的服务质量，确定资源可用性，考虑隐私和用户认证，以及同步通信，并将应用与OSI模型的较低层连接起来。

回到HL7标准，HL7第二版标准（也称为Pipehat）最初创建于1989年，但目前仍在使用并定期更新，形成了2.1、2.2、2.3、2.3.1、2.4、2.5、2.5.1、2.6、2.7、2.7.1、2.8、2.8.1、2.8.2和2.9版本。v2.x标准是向后兼容的（例如，基于2.3版本的信息将被支持2.6版本的应用程序所理解），在更高的版本中，你会看到一些字段是专门为它而留的。

当我们使用IRIS时，我们通常有能力快速的部署一个现成使用的BI基础模块（数据、分析立方体和IRIS BI仪表盘）。当我们开始使用Adaptive Analytics时，我们通常希望有同样的功能。Adaptive Analytics拥有我们需要的所有工具。文档中包含了对如何使用开放的网络API的描述。用户界面和引擎之间的所有交互也都是通过内部的Web API发生的，并且可以被发射出来。

有必要将这两个过程自动化：在容器中部署Adaptive Analytics和直接部署到服务器系统。为此，最简单的方法是使用bash脚本来处理API。我们唯一需要的第三方应用程序是一个名为jq的JSON文件解析器。你可以使用以下命令来安装它：

apt update
apt install -y jq

首先，我们需要登录以获得一个API访问令牌。这个令牌也适用于引擎本身的方法。我们必须将访问令牌保存在一个变量中，因为现在我们几乎在每个请求中都需要它。对于一个标准的登录和密码admin/admin，该命令将看起来像这样：

TOKEN=$(curl -u admin:admin --location --request GET 'http ://localhost:10500/default/auth')

在我们开始谈论数据库和现有的不同数据模型之前，我们最好先谈谈什么是数据库以及如何使用它。

一个数据库是以电子方式存储和访问的有组织的数据集合。它用于存储和检索通常与主题或活动相关的结构化、半结构化或原始数据。
每个数据库的核心至少存在一个用于描述其数据的模型。并且根据它所基于的模型，一个数据库可能具有略微不同的特征并存储不同数据类型。

要写入、检索、修改、排序、转换或打印数据库中的信息，需要使用称为数据库管理系统 (DBMS) 的软件。

数据库及其各自的数据库管理系统的大小、容量和性能增加了几个数量级。各个领域的技术进步使之成为可能，例如处理器、计算机内存、计算机存储和计算机网络。一般来说，数据库技术的发展根据数据模型或结构分为四代：导航型、关系型、对象型和后关系型。

与以特定数据模型为特征的前三代不同，第四代包括许多基于不同模型的不同数据库。它们包括列、图、文档、组件、多维、键值、内存等。所有这些数据库都由一个单一的名称 NoSQL 联合起来（没有 SQL，或者现在更准确地说不仅仅是 SQL）。

而且，现在出现了一个新的类，叫做NewSQL。这些是现代关系数据库，旨在为在线事务处理工作负载（读写）提供与 NoSQL 系统相同的可扩展性能，同时使用 SQL 和维护 ACID。