整合跟踪器和汇总数据{ #integrating-tracker-and-aggregate-data }¶
大多数部署 DHIS2 的政府和其他组织都同时使用总体和个体（跟踪器）功能。在 DHIS2 中，它们由不同的数据模型表示，数据收集和分析应用程序及应用程序接口也各不相同。然而，在许多使用案例中，需要或需要将这两类数据整合在一起，本指南讨论了实现这一点的不同方法。此类用例包括
- 确保使用 DHIS2 Tracker 实施的各种个人层面的系统（如病例监测、免疫登记等）能够向国家 HMIS（汇总）提供数据。
- 通过跟踪计划和综合数据集收集的数据可能是互补的。例如，如果跟踪系统被用作免疫接种电子登记册，那么在计算免疫接种覆盖率时，就需要将通过跟踪系统收集的服务数据与通常作为综合（年度）数据提供的人口估计数结合起来。
- 在许多情况下，跟踪器的实施是分阶段进行的，首先在某些类型的卫生设施或按地理区域实施。因此，同样的数据可能在某些地点使用追踪器收集，而在其他地点则作为汇总数据收集，要获得完整的数据概览，就需要将追踪器数据和汇总数据结合起来。这种区别对待或混合方法也可能是永久性的。
- 通过跟踪器收集的数据可能与既定的综合报告有部分重叠。例如，疟疾相关活动月度报告可能既包括疟疾病例信息，也包括蚊帐发放等预防活动信息。如果疟疾病例登记采用跟踪器，则疟疾月度报告可根据跟踪器数据部分完成，但仍需提供预防活动的汇总报告。
- 当在一个计划领域（免疫接种、艾滋病等）引入跟踪系统时，如果之前已经收集了综合数据，要确保数据在一段时间内具有可比性，就必须将综合数据和跟踪系统数据结合起来，以便进行纵向数据分析。
- DHIS2 中的某些数据质量检查仅适用于汇总数据。因此，要对跟踪数据进行这些检查，就必须首先将其汇总并作为汇总数据元素存储。
有几种方法可以实现这一目标，适用于不同的目的，各有利弊。DHIS2 核心功能支持的主要方法有
- 在分析/仪表板中并排合并跟踪数据和汇总数据。这种方法很容易实现，但它假定 >* 在同一个 DHIS2 实例中可以获得汇总数据和跟踪数据。此外，这种方法还限制了分析的类型。
- **使用同时参考跟踪计划指标或数据元素和 >*汇总数据元素的汇总指标**来合并跟踪和汇总数据。这需要更多的配置才能运行，而且还假设所有数据都在同一个 DHIS2 实例中。
- 将汇总的跟踪器数据保存为汇总数据值，即把数据从跟踪器数据模型移到汇总数据模型（→DHIS2 社区通常称为 "跟踪器到汇总 "）。这涉及到最全面的配置和支持服务的持续维护。然而，这也是最灵活的方法，可以进行最全面的数据分析，并支持在不同的 DHIS2 实例中收集跟踪器和汇总数据的常见情况。
本指南的重点是最后一种方法，我们相信这将是大多数 DHIS2 实施的首选方法。还有其他一些整合跟踪器和汇总数据的方法，它们依赖于自定义脚本、手动数据传输或使用各种第三方工具和应用程序。在此不作讨论。
将汇总的跟踪器数据保存为汇总数据值{ #save-aggregated-tracker-data-as-aggregate-data-values }¶
使用 DHIS2 的核心功能将汇总跟踪器数据保存为汇总数据值涉及一些关键步骤：
- 定义如何汇总跟踪器数据，即如何计算不同类型的事件和活动。这需要使用*计划指标*和（从 DHIS2 v42 开始）计划指标分类。
- 在跟踪数据（计划指标）和汇总数据（数据元素）之间建立*映射。这需要使用分配给计划指标和数据元素的代码或标识符。在实践中，计划指标的定义和配置以及与数据元素的映射通常是反复进行的。
- 设置*汇总数据交换*，准确定义要传输的数据：特定变量、组织单位和时间段。这可以通过应用程序接口或使用数据交换应用程序完成。数据交换可以手动进行，也可以计划运行，例如每晚一次，数据交换可以在一个 DHIS2 实例内进行，也可以在两个不同的实例之间进行。
实例：带有跟踪程序的 DHIS2 实例与带有汇总数据的 DHIS2 HMIS 实例之间的信息流](resources/images/Aggregate_Exchange.png){.center width=50%}
确定计划指标和分类{ #defining-program-indicators-and-disaggregations }¶
如果使用 DHIS2 v42 或更高版本，则通过配置计划指标和（相关情况下）*计划指标分类*来确定如何汇总来自跟踪计划的数据。要填充一个汇总数据集（如跟踪计划的月度设施报告），通常要为每个汇总数据元素定义一个计划指标，并为每个汇总数据元素类别定义一个计划指标分类。这种分类的典型例子是年龄和性别。下图对此进行了说明。
将程序数据转换为聚合数据集的程序分解示例](resources/images/Tracker_Aggregate_C19_Example.png){.center width=50%}
虽然图中没有显示，但计划指标映射也适用于属性类别组合，即应用于整个数据集的分类。因此，如果目标汇总数据集被分解为 "实施伙伴 "等属性类别组合，而实施伙伴信息被记录在跟踪计划中，则可以配置一个表达式来产生属性分解。
有关设置程序指标分解的详细说明，请参阅 用户指南/配置系统/程序/设置新的程序分解映射。
在 DHIS2 v41 及以下版本中，不提供计划指标分解功能。这意味着在 v41 及更早版本中，必须为每个单独的 * 数据元素（data element）+ 类别选项组合（+ 属性选项组合）* 配置一个计划指标。这通常对配置和维护的要求更高，也会导致性能降低（在某些情况下会明显降低）。
绘制计划指标和综合数据要素图{ #mapping-program-indicators-and-aggregate-data-elements }¶
要将数据存储为总体数据值的每个计划指标都需要使用某种形式的标识符映射到总体数据元 素。当使用 DHIS2 v42 及更高版本的计划指标分解功能时，DHIS2 会自动处理将标识符从跟踪数据模型映射到适当的汇总类别选项组合和属性选项组合。从计划指标到数据元素的映射不是自动的，但可以使用 "汇总数据导出的数据元素 "字段（Data element for aggregate data export）来完成。为了将计划指标与数据元素的映射保持在一个地方，您也可以使用同样的方法，通过将 "分类/属性类别组合 "下拉菜单设置为 "无"，来对**未分类的计划指标进行映射。
*如果计划与 HMIS 交换数据，请确保类别相同
无*计划指标分类的绘图{ #mapping-without-program-indicator-disaggregations }¶
一般来说，我们建议在运行 v42 或更高版本时使用计划指标分解功能；即使部分或全部计划指标实际上没有被分解，它也能让您在一个地方维护从计划指标到数据元素的映射，而无需自定义属性等。然而，如果在不支持计划指标分解的 DHIS2 实例中工作，或由于某种原因尚未使用计划指标分解功能（例如，映射是在早期版本中完成的），则必须将映射设置为计划指标定义本身的一部分。这可以通过不同的方式来完成，理论上可以使用计划指标的名称、代码、ID 或自定义属性，并将其与聚合数据元素的名称、代码、ID 或自定义属性进行任意组合匹配。你可以在*汇总数据交换*工作中指定在程序指示器和数据元素方面分别使用什么标识符。
这种映射的常见模式是将目标数据元素的 id 分配给计划指标的自定义属性。计划指标有专门用于类别选项组合和属性选项组合标识符的内置属性。但是，默认情况下没有相应的字段来指定数据元素的标识符（即代码或 id）。原则上，可以使用计划指标本身的代码，但如果多个计划指标链接到同一个数据元素（具有不同的类别选项组合），这样做就会失败。建议创建一个分配给计划指标的属性。
属性：
- 应为文本类型
- 不应是强制性的，因为并非所有计划指标都将与汇总数据元素相关联。
- 不应是唯一的，因为多个计划指标可能指向相同的数据元素标识符。
- 应仅适用于 "计划指标"，因为它与其他地方无关。
其他属性，如名称、描述和代码，可根据特定实现的元数据命名约定来定义。
自定义属性分配给计划指标后，在 "维护 "应用程序中添加或编辑计划指标时，它将作为新字段/属性出现。需要创建和/或修改每个要将数据传输到汇总数据元素的计划指标，以包含相应数据元素的代码和类别选项组合代码（默认类别选项组合的该字段可以为空）。
利用汇总数据交换服务移动数据{ #moving-data-with-the-aggregate-data-exchange-service }¶
当计划指标被定义并映射到综合数据元素后，最后一步就是实际提取跟踪数据并将其存储为综合数据值。DHIS2 推荐的工具是汇总数据交换服务（DHIS2 v2.39）和相应的数据交换应用程序。这是一种通用服务，用于从 "源 "DHIS2 实例的分析 API 导出数据，并将数据作为聚合数据值导入 "目标 "DHIS2 实例。请注意，源实例和目标实例可以是相同的，这意味着数据只是在内部传输。为了将跟踪器数据保存为汇总数据值，我们从 "源 "实例中提取程序指标数据值，并将其保存为 "目标 "实例中的汇总数据元素。
在许多组织中，跟踪数据和汇总数据是在不同的实例中收集和管理的。例如，可能会有一个专门的跟踪器实例，用于各种基于病例的监控计划，该实例应将数据输入到一个单独的 HMIS 实例中，以托管常规的汇总数据。在这种情况下，数据交换**可以设置为直接从跟踪器实例向汇总实例发送数据，而无需首先在跟踪器实例中实际存储汇总数据值。不过，我们建议分两步进行：首先在同一跟踪器实例中将跟踪器数据存储为聚合数据元素值，然后将聚合数据值移动到聚合（如 HMIS）实例。
原因有两个：
- 它简化了实际的 "跟踪器到汇总 "转换，特别是确保不会出现与组织单位相关的问题。
- 它确保跟踪器实例的用户可以轻松访问汇总数据值，而汇总数据值通常更容易用于数据分析。
这样做的主要缺点是必须在两个地方维护汇总元数据。
无论是 "内部 "数据交换还是在两个实例之间直接移动数据，上述映射都是用来将源数据与目标数据中的适当元数据联系起来的，因此交换依赖于长期保持的一致且可解析的标识符。在 DHIS2 v42 及更高版本中，计划指标分解简化了从跟踪器到汇总的类别和属性选项组合的映射。当**不使用具有内置映射功能的计划指标分解功能时，使用适当的*标识符模式*配置数据交换至关重要：
- 输出 ID 模式*决定输出的汇总计划指标数据（以及组织单位等）使用何种标识符。
- 输入 ID 模式*决定使用哪些标识符来标识数据导入中使用的数据元素。
数据交换中使用的所有 ID 方案属性](resources/images/Data_Exchange_IDchemes.png){.center width=70%}
数据交换应用程序中显示的 ID 方案选项](resources/images/Id_Schemes.png){.center width=70%}
例如，如果计划指标上的自定义属性用于存储目标数据元素的 id，则输出数据项 ID 方案应指定该自定义 属性，而 "输入数据元素 ID 方案 "应为 id。
id映射示例](resources/images/Data_Exchange_IDchemes_EG.png){.center width=70%}
将交换调度为作业队列{ #scheduling-exchanges-as-job-queues }¶
数据交换可以在数据交换应用程序中手动运行，也可以通过应用程序接口运行。不过，常见的情况是自动运行这一流程，例如每晚或每周。因此，可以使用日程安排程序安排数据交换自动运行。
由于数据交换从分析 API 提取数据，因此数据交换的调度必须与分析表更新的调度相协调。通常情况下，顺序应为
- 更新跟踪器分析表
- 从跟踪器到集合体的运行数据交换
- 更新汇总分析表
- (可选）运行数据交换，将数据转移到单独的聚合实例中
这将确保交换中包含最新的跟踪器数据，并确保汇总数据可用于分析和/或将其移至单独实例的第二次交换。
有关配置和安排汇总数据交换的更多信息，请参阅文档的其他部分：
实施方面的考虑{ #implementation-considerations }¶
以下各节列出了指导实施的核心决定、实用选项和建议默认值。
迁移到 DHIS2 v42 中的计划指标分类{ #migrating-to-program-indicator-disaggregations-in-dhis2-v42 }¶
DHIS2 v42 中新引入的*计划指标分类*功能，与以前为每个分类配置单个计划指标的方法相比，具有多项优势。除了减少需要配置和长期维护的单个计划指标的数量外，它还能显著提高性能，使数据传输在许多情况下快上几倍。
如果您已经在早期版本的 DHIS2 中配置了 "跟踪器汇总"，但没有使用计划指标分类，您应该计划更新配置以使用这一新功能（假设相关数据集确实包含分类数据）。如果您遇到性能问题，尤其应该考虑更新配置。
数据传输配置{ #data-transfer-configuration }¶
与数据传输有关的两个主要考虑因素是
**在自动传输时，传输频率可以是每天一次，也可以是每个报告/汇总期（如每周、每月、每季度）仅传输一次。更频繁的更新意味着数据可以作为汇总数据值提供，可以更快地使用和分析，并随着新信息和更新信息的到来而保持更新。这是否有用取决于相关的跟踪计划。例如，在报告期间每天更新数据，如果提供给设施一级的工作人员，可能是有用的信息，但如果汇总的目的主要是为了方便和自动向更高一级进行 HMIS 日常报告，则用处不大。
**在设置汇总数据交换时，您必须决定应更新多长时间以前（多少个时期）的数据，以及是否传输当前时期的数据（数据不完整，见上一点）。这一决定可能必须与有关汇总数据的潜在现行做法保持一致，例如何时或如何验证数据，以及是否在某一时刻锁定数据以供编辑（下文将进一步讨论）。与此相关的问题是，是否要区分迁移新数据值和更新以前报告的值。
在讨论这些问题时需要考虑到，跟踪数据在许多情况下是根据纸质登记簿追溯输入的，而不是在提供服务或接触病人时直接输入的。此外，数据的更正和编辑可能会在实际事件发生后相当长的一段时间内进行，例如，在随访过程中发现前一次就诊的数据有误。
除非有充分的理由不这样做，否则建议更新和编辑的时间越早越好，因为有合理的机会对基础跟踪数据进行添加和更新。这样可以确保使用的是最正确和最新的信息，尽管这可能需要修改 HMIS 数据管理标准，如数据验证和锁定。
注意：在**更新*之前生成的值时，聚合数据交换服务目前存在限制。请考虑这种情况：
1.数据交换任务已运行，并更新了某一特定组织单位中某一特定计划指标的非零值期间的汇总数据值 >2.
2. 更新跟踪器数据，使同一计划指标在该组织单位不产生非零值。
再次运行同一时期的数据交换任务，更新现有的汇总数据值。在这种情况下，步骤 3 中的数据交换工作将不会**删除在步骤 1 中产生的值。目前正在努力改善这种情况。
数据质量和验证 关键问题{ #data-quality-and-validation-key-issues }¶
确保数据质量是跟踪数据和汇总数据的关键问题，而将两者联系起来则会在这一领域带来新的潜在难题。有一些工具和方法可以减少跟踪数据收集过程中出现错误的几率。然而，错误总是有可能发生的。在基于跟踪器的汇总数据仍在定期更新的期间内（如上一节所述），跟踪器数据中的更正也会自动流向汇总数据。不过，有两种情况必须决定如何处理数据更正：
如果在跟踪器中发现并纠正了错误，在数据例行迁移的时间段和/或汇总数据已验证和/或锁定之后。可能的解决方法包括
- 处理汇总数据中的差异（如果错误较小）；
- 对受影响时段的数据进行临时转移；
- 手动更正汇总数据。
如果在汇总数据中发现数据质量问题。这种情况出现的可能性较小，因为只有在汇总信息时，或在数据明显不完整的情况下，跟踪器数据中相对较大或系统性的错误才会显现出来。可能的解决方法包括
- 更正跟踪器中的源数据，然后重新传输数据（如有可能）；
- 更正/编辑汇总数据（如有可能），并接受差异。
在汇总跟踪数据时，另一个相关的数据质量问题涉及数据的**及时性和完整性**，这是汇总报告（如在 HMIS 中）的关键数据质量指标。当通过 DHIS2 直接报告汇总数据时，用户点击一个按钮，表示某组数据（报告表）已完整报告。这将作为计算数据及时性（在指定截止日期前提交）和完整性的依据。根据跟踪数据生成汇总数据时，无法获得完整性和及时性信息。关于这个问题，可以考虑几种方法：
- 在某些情况下，没有完整性和及时性数据是不成问题的。跟踪器数据一般没有完整性和及时性信息，从跟踪器生成的汇总数据值也可以以同样的方式查看。例如，如果数据传输的主要目的是为了方便进行数据分析，增加维度，或为了使用汇总数据的分析工具，就会出现这种情况。
- 如果数据是某一例行报告数据集的子集，而其他部分直接作为汇总数据输入，则跟踪数据的完整性信息可作为整个数据集完整性的一部分进行核实和报告。
- 完整性和及时性信息可由负责提交汇总数据的用户手动管理。这可以作为验证流程的一部分，由用户（在汇总数据输入应用程序中）验证数据，然后确认数据是否完整。虽然这可以增加一个额外的验证步骤，但也会耗费更多资源，而且真正的数据验证在某种程度上需要一定程度的人工统计，这在一定程度上违背了自动汇总跟踪器数据的初衷。
- 开发一个脚本或工具相对容易，只要报告了一定数量（即指定数量的数据元素值）的数据，就能自动将数据集标记为完整。这对于识别已报告某些数据的医疗机构非常有效，但这一自动流程无法确定这些报告是否真正意义上的*完整*。
一般来说，当跟踪器数据被用于生成综合数据值时，这是一种数据二次使用的形式，超出了数据收集的主要目的。重要的是，要向用户明确说明如何管理数据验证和更正问题，如何处理 "完整性 "等问题，并明确界定数据的 "真实来源"。
数据访问和所有权{ #data-access-and-ownership }¶
在 DHIS2 中，跟踪数据和汇总数据的访问都是通过基于用户组的共享来控制的。因此，跟踪数据的共享和由跟踪数据生成的汇总数据值的共享可以是不同的，在两种数据被托管在不同的 DHIS2 实例中的常见情况下，相同的用户可能根本无法进入系统。这样做有一定的好处，例如，在不影响隐私/安全的情况下，汇总数据值可以比跟踪数据得到更广泛的共享。与此同时，它要求在两个不同的实例中设置适当的数据共享，还可能要求用户访问两个不同的系统。(可以使用 OpenID Connect 让用户在两个实例中共享用户名和密码）。
与数据访问相关的是数据所有权问题，这个问题也与数据质量和验证有关。需要制定明确的程序，说明谁负责和 "拥有 "跟踪器以及跟踪器生成的综合数据值。在涉及多个卫生计划的情况下，这一点尤为重要。例如，如果一个免疫接种跟踪计划将数据输入一个综合的 HMIS 数据集，而该数据集由一个单独的 HMIS 单位负责。
过渡期{ #transition-period }¶
当追踪器数据汇总的目的是为了取代已有的汇总报告（如现有的 HMIS 常规报告）时，计划在一段时间内（如 6 个月）保持并行报告通常是有用的。在这段时间内，应将跟踪器生成的总数与现有手工报告项目生成的总数进行比较。虽然两者不可能完全相同，但这种比较是有用的，因为它们
- 应围绕差异的来源展开讨论，例如（数据源中的）数据质量问题。
- 当跟踪器数据的完整性和质量与人工报告相同或更好时，应为相关决策提供信息，以便停止并行报告。
从技术上讲，这可以通过在汇总实例中设置一个具有独立数据元素的独立 "影子 "数据集来实现，这样就可以保存两个并行的汇总数据集，并在其中进行比较。或者，也可以在跟踪器实例中保留汇总数据集的副本，用于比较。
组织单位同步{ #organisation-unit-synchronization }¶
当跟踪数据和汇总数据分别存放在不同的 DHIS2 实例中时，在它们之间移动数据的一个关键要求是两个数据库中的组织单位必须一致。无论汇总和传输是在一次操作（汇总数据交换）中进行，还是在两次单独的操作中进行，这一点都适用。有关组织单位维护的更多信息，请参阅专门章节。
其他方法{ #other-approaches }¶
虽然将跟踪数据保存为总体数据值的方法概述了与病例监控系统和 HMIS 等常规系统集成最相关的方法，但也有其他更直接的方法将跟踪数据和总体数据结合在一起。这些方法概述如下。
注： 这些方法的一个主要局限性，特别是用计划指标计算的总体计数，以前一直是缺乏数据的*维度*。例如，可以将年龄分类和性别分类作为单独的数据维度进行分析，直接用于图表和表格中进行筛选，并在不同变量间重复使用。然而，随着 v42 版中引入了计划指标分类，情况就不再是这样了--带有分类的计划指标也可以直接在数据分析工具中使用，而无需首先将数据存储为总体数据元素值。
并列显示跟踪器和汇总数据{ #showing-tracker-and-aggregate-data-side-by-side }¶
通过将汇总数据和跟踪器数据纳入相同的数据展示台图表或表格中，可以同时显示和分析汇总数据和跟踪器数据。此外，还可在事件报告和事件展示台应用项目中创建跟踪器数据的可视化，并将其与仪表板上的汇总数据可视化结合起来。任何可以访问 DHIS2 分析应用项目中两类数据的用户都可以使用这种方法。
优点：
- 易于设置
- 可很好地展示和分析赠送的数据
- 可包含详细数据（如病例行列表）
**缺点
- 要求跟踪器和汇总数据位于同一个 DHIS2 实例中
通过指标组合数据{ #combining-data-through-indicators }¶
指标可基于总体数据和跟踪数据，也可分别或合并为一个指标。跟踪数据元素、被跟踪实体属性和计划指标均可纳入指标计算。
这种方法在多种情况下都很有用：
- 不同的医疗机构通过综合数据集和跟踪器计划收集相同的数据，即一些医疗机构收集综合数据，另一些医疗机构通过跟踪器收集个人数据。
- 同一数据可作为不同时期的汇总数据值和跟踪器数据值提供，例如，目前通过跟踪器收集的数据在前几年是作为汇总数据收集的。
- 当需要根据综合数据制定指标时，即通过跟踪器收集的服务数据与作为综合数据的分母相结合。
优点：
- 设置相对容易
- 可以向终端用户隐藏整合汇总数据和跟踪器数据的部分复杂性
缺点：
- 在数据可能重叠的情况下难以管理
- 要求跟踪数据和汇总数据位于同一个 DHIS2 实例中