# 健康记录模型上下文协议服务器
## 基本信息
- Slug: `jmandel-health-record-mcp`
- Source: modelscope
- Publisher: @jmandel/health-record-mcp
- Categories: health-and-wellness / databases
- Hosted: No
- License: MIT License
- Source URL: https://www.modelscope.cn/mcp/servers/@jmandel/health-record-mcp
## 简介
一个模型上下文协议服务器，通过使用SMART on FHIR将人工智能工具与电子健康记录连接起来，允许对兼容电子健康记录中的患者数据进行安全的搜索、查询和分析。
## 安装提示

```bash
# 示例：提取数据并保存到 data/my_record.sqlite bun run src/cli.ts --create-db --db ./data/my_record.sqlite ``` 按照提示（在浏览器中打开链接）连接到您的EHR。 2. **运行MCP服务器：** 一旦数据库文件创建完成，再次运行CLI，仅指向数据库文件。这将把数据加载到内存中，并启动MCP服务器，在标准输入/输出上监听命令。
```

## MCP Server 详情

# EHR Tools with MCP and FHIR
![EHR Tools Overview](static/overview.png)

[https://youtu.be/K0t6MRyIqZU?si=Mz4d65DcAD3i2YbO](https://youtu.be/K0t6MRyIqZU?si=Mz4d65DcAD3i2YbO)

该项目充当一个专门的服务器，为大型语言模型（LLMs）和其他AI代理提供与电子健康记录（EHRs）交互的工具。它利用**SMART on FHIR**标准进行安全的数据访问，并通过**模型上下文协议（MCP）**来暴露这些工具。

可以将其视为一个安全的网关和工具包，使AI能够安全地访问和分析来自不同EHR系统的患者数据。

## 核心理念

系统的工作分为三个主要阶段：

1. **SMART on FHIR 客户端（在本项目中实现）：** 使用标准的SMART App Launch框架安全地连接到EHR。它提取广泛的患者信息，包括结构化数据（如病情、药物、实验室结果）和非结构化的临床笔记或附件。
2. **MCP 服务器（本项目）：** 将提取的EHR数据通过一组强大的工具公开，这些工具可以通过模型上下文协议访问。这些工具允许外部系统（如AI模型）查询和分析数据，而无需直接访问EHR本身。
3. **AI / LLM 接口（外部消费者）：** AI代理或大型语言模型连接到MCP服务器，并使用提供的工具对患者的记录“提问”，执行搜索或运行自定义分析。

## 可用工具

MCP服务器提供了几个用于与加载的EHR数据交互的工具：

*   `grep_record`：在整个获取的记录（结构化FHIR数据+笔记/附件中的文本）中执行文本或正则表达式搜索。适用于查找关键词或特定提及（例如，“糖尿病”、“阿司匹林”）。
*   `query_record`：直接针对结构化FHIR数据执行只读SQL `SELECT` 查询。对于基于已知FHIR资源结构的精确查找非常有用（例如，通过LOINC代码查找特定的实验室结果）。
*   `eval_record`：在获取的数据（FHIR资源+附件）上直接执行自定义JavaScript代码。为复杂计算、组合多个来源的数据或自定义格式提供最大的灵活性。

这种设置使AI工具能够通过标准化和安全的接口利用全面的EHR数据。

*(开发人员设置和使用细节可以在代码库和特定模块文档中找到。)*

---

## 组件与使用

该项目提供了不同的方式来获取EHR数据并通过MCP工具公开：

### 1. 独立的SMART on FHIR Web客户端

该项目包含一个独立的Web应用程序，允许用户通过SMART on FHIR连接到他们的EHR并获取数据。

*   **托管版本：** 您可以使用公开托管的版本：\
    [`https://mcp.fhir.me/ehr-connect#deliver-to-opener:$origin`](https://mcp.fhir.me/ehr-connect#deliver-to-opener:$origin) \
    （将 `$origin` 替换为实际打开此链接的窗口的源）。
*   **工作原理：** 打开此页面时，会提示用户选择他们的 EHR 提供商。然后它会启动标准的 SMART 应用启动流程，将用户重定向到其 EHR 的登录页面。成功认证和授权后，客户端会获取一套全面的 FHIR 资源（如患者、状况、观察结果、药物、文档等），并尝试从任何关联的附件（如在 `DocumentReference` 中找到的 PDF、RTF、HTML 等）中提取纯文本。
*   **数据输出 (`ClientFullEHR`)：** 获取完成后，客户端会将所有数据汇总成一个 `ClientFullEHR` JSON 对象。该对象包含：
    *   `fhir`：一个字典，其中键是 FHIR 资源类型（例如，“Patient”），值是相应的 FHIR 资源数组。
    *   `attachments`：一个已处理的附件对象数组，每个对象包括元数据（源资源、路径、内容类型）以及内容本身（`contentBase64` 用于原始数据，`contentPlaintext` 用于提取的文本）。
*   **数据传递：** 如果通过 `#deliver-to-opener:$origin` 哈希打开，则客户端会提示用户确认，然后使用 `window.opener.postMessage(data, targetOrigin)` 将 `ClientFullEHR` 对象发送回打开它的窗口。

### 2. 通过 Stdio 的本地 MCP 服务器 (`src/cli.ts`)

这种模式非常适合于本地运行 MCP 服务器，常与 Cursor 或其他命令行 AI 客户端工具一起使用。

*   **两步过程：**
    1.  **将数据提取到数据库：** 首先，使用 `--create-db` 和 `--db` 标志运行命令行界面。这将启动一个临时的Web服务器，并使用上述相同的SMART on FHIR Web客户端逻辑来获取数据。与通过 `postMessage` 发送数据不同，它会将 `ClientFullEHR` 数据保存到本地SQLite数据库文件中。
        ```bash
        # 示例：提取数据并保存到 data/my_record.sqlite
        bun run src/cli.ts --create-db --db ./data/my_record.sqlite
        ```
        按照提示（在浏览器中打开链接）连接到您的EHR。
    2.  **运行MCP服务器：** 一旦数据库文件创建完成，再次运行CLI，仅指向数据库文件。这将把数据加载到内存中，并启动MCP服务器，在标准输入/输出上监听命令。
        ```bash
        # 示例：使用保存的数据启动MCP服务器
        bun run src/cli.ts --db ./data/my_record.sqlite
        ```
*   **客户端配置（例如，光标）：** 配置您的MCP客户端以执行此命令。**至关重要的是，对 `src/cli.ts` 和数据库文件都使用绝对路径。**
    ```json
    {
      "mcpServers": {
        "local-ehr": {
          "name": "本地EHR搜索",
          "command": "bun", // 或者bun的绝对路径
          "args": [
              "/home/user/projects/smart-mcp/src/cli.ts", // cli.ts的绝对路径
              "--db",
              "/home/user/projects/smart-mcp/data/my_record.sqlite" // 数据库文件的绝对路径
            ]
        }
      }
    }
    ```

### 3. 通过SSE的完整MCP服务器 (`src/sse.ts` / `index.ts`)

这种模式运行一个持久化的服务器，适用于多个客户端可能通过网络连接的场景。它使用Server-Sent Events (SSE) 作为MCP通信通道。

*   **认证：** 客户端认证依赖于Model Context Protocol指定的OAuth 2.1。服务器提供标准端点（如 `/authorize`、`/token`、`/register` 等）。
*   **数据提取：** 当客户端发起OAuth连接时，服务器自己处理SMART on FHIR流程，在授权过程中获取 `ClientFullEHR` 数据，并在整个客户端连接期间将其保留在内存中（或持久化会话中）。
*   **状态：** 尽管功能可用，但MCP规范对于OAuth 2.1客户端交互仍在发展中。目前，客户端对该认证方法的支持**极其有限**，使得除了专门的开发者或调试工具外，很难用标准客户端测试这种模式。应将此SSE模式视为**实验性**。