如果您试图遵守和/或避免美国 HIPAA 下的违规通知规则，那么在您的数据库中混淆数据关系对您毫无帮助。

根据 HIPAA，如果数据被加密，您无需通知患者/保险公司/等有关违规行为。但是，加密意味着它是使用符合 FIPS 140-2 的密码进行加密的，并且只有该加密数据是由第三方获得的。

在数据库上，您可以使用透明数据库加密或第三方加密套件等工具。这意味着如果有人获得了数据库的副本，它将是符合 FIPS 140-2 的加密，因此不会触发违反通知或 HIPAA 下的其他后果。

然而，在 HIPAA 下，仅仅拥有一个难以理解的数据库并没有涵盖，而且隐匿性安全不会为您赢得 CMS 审核的任何分数......即使您解释隐匿性是 HIPAA 要求的“补偿控制” .

此外，虽然安全通常意味着将未经授权的个人拒之门外，但对于保存 PHI 数据的组织来说，下一件最糟糕的事情就是丢失该数据。拥有具有复杂关系的数据库很容易丢失该数据，并且在处理 HIPAA 时应将数据的完整性视为安全问题。

请注意，透明的数据库加密或其他在线加密方法对数据库的在线入侵（例如通过 SQL 注入）几乎没有作用。如果有人通过运行 SELECT * 语句获得数据库转储，则不会加密此数据。为此，您需要保护/分割您的数据库用户，并研究保护前端 Web 应用程序的最佳实践。

简而言之，以某种方式加密数据库；但数据库加密应该只是更大的 HIPAA 合规策略的一小部分。但是，隐匿性安全不应成为您的安全策略的任何部分。

您要求最好，让我首先将我的回答限定为最好，从某种意义上说，我尽最大努力让您可能更有信心做出自己的选择。由于“最佳”可能是相当主观的，而且我不是万能的知道者，我很确定可以找到另一个最佳答案。

我还想引用AviD 的可用性规则：

以牺牲可用性为代价的安全是以牺牲安全为代价的。

（虽然与此没有直接联系，但我确实想指出它，如果只是提一下，如果您破坏可用性，那么一切都是徒劳的）

我的第一个想法是“哦不，你的整个数据库都被盗了！”。我希望您的首要任务是防止这种情况发生（我不知道您是否真的担心这一点，或者它是否只是在为最坏的情况做计划）。然后尽一切必要努力隐藏所有必需的数据。您可以隐藏而不会显着影响性能的任何其他数据都是肉汁。

在我的时间里，我已经完成了非常少量的 HIPAA，并且发现一些规则可能是故意模糊的。我认为这是为了允许使用新技术，而不必更改规则或其他东西。

简而言之，如果您的情况需要混淆 id ，那么您必须这样做（要求就是要求），如果没有，那么如果您觉得难度和性能损失是可以忍受的，那么您可以这样做。首先遵循要求。超越有意义的地方。

在您的情况下，似乎为了使未来的维护变得更加困难而付出所有额外的麻烦似乎是没有意义的。专注于保护数据库本身，同时仅在必填字段上维护加密/混淆可能是更好的利用时间。你可以随心所欲地混淆 id，但如果数据库很容易被盗，那又有什么意义呢？

PS：我不是律师，也不会在电视上播放。如果您实际上正在处理 HIPAA，请确保您自己检查 HIPAA 要求。

这最终是一个糟糕的想法，并且会在数据完整性方面付出代价。被掩盖的数据关系是会被破坏且不可靠的数据关系。它甚至不会让你更安全。默默无闻只能保护最温和的好奇心。看看破解模糊系统的悠久历史就可以证明这一点。

这种方法将导致预约丢失，可能会导致与错误的医生进行预约，并且系统通常不可靠。

一般来说，这些类型的要求（HIPPA、PCI 等）是由非技术人员编写的，并且可以进行广泛的解释。

询问驱动需求的人他/她是否愿意为了安全而牺牲系统的完整性和可靠性。这基本上就是所要求的。我的猜测是，如果有人要求诸如“模糊数据库表 ID”之类的疯狂事情，那么他们将 HIPPA 解释为一种非常狭隘的方式。

我的一般建议是找一个有专业知识的人来解释你实际可以做什么的 HIPPA 要求，而不是试图在最严格的意义上解释它。

刚开始为我正在构建的即将到来的应用程序研究 HIPPA 合规性，从我看到的情况来看，您对规则/法规的要求有点过火了。就混淆您的数据而言，主要要求之一是保护您的电子受保护健康信息或 (ePHI) 这包括姓名、SSI 号码或私人或患者敏感数据等内容。您的数据库中的一个内部 ID 不属于此类别，并且试图混淆它只会给您带来整个世界的问题，而不会完成任何事情。例如，如果发生了一些数据泄露并且他们看到 ID 5 与 id 8 相关联，那么对于没有其他一些个人数据的人来说，这对任何人来说都没有多大意义，这些数据将被加密。

同样，我可能不是最好的来源，因为我也只是在学习 HIPPA 合规性，但我对 PCI 合规性了解很多，而且它们看起来非常相似。