【隐私保护合规】在医疗保健信息系统中执行数据保护影响评估的方法和工作流程,第四部

3.结果

3.4.软件实施

在MS Access（Microsoft Inc.，Redmond，WA，USA）中开发了一个特别软件，用于支持拟议DPIA方法的执行。

软件实现了技术文件夹（系统级记录）和技术表（应用程序/设备级记录）。技术文件夹介绍了复杂多组件系统的评估，其中综合方法对服务器端应用程序、客户端设备和其他连接设备有用，某些方面（如用例、制造商或供应商）是相同的。技术表用于评估单个组件的特定方面，例如单个设备归档系统框架中使用的敏感数据的方式。

技术文件夹（图4）由三个不同的页面组成。第一个（图4-A）包括系统和数据生命周期的简短描述，并使用突出显示参考文档的检查表来填写记录（通过页面右上方的“转到文档”按钮，该检查表也链接到记录）。此外，它还报告供应商参考和相关ROPA记录的参考。此页面表示系统的上下文定义。

Fig. 4. The technical folder (system level record). A- First page. B- Second page. C- Third page.

第2页（图4-B）总结了ROPA中定义的与数据处理相关的信息（例如范围、数据类型、收件人等）。页面底部的复选框表示机构网络内的集成类型，可以是“隔离系统”（在网络上运行但不共享任何资源的系统），也可以是“集成系统”（与医院信息系统共享基础设施资源的系统，如Active Directory、备份、存储库、虚拟服务器等）。第三页（图4-C）报告了概率/影响矩阵，以及风险评估背后原因的叙述性描述。

实现单个应用程序/设备记录的技术表分为不同的页面。第一个（图5-A）包含软件描述，以及根据CEI 62-237医疗软件指南的分类[17]。第2页（图5-B）报告了主要假设纠正措施的列表。例如，技术表的“措施描述”部分（图5-B）中记录了可能的静止和在途加密功能，并在工作流的风险评估和评估活动中予以考虑（图2）。第3页（图6-A）报告了医疗软件设备的已知可能关键性列表，而第4页（图6-B）报告了一个表，其中列出了个人数据的已识别威胁，每个威胁都有其发生概率的估计。最后一页（图7）记录了与个人权利和自由相关的风险评估，根据已识别威胁的实现及其估计概率。

Fig. 5. The technical sheet (application/device level record). A- First page. B- Second page.

Fig. 6. The technical sheet (application/device level record). A- Third page. B- Fourth page.

Fig. 7. The technical sheet (application/device level record) - Fifth page.

3.5.验证结果

在ASUGI使用的11台IT设备上测试了所提出的方法。表1报告了按照为技术表/文件夹提出的方法对每个应用程序/设备进行风险分析的结果。所有系统均被评估为低风险，只有三个系统被分类为中风险和高风险。主要的关键问题是缺乏适当的软件安全措施（例如，没有认证或授权控制）或数据安全措施（如，没有备份的本地存储）。由于我们不打算对商业产品提供具体判断，因此未提供有关11款软件的进一步详细信息。

Table 1. Testing results.

例如，我们描述了“核医学图像定量分析独立应用程序”的技术文件夹的内容，如图4、图5、图6和图7所示。这是一个由单个应用程序组成的系统，因此我们实现了技术文件夹和一个技术表。

在第一页（图4-A）中，我们报告了应用程序的用例：一个独立的桌面应用程序，它从文件系统加载DICOM文件，并执行一些特定的计算，生成一些报告。然后，编制带有可用文件的检查表：具体示例是一个正在评估的软件，因此所有投标文件都不可用，在数据工作流程的描述中，数据存储在本地文件夹中带有下划线。在第二页（图4-B）中，记录了处理范围——对核医学图像进行定量分析——以及相关人员：肿瘤患者和核医学医生——保留期——取决于用户的意愿。

应用程序/设备记录（图5）显示，该软件是根据CEI 32-237分类为D1的独立产品。安全分析解决了存储问题、PC上本地存档的数据以及缺乏认证。软件符合IHE配置文件。数据安全明确要求客户端主机策略完全由用户机构负责。这一假设似乎立即无法接受，因为如果应用程序能够适应基础设施和环境，则可以在机构责任下应用机构安全模型和政策。这在安装手册中不能被视为正确。

应用程序/设备记录的最后一页记录了设备的风险评估。“未经授权访问数据”事件被评为极有可能（因为上述身份验证问题），并与高度严重的影响相关（因为访问报告和PACS图像可能会对数据主体产生重大影响）。关于事件“数据不可用”，估计概率很高（因为本地存储），严重程度中等；已经假设，由于设备的目的（这是一种非常缓慢的疾病的诊断），数据主体的唯一后果是重复检查。

回到系统记录的第三页（图4C），最后的评估是红色的，因为缺乏数据保护和授权，使得在没有授权的情况下访问敏感数据非常容易，而且应用程序不符合机构信息安全模型/策略。

4.讨论和结论

在这项工作中，我们描述了一种特定于HIS的方法，该方法能够支持风险评估并执行DPIA。这种方法的主要贡献在于将信息系统而不是处理本身确定为分析对象。这在医疗环境中至关重要，因为涉及个人数据的过程非常复杂，否则很难追踪。此外，关注HIS环境中的系统/软件代表了一种模块化方法，允许处理不同系统的集成以及HIS组件的演变。事实上，在添加新的软件/系统时，不必重新设计整个过程，只需根据HIS评估此新软件/系统的风险和影响即可。

该方法在真实环境中成功应用，从而支持其有效性和突出可用软件/系统中的风险和批评的能力。

目前的一个限制是，威胁和风险没有标准化或分类，管理这种方法的组织流程尚未定义。更具体地说，从长远来看，医院组织中应该有一个特定的参与者负责维护和更新与DPIA相关的文件，并使用拟议的方法编制。

该方法可以是GDPR合规过程的一部分，这也需要评估是否符合规范要求和主体权利的保证。记录可以扩展，包括IEC80001[16]医疗IT网络风险管理文件的定义，该文件记录了连接到HIS网络的每个设备的风险管理过程。然而，这种扩展需要与其他行为者合作，其中包括临床工程办公室，因为规范还涉及系统的安全性和有效性概念。最后，记录可以记录AgID措施的实施情况[18]，这是意大利公共行政部门必须实施的一套控制措施，以确保最低水平的信息和通信技术安全。

总之，至少在短期内，开发的方法是适用的和可持续的，并且有可能扩展到更通用的数据和系统安全框架，这为确保欧洲医院的数据环境更安全奠定了基础。

道德声明

这项研究不包括人类或动物研究，也不需要伦理委员会的批准。