如何将SQL Server数据全量及增量迁移至Azure API for FHIR托管服务器？

• 批量抽取与转换：从SQL Server导出所有历史患者数据，把你手动转换FHIR资源的逻辑封装成批量处理脚本（C#、Python或SSIS均可）。写SQL查询拉取全量患者记录，遍历结果集逐条映射成Patient资源的JSON结构，最后将多个资源打包成Bundle格式。
• FHIR批量接口提交：调用Azure API for FHIR的$batch或$transaction端点批量插入资源。示例Bundle结构如下：

{
  "resourceType": "Bundle",
  "type": "batch",
  "entry": [
    {
      "request": {
        "method": "POST",
        "url": "Patient"
      },
      "resource": { /* 患者资源JSON */ }
    }
    // 更多患者资源条目
  ]
}

建议每次批量提交100-500条，避免单请求过大导致限流或超时。

• 错误重试机制：批量请求可能出现部分资源提交失败，需将失败的资源ID和错误信息记录到SQL Server日志表，后续单独重试这些条目，保证数据完整性。

• 增量数据识别：给SQL Server患者表添加LastModified datetime字段，EMR新增或更新数据时自动更新该字段。同步时仅拉取LastModified > 上次同步结束时间的记录。若无法新增字段，也可使用IsSynced bit标记，但此方式无法处理更新数据，优先推荐时间戳方案。
• 定时触发同步任务：用SQL Server Agent Job、Azure Automation Runbook或Windows任务计划，每天固定低峰期（如凌晨）触发同步脚本。脚本逻辑为：拉取增量数据→批量转换为FHIR资源→提交到FHIR服务器。
• 幂等性保障：同步时通过患者唯一标识（如SQL患者ID作为FHIR Patient的identifier）调用GET Patient?identifier=XXX检查资源是否存在。存在则用PUT请求更新，不存在则用POST创建，避免重复插入。
• 同步状态跟踪：创建同步日志表，记录每次同步的开始/结束时间、成功条数、失败条数、上次同步的最大LastModified值，方便排查问题和断点续传。

• 并行处理：若增量数据量较大，可将数据分成多个小批次并行提交，但需注意Azure API for FHIR的请求限制，避免触发限流。
• 预验证资源格式：转换后用FHIR验证工具批量检查资源格式，提前发现错误，降低提交后的失败率。
• 监控与告警：通过Azure Monitor监控FHIR服务器请求状态和同步脚本执行日志，出现失败时及时触发邮件或短信告警。

内容的提问来源于stack exchange，提问作者Kedarnath Shinde