据我所知没有。我相信这是因为..我认为解决方案（由问题暗示）不是一个好的解决方案/建议。

不仅因为散列函数可能会发生冲突（即使它的概率非常低，影响也会很大，所以我们为什么要添加这样的风险？），还因为你在散列之前还有一个问题：除非你解决了一些问题尚未完全解决（即语义互操作性），在医学档案中，您可以 - 例如 - 以几种不同的方式查找/制定完全相同的医学概念（即不同的文本序列可能意味着相同的事物/医学概念），因此在这些情况下，您会得到不同的哈希值相同的概念（！）。你将如何管理？您能否将所有这些不同的哈希映射到相同的医学概念？（过敏类型或其他）。你怎么说两个哈希真的意味着两个不同的东西......它们应该是什么东西？我相信您将无法预测我们语言中所有可能的不同方式，我们可以表达相同的概念，并且由此产生的散列值将在语义方面严重流动。

即使您选择在 med 配置文件中使用最好的术语和受控词汇或编码信息，它们仍然需要随着时间的推移持续维护和修订（由于版本控制等，例如别名、新概念输入、已弃用概念等） .) 所有会严重影响基于哈希值隐藏的概念的“决策支持系统”的有效性和可靠性的事情。因此，我认为将医学概念隐藏在哈希后面并仅根据哈希值做出决定并不是一个好主意。

此外，如果我授权我的医生访问我的病历，我希望他能够非常清楚地看到我的过敏是什么，他可以理解。你能想象你的医生看着应该映射的散列值与一些医学编码信息完全没有办法真正验证可能背后的真实概念吗？不是一个好主意。你要压缩吗？使用压缩算法。你想要安全吗？具有双向功能和身份验证基础设施等的用户加密（请记住，散列是一种“单向”功能）。只是继续对我们今天使用的那些东西使用散列（索引，更有效地检索项目，数字签名等），而不是隐藏/存储医学概念。我不会以这种方式进行创新。但可能是我错了。有更好的答案吗？

在这种情况下，散列不会很实用。不是因为冲突，因为良好的加密安全散列（例如SHA-2）不会有任何可能在野外以任何合理概率发生的冲突。问题是散列是单向的，因此为了推断您的条件，必须对所有可能的组合进行散列并与您的散列进行比较。

一种更有趣的方法是使用同态加密。同态加密允许您对加密数据进行某些类别的计算，例如计算平均值等。微软研究院在这篇论文中开发了一种非常有前途的方法。

您建议的这种设置存在一个根本缺陷，即它本质上容易受到知情猜测的影响。通过发送有针对性的请求，可以很快缩小可能条件的数量；这与医学诊断本身背后的过程完全相同。

有一个关于使用加密数据库的活跃研究领域，这样您就可以获得有关数据的一些部分信息，而无需对其进行解密。但是，部分信息可能非常具有启发性。例如，如果您有一个加密数字x并且可以提出诸如“ x是否大于 1000 ？”之类的问题。然后二分搜索将在几十个请求中以高精度显示x 。

这意味着这里设想的安全模型（医生是潜在的攻击者）是一个相当绝望的设置。（此外，它的实际意义相对较小：医生需要了解患者的所有病史才能正常工作。）

同态加密是一个独特的模型：通过加密数据计算事物的能力，从而获得加密结果。这对于将大部分计算工作卸载到功能强大但不受信任的系统很有用。但是谁能获得解密结果，谁就有权解密所有存储的数据，通过构造；所以这不是同一个模型。