TrueVault的去身份识别过程是如何工作的？

Question

我正在考虑使用TrueVault，但我并不完全确定去识别数据和重新识别数据所涉及的事件顺序。更多信息，这里。这就是我所理解的过程，但我不知道具体的顺序是什么：

1. PHI存储在符合HIPAA的TrueVault服务器中.TrueVault返回一个不透明标识符，该标识符可以与未识别的数据一起存储在AWS中。
2. 为了获取这些数据，数据从两个不同的来源返回: TrueVault服务器和AWS，其中正在对数据集进行分析。这是同时发生的吗？先发生什么？
3. 若要提取非标识符，将向AWS服务器发出请求，该服务器还将返回不透明标识符。然后，向TrueVault服务器发出请求，以标识与不透明标识符关联的用户。这是正确的顺序吗？
4. 当经过身份验证的用户请求时，数据将在客户端应用程序中重新标识。

这里的事件顺序是什么？PHI数据首先被发送到TV服务器，然后一个不透明的标识符与分离的数据一起发送给AWS吗？客户端应用程序在任何时候都有哪些信息？如能澄清这一进程，将不胜感激。

Answer 1

TrueVault建议做数据去识别和重新识别客户端(在您的web或移动应用程序逻辑中)。这就产生了两个有趣的流：

De-Identification

1. 数据由用户输入到应用程序中。
2. 您的应用程序(例如浏览器中的JavaScript代码或iOS设备上的Swift代码)将将该数据拆分为标识的内容(姓名、电话号码等)和未标识的数据(其他健康数据)。
3. 标识信息通过TrueVault API从客户端应用程序直接发送到TrueVault。理想情况下，最终用户被认证为TrueVault用户，因此API权限可以进行粒度定义。API返回一个不透明标识符，该标识符可以与未识别的数据关联并存储在您的服务器上。
4. 未识别的健康数据(以及TrueVault id)被发送到您的服务器。您的服务器不处理标识数据和健康数据，因此它不属于HIPAA法规的范围。

Re-identification

假设您的终端用户希望根据存储在服务器上的标准(例如血压)搜索数据，但是他们希望看到结果集中的标识数据。这种重新识别应该发生在客户身上。类似于：

1. 客户端设备向服务器发出请求，以检索与查询匹配的信息。
2. 客户端设备从服务器结果中提取TrueVault ids。这些if是不透明的，不是标识的，但它们可以用于从TrueVault API检索标识数据(如果正确验证的话)。
3. 客户端设备请求从TrueVault API中识别与服务器返回的TrueVault ids相对应的数据。理想情况下，最终用户被认证为TrueVault用户，因此API权限可以进行粒度定义。
4. 客户端设备合并数据集，使UI显示数据的重新标识视图。

法规

按照这些步骤，您可以创建无缝的用户体验。最终用户没有理由知道您正在取消识别和重新识别数据。

此过程旨在使您的服务器基础设施不受HIPAA规则的影响，因此如果您愿意，可以以不兼容的方式承载这些未识别的数据。这都是上上下下的HHS，他们甚至有具体的指导：https://www.hhs.gov/hipaa/for-professionals/privacy/special-topics/de-identification/index.html.

通过避免将已识别的PHI存储在服务器上，您可以跳过应用于服务器端基础结构的物理和技术保护。请理解，您没有完全逃避HIPAA的管理要求。例如，在上面所述的系统中，仍然有人在观察已识别的PHI。必须对这些人进行培训，必须限制他们从事工作所需的最低数量。如果您正在开发一个必须符合HIPAA的应用程序，无论您是否使用TrueVault，所有这些工作都是非常困难的。TrueVault为您节省的全部工作是拥有安全和兼容的基础设施，用于存储数据、维护审计日志、安全备份、高可用性、控制访问、管理用户等等。