.NET FHIR客户端连接Smile(HAPI) CDR服务器无法获取全部患者记录

这个问题我之前对接Smile CDR的时候也碰到过，大概率是服务器端的分页限制或者客户端续页逻辑的小问题，给你几个具体的排查方向和解决办法：

1. 先检查Smile CDR的搜索结果上限配置 #

Smile CDR默认会对搜索请求设置最大返回结果总数的限制，很多时候管理员会把这个值设为2000（刚好是你碰到的数量）。你可以登录Smile CDR的管理控制台，找到对应的FHIR存储模块，检查以下两个配置项：

• Maximum Total Results Per Search（对应配置键fhirstore.search.max_total_results）：如果这个值设为2000，那不管你怎么分页，最多只能返回2000条结果。把它调整为3235以上，或者设为0表示无限制。
• Default Page Size：这个是每页默认返回的条数，即使它设为2000，续页应该能拿到下一页，但如果上面的max_total_results设了2000，就会直接截断结果。

2. 替换客户端的Continue方法，手动处理续页链接 #

有时候.NET FHIR客户端的Continue方法在处理Smile CDR的续页链接时可能有兼容问题，你可以试试手动解析bundle里的next链接来请求下一页，代码可以改成这样：

var patients = new List<Patient>();
// 指定一个服务器允许的每页条数（比如500，避免单页数据过大）
var searchParams = new SearchParams().Count(500);
var bundle = await client.SearchAsync<Patient>(searchParams);

while (bundle != null)
{
    patients.AddRange(bundle.Entry.Select(e => e.Resource as Patient));
    // 手动获取下一页的链接
    var nextLink = bundle.Links.FirstOrDefault(l => l.Relation == "next")?.Url;
    if (string.IsNullOrEmpty(nextLink))
    {
        break;
    }
    // 直接请求下一页的bundle
    bundle = await client.GetAsync<Bundle>(nextLink);
}

这样可以绕过客户端内置的续页逻辑，直接用服务器返回的next链接请求，避免潜在的兼容问题。

3. 排查续页请求是否失败 #

你可以在循环里加一些日志，打印每次返回的bundle的条目数量，以及是否存在next链接。比如：

Console.WriteLine($"当前bundle包含{bundle.Entry.Count}条记录，是否有下一页：{nextLink != null}");

如果发现某次bundle返回后没有next链接，但总数量还没到3235，那可能是服务器在处理续页时出错了。这时候可以去Smile CDR的日志里找相关的错误信息，比如数据库查询超时、权限限制或者其他异常。

4. 用Postman直接测试API，定位问题来源 #

把.NET客户端的请求复制到Postman里，手动执行分页请求：

1. 先调用GET /Patient?_count=1000，查看返回的bundle里的条目数和next链接
2. 接着调用next链接，重复直到没有next，统计总条数
   如果Postman能拿到全部3235条，那问题出在.NET客户端的续页逻辑上；如果Postman也只能拿到2000条，那肯定是服务器的配置或者权限限制问题。

5. 检查是否有隐含的过滤条件 #

虽然你的请求是Patient/，但有些服务器或者客户端会默认添加过滤参数（比如_active=true），导致只返回部分患者。你可以在请求里显式添加_active=all来排除这个可能性，或者查看请求的实际URL（可以通过客户端的日志或者Fiddler抓包），确认没有额外的过滤参数。

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