在 EPIC FHIR 上搜索患者
search Patient on EPIC FHIR
我想弄清楚患者在 EPIC FHIR 上的搜索效果如何。
在此处的沙箱上测试所有内容：https://fhir.epic.com/Documentation?docId=testpatients.
文档：
Starting in May 2019, Patient.Search requests require one of the following minimum data sets by > default in order to match and return a patient record:
- FHIR ID
- {IDType}|{ID}
- SSN identifier
- Given name, family name, and birthdate
- Given name, family name, legal sex, and phone number/email
这工作正常（返回一名患者）：
/api/FHIR/R4/Patient?family=Lin&given=Derrick&birthdate=1973-06-03
但这也返回相同的记录（家庭中的额外角色，错误的性别）
:
/api/FHIR/R4/Patient?family=Lina&given=Derrick&birthdate=1973-06-03&gender=female
另外这个返回一条记录（家族中的额外字符，没有名字）：
/api/FHIR/R4/Patient?family=Lina&birthdate=1973-06-03
不确定我做错了什么，或者这是预期的行为？
我很惊讶最后一个搜索返回任何结果，但对于前两个搜索，这对于 Epic 来说是完全可能的，甚至是意料之中的。 Epic 在后台有特殊的逻辑，会根据某些标准评估您传入的参数值，例如名称是否完全匹配，名称是否相似，出生日期是否完全匹配等。因此，通常不仅完全匹配而且Patient.Search API 将返回相似的匹配项。标准的权重可由 Epic 客户自定义，因此有些标准的逻辑可能比其他标准更严格。
我建议始终根据您的输入参数验证返回的结果，以验证您使用的是完全匹配。
这里有一堆历史，但 Epic 当前的 Patient.search 表现得更像 Patient.$match。具体来说，提供给 Patient.search 的标准使用（近似）OR 逻辑而不是 AND 逻辑组合。在幕后，它实际上更多的是加权分数，但最终，你提供的标准越多，你可能得到的结果就越多。如果您习惯于 REST API 查询参数的正常工作方式，这通常是违反直觉的。从技术上讲，它是规范合法的，因为 FHIR 有一个关于服务器能够 return 它认为合适的其他适当结果的宣传。
https://build.fhir.org/search.html#Introduction
However, the server has the prerogative to return additional search results if it believes them to be relevant.
我们现在没有任何具体的更新，但很快 (tm) 可能会有变化。
我想弄清楚患者在 EPIC FHIR 上的搜索效果如何。 在此处的沙箱上测试所有内容：https://fhir.epic.com/Documentation?docId=testpatients.
文档：
Starting in May 2019, Patient.Search requests require one of the following minimum data sets by > default in order to match and return a patient record:
- FHIR ID
- {IDType}|{ID}
- SSN identifier
- Given name, family name, and birthdate
- Given name, family name, legal sex, and phone number/email
这工作正常（返回一名患者）：
/api/FHIR/R4/Patient?family=Lin&given=Derrick&birthdate=1973-06-03
但这也返回相同的记录（家庭中的额外角色，错误的性别） :
/api/FHIR/R4/Patient?family=Lina&given=Derrick&birthdate=1973-06-03&gender=female
另外这个返回一条记录（家族中的额外字符，没有名字）：
/api/FHIR/R4/Patient?family=Lina&birthdate=1973-06-03
不确定我做错了什么，或者这是预期的行为？
我很惊讶最后一个搜索返回任何结果，但对于前两个搜索，这对于 Epic 来说是完全可能的，甚至是意料之中的。 Epic 在后台有特殊的逻辑，会根据某些标准评估您传入的参数值，例如名称是否完全匹配，名称是否相似，出生日期是否完全匹配等。因此，通常不仅完全匹配而且Patient.Search API 将返回相似的匹配项。标准的权重可由 Epic 客户自定义，因此有些标准的逻辑可能比其他标准更严格。
我建议始终根据您的输入参数验证返回的结果，以验证您使用的是完全匹配。
这里有一堆历史，但 Epic 当前的 Patient.search 表现得更像 Patient.$match。具体来说，提供给 Patient.search 的标准使用（近似）OR 逻辑而不是 AND 逻辑组合。在幕后，它实际上更多的是加权分数，但最终，你提供的标准越多，你可能得到的结果就越多。如果您习惯于 REST API 查询参数的正常工作方式，这通常是违反直觉的。从技术上讲，它是规范合法的，因为 FHIR 有一个关于服务器能够 return 它认为合适的其他适当结果的宣传。
https://build.fhir.org/search.html#Introduction
However, the server has the prerogative to return additional search results if it believes them to be relevant.
我们现在没有任何具体的更新，但很快 (tm) 可能会有变化。