计划阶段 结构{ #program-stages-structure }¶

在确定要使用的个人标识符之后，您就可以通过定义**计划阶段**来绘制计划的总体结构图了。

跟踪程序可以有一个或多个程序阶段。每个程序阶段都定义了程序中特定类型的事件，包括应收集哪些数据、以何种顺序收集、使用何种数据验证或交互逻辑（程序规则）。使用纸质表格类比，可以将每个程序阶段视为病人病例档案中的一个特定表格。无论是诊断咨询还是常规随访，医疗服务提供者与患者的每一次接触，都应填写带有预定义问题的特定表格。

例如，一个简单的 "疾病治疗 "程序可能有初始病例报告阶段、治疗阶段、实验室阶段和结果阶段。

简单疾病程序](resources/images/simple_program.jpg""){ .center width=70% }

在 Tracker Capture 应用程序中，这个程序阶段的设计将这样呈现：

在这一步，需要考虑计划阶段的三个重要特征：

• 内容：每个阶段都有哪些问题，应该如何安排？
• 频率：某些阶段可以执行多次吗？
• 顺序：程序阶段是否应该按照一定的顺序输入，它们之间是否有一定的时间间隔？

内容：数据元素和章节{ #content-data-elements-and-sections }¶

程序阶段主要由数据元素和数据输入表组成。

创建和命名计划阶段的第一步是分配数据元素。有关输入计划阶段详细信息的更多信息，请参阅下文**排序。如果您首先需要在跟踪器域中创建数据元素，请参阅用户指南。创建数据元素时，您会发现数据元素 ** 值 ** 类型**有多种可能。您还可以为数据元素指定一个选项集（即多选列表）。

下面是创建**跟踪器域数据元素**时的一些经验法则：

• 为数据元素选择合适的值类型至关重要。一旦在任何程序中输入了该数据元素的值，就不能轻易更改值类型而不丢失以前的值。其他数据元素属性，如名称、描述和存储零值，可在数据值已输入数据库后更改。
• 最常用的值类型是文本、整数和数字。如果要使用其他限制性更强的值类型，请务必仔细阅读文档，并提前测试值类型，以确保确实需要使用它。
• 一般来说，为确保数据质量，最终用户应在可用的最低抽象级别输入数据。例如，以整数值输入原始血压比以文本输入血压状态（如 "血压高 "和 "血压正常"）更可取。DHIS2 可根据患者的血压值自动计算血压状态，并遵循全国统一的惯例。
• 如果需要文本值类型，选项集总是优于用户输入的自由文本，因为这样可以减少人为误 差，并使生成的数据更易于分析。
• "聚合类型 "指的是将所有事件的原始数据元素值进行聚合时的_默认_聚合方法。然而，基于跟踪器的指标通常是通过_程序指标（见下文）_来计算的，这种指标在数据采集后更具灵活性和可定制性。因此，不必担心您的聚合类型应该是 COUNT、NONE 还是 SUM。
• 大多数带有选项集的数据元素都使用 TEXT 值类型，而选项集的值类型也是 TEXT。如果对带有选项集的数据元素使用不同的值类型--例如，可能的数值列表--则应确 保所选值类型在数据元素和选项集之间相匹配。还要记住，数据元素的聚合将以选项集代码为基础，因此这些代码必须符合所选的值类型。
• 如果值类型是文本，聚合类型通常是 COUNT 或 NONE。
• 如果数值类型是数值，聚合类型通常是 COUNT、NONE、SUM 或 AVERAGE。数值类型还可以使用其他聚合类型（如标准偏差），但一定要事先测试是否真的需要。

在决定数据元素值类型时，经常遇到的一个难题是从预定义列表中选择多个值（"选择多个" 类型的问题）。虽然截至 v2.40 的汇总数据集中提供了这一功能，但 DHIS2 Tracker 中并没有特定的数据值类型，因此采用了两种不同的设计策略。

• 如果选项列表很短（3-10 个），但用户可能会全选或不选，则可为每个选项配置单独的 "只选" （复选框）数据元素。您可能希望包含一个 "全选 "复选框或一个 "不选 "复选框。这样可以最大限度地提高数据输入的灵活性，但过多的复选框可能会使数据输入表 格变得非常冗长。
• 如果选项列表有点长（10-20 个以上），但用户一般只选择其中有限的几个（1-4 个），那么就可以为 "选择 1"、"选择 2"、"选择 3 "等创建不同的数据元素，每个数据元素都有相同的选项集。利用程序规则，如果选择 1 填满，表单就会显示选择 2 数据元素，如果选择 2 填满，表单就会显示选择 3（有关程序规则设计的更多详情，请参阅下文）。

选择数据元素后，您会看到每个数据元素都有七八个可能的参数。对于大多数程序配置，您只需考虑 ** 强制 ** 复选框。在该阶段的数据输入过程中，用户将被阻止保存其事件，直到所有 "强制 "数据元素都已输入。作为程序设计人员，您必须仔细考虑是否任何数据元素在所有情况下都是必需和可用的。如果有可能出现空值或未知值，那么该数据元素就不应该是强制性的，否则可能会使最终用户感到困惑，并导致数据质量低下。请注意，如果数据元素只有在特定条件下才必须使用，则可通过程序规则操作进行配置。

有关其他参数的详细信息，请参阅《用户指南》（#create-or-edit-a-tracker-program）。

选择计划阶段数据元素](resources/images/image11.png "选择计划阶段数据元素")

选择了程序阶段的内容后，您就可以决定该阶段的数据输入结构。

与事件程序和数据集一样，Tracker 中也有三种类型的数据输入表单：

表格类型	描述
基础	列出属于程序的所有数据元素。您可以随时更改数据元素的顺序。
删除源指标,增加目标指标	各部分按特定顺序组合数据元素。然后，您可以随时安排各部分的顺序，创建所需的数据输入表布局。
定制	将数据输入表单定义为 HTML 页面，您可根据需要进行自定义。(注意：此功能仅适用于 Tracker Capture 应用程序）。

如果没有定义自定义表单或分段表单，则将使用基本表单。基本表格最简单易用，因为它们基本上是一个长长的列表，列出了分配给阶段的所有数据元 素。但是，如果程序阶段数据元素的数量过多，需要滚动才能全部看到，那么表格就会使用户难以找到特定的数据元素。

各部分实质上是数据输入表单中的小标题。由于它们将数据元素组合在一起，因此可以创建一种垂直结构，帮助最终用户导航。因此，一般推荐**分节表单**。在 Android 应用程序中，打开阶段时所有分节默认都是折叠的；用户需要点击分节标题才能看到其数据元素。

自定义表单在设计 DHIS2 数据录入体验方面具有最大的灵活性，可以模仿纸质表单或其他国家信息系统，包括自定义颜色、内联图像和显示格式。然而，出于多种原因，大多数实施工作应尽可能避免使用自定义表单。随着新数据的添加，自定义表单需要额外的设置和维护工作；无法在安卓应用程序中使用；未经测试，无法与新的 DHIS2 更新一起使用；如果出现故障，则需要熟悉 HTML 的熟练系统管理员提供紧急援助，以排除故障。如果自定义表单和分区表单都存在，则自定义表单优先于分区表单。

有关如何配置程序阶段窗体的信息，请参阅[用户指南]（#configure_tracker_program_in_Maintenance_app），示例请参阅 Play 演示。

频率：可重复阶段{ #frequency-repeatable-stages }¶

程序阶段可以是一次性的，也可以是可**重复的。为什么要让程序阶段可重复？当阶段捕获的数据在范围上是可预测的，但在频率上是不确定的。例如，HIV 监测计划可能会为 "患者访视 "设置一个可重复阶段，因为大多数患者每个月都会接受抗逆转录病毒治疗。他们一生中可能会接受一次、两次、十次或数百次治疗。

需要注意的是，每个注册阶段生成可重复阶段的次数没有上限。如果没有严格的限制，最终用户可能很难回头查看或编辑之前重复的事件，或者用户可能会意外创建大量不需要的事件。不过，可以编写程序规则，以便在程序阶段的计数超过某个阈值时显示警告或错误信息。实践社区中描述了这一过程。

使用可重复阶段的主要缺点来自 DHIS2 分析，特别是使用来自多个事件的数据元素值的更复杂的计划指标。考虑上述计划的 "治疗阶段"，假设一般有四个治疗事件。

可重复处理阶段可实现以下计划指标：

• 每位患者的平均治疗次数
• 去年注册的患者中，治疗事件总数超过五次的患者人数
• 最近一次就诊时接受药物治疗的 18 岁以上患者人数
• 上个月在一次或多次治疗活动中接受药物治疗的男性患者人数

可重复治疗阶段不可能实现以下计划指标，但如果有单独的序数治疗阶段（治疗 1、治疗 2 等），则可以实现以下计划指标。

• 首次治疗事件与结果事件之间患者体重的平均差异
• 上个月在入院后不到 5 周的治疗就诊时接受药物治疗的患者人数
• 连续两次就诊期间接受药物治疗的患者人数总计

从可用性和维护角度来看，使用较少的程序阶段通常是最简单的。不过，在最终确定程序结构之前，应考虑程序的分析要求，以防可重复阶段带来挑战。

排序：舞台工作流程和活动安排{ #sequencing-stage-workflow-and-scheduling-events }¶

再看看上面的病人流程图。你会发现病人数据在通过数据收集系统时有一个可预测的路径。程序有明确的入口点和出口点，中间还执行了许多标准流程。

一旦你定义了每个阶段的内容，并确定其中是否有重复的内容，那么你就应该考虑最终用户输入各阶段的逻辑顺序。数据录入的顺序业务逻辑应在系统设计指南中明确定义，以支持跟踪系统终端用户的培训，并改进跟踪系统分析的解释。

例如，"简单疾病治疗计划 "有四个阶段：初始病例报告、治疗、实验室检测和结果。注册时，诊断细节被输入初始病例报告。如果病人康复、死亡或被认为失去随访机会，则记录在 "结果 "阶段。治疗和实验室检查可以重复多次，但必须在初始病例报告和结果阶段之间的某个时间进行。通常情况下，实验室检测和治疗就诊将由实验室和诊所的不同医务人员同步记录。

简单疾病治疗计划](resources/images/simple_program.jpg){ .center width=80% }

应更详细地审查最终用户在初始病例报告、治疗和实验室检测表格之间的顺序流程。

• 在实验室检测确诊之前是否可以建立病例档案？
• 在实验室结果确诊之前是否可以进行治疗？
• 患者是否应在初次病例报告的同一天接受治疗？
• 如果临床治疗后需要进行后续检查，如何通知实验室？
• 是否建议每次治疗之间的间隔时间，例如每 30 天一次？

这些问题需要对医疗系统的病例管理程序和临床工作流程有深入了解的主题专家来回答。如果需要遵循严格的协议，例如治疗间隔的最短天数，则可以通过 DHIS2 系统的设计加以强化。

在此设计阶段，回顾一下 DHIS2 跟踪系统中不同类型的日期以及它们与数据录入过程的关系可能会有所启发。

本表解释了最终用户在输入数据时可编辑的日期。每个日期的名称都可以在程序配置时进行编辑，使这些概念在上下文中更容易理解。

日期	描述
注册日期	TEI 实际加入计划的日期
事件日期	触发技术教育指标（TEI）第一个事件的真实世界发生日期
报告日期	用于报告的事件日期。既可以定义为实际发生事件的日期，也可以定义为系统记录事件的日期。
到期日	事件预定发生的日期。未来的到期日期可在注册时或数据录入时设置。与报告日期不同，事件日期可以在未来设置。

每个事件都记录了更多日期。请参阅下面 [附录 A]（#附录-A-跟踪日期）中的完整列表。

Tracker 中没有严格定义程序阶段数据输入顺序的默认方法。不过，有几种方便的方法可以指导最终用户对程序阶段进行排序。

首先，在维护应用程序中配置程序时，可以对程序阶段进行排序。进入 （4）程序阶段，点击任何阶段上的三点 "操作 "菜单，您就可以在列表中上下移动该阶段。点击 "保存 "后，无论使用 "表格数据录入 "部件还是 "时间轴数据录入 "部件添加新的程序阶段事件，都将改变 Tracker Capture 应用程序中各阶段的垂直排序顺序。

.

在某些使用情况下，实施系统可以通过在每个阶段名称中添加序号前缀来使阶段顺序更加清晰，例如，阶段 0 - 前次分娩、阶段 1 - 第一次产前检查、阶段 2 - 第二次产前检查等。

另一种执行程序阶段顺序的方法是使用程序规则。请注意，上述产前护理计划在维护应用程序中列出了 "产后护理访问 "阶段，但在数据录入时还看不到该阶段。这是因为有一个程序规则条件，即除非在 "出生护理 "阶段记录了出生，否则就会隐藏产后护理阶段。这样的程序规则可以层层叠加，应用严格的顺序逻辑，如完成第一阶段解锁第二阶段，完成第二阶段解锁第三阶段等。

以下是设置标准程序阶段顺序的其他方法。

• **在注册页面上显示第一个阶段**将在注册页面上嵌入第一个列出的阶段，迫使用户在病人注册到计划之前完成第一个阶段。在维护应用程序中，该设置配置在 "计划详情 "部分，而不是 "计划阶段详情 "部分。

注册页面的第一阶段](resources/images/image5.png "注册页面"){ .center width=80% }

• 要求用户在完成该阶段后完成程序。该程序阶段设置可用于标记序列的最后程序阶段，因为它会提示用户在该阶段完成后关闭注册。

• 注册后打开数据输入表单 将使用户在完成注册后直接进入该阶段的数据输入表单。这意味着活动将默认为 "激活 "状态。只有选中"自动生成事件"，才能激活此设置。
• 注册后自动生成（计划）事件。此设置将在注册日期后的规定天数内自动生成该阶段的计划事件。例如，初始病例报告阶段可以在注册后立即开启，而实验室阶段则会自动生成，计划在进入计划七天后进行。这意味着初始病例报告发生在实验室阶段之前。只有当计划遵循标准的事件顺序，且事件之间的间隔可预测时，才可使用此设置。
• ** 为可重复程序阶段中的下一个预定事件设置间隔。** 用户完成一个可重复程序阶段后，就可以为该阶段安排下一个事件。程序将自动推荐下一个事件的到期日。这可能是最近的事件日期加上"标准间隔天数" 值，或者是上一个事件的日期类型数据元素（配置程序规则，如此处示例）。
• 事件周期类型 这一可配置的设置为程序阶段中的每个事件设置了特定类型的周期。最终用户可以选择一个时间段，如一天、一周或一个月，而不是为事件日期选择一个日期。用户不能在所选时间段内输入多个事件。请参见此处的 "每日 "事件时间类型示例。

下表概述了计划阶段排序的配置方法

舞台顺序	流量控制	配置方法
第一种	严格指示（用户必须遵守）	在注册页面显示第一阶段
	灵活指导（用户可能不遵守）	注册后开放数据输入表
	严格指导	程序规则隐藏其他阶段，直到第一阶段完成
中间阶段	灵活指导	通过警告框、阶段名称前缀等引导用户下一步执行哪个阶段
	严格指导	如果输入顺序不正确，程序规则会在完成阶段时显示错误
	灵活的指导	按特定顺序自动安排各阶段的截止日期（最远的阶段为 "最后 "阶段）
最后阶段	灵活	程序阶段设置：要求用户在完成阶段后完成程序
	灵活/严格	程序规则：在最后程序阶段输入数据后显示警告，要求用户完成程序

预定活动和到期日{ #scheduled-events-and-due-dates }¶

就像病人可以到期预约一样，注册跟踪程序的人也可以安排事件。用技术术语来说，如果一个事件有到期日期，但没有报告日期，那么它的状态就是 "SCHEDULED"。计划事件可以帮助最终用户了解在数据录入过程中下一步需要输入哪些阶段。它们可在 DHIS2 行列表应用程序中查看，而采集中的工作列表则可显示即将到来或错过的预约。此外，"到期日 "还可用于安排程序通知，如提醒患者即将到来的预约。

不过，我们也要考虑到活动安排功能的局限性。

• 每个招生计划的每个阶段每次只能有一个预定事件，即使该阶段是可重复的。
• 自动推荐的到期日可能是周末或节假日，因此用户应在安排事件前确认到期日是否有效。
• 用户可以随时更改事件的到期日，但这些重新安排的操作不会被记录，只有最新的到期日才会被提供。此外，一旦计划事件被打开，事件状态从 "计划 "变为 "活动"，就无法查看该操作发生的时间或哪个用户打开了该事件。这意味着很难分析预约的后续情况，即很难估计有多少已安排的预约变成了活动访问。
• 在许多使用案例中，程序阶段永远不会被计划，因此 "到期日 "的概念可能会让最终用户感到困惑。在这种情况下，您可以考虑在维护应用程序中配置程序阶段详细信息时选中 "隐藏到期日期"。

活动和注册生命周期{ #the-event-and-enrollment-lifecycles }¶

每个事件和注册都有一个状态字段。它们还可以被标记为软删除或丢失，以便跟进。通过正确的权限，最终用户也可以创建或删除事件。

部署跟踪器后，您可能需要检查用户是否严格遵守规定的控制流程，或调查有问题的数据。这些事件和注册的状态字段将帮助您了解用户活动，并生成适当的程序指标。

入学人数

• ACTIVE.当被跟踪的实体参与该计划时，它将同时被使用。
• 已完成。当被跟踪实体结束参与计划时使用。
• 已停用。网络用户界面中的 "停用"。当被跟踪实体取消参与计划时使用。

活动

• 激活。通过 "添加新事件 "创建事件后，会立即将其设置为 "活动"。如果事件处于 "活动 "状态，则可以编辑事件详细信息。已完成的事件可以再次变为活动，反之亦然。
• 已完成。只有当用户单击 "完成 "按钮时，事件的状态才会变为 "已完成"。如果事件处于已完成状态，则无法编辑事件详细信息。活动事件可以再次变为已完成，反之亦然。
• 被剔除。不再需要发生的预定事件。在 Tracker Capture 中有一个按钮。
• 日程。如果事件没有事件日期（但有到期日），则事件状态保存为 "日程"。当通过 "计划事件 "选项卡创建事件时，它们会立即被设置为 "计划 "状态，直到有事件日期为止。
• 逾期。如果计划事件（无事件日期）的到期日已过，则可解释为 "逾期"。
• 已访问。(自 2.38 版起已删除。VISITED 已迁移至 ACTIVE）。在 Tracker Capture 中，可以通过添加带有事件日期的新事件来达到 VISITED 状态，然后在向事件添加任何数据之前离开。在用户界面中看不到 "已访问 "状态，其处理方式与 "活动 "事件相同。

一个阶段还是多个阶段？将服务划分为 "部分 "和 "阶段"{ #one-stage-or-multiple-grouping-services-as-sections-vs-stages }¶

回顾上述内容，我们可以发现，数据元素既可以按照计划阶段来组织，也可以按照阶段内的各个部分来组织。程序阶段可以是一次性的，也可以是可重复的。程序规则可根据先前的数据值显示或隐藏某些阶段或部分，从而创建控制流，以规定的顺序输入数据。

因此，设计跟踪程序的最关键步骤之一就是了解如何有效地使用阶段和部分来将不同的数据元素组织在一起。

在健康领域，我们可以将跟踪数据元素大致归类为向每个人提供的**"服务 "**集。这些服务可以是管理性的：

• 在同一次就诊中，由同一医疗服务提供者提供
• 在同一事件中，但由不同用户输入
• 在一个标准的周期性相遇序列中
• 以非结构化的异步方式记录服务，可以是在同一次或不同一次就诊中记录的服务，也可以是由同一医疗服务提供者或不同医疗服务提供者记录的服务

作为一般经验法则，**用户应能在同一程序阶段**内输入单次就诊提供的所有服务。除非不同的用户输入了不同服务的数据，或者后来才有了额外的数据（如检验结果、新的就诊病例等），否则通常没有必要在不同阶段之间移动。

下面举例说明如何将同一项目下的服务建模为阶段或部分。我们将回到之前的例子，即一个包含病例报告、治疗、实验室和结果等阶段的通用 "治疗计划"。治疗 "和 "实验室 "服务是否可视为包含在同一阶段中？

1. 在一个可重复的 "参观 "阶段提供所有核心服务
   1. 当所有服务都可以由同一个人在同一次就诊中提供时，这种配置是最理想的
   2. 在本例中，病例报告不可重复，因为它只在注册时出现一次。
   3. 该示例还显示了 "选择服务 "部分，该部分带有复选框（只选中 "是 "数据元素）和程序规则，用于隐藏其他服务部分，除非该服务被 "选中"。这可以让用户轻松跳过问题较多的其他部分（服务），从而加快工作流程。
   4. 可以认为，"结果 "与治疗或化验结果同时记录。如果输入了病例结果值，程序规则会要求用户完成注册。程序规则还可以阻止为该病例打开未来的就诊事件。

1. 所有核心服务都是各自不可重复或可重复的阶段
   1. 如果实验室检测结果与提供的治疗不同步输入（由不同用户或在不同时间点输入），则是更好的设计。
   2. 然而，跨治疗和化验结果阶段的计划指标更难计算，例如 "化验结果呈阳性与治疗之间的天数 "或 "在化验结果呈阳性之前接受治疗两次或两次以上"。
   3. 此示例仍有一个不可重复的病例报告阶段，用于输入基本的病例详细信息。有些程序还会根据注册或初始病例报告时输入的详细信息，在阶段中显示或隐藏后续事件。
   4. 由于实验室结果和治疗是分开的，因此结果阶段也是分开的。您可以在此进行设置，以便在阶段完成后完成程序。

1. 一个可重复的参观阶段，根据需要展示其他阶段
   1. 与示例 2 类似，关键服务（治疗和化验结果）被分成两个可重复的阶段，供不同的用户使用。不过，这两个阶段在向任何服务阶段添加新事件之前，可能会共享一个必要的问题列表，例如对可能需要紧急护理的患者症状进行 "快速检查"。这份数据元素清单可能是每次就诊时需要输入的大部分数据，而治疗和实验室结果则由不同的服务提供商以异步方式输入。
   2. 与示例 1 类似，此访问阶段可以包括 "选择服务 "问题，其中的程序规则可以隐藏后续 阶段，直到访问阶段在当前日期完成。
   3. 当有两个或多个可重复部分时，这也是计算 "就诊 "真实次数的一种方法。在例 2 中，计划指标可以计算出治疗事件和实验室结果事件的总数，但无法计算出在同一次就诊（即同一天）中同时发生了多少次。
   4. 如果程序中存在多个条件，并可能出现多个实验室结果，则有必要将每个结果记录为离散事件。
   5. 其他预防计划，不同提供者提供不同的服务 = 异步数据录入

1. 服务的每次迭代都有自己的阶段
   1. 没有可重复的阶段，因此必须假定在注册过程中最多有固定的接触次数（例如，为每个结核病接触者最多提供三次随访测试，因此 FU 1、FU 2、FU 3 可以分别作为不同的阶段）。
   2. 在某些用例中，每个人可以或应该就诊的次数是固定的。例如，一个疑似肺结核病人应该就诊五次，每次就诊之间有固定的时间间隔。在这种情况下，为序列中的每个步骤设置一个单独的不可重复阶段是合理的：1 号治疗、2 号治疗和 3 号治疗等。程序规则可以隐藏所有其他治疗，直到 1 号治疗完成；3 号治疗隐藏，直到 2 号治疗完成，以此类推。
   3. 这种方法的主要优点是可以在每次就诊之间设置固定的到期日间隔。根据特定数据元素值在序列中出现的位置（"肺结核接触者在 3 号就诊时开始治疗"），也可以更容易地筛选出注册计划指标数据。
   4. 但我们不建议这样做，因为任何这种 "固定最大值 "的遭遇都可能随着系统的发展而发生变化，而且一旦输入数据，就很难恢复到可重复的阶段。行列表和事件类型计划指标的配置更为复杂，因为需要将多个阶段组合在一起。此外，单独维护每个阶段可能会造成负担，因为必须对每个单独的阶段进行更改，而且数据录入人员在浏览时也会感到困惑。

艾滋病毒预防跟踪器示例

在拉丁美洲的这项艾滋病毒预防计划中，每次登记都从风险评估阶段开始，以获取病例监测数据（如关键人群状况）。一旦注册，每次就诊都是一次 "访问"，其中有多个部分，可根据需要显示或隐藏，包括 HIV 检测、暴露后预防、风险评估跟踪和性传播感染筛查。如果发现有感染 HIV 的严重风险，则会提供另一部分用于 PrEP。如果一个病例在注册时已是 HIV 感染者，则警告框会提示该病例已加入单独的 HIV 病例监测计划。

艾滋病预防计划示例](resources/images/image42.png "计划结构示例")

计划阶段的设计对设计适当的分析方法以行列表和汇总跟踪器数据有影响。对于用户与同一个人有多个 "接触点 "的健康计划而言，将用户工作流划分到不同的计划阶段可能会更容易。不过，正如我们将看到的，如果将所有数据归入单一的计划阶段，通常更容易配置和使用计划指标。

附录 A：跟踪日期{ #appendix-a-tracker-dates }¶

跟踪模型中可用日期的完整列表

跟踪日期	可查看	描述
TEI 创建日期	应用项目接口	在 DHIS2 数据库中首次创建的跟踪实体实例（TEI）。
TEI 最后更新日期	应用项目接口	TEI 任何属性的最后更新时间
TEI 创建于客户日期	应用项目接口	最终用户生成 TEI 的日期。在将 Android 应用程序上创建的 TEI 与 DHIS2 数据库同步时使用。
创建注册日期	应用项目接口	首次在 DHIS2 数据库中创建注册。
注册最后更新日期	应用项目接口	登记表中任何事件的最后更新时间
注册日期	应用程序接口/用户界面	TEI 实际加入计划的日期
事件日期	应用程序接口/用户界面	触发技术教育指标（TEI）第一个事件的真实世界发生日期
完成 日期	应用项目接口	注册被标记为完成的日期
事件创建日期	应用项目接口	事件首次在 DHIS2 数据库中生成。
事件 最后更新日期	应用项目接口	事件中任何数据值的最后更新时间
活动日期	应用程序接口/用户界面	用户输入的事件实际发生日期
到期日	应用程序接口/用户界面	事件的预定日期，可以在关闭上一个事件时生成，也可以在打开事件时自动生成或编辑。