跟踪分析{ #tracker-analytics }¶

DHIS2 分析应用程序可通过四种主要方式使用跟踪器数据来生成分析结果，如表格、图表和地图。

• 线路列表
• 数据展示台应用程序中的事件数据项
• 计划指标
• 指标（见 "共同挑战 4：汇总与分解）

行列表（v2.38 及以上版本）{ #line-listing-v238-and-above }¶

生成符合定义标准的计划中所有注册人数或事件的列表。这些标准可以是组织单位、时间维度和特定数据值的组合。例如，您可以为疟疾治疗计划中的所有注册情况定义一个行列表，其中组织单位为该地区的所有机构，注册日期为过去 3 个月内，数据元素"'病例结果'"的值为死亡。

列表中每一行的字段可由用户指定，例如跟踪实体属性（病例 ID）、特定计划阶段的数据元素值（疟疾药物）。下面的示例来自住院病人发病率和死亡率事件程序，显示了按入院日期、性别和出院日期分列的入院情况，所有情况都按入院时的年龄进行了筛选。因此，它结合了跟踪实体属性 (TEA)、计划指标值和数据元素值。

使用跟踪程序时，您可以将多个阶段结合起来，并在水平列表中显示每个阶段最后 X 个事件的数据。

更多详情，请参阅 文档。

请注意，"行列表 "的许多功能也可以通过 "捕获应用 "或 "跟踪器应用 "中的 "工作列表 "实现。对于最终用户来说，工作列表可能比直线列表更有用，因为您无需打开新窗口/应用来查看患者列表，而且在工作列表中单击单个病例将直接进入 TEI 资料页面。

对于数据分析师来说，行列表非常有用，可以找出符合特定条件的个别异常值，尤其是跨组织单位和跨时期的异常值。但是，查看一长串事件或注册人数很难发现数据的潜在趋势。随着跟踪计划规模的扩大，您将希望看到跟踪数据以有意义的方式进行汇总。

DHIS2 核心团队建议使用新的 "线路列表 "应用程序，而不是旧的 "事件报告 "应用程序，后者已被 "线路列表 "取代，在未来的版本中将不再支持。

数据展示台应用程序中的事件数据项{ #event-data-items-in-data-visualizer-app }¶

还可以在数据可视化应用程序中直接汇总某些事件数据项，以制作数据透视表和图表。最终用户可以实时操作和更改数据展示台应用程序中的报告。

重要的是，只能聚合数值数据值。如何聚合这些数值由数据元素的聚合类型设置，也可以在整个可视化的 Options 中设置聚合。这些跟踪器数据的可视化效果可直接从数据展示台应用程序生成：

Average weight in grams at birth in the child program, by month at facility

今年各地区接受疟疾重点调查的家庭总数

对于某些配置，数据展示台可以快速获得事件数据输入的摘要。但直接汇总数据元素有一些关键的**限制：

• 查询包括在给定计划、组织单位和时期维度的所有事件中发现的所有数据元素值。如果数据元素出现在多个阶段，或在一个可重复的阶段中，那么这些数据元素值将被汇总在一起。
• 只有事件日期可用作时间维度，而不能用作注册日期，也不能用作追溯期边界，以创建追溯期开始前的事件 "队列"。
• 不能按选项集值（分类变量）进行汇总，如 "结果 "数据元素为 "治愈 "的事件总数。
• 您不能应用筛选器来排除高于或低于阈值的错误输入的数字数据元素值，例如排除所有 "体重超过 10,000 克的婴儿"。
• 您不能根据第二个事件数据项（无论是数字还是分类）创建分类，如 "出生时体重，妊娠 35 周以上和 35 周以下 "或 "按性别分列的出生时体重"。
• 请注意，通过**地图**应用程序，您可以将事件数据项过滤器应用到事件层查询。过滤后的查询还可将数值按地理层级汇总。数据展示台应用程序中不提供此类筛选器。

最重要的是，在数据可视化应用程序中很难显示符合给定条件的基本事件计数或注册计数。对于常见的健康追踪器，您希望生成符合特定条件的患者或就诊次数的简单计数。单个数据元素值的聚合并不那么重要。

计划指标¶

计划指标 (PI) 可以让您轻松配置个人数据的多层查询。它们允许根据属于跟踪程序的数据元素和/或跟踪实体属性创建值。从根本上说，我们可以利用跟踪程序中的单个数据项，生成用于常规分析的汇总值。

PI 可用于汇总事件内或整个注册中的数据，将从多个不同阶段输入的数据或跟踪的实体属性结合在一起。某些配置还可能将 PI 包含在网页或安卓系统的 "TEI 面板 "中，以提供跨事件或事件内的计算，并在数据录入期间向用户提供注册情况汇总（事件总数、空白数据元素值的百分比、上次访问后的天数等）。本节的重点是配置计划指标，以显示指定组织单位/期间内所有事件或注册人数的汇总数据（计数、总和、平均值等）。

计划指标有两种_类型_：

• 事件：基于事件组织单位和（默认情况下）事件日期的维度。这将根据单一程序阶段内的所有事件执行操作
• 入学：基于注册组织单位和（默认情况下）注册日期的维度。可评估多个计划阶段的数据值，但根据单一数据元素值进行查询时，默认评估每个可重复阶段中最近事件的数据。

计划指标有五个组成部分，规定了价值的计算方法。它们按以下顺序进行评估（请参阅下文，了解这一点为何重要）。

评估	零件	评论
1	组织单位	对于事件类型，它是事件的组织单位。对于注册类型，它是注册的组织单位，即使注册中的某些事件是在其他地方输入的。
2	期	由分析期边界定义。根据 PI 类型，默认为报告期开始和结束之间的注册日期或事件日期。
3	过滤	为事件或注册创建值过滤器。包括跟踪的实体实例属性值，或特定程序阶段（事件类型）内的任何数据元素，或任何程序阶段内的任何数据元素。可使用各种函数和变量进行附加操作，如过滤注册日期与出生日期之间的年数超过 18 年的 TEI。
4	以目标取代源	上述标准定义了要包括哪些注册（或事件）。表达式是应用于每个注册（或事件）的值。通常是 event_count、enrollment_count 或 tei_count，但也可以是数据元素值或更复杂的表达式。
5	聚合类型	如何汇总应用于每个注册（或事件）的表达式。通常是 "计数 "或 "平均值"。

PI 在 FILTER 条件中功能最强大，可用于定义注册或事件是否符合某些标准。过滤标准可从多个数据元素和/或事件和/或跟踪实体属性中得出。这种功能对于大多数以患者为中心和病例报告的情况至关重要，因为在这些情况下，您所关心的不是原子数据元素值的汇总，而是符合特定条件的事件（会诊）和患者（注册）的计数。

因此，强烈建议为跟踪系统的所有常规报告需求配置程序指标。

计划指标到底是什么，为什么重要？¶

从技术上讲，程序指示器是一个预配置的 java 代码段，可被 DHIS2 分析引擎翻译成 SQL 表达式。在分析查询中包含计划指标时，例如在数据展示台中打开图表，该 SQL 表达式就会与期间和组织单位维度结合到查询中，由此对注册和/或事件分析表进行的数据库查询就会返回输出结果。

这种快速的技术解释对于理解有关计划指标的几个关键问题非常重要。

首先，系统设计人员只需进行最少的配置，就可以使用 PI 构建非常复杂的 SQL 查询。在上面的示例中，PI 过滤器中的一行代码就产生了 8 行 SQL 代码，而分析查询中的每个周期和组织单位维度都需要重复这些代码。与 SQL 查询相比，程序指示器的配置相对简单，如果管理得当，其灵活性足以涵盖跟踪器数据所需的______________________________________________________重要查询。

其次，计划指标值并不存储在 DHIS2 数据库中，但它们为 "即时 "查询数据库分析表提供了一个框架，或者说，一旦终端用户加载了带有计划指标的可视化信息，就可以 "即时 "进行查询。这意味着每次创建或编辑程序指标时，都无需重新生成分析表。

这两点是需要权衡的。PI 非常灵活，易于设置，但由此产生的 SQL 查询并没有对性能进行优化，在大规模使用时效率会非常低。PI 也是按需计算的，这意味着用户每次加载带有程序指标的仪表盘时，都会触发一次数据库查询。许多用户可以同时进行低效的分析查询，给服务器带来不必要的压力，导致整个系统严重减速。

:mag：国家案例研究

在 Covid-19 疫苗接种活动中，计划指标的性能影响显而易见，当时每天有数以百万计的跟踪器注册人数被数百个终端用户仪表盘查询，这往往会导致严重的性能挑战。[从这一经验中吸取的教训]（#tracker-performance-at-scale）提供了一个框架，其中包含改进大规模追踪器分析的具体技术，例如[追踪器到汇总脚本]（#integrating-tracker-and-aggregate-data），用于定期将项目指标值写入汇总数据元素。

最后，与汇总数据元素一样，计划指标**需要一个组织单位维度和一个时期维度**才能返回有意义的值。但是，汇总数据元素是针对单个期间和单个组织单位输入的，而跟踪数据自然要复杂得多：单个注册可能在一段时间内有多个事件，每个事件可能由不同的机构输入。然而，对于每个组织单位和时期的组合，PI 最终只会输出一个值。因此，在设计计划指标时，您需要仔细考虑如何解释纵向数据的 "地点 "和 "时间"。

下面举例说明在定义和配置计划指标时遇到的挑战，特别是在计划指标类型、时期界限、组织单位分配和（不）汇总方面。

共同挑战 1：事件与注册类型{ #common-challenge-1-event-vs-enrollment-type }¶

在建立计划指标时，最重要的决定是它应该是事件类型还是注册类型。

大多数实施者都知道，两种类型的 PI 都可以通过数据元素值和/或跟踪实体属性值 (TEA) 进行筛选。如果计划指标必须评估两个或两个以上计划阶段的值，则只能使用注册类型的 PI。

但一个非常常见的错误是，在汇总可重复程序阶段的数据时混淆了这两种类型。

回顾一下，事件代表不同的_偶遇_，注册代表不同的_病例文件_。当您使用计划指标对跟踪数据进行汇总统计时，同样的概念逻辑也适用：一般来说，当我们要统计不同的接诊情况时，我们使用事件类型的 PI；当我们要统计不同的病例档案（或人员）时，我们使用注册类型的 PI。

实施者必须问：_我是要总结所有的遭遇，还是只总结独特的人？

在追踪器使用 1 级学院的这个示例中，我们正在统计一个 Covid-19 疫苗接种计划中患有潜在疾病的病例。数据元素 "COVAC - 基本病症 "出现在一个可重复的计划阶段中。

我们制定了两个计划指标：一个是采用注册人数汇总的注册类型，另一个是采用事件计数汇总的事件类型。

您会看到基于事件的指标报告了更高的值，因为它在计算每个事件的基础条件变量；如果您想知道患有基础条件的唯一人数，在这种情况下这是不合理的。

报名和活动](resources/images/image38.png){ .center width=80% }

为什么会这样呢？

同一患者可以有多个具有此数据元素值的事件。这些事件可能都发生在同一时期。此外，同一个人可能在不同的地区（组织单位）发生事件。因此，很有可能重复计算具有 PI 类型的个人。

同时，每次注册只有一个注册日期和一个注册组织单位。

如果您想统计独特的个体，通常采用注册类型是更好的方法。

但请再看一下 "基本情况 "的示例计划指标。可能会出现对该问题有两个不同回答的注册情况。也许在初次就诊时未报告潜在病症，而在随后的就诊中，该值又有所不同。在同一计划阶段，注册类型的计划指标将如何处理一个数据元素的多个值？

在有重复事件的计划阶段内，注册类型指标使用**来自最近有该数据元素数据值的事件的数据。** 在下图中，如果在筛选器中没有该计划阶段的任何事件，则不计算注册人数，只评估有数据元素值的事件。

通常情况下，只考虑每个案例的最新值是有价值的，因为该值可能被认为更及时、更准确。但在某些情况下，您需要评估某个数据元素的某个值的所有注册情况。这就是 d2:count 类函数在 PI 过滤器中发挥作用的地方。它们可确保程序指示器评估每个注册人数中的所有事件，并计算符合条件的人数。

使用程序指示器过滤器中的这些功能，您可以回答这样的问题：

• d2:count(#{jdRD35YwbRH.zocHNQIQBIN})>=1d2:count(#{jdRD35YwbRH.zocHNQIQBIN})>=1`

_"有多少肺结核患者至少有一项涂片显微镜检测结果？

• d2:countIfValue(#{jdRD35YwbRH.zocHNQIQBIN},'Positive')>=1`

_"有多少肺结核患者在涂片显微镜检查中至少有一次_阳性_结果"？

• d2:countIfCondition(#{edqlbukwRfQ.vANAXwtLwcT},'>8')>=1`

_"有多少孕妇至少有一次产前检查的血红蛋白值超过 8？

您可以利用数据元素和跟踪实体属性值的组合来构建计划指标过滤器。对于注册指标，这些数据元素可以来自不同的计划阶段，您甚至可以在一个阶段的所有事件中扫描符合特定条件的数据元素值。但是，您不能在一个 d2:countIfCondition 过滤器中建立多个子表达式，以确保同一事件中存在两个数据元素值。

例如，您可以过滤任何事件报告了基础条件的注册：

d2:countIfValue(#{covacprogramUID.underlyingcondUID},'Yes')>=1`

并可筛选出任何事件报告了怀孕和任何事件报告了基础病症的登记：

d2:countIfValue(#{covacprogramUID.pregnancymarkUID},'Yes')>=1&&d2:countIfValue(#{covacprogramUID.underlyingcondUID},'Yes')>=1。

但您不能通过注册类型的计划指标筛选出在同一事件中同时报告了怀孕和潜在病症的情况。这种评估（同一事件中的两个值）只有在事件类型的计划指标中才能进行。

最后，大规模实施应注意，当计数*函数被添加到过滤器中时，，这将给 PI 评估_ 的性能带来挑战。在后台，只要查询计划指标，注册类型指标就会加入 analytics_enrollment_[programUID]表和 analytics_event_[stageUID]表。在查询过程中，每次使用 count* 都会导致对事件表进行单独扫描，并执行单独的连接。由于 d2:countIf 的灵活性，在加载仪表盘时出现了一些最严重的延迟。

下表详细说明了两种 PI 类型之间的区别。

	活动类型	注册类型
组织单位 dx	事件组织单位	招生单位
周期 dx（默认值）	活动日期	注册日期
可根据 TEA 值进行筛选	是的	是的
可在一个不可重复的阶段中通过多个值进行筛选	是的	是的
可在可重复阶段通过多个值进行筛选	是的	从周期内阶段的最近事件中选择值*。
可根据多个程序阶段的值进行筛选	不	是的

* 如果应用了d2:countIfValue函数，该值可能出现在可重复阶段的任何事件中。如果在多个数据元素中应用该函数，可重复阶段中的每个数据元素值都可能出现，但会出现在不同的事件中。

共同挑战 2：计划指标周期性{ #common-challenge-2-program-indicator-periodicity }¶

所有分析查询至少需要一个周期维度，如 "上周"、"2022 年 1 月 "或 "今年"。然而，跟踪器数据本质上是纵向数据，因此本质上与单一基期无关。

程序指标使用 analytics period boundaries 来定义分析查询的周期。

从跟踪器数据中得出的任何日期都可用作评估跟踪器数据的边界目标。如果指定的日期值在这些时期边界所确定的范围内，那么该注册或事件就会包含在查询中。

选择程序指示器类型时，会自动配置两个默认值。

• 默认情况下，作为边界目标的日期由计划指标类型决定。注册类型 PI 使用注册日期作为目标，而事件类型 PI 使用事件日期。
• 默认情况下，周期边界设置为分析查询中报告期的开始和结束。

这意味着，对于_大多数_事件类型的计划指标，计划指标周期被定义为报告期内的事件日期。对于_大多数_注册类型的计划指标，计划指标周期被定义为报告期内的注册日期。

下图显示了事件类型和注册类型 PI 的默认时间界限如何选择要评估的事件或注册。如果在数据透视表中放置计划指标以查询今年 4 月的事件，则事件类型计划指标的默认边界将评估今年 4 月内发生的所有事件。

不过，可以根据具体的分析需要对这些默认的时段界限进行调整。

删除句号边界{ #removing-a-period-boundary }¶

将 "开始前 "或 "结束后 "这两种时间界限类型的第一个词看作是箭头，指向时间的后方或前方，可能会有所帮助。设置两个时间方向相反的边界（"开始后 "和 "结束前"）可以确保边界是封闭的。如果删除其中任何一个，边界就会变成开放式的。这可用于创建**cumulative**计划指标，如 "统计报告期结束前的所有注册人数"。这样，对四月份的查询就会选择四月底之前任何时间的所有注册人数。

请注意，由于性能影响，应谨慎使用此类 "累计计数 "PI。如果要使用累积计数 PI 查询过去 12 个月的数据，则需要对每个月的数据进行单独的累积查询，而不是对随后的月计数进行求和（将第 2 个月的总数与第 1 个月的累积值相加，将第 3 个月的总数与第 2 个月的累积值相加，等等）。

添加和混合周期边界{ #adding-and-mixing-period-boundaries }¶

当使用注册类型 PI 来筛选两个或多个事件的数据值时，常见的误解是周期边界将跨越这些 事件发生的时间段。但如上所述，默认的期间边界将针对期间内的所有_注册日期_。在病例管理项目中，病例通常会活跃很长时间，例如 HIV 病例监测项目，大多数注册日期实际上可能早于相关时期数月或数年。

在这种情况下，可以将注册类型 PI 的边界目标切换到事件日期。这样，所有至少有一个事件发生在报告期内的注册信息都会被评估。

正如您可以更改或删除周期界限一样，多种类型的周期界限也可以相互叠加，以进一步限制周期性。

例如，您可以设置一个注册类型 PI，将评估限制在期间内的事件日期和期间开始日期之前的注册日期。这样可以确保评估的所有事件都是 "后续事件"，因为注册是在前一时期首次开通的。

**提示

如果您在过滤器中包含数据元素值，PI 将查询本月最新跟进事件中的数据元素值。如果将该数据元素值封装在d2:countIfValue()函数中，PI 查询将搜索本月所有后续事件中的数据元素值。

如果边界目标应仅限于特定阶段的事件，则可以选择 "自定义 "边界目标，并输入文本 PS_EVENTDATE:{programStageUid}。

自定义边界目标也可以是日期数据类型的跟踪实体属性或数据元素，例如出生日期 TEIA 或 "实验室检测结果日期 "的数据元素值。有关自定义边界目标和附加数据元素的更多示例，请参阅[用户指南]（#about_program_indicators）。

周期边界偏移{ #period-boundary-offsets }¶

在大多数情况下，分析查询的时间段应为事件或注册发生的时间段。在一些非常特殊的纵向分析用例中，计划指标应评估报告期之前（或之后）一定时间内的跟踪器数据。这些数据被称为**队列**，在各种情况下都很有用：

• 辍学：对在报告期内预计会发生但并未发生的事件的注册情况进行评估。
• 与报告期间隔不一致的预期事件间隔：
  • 应在住院治疗 6 周后进行化验。
  • 常规高血压管理访视应每 5 周进行一次，您想知道有多少人在前三个月的最近一次访视中血压得到了控制
• 计划管理：HIV 队列会统计在此期间某个时间段接受抗逆转录病毒疗法 6 个月的患者人数，以及在这些患者中有多少人接受过病毒载量检测。

在定义期间边界时，两个可选值--按金额偏移期间和期间类型--定义了如何相对于 报告期间移动（"偏移"）期间边界。

在下面的示例中，一个注册类型 PI 的分析期边界后移了一个月。抵消周期类型为 "每月"，金额抵消周期为-1。

这就是我们如何通过移动分析窗口，查看相对于分析期的前一个时间段的跟踪器数据，从而用程序指标创建**队列。

重要**

负值的周期偏移会使目标在时间上_向后_重新定位。正偏移边界在实践中比较少见，因为它们评估的是_报告期结束后_的跟踪器数据。在日常的 HIS 使用案例中，这种情况不太可能用于 "实时分析"。

从这个例子中可以看出，重要的是要注意参保边界已经转移到分析期开始前一个月，并在报告期结束前一个月结束。

• 五月份的查询显示的是四月份输入的注册信息。
• 2022 年的年度查询将实际评估 2021 年 12 月 1 日至 2022 年 11 月 30 日的所有注册情况。
• 2023 年第 18 周（5 月 1 日至 7 日）的每周查询同样会向后推移一个月，并评估 2023 年 4 月 1 日至 7 日的所有注册情况。

要在 "队列 "计划指标的基础上更进一步，您可能需要像上一节那样，将注册日期 和事件日期的期间界限混合起来，但要有效利用期间偏移。

在本例中，我们希望统计上个月创建但在当前报告月至少发生过一次事件的注册人数。这对描述病例随访情况很有用：您的项目中有多少新病例在一个月内进行了随访？

固定窗口队列还是相对窗口队列？

请注意，我们仍然为注册日期的开始期和结束期边界定义了时间偏移。在这里，我们队列的 "窗口 "是分析期开始前一个月后至分析期结束前一个月的所有注册。因此，队列窗口**取决于分析期的持续时间**。

如果最终用户选择每周分析一次，那么群组窗口将为一周，而如果他们选择每年分析一次，那么群组窗口将为一年，以此类推。

这对于许多队列分析情况来说并不理想，因为在这些情况下，队列窗口的固定持续时间是计划指标本身定义的要素。例如，您可能想知道有多少高血压患者在注册后 90 天内进行了随访。或者，您想定义一个月度队列窗口（如上文所述），但要计算该月度队列中一年内的月平均病例数。

一种选择是使用灵活的 "相对窗口 "队列，但在计划指标的名称或描述中说明这只能用于特定类型的时期，如每月。然而，这很可能会引起误解。

如果您的计划指标为队列指定了一个固定的窗口，那么最好将队列时期边界的打开和关闭建立在一个**单一**点 上，如分析时期的开始。这种方法可确保队列窗口的持续时间固定，而不受查询时段的影响。

在下面的示例中，尽管报告期是每周一次，但每月都会生成一个注册队列。我们可以想象添加针对事件日期的边界，以回答以下问题："有多少上个月注册的病例在本周进行了随访？

请注意，由于队列长度是计划指标定义中固定且重要的部分，因此您需要为每个固定的队列持续时间（每月队列、每周队列等）创建一个新的计划指标。

共同挑战 3：转让和所有权{ #common-challenge-3-transfers-and-ownership }¶

前面关于追踪分析的章节研究了时间这一单一维度的偶发纵向数据所产生的复杂性。然而，另一个重要维度是**地点**。如上所述，在计算计划指标时，组织单位是首先要分析的组成部分。那么，当相关事件实际发生在多个不同的组织单位时，我们应该如何确定注册的 "位置 "呢？

在卫生系统中，人们经常在不同的卫生机构之间流动，以接受针对同一病症的服务。他们可能在初级保健中心接受诊断，然后转到专科诊所接受治疗。化验结果可能由另一个地方的化验员输入。开始治疗后，社区卫生工作人员可能会进行家访跟进。

:mag：国家用例

视具体情况而定，病人流动的频率很高。在孟加拉国的一项产前保健 DHIS2 跟踪系统试验中 for example, pregnancy registrations and follow up treatment could be provided both by community health workers and public rural health clinics, all sharing the same patient health record on a Tracker program with Open access. Out of about 14,000 total registrations ，81% 的人在初次登记后至少有一次随访；在 7750 次随访中，约有 8%的随访发生在与登记不同的组织单位。这意味着不同的公共机构--甚至不同类型的机构--为同一个人提供服务。

在 DHIS2 追踪系统中，多个机构单位可为同一登记输入事件数据。第二个机构（"机构单位 B"）可以通过三种不同的方式访问另一个机构（"机构单位 A"）创建的注册记录并创建新事件。

• 假设用户的 "搜索范围 "允许访问在机关单位 A 中注册的 TEI，还假设程序访问级别为 "开 放"、"已审核 "或 "受保护"。(有关不同程序访问设置的解释，请参阅 Docs）。
• 机构单位 A 的用户向机构单位 B 进行**一次性转介**。该程序可以有任何访问级别以允许这样做，但机构单位 B 需要指定该程序。机关单位 B 的用户只能为指定程序阶段内的单个事件输入数据，且不能编辑之前的事件。
• A 机构单位的用户向 B 机构单位进行**永久转移**。这与 "一次性转介 "的不同之处在于，B 单位将拥有对注册的所有程序阶段的编辑权限，B 单位也可在工作列表中通过搜索访问这些阶段。转让后，可以说该注册现在 "属于 "B 组织单位，因为所有权已被授予。

有关如何在 Tracker Capture 应用程序中使用 "一次性转介 "和 "永久移动 "的信息，请参阅《用户指南》。目前正在为采集应用程序设计转移和转介工作流程。

让我们用图表说明计划指标如何处理来自不同组织单位的注册事件。在下面的示例中，**永久转学**是从组织单位 A 转到组织单位 B。

通常，事件类型计划指标只需根据每个组织单位发生事件的地点来确定其 "地点 "维度。同样，注册类型的计划指标将根据用户最初创建每个注册的组织单位进行评估。

发生转移时，有几类查询很难通过 PI 准确回答，例如

• 四月份，A机关单位和B机关单位共接诊了多少**个病人？
  • 问题：使用 V{enrollment_count} 表达式的事件类型 PI 将计算在机构单位 A 和机构单位 B 中至少发生过一次事件的所有唯一注册患者。但是，当汇总到更高层次时，这将重复计算转院患者，因为该患者在同一时期在两个机构单位中都发生过事件。
• 假设每个月至少有一次就诊，那么 B 单位 5 月份预计会有多少病人？
  • 问题：PI 可以计算 B 单位在 5 月开始前的所有注册人数，但这不包括从 A 单位转入的人 数，而 A 单位应在 5 月份转入。
• 对于 A 组织单位 3 月份的所有注册人员，他们在 4 月份接受了多少次随访？
  • 问题：可以使用自定义分析期边界构建事件类型 PI，以查找 3 月份之前的注册情况和 4 月份的事件。但是，如果使用 PI 事件类型，转入 B 单位后的两个事件将不计入 A 单位。

在一些治疗长期慢性病的项目中，注册可能会持续很长时间，一个病人可能会转院多次。当使用注册类型的 PI 来分析不同时间间隔内多个事件的数据时，核心问题就会变得更加明显，例如带有及时随访的注册事件。

在这个简单的例子中，我们想找出所有在上个月注册，但在报告期内也进行了随访（事件）的患者。我们应该如何对在报告期内或报告期间转院的患者进行分类？是知道他们在哪里注册的更重要，还是知道他们最近一次就诊是在哪里进行的更重要？

但在这里，只能使用注册的组织单位。这可能会对艾滋病或婴儿营养追踪器等大型实施产生严重后果，因为在这些实施中，病人可能会注册多年并反复转移。当病人转院时，注册组织单位会误导真正负责提供服务和输入数据的组织单位。大多数项目管理人员都希望根据患者最后接受服务的地点来监控患者的状态，而不是患者多年前注册的地点。

所有权分析（v2.40 及以上版本）{ #ownership-analytics-v240-and-above }¶

从 DHIS2 版本 2.40 开始，用于 PI 计算的 "组织单位字段 "可在维护应用程序中使用（可在每个 PI 的分析期边界设置上方找到）。该功能为系统设计者提供了更大的灵活性来配置 PI 计算的组织单位维度，并解决了上述问题。

现在有多个选项可以指定用于计算 PI 的组织单位。

• 事件组织单位（默认用于事件类型 PI，不适用于注册类型 PI）
• 注册组织单位（注册类型 PI 的默认值）
• 登记组织单位（技术教育指标的创建地点）
• 报告期开始时的业主组织单位
• 报告期末的业主组织单位

最后两个选项允许设计者配置 PI 组织单位维度的决定方式：在报告期间进行转账之前或之后的位置。

让我们回到之前的例子。我们希望查看在上个月注册并在报告期内至少发生过一次事件的患者。在这里，我们选择 "结束组织单位的所有者"作为**组织单位字段**。

会发生什么情况？这是因为在所查询的报告期结束时，这两个从 A 单位转入的注册人数归 B 单位所有。

回到我们之前所面临的挑战，巧妙利用所有权分析可有助于解决这些问题。

• 四月份，A机关单位和B机关单位共接诊了多少**个病人？
  • _问题：使用 V{enrollment_count} 表达式的事件类型 PI 将计算在机构单位 A 和机构单位 B 中至少发生过一次事件的所有唯一注册患者。但是，当汇总到更高层次时，这将重复计算转院患者，因为他们在同一时期在两个机构单位中都发生过事件。
  • 请回答：注册类型 PI 带有 V{enrollment_count} 表达式，事件目标期的边界为月初和月末。组织单位字段为 "月末所有者"，转入的注册将计入组织单位 A，而不是组织单位 B。
• 假设病人每月至少就诊一次，那么 B 单位 5 月份预计会有多少病人？
  • 问题：PI 可以计算 5 月开始前 B 单位的所有注册人数，但这不包括从 A 单位转入的人 数，而 A 单位的注册人数应预计在 5 月_。
  • 答：是：注册类型 PI，带有 V{enrollment_count} 表达式，注册目标期的边界在本月开始之前。组织单位字段为 "报告期开始时的所有者"，转移的注册将计入组织单位 B。
• 对于 A 组织单位 3 月份的所有注册人员，他们在 4 月份接受了多少次随访？
  • 问题：可以使用自定义分析期边界来构建事件类型 PI，以查找 3 月份之前的注册情况和 4 月份的事件。但是，如果使用 PI 事件类型，转入 B 单位后的两个事件将不计入 A 单位。
  • 答：是的：带有 V{event_count} 表达式的事件类型 PI、带有周期偏移以覆盖上个月的注册目标周期边界，以及用于捕获报告期内所有事件的事件目标周期边界。然后，您就可以决定如何处理报告期内的转账。如果组织单位字段为 "报告期开始时的所有者"，那么在所有权转移后在 B 组织单位创建的两个事件仍将计入 A 组织单位。

在分析中使用所有权组织单位时应注意以下几点。

• 即使存在分析期边界偏移，使分析窗口在时间上向前或向后移动，组织单位维度在报告期的**开始或结束时仍然是所有者。
• 如果在这种查询中将几个时段合并在一起，则应使用第一个时段开始时的所有者或最后一 个时段结束时的所有者。因此，虽然 "今年几月 "和 "今年 "涵盖的时间相同，但 "今年几月 "将显示 12 个时段，并分别计算每个月月底的所有权，而 "今年 "将显示一个时段，并只检查年底的所有权。
• 转介并不赋予注册及其事件的所有权。在进行转介时，只有 "转出 "组织单位才是分析的所有者。
• 当 Capture 或 Tracker Capture 中执行永久性转移时，所有权转移日期即为 当前日期。因此，如果数据录入人员记录了过去的转介，或对遗留数据进行了回录，系统管理员应在 DHIS2 后台 SQL 中准确更新所有权历史记录。
• 截至 v2.40，无法使用计划指标计算转诊和转院总数。这包括 "本期转诊了多少病人？"和 "总共转诊了多少病人，其中有多少人在转诊后完成了活动？"等问题。虽然有可能通过 SQL 视图找到所有权历史表中的这一信息，但目前还无法开发一个 PI 来计算截至 2023 年 5 月的转院或转诊行动数量。正在为未来的 DHIS2 版本开发这一功能。

共同挑战 4：汇总和分类{ #common-challenge-4-aggregation-and-disaggregation }¶

以上各节假定，计划指标的预期值应是符合特定条件的病例或遭遇次数。现在，我们将讨论如何对计划指标配置进行调整，以产生不同于病例计数的输出结果，例如百分比或平均值。

首先，请记住每个计划指标都需要一个 "表达式 "和一个 "聚合类型"，这两者都用于聚合 PI 值。对于作为病例计数的 PI 来说，这些表达式通常非常简单，如表达式 = V{enrollment_count} 和聚合类型 = 计数。它们可用于不同的汇总，如 "去年出生的婴儿平均接种疫苗数"。

其次，重要的是要记住，计划指标也可以构成指标的分子或分母。在这里，您可以将基于追踪器的数据输入与来自 DHIS2 数据集的综合数据值联系起来。大多数计划使用这种所谓的 "超级指标 "方法来计算干预措施的**人口覆盖率**，方法是将人口值纳入分母，而将计划指标值纳入分母。例如，您可以计算接种卡介苗的新生儿占医疗机构所有新生儿的百分比，其中接种的卡介苗来自跟踪计划，而新生儿则是医疗机构级别的 HMIS 表格。指标分子和分母可以包含内联表达式，指标本身也有聚合类型。

如果指标分子中包含一个计划指标，则每次查询指标值时，都会有四种不同的属性来定义聚合。这些属性按特定顺序应用，具体说明如下。

聚合特性和计算顺序

订购	特征	应用的汇总级别	例
1	PI 表达	每次活动（或注册，取决于 PI 类型）	出生日期或出生日期与首次接种卡介苗之间的天数
2	PI 聚合类型	在每个时期和组织单位维度的所有事件（或注册）中	从出生到接种卡介苗的平均天数
3	指标表达式（分母/分母）	如果需要，在聚合类型后修改 PI 值，然后再用分母除以分子	如果组织单位从出生到卡介苗接种的平均间隔时间超过 60 天，数值为 1，否则为 0
4	指标汇总类型	如何合并多个组织单位和/或多个时期的数值	本期提供 "延迟抗逆转录病毒疗法 "的设施高潮单元总数

如何按照重要的 TEI 特征（如患者年龄和性别）对计划指标进行分类？与总体指标不同，计划指标不允许按类别选项组合进行即时数据分类。为了对计划指标进行分类，每进行一次分类，都必须创建一个新的计划指标。

为了创建分类，需要将一个新的子表达式与计划指标的**过滤器**连接起来。例如，上一节中描述了 "有潜在疾病的患者 "PI 的过滤器：

d2:countIfValue(#{covacprogramUID.underlyingcondUID},'Yes')>=1`

若要添加患者性别分类，则需要为跟踪的实体属性值添加两个额外的计划指标，一个是男性，另一个是女性。

d2:countIfValue(#{covacprogramUID.underlyingcondUID},'Yes')>=1 && A{sex}==='Male'`。

d2:countIfValue(#{covacprogramUID.underlyingcondUID},'Yes')>=1&&A{sex}==='Female'`"。

要根据年龄限制筛选条件，可添加一个子表达式来筛选出生日期和分析期开始日期之间的时间。

d2:countIfValue(#{covacprogramUID.underlyingcondUID}, 'Yes')>=1 && d2 yearsBetween(A{dob}, V{analytics_period_start}>=60)`

这些新增内容对于编制少量分类指标来说可能并不困难。但是，在分类较多的情况下，手工复制和修改每个计划指标，并长期保持对它们的修改，是一项繁琐的工作。例如，如果按两个性别和四个年龄段进行分类，就需要八个不同的计划指标。

已开发出两个定制的 DHIS2 应用程序，用于按多种条件自动分列计划指标。

• 计划指标分类应用程序（来源：坦桑尼亚 HISP）

• 程序数据集连接器应用程序（来源：BAO systems）

提示

如果您使用 PDAC 应用程序，您可以将计划指标的分类应用到汇总数据元素的类别组合中。这有助于实现从跟踪器到汇总数据的流水线操作，具有许多优势，例如可加快仪表盘上的分析查询速度。

跟踪分析对数据使用的影响{ #implications-of-tracker-analytics-for-data-use }¶

• 跟踪数据既是纵向的，也是地理分布的。这意味着单个技术教育指标的数据本质上与一个时期或一个组织单位无关。计划指标定义了如何根据一个时期维度和一个组织单位维度来查询跟踪数据。
• 在设计用于汇总跟踪器数据的计划指标时，必须明确您是在计算唯一的会诊（事件），还是在计算患者（注册人数，如果注册人数可重复，则为 TEI）。
• 所有唯一患者计数必须 使用注册类型 PI，因为事件类型会导致重复计算较低级别的患者。同样，所有纵向 PI（需要一个以上事件数据的计算），必须 使用注册类型 PI。对于低于 2.40 版的 DHIS2，病人计数和纵向指标与病人注册的组织单位相关联，而该组织单位 有时并不是提供服务的地点。
• 注册类型 PI 为查询纵向数据提供了一种强大的方式，但在病人管理中，注册可能会长期开放，因此应谨慎使用添加 d2:countIf() 语句。在仪表盘上即时计算时，这些语句会减慢仪表盘的运行速度并降低系统性能。
• 在注册类型 PI 中，有可能将 "所在 "维度误解为事件组织单位，而不是注册组织单位。这一点应在仪表盘和培训中告知最终数据用户。
• 在开发具有自定义 "分析期间边界 "或自定义 "组织单位 "的 PI 时，请确保在 PI 的名称和描述中包含描述这些自定义的文本，以及其所属的任何指标和呈现这些数据的任何可视化或仪表板，以支持对结果的解释。
• 在全国范围内，事件型 PI 的计算速度通常比注册型 PI 快得多，而且可能更容易为最终用户所解释。在为您的计划设计重要的计划指标时，如果可能的话，尽量想办法将所有相关的计划数据都包含在一个计划阶段中。程序规则允许将前一事件中的数据元素值分配到后续事件或另一阶段中。此外，还可以使用程序规则，根据输入的特定数据值，只显示特定部分的程序阶段，从而更容易将所有相关数据纳入单一阶段。
• 请参阅《追踪器实施指南》，了解 COVID-19 疫苗系统在配置[大规模追踪器分析]（#分析性能）方面的更多经验。

一旦你对跟踪实体属性、计划阶段、数据元素和所需的计划指标有了一个概念，你应该能够为你建议的跟踪系统绘制一个**系统设计图**，突出个人注册如何在每个阶段之间进展。请参阅 DHIS2 元数据包文档中的 示例。

在为程序绘制出示意图或早期原型后，您应审查便于最终用户输入数据的其他功能。

您可能还想与利益相关者和部分最终用户一起审查这一早期原型，以便就拟议计划设计的可行性获得一轮反馈。