文章分类
3.结果
3.1.关键问题的定义
3.1.1.关键问题1：处理的定义
根据GDPR，DPIA应在单个处理或一组导致类似风险的类似处理上执行。因此，ROPA中定义的一个或多个处理是DPIA的主题（如果它们导致高风险）。
在医疗保健中，“处理”可能有多种定义：它可以指特定的护理路径，或指整个门诊环境，或指单个患者的单一诊断检查。
WP248[12]指南中引用的ISO/IEC 29134:2017[15]作为DPIA的参考，允许关注信息系统，而不是关注单个处理。本标准将PIA定义为评估处理个人数据的过程、信息系统、软件、软件模块、设备或实体的隐私潜在影响的工具[15]。
根据本标准，通过关注处理数据的信息系统，可以克服精确识别DPIA主题（“处理”）的关键问题。事实上，主要风险存在于涉及电子传输的数据流中，电子传输处理大量数据，并且可能受到不必要的访问。
3.1.2关键问题2：遵守个人权利和自由
在医疗保健领域，众所周知，数据的最重要特征之一是数据所有者（患者）与数据用户（医疗保健专业人员）不同。因此，并非构成PIA基本原则的所有权利（如第13-20条所定义）都适用于所有健康相关数据。医疗机构已经尽可能为患者提供了数据可访问性和可移植性方面的一些权利，但没有，例如，法律禁止的删除数据的权利。关于可访问性（第15条），患者通常有权要求复制其医疗数据（健康记录、报告等），但无权随时访问任何数据，相反，负责治疗患者的医疗专业人员也有权这样做。关于可移植性（第20条），这取决于确保系统互操作性的标准的可用性，从而限制了可移植数据的类型（例如，使用DICOM的诊断图像是可移植的，而不符合HL7-CDA2的记录是不可移植的）。
由于这些原因，不可能将PIA方法的第2步（保证符合基本原则的措施的定义）应用于医疗数据，因此这被排除在我们开发的方法之外。保证遵守基本原则的措施可以在单独的分析中处理，并且仅适用于这些数据和文件。
因此，技术表将仅记录与数据安全相关的风险评估，如PIA方法的步骤3所述，尽管稳健的数据安全将有助于实现这些原则。
3.1.3关键问题3：对个人的影响
在定义对个人的影响时，PIA方法定义了三种类型的影响：物理、物质和心理。一般来说，对个人的影响很难估计，因为它取决于对损害的主观感受。此外，健康数据丢失可能会影响个人的健康：例如，丢失放射图像可能会导致重复检查，从而增加对个人的电离辐射水平，或者在紧急情况下，重复检查所损失的时间可能对干预至关重要。DPIA分析中不能充分考虑这些类型的影响，因为它们对于单个信息的上下文而言过于具体，可能包含在“信息业务连续性计划”中。后者是运营内部数字服务的公共卫生机构的强制性文件，应评估企业服务每一次损失的潜在损害，并在技术和经济层面上提供适当措施，以减轻服务损失的影响。
3.2.收集信息的定义
一般而言，风险评估的主题可以是支持临床活动的信息系统，例如公开招标后提供的系统，其可以包括具有共同目的的不同设备（例如，实验室系统），或具有类似特征的一系列不同设备（例如，一系列超声扫描仪）。在选择评估主题时，需要在应用严格和系统的方法与评估的复杂性、可持续性和评估过程的适用性之间进行权衡。
在任何情况下，对于构成系统的每个应用程序/设备，收集所有相关文档，作为风险分析的起点。参考文件可以从技术报价文件开始，以及使用手册、CE符合性声明、安装细节、合同条款中定义的技术要求、责任协议、MDS2和GDPR合规性完成。可能需要联系制造商，以获得所实施缓解措施的具体细节。
3.3.执行DPIA的工作流
我们建议使用针对技术资产而非处理本身的模块化方法在系统上执行DPIA：对于每个信息系统，我们建议创建一个技术文件夹，以评估与该系统相关的风险，并由技术表组成，每个设备或模块组成系统本身。换言之，我们建议从对系统中包含的每个单个技术资产（单个技术表）的分析开始执行系统DPIA，并将其组合在DPIA（技术文件夹）下的系统技术文件夹中，以便在同一资产涉及另一上下文时重新使用技术表。这具有适用于由同一技术系统管理的所有处理的优点，从而使它们以多对多的关系独立：每个处理可以与一个或多个技术表相关联，每个技术表可以与一种或多种处理相关联。
3.3.1.DPIA描述工作流程
图2显示了在由不同应用程序/设备组成的系统上执行DPIA过程的拟议工作流。
Fig. 2. Workflow of information collection for the Data Protection Impact Assessment.
DPIA的起点是医疗机构的安全模型，每个系统/设备都应遵守该模型，以确保风险缓解。因此，工作流从处理上下文的定义和描述开始；这可能包括可能影响流程的技术、组织和法律方面。
然后，对于构成系统的每个应用程序/设备，从收集所有相关文档开始，通过实施风险分析来定义技术表。技术说明书必须在实施信息系统的机构背景下评估信息系统，而不是评估系统本身的安全性，因为系统或设备在连接到医院网络时，可能会导致独立解决方案无法识别的风险，如IEC 80001-2[16]所述。
在确定关键性以及特定应用程序/设备的威胁之后，根据事件发生的概率和影响的严重程度，并具体参考个人的权利和自由，对三个不希望发生的事件（包括机密性、完整性和可用性）中的每一个事件估计风险级别。如果评估在分析的全面性方面令人满意，该过程将继续评估适当的缓解措施。否则，在收集更多信息后，将重复应用程序/设备的分析。
以模块化方式分析所有应用程序/设备后，将创建技术文件夹，并根据组织的标准（如政策、业务策略、风险偏好）接受或拒绝由所有应用程序和设备技术表组成的系统的总体剩余风险。在后一种情况下，在应用程序/设备上实施进一步的措施，以降低系统的风险。如果剩余风险被接受，DPIA将被正式记录和验证，组织必须在系统的整个生命周期中管理和监控风险。应分析环境中的每个变化，以监控风险并更新DPIA。
3.3.2.在医院采购流程中集成工作流
通过技术表的评估过程必须纳入医院采购流程（图3）。
Fig. 3. Integration of single application/device assessment in hospital procurement processes.
技术表应在系统获得后（通常通过公开招标）以及安装和验收测试前编制。这对于在系统实施之前获得必要的变更以降低风险至关重要。
只有在剩余风险被认为是可接受的情况下，才能进行安装和验收测试。相反，如果风险仍然不可接受，则需要制造商采取纠正措施，并重复评估，直到风险变得可接受为止。如果剩余风险被判定为不可接受，机构应有权拒绝系统安装。在任何情况下，如果IT规范定义明确，则不可接受系统的剩余风险非常低。
对于已在使用的系统，流程如绿色矩形所示（图3）。在这种情况下，用于分析的可用文件可能不足，制造商不太可能获得所需的更改（取决于初始合同）。
- 登录 发表评论