定义跟踪实体{ #defining-the-tracked-entity }¶
至此，您已详细绘制了报告系统，并开始将这些报告系统概念与 DHIS2 术语进行映射。重温一下 DHIS2 的关键概念，回忆一下跟踪实体实例 (TEI)、注册、跟踪实体属性 (TEA) 和数据元素之间的区别，可能会有所帮助。
下面的章节将以这些知识为基础进行描述：
- 例行报告中的核心分析单位（"*追踪的是哪类记录？）
- 识别每条记录与其他记录不同的数据点（"*用户如何搜索和识别唯一记录？）
人员和案件{ #persons-and-cases }¶
您应该考虑的第一个问题是，被跟踪的个人是否会有多次接触或跟踪。如果与客户只有一个 "接触点"，例如单剂量疫苗接种活动，您可以考虑使用事件捕获数据模型。使用跟踪器的好处有限，除非客户会被多次看到。事实上，个人级别的跟踪会给护理提供者带来输入和查询患者标识符的额外负担，而且在非必要时存储此类敏感信息还会带来不必要的数据安全风险。
第二个问题是登记是否**可重复**，即一个人一生中是否可以被视为 "病例 "不止一次。对于一些跟踪慢性病的项目，如儿童免疫接种和艾滋病病毒感染，如果同一个人登记了不止一次，那么这个病例就被认为是重复的。而对于产前护理或疟疾调查等其他项目，一个人在项目中循环多次可能很常见。这一决定对搜索过程、记录重复和指标计算都有影响。
请注意，大多数跟踪器用例的跟踪实体实例类型都是 "人"，但疾病监测 "病例 "除外。一个人可能注册了多个项目，接受不同类型的医疗服务；因此，要查看一个人的临床病史概览，将病人跨项目的所有注册信息链接到一个共同的 "人 "TEI 是非常有用的。在疾病监测场景中，使用 "病例 "跟踪实体实例类型可能更合适，每个病例都有自己的唯一标识符编号，并被视为一条不同的记录。在这种情况下，最急需的是快速报告：没有必要将病人以前经历的病例联系在一起，而搜索 "人 "的 TEI 来联系病人以前的所有注册记录只会减慢数据录入过程，而不会增加价值。
此外，一些特殊用例需要将非人作为被跟踪实体进行跟踪，例如跟踪医疗用品或药品的物流程序。
注
为描述最常见的跟踪器应用场景，本指南将假设使用案例中的跟踪实体类型为 是 "人"、"病人 "或 "客户"，除非另有说明。
标识符和数据元素{ #identifiers-and-data-elements }¶
下一个重要区别是将 ** 跟踪实体属性** 与其他重要数据点分开。
一般来说，"追踪实体属性"（TEA）有助于确定 TEI 记录属于某个特定的客户。其中一些可能是_可搜索_的，这意味着用户可以用 TEA 值查询 DHIS2 数据库，找到病人的注册信息。用户只需查看记录的 TEA 即可确定该记录属于其客户。
这些数据通常只采集一次--即客户首次加入追踪项目时--因此应被视为可靠的半固定值，在不同项目之间很少发生变化。
**数据元素**是为跟踪程序输入的所有其他数据。它们通常用于表示客户的健康状况、诊断、治疗、结果或接受的其他服务。与 TEA 相比，它们更有可能在与医疗服务提供者的接触中发生变化。请注意，这些数据元素应使用域类型 "跟踪器"，以便与汇总域中使用的数据元素区分开来。
*** 跟踪实体属性***与客户的*身份*有关，可帮助用户核实他们在 DHIS2 中看到的 TEI 代表了相关的特定人员。
数据元素****是所有其他*表格字段*，通常与客户的健康记录或他们在项目中接受的其他服务有关。
跟踪实体属性的标准示例包括客户姓名、出生日期、电话号码和其他国家标识符。数据元素通常因健康领域而异，但通常包括疾病诊断、病人体重、化验结果、提供的药物和治疗结果。
数据元素和跟踪实体属性都有多种类型，包括日期、是/否、仅是、自由文本和 "单选 "多选（选项集）。跟踪实体实例属性值类型和数据元素值类型的完整列表可在《跟踪用户指南》（#configure_tracked_entity）中找到。
此外，程序规则 可用于验证这些字段的值，或应用跳过逻辑，只在特定条件下显示这些字段。程序规则提供了一种在跟踪器和事件捕获中根据用户输入生成动态行为的方法。有关程序规则的更多信息，请参阅[交互设计]（#interaction-design）部分和《用户指南》。
作为个人标识符的跟踪实体属性{ #tracked-entity-attributes-as-personal-identifiers }¶
跟踪实体属性可以说是将特定客户的身份与其个人健康记录联系起来的数据点。它们可以帮助医疗服务提供者最初_注册_一个独一无二的人，然后再_搜索_和_检索_相同的记录。在某些情况下，如疫苗接种登记处，标识符还可以验证一个人是否有资格获得服务。在许多情况下，并非所有患者都能获得国家身份标识符；据世界银行称， 全球有超过 10 亿人 没有官方身份标识。在这种情况下，医疗服务提供者可能需要依靠不同的跟踪实体属性组合来唯一识别跟踪器中的病人。
理想的跟踪实体属性既要**universal（高可用性），又要unique**（高特异性）。跟踪程序通常需要多个 TEA 来帮助用户执行搜索、注册和验证操作。
下表根据 DHIS2 实施者的经验，按可用性和特殊性列出了 TEA 的常见示例。
| TEA 名称 | 可用性 | 特异性 | 评论 |
|---|---|---|---|
| 姓氏 | 高 | 低 | 在任何文化背景下，同姓客户的比例通常都很高（史密斯、冈萨雷斯、班达、阿里、德维等）。以自由文本形式输入姓氏也容易出现拼写错误或音译问题。 |
| 出生日期 | 中-高 | 高 | 许多客户可能不知道自己的准确出生日期。请注意，"年龄 "类型的 TEA 将根据登记时报告的年龄（以年为单位）计算出一个估计的出生日期，因此在不同计划中使用时非常不精确，也不一致。更好的解决办法是在 "出生日期是估计的 "TEA 中添加 "是"，以补充 "出生日期 TEA"。 |
| 电话号码 | 中-高 | 高 | 电话号码可以很好地充当不同的标识符，尽管它们可能会随着客户更换移动服务提供商而改变。请注意，有些客户可能没有手机，或者可能与他人共用手机。程序规则可以在输入数据时验证电话号码的长度或起始位数。 |
| 地址 | 中低 | 中-高 | 城市和农村环境中的许多客户居住在公共住房或无地址的住宅中。容易出现自由文本拼写错误，作为客户搜索标准的作用较小。 |
| 居住地村庄（或其他区域地理位置） | 高 | 低 | 可能有助于确认搜索结果，尤其是在住所没有地址的情况下。但类似的拼写错误和搜索准确率低的问题依然存在。 |
| 国民身份证 | 中低 | 非常高 | 尽管民事登记和人口动态统计（CRVS）在全球范围内得到了改善，但许多情况下并没有一个通用的、独一无二的标识符，如国民身份证。虽然在拥有国民身份证计划的国家中，唯一性很高，但调查显示 覆盖面可能分布不均。在低收入国家，妇女、儿童和低收入阶层拥有国民身份证的可能性较低。一些实施 DHIS2 的国家将其系统与中央民事登记和人口动态统计系统登记册连接起来，将国民身份证自动输入客户记录。 |
| 原产国 | 中 | 非常低 | 可用于疾病监测，以确定疾病来源、补充客户地址或识别护理不公平现象。不建议用于客户搜索。 |
| 国民健康（保险）身份证 | 中 | 高 | 在存在此类标识的情况下，某些情况下可能会有多个保险计划或多个国家标识。因此，用户在注册和搜索时可能需要从多个国家标识符（如护照号码、保险计划号码、出生证）中选择一个。 |
| 案件编号（书面） | 中 | 高 | 一些医疗单位在纸质登记册上为每位患者预印了一个唯一的病例 ID。可以在登记时手动将其输入 DHIS2。 |
| 唯一标识符（自动生成） | 高（网络） 中-高（安卓） | 高 | DHIS2 可根据顺序或随机模式自动填充唯一标识符字段。这些标识符在安卓设备上是本地保留的，需要定期同步到服务器以刷新本地可用标识符列表，因此包含顺序标识符或日期的标识符可能会有性能影响或意外行为。有关 TextPattern 的更多信息，请参见用户指南。 |
* 在许多情况下，一个 "人 "在其一生中可能多次被视为一个程序 "案例"。因此，只有当跟踪实体类型为_Case_时，才可将案例 ID 用作跟踪实体属性。如果跟踪实体类型是_Person_，那么病例 ID 可以用作程序阶段的数据元素，作为验证检查，但不应该**用作跟踪实体属性，因为一个人可能有不止一个病例 ID。相反，在疾病监测中，被跟踪实体类型是 "病例 "而不是 "人"，那么实施者就不能使用任何唯一个人标识符，如国民标识符，因为这可能被复制到属于同一个人的多个病例中。
跨计划共享 TEA{ #sharing-tea-across-programs }¶
在同一个 DHIS2 数据库中，客户的 TEA 值还可以在其任何注册信息中共享，这样可以加快数据录入速度，并支持在卫生领域共享客户的情况下进行重复数据删除工作（例如结核病和艾滋病病例监测）。
如果 TEA 只在单个程序中使用，则应 [分配给程序本身]（#create-or-edit-a-tracker-program）。如果 TEA 应在多个程序中共享，则应将其分配给被跟踪实体 type。如果您决定使用关系功能来连接两个不同程序中的两个跟踪实体实例（例如 ANC 中的母亲和免疫跟踪程序中的儿童），当您搜索 "目标 "TEI 以将关系添加到当前 "来自 "TEI 时，分配给跟踪实体类型的 TEA 将显示在对话框中。
制作可搜索的 TEA{ #making-tea-searchable }¶
TEA 对于搜索客户端记录至关重要，但为了提高系统性能，您可能希望将搜索范围限制在与程序相关的所有 TEA 的较小子集上。某些类型的搜索可能会返回过多结果或导致服务器长时间延迟，因此在搜索灵活性和搜索性能之间存在固有的平衡。
不过，一般来说，应考虑将所有可搜索的 TEA 分成尽可能小的部分。例如，可以考虑将 "姓 "和 "名 "的可搜索 TEA 各分一个，而不是将 "全名 "的可搜索 TEA 各分一个。这样细分搜索条件通常比扫描每个 TEA 的整个全名更快得到搜索结果。
“核心TEA案例简介”{ #the-core-tea-case-profile }¶
在病例监测项目中捕获的一组核心TEA字段（如出生日期和名字）已为许多DHIS2元数据包预先生成。 对于新的追踪项目，一项重要建议是安装 通用元数据库包，其中包括世卫组织的核心病例档案，将其作为项目配置的起点。
将Tracker与人口登记系统对接{ #linking-tracker-with-population-registers }¶
本着“数据只录入一次，多次利用”的原则，一些国家已采取措施，将其国家民事登记数据库（或“人口登记册”）与用于优先应用场景的DHIS2 Tracker程序进行对接。 终端用户无需在程序中根据各种人口统计细节搜索现有的TEI，也无需为每位“新”患者费力地添加TEI属性值，只需通过国家识别码进行搜索，姓名、出生日期和性别等关键TEI属性便会自动填入。 这不仅提高了检索效率，也更有利于确保人口统计数据的准确性和质量。
各国应用案例
根据人口特征、卫生项目应用场景及法律背景的不同，与Tracker人口登记系统对接的方式也有所不同。 在新冠疫苗接种活动中，佛得角和斯里兰卡， 及其他国家发现，从国家人口登记册导出数据、将这些数据转换为DHIS2追踪实体实例（TEI），然后将这些TEI一次性导入其国家新冠疫苗追踪系统，是一种切实可行的做法。 由于两国人口规模可控（分别为50万和2100万），且疫苗接种活动范围有限（仅限成年人），因此将数据导入单个DHIS2实例是可行的。 对于持续的公共卫生监测、敏感亚群体，或向未登记人员（如婴儿）提供服务的情况，与“实时”民用登记与民事状态（CRVS）系统建立直接链接可能更为合适。 例如在卢旺达，DHIS2追踪系统的搜索页面中通过自定义JavaScript，可根据输入的国民身份证号直接向国家CRVS系统发起API查询；当搜索结果得到确认后，人口统计详细信息会自动填入登记页面。这种DHIS2与CRVS的集成是双向的。 在卢旺达儿童免疫追踪系统中，新录入的未登记新生儿信息会通知民事登记员签发出生证明。
一个项目还是多个项目？{ #one-program-or-multiple }¶
此时，您应考虑您的Tracker系统需要一个程序还是多个程序。 一个程序定义了实体可能经历的事件序列——即事件的“框架”——以及实体加入该程序时所需的属性。如果存在_多条进入或退出程序的路径_，那么您可能需要考虑为每条路径设置一个独立的程序。
示例
实验室可能会对一名疑似结核病患者进行多项标本检测，但每位结核病确诊患者都会从诊所获得一套明确规定的服务。由于实验室和诊所的工作流程、用户群体以及追踪对象（检测样本与个人）各不相同，因此可以考虑分别建立实验室数据录入系统和结核病病例监测系统。 任何已接受治疗的结核病患者均可立即纳入结核病病例监测系统，但疑似病例只有在实验室通过实验室系统报告确诊结果后，才会被纳入结核病病例监测系统。 如果是整合了结核病病例监测与结核病筛查的综合项目，则纳入的病例中大部分为疑似病例，其中只有部分会接受治疗。
DHIS2 Tracker 支持此类操作，允许将 TEI 注册到多个项目中。各项目间的 TEI 属性可以相同，也可以不同。 不同用户组可根据其报告职责访问各个项目。此外，还可以生成显示 TEI 在各个项目中注册情况的行列表。但是，截至 DHIS2 v2.40 版本，尚无方法能够根据多个项目中的数据元素值来分析被追踪实体的实例。