我需要在我们的临床存储库中实现FHIR API。由于我们的数据是从多个来源存储的，因此每个临床数据/行为都用System + ID对表示，其中系统通常由OID表示。例如患者标识符 {1.4.7.9.9，MRN123}
问题是如何从客户的角度处理这些资源
我的选择是：
1. h_t_t_p：//BaseUrl/1.4.7.9.9/Patient/MRN123 / ... - 其中 h_t_t_p：//BaseUrl/1.4.7.9.9 将是设置为基地址和路径，所有资源都将在其上进行评估
2. h_t_t_p：//BaseUrl/Patient/1.4.7.9.9+MRN123 / ... - 系统和ID的串联。这种方法最不受欢迎，因为消费者通常不了解systemId（在选项1中 - 我们将为他提供要使用的baseUrl。）
3.＆＃34;标准＆＃34; URL模式h_t_t_p：// BaseUrl / Patient / MRN123 / ...在HTTP请求的标头中将System作为自定义属性。
感谢您的想法和其他选择（如果有的话），以解决该问题
感谢
答案 0 :(得分：0)
选项3不符合要求，因为它会导致冲突的密钥 - URL本身在服务器中必须是唯一的。
选项1本质上需要一个不同的FHIR端点（具有自己的一致性声明和处理查询的能力等）。这对您和其他实施者来说似乎都是一种痛苦（所有实施者都会与您交谈）需要知道所有基本网址，他们必须搜索所有端点以查找所有患者等。）
因此留下选项2.我不明白为什么这是不受欢迎的。作为一般规则，资源ID类似于数据库主键。在他们搜索您的系统之前，没有外部系统知道它们是什么。 FHIR系统的客户端不能依赖任何特定的资源ID方案 - 在许多服务器上它们是随机的guid。因此，搜索是针对业务标识符执行的 - 在您的情况下，我希望有一个“标识符”元素也包含患者标识符 - 即使它也以错位形式表示为“id”。然后你可以搜索[base] / Patient？identifier = MRN123，虽然有可能找回多个匹配。
旁注：你不能在标识符中使用“+” - 所以我建议1.4.7.9.9：MRN123。