元数据管理项目{ #procedures-for-managing-metadata }¶
本节讨论与长期维护 DHIS2 元数据相关的项目和建议。它描述了与协调长期配置过程相关的项目挑战，并提供了标准操作项目范例，这些范例可加以调整和使用，以更好地协调这些过程。
管理元数据时可能导致复杂化的项目问题包括
- 开发实例不可用或使用不当
- 添加元数据或修改配置的标准操作项目 (SOP) 存在漏洞
- 添加新元数据时缺乏协调
- 添加基于世卫组织/标准的数字数据包时假设不正确
- 随时间推移修订数据收集工具
开发实例不可用或使用不当{ #development-instances-not-available-or-not-used-properly }¶
在进行 DHIS2 配置时，建议至少有一个开发实例供您使用。如果您有一个以上的生产实例，则应考虑为每个实例都准备一份副本，以便创建新的元数据或以其他方式修改配置（图 1）。
许多元数据难题都是由于用户直接在生产系统中添加元数据造成的。这些元数据要么没有正确配置，要么没有在系统中使用，导致日后发现更改时需要清理。
使用开发系统可以避免这些挑战，因为如果不需要，开发系统上的项目应该可以删除，而不会对生产系统的配置或数据产生任何影响。
添加元数据或修改配置的标准操作项目{ #standard-operating-procedures-for-adding-metadata-or-modifying-the-configuration }¶
所有 DHIS2 实施系统都应具备添加元数据的标准操作项目。您可以查看分别用于添加总体元数据 和用户 的标准操作项目示例。
在实施标准操作项目时，应对每个具体项目进行培训，并继续对其实施情况进行评估，直至所定义的项目成为标准做法。这些项目往往超出了定制/修改元数据的机械范围，需要添加或修改配置的人员仔细考虑如何添加对象以及这对系统整体易用性的影响。
添加新元数据时缺乏协调{ #lack-of-coordination-when-adding-new-metadata }¶
除了制定添加元数据或修改配置的具体项目外，还应以协调的方式开展这些行动。这种协调可以是简单的，例如团队成员之间的内部讨论，也可以是复杂的，例如由一个委员会对所有计划中的项目进行总览，并据此安排修改时间，这将取决于实施的具体情况。
缺乏协调往往会导致元数据版本的重复创建。举例来说，如果有两个管理员在一个系统中添加了相同的新汇总表单，却没有通知对方，那么系统中很可能会出现大量重复的元数据。
在这些情况下，建立一个协调机制，通知参与配置 DHIS 2 系统的人员正在发生的情况，可以节省大量的时间和精力，因为清理这些重复数据是一个耗时的过程。
添加数字数据包时的错误假设{ #incorrect-assumptions-when-adding-digital-data-packages }¶
导入系统的世卫组织软件包 或其他基于标准的配置可能会添加大量重复的元数据。例如，数据包仅在其仪表板上使用指标。这些指标可能与现有数据元素重复。此外，如果在导入基于标准的软件包之前，未对现有系统中填充了现有元数据的项目进行匹配，则可能导致在导入过程中创建重复项目（如类别选项、选项集等）。
一般来说，在导入基于标准的软件包时，应尽量重新使用现有的元数据。这可能需要在导入前编辑软件包的 json 文件，以便导入文件中的 ID 与导入系统中的现有 ID 相匹配。
就仪表盘而言，重复的指标可能不成问题，特别是如果它们被正确地组合在一起。在导入软件包之前，应根据具体情况判断其对系统的影响。
注意：应首先在开发系统中尝试导入软件包。只有在所有问题都得到解决后，才能将它们导入到生产系统。
随时间推移修订数据收集工具{ #revisions-of-data-collection-tools-over-time }¶
当数据收集工具随时间更新时，可以采取措施重新使用各种对象，而不是创建其重复版本。
程式¶
在可能的情况下，应毫不犹豫地在不同的事件和跟踪项目之间重复使用元数据。这些元数据始终与正在创建的特定项目相关联，并将在系统内保持所需的分离。
数据集{ #data-sets }¶
对于汇总数据集而言，元数据的重复使用可能不太明确。一个常见问题是当分类数据从一种形式修改为另一种形式时。让我们以图 2 所示为例。
从表中我们可以看到，每个数据元素的分类都已更改。与其创建新的数据元素来应用这些新的分类，还不如使用 "类别组合重载 "功能。该功能允许一个数据元素随着时间的推移与多个类别组合相关联。
要覆盖类别组合，请从维护中打开数据集。在添加数据元素的地方，你会看到一个小扳手图标。将鼠标悬停在该图标上时，上面会显示 "覆盖数据元素类别组合"（图 3）。
！catcombo_override 图 3
从这里你将打开一个菜单，左侧列出你的数据元素，右侧允许你选择类别组合（图 4）。
图 4
只需在此菜单中选择要覆盖的数据元素的类别组合即可。
注意：您可能需要创建新的类别选项、类别和类别组合。如果需要，请查看示例 aggregate metadata procedure.。
这样做的明显好处是，您可以在更长的时间内审查这些重复使用的数据元素中的数据。使用旧表格输入到这些数据元素中的任何数据仍可进行审查，并与使用新表格（和分类）的时期进行比较。
总报告率{ #aggregate-reporting-rates }¶
在创建一个新的数据集以取代以前的数据集时，如果需要，您应考虑合理调整报告率，因为您创建的新数据集默认情况下不会与以前的任何报告率相关联。如果您想将报告率保持在一起，可以将它们从旧数据集导出/导入到新数据集，这样您就可以在需要时将所有旧报告率与新报告率一起进行审查。在生产系统上执行此过程之前，应在开发实例中进行测试_。在执行任何导入操作之前，请务必进行备份。
要检索现有报告率，可以与 /completeDataSetRegistrations 资源交互，并使用以下查询语句
api/completeDataSetRegistrations?dataSet=XA8e9AVn8Vo&startDate=2000-01-01&endDate=2017-07-01&orgUnit=mPlB2jqKNP0&children=true
注意： 请将本例中的数据集 ID 替换为您自己系统中的数据集 ID，日期替换为您需要的日期，组织单位 ID 替换为您自己的 ID。在本例中，我们要从所有子组织单位中选择报告率，因此要将组织单位 ID 替换为父组织单位 ID。
这将返回一个结果，其中包括查询中涵盖的每个时期的以下参数。
{completeDataSetRegistrations：[{"period":"201408","dataSet":"XvcWsuHBsGA","organisationUnit":"ZUwksatWvE8","attributeOptionCombo":"HllvX50cXC0","date":"2014-09-15","storedBy":"automatic"}]}
检索到报告率后，可以向以下端点发出 POST 请求，将其推送到新的数据集中
api/completeDataSetRegistrations
注意： 您应将初始查询中返回的数据集 ID 替换为您要导入这些报告率的新数据集的数据集 ID。在将信息发布到 completeDataSetRegistrations 资源之前，请执行此操作。
使用指标连接历史数据{ #linking-historical-data-using-indicators }¶
如果您制作了新的数据元素来表示以前部分表示过的概念，那么可能值得创建将这些数据元素连接在一起的指标，这样就可以随着时间的推移纵向查看这些数据（即在创建输出时，您可以在一个变量中查看新旧表格中的数据）。这一原理的前提是新旧数据元素的数据没有重叠（即它们不是在同一时期收集的，否则会导致指标值不正确/重复）。
为此，请创建一个新指标，并将以前的数据元素与新的数据元素相加。这样就可以创建各种输出，在单个输出中显示同一变量所代表的历史数据和当前数据。如果不这样做，在进行分析时就必须选择 2 个（或更多）单独的数据元素来表示这一概念。这也会显得不连贯，因为它们会在图表中以不同的线条、表格中不同的行或列来表示，而且只显示正在进行收集的期间内的变量数据。