跳转至
For the complete DHIS2 documentation index, see llms.txt.
维护与使用

组织单位维护{ #organisation-unit-maintenance }

组织单位和组织单位层次结构是 DHIS2 元数据和数据模型的基本要素之一。它们囊括了卫生设施、学校和行政区域等地理环境，形成了一个单一的分级结构，是每个数据值、被追踪实体和追踪事件的基础。组织单位是 DHIS2 中*访问控制*的关键要素，因为每个用户都与一个或多个组织单位相关联，这些组织单位控制着用户可以查看和/或编辑的数据。组织单位也是 DHIS2 与其他系统（如电子病历系统、物流平台等）之间实现互操作性的关键因素。在某些情况下，DHIS2 是国家架构中组织单位的主要真实来源，而在其他情况下，可能会有一个专门的设施登记处，DHIS2 应从该登记处接收组织单位的更新。

由于组织单位非常重要，因此关键是要做好组织单位层次结构的初步[设计]（#组织单位），并确保有明确的治理结构和 SOP 来管理和维护组织单位。本节重点讨论与组织单位的长期维护相关的主题。

维护组织单位组和组套{ #maintaining-organisation-unit-groups-and-group-sets }

组织单位分组和分组集是 DHIS2 广泛使用的强大功能，可为任何数据提供额外的分析维度。常见的例子有*所有制*（公立、私立、宗教）、类型（保健中心、地区医院、三级医院）和*城市/农村*，但理论上任何类型的组织单位分类都可以配置。当组织单位分组集被用作数据维度时，就需要格外重视分组集中分组的维护。具体来说，为了确保分析得出的数字正确无误，一个组织单位不得**属于一个组集中的多个组，而任何**应该包含在分类中的组织单位都必须包含在一个组中。

举例来说，一个组织单位组*所有权*包含三个组织单位组*公共*、私人*和*信仰。如果将设施 A 同时添加到*私人*和*基于信仰*组织单位组中，那么使用*所有权*作为数据维度进行的任何分析都无法准确反映设施 A 的数据（该设施的数据最终只能归入其中一个类别）。如果设施 B 没有加入这三个组别中的任何一个，那么在使用*所有权*维度对数据进行分析时，该设施的数据将被排除在外。

因此，总之，组织单位组的成员资格必须妥善设置并长期保持，这些数据维度才能发挥预期功能并产生正确结果。关于创建和修改组织单位的[标准操作程序]（#standard-operating-procedures-sops）必须提供明确的指导，说明如何对组织单位进行分类，以及应将其添加到哪些组中。不过，还需要能够批量监控组织单位组的分配情况。这可以通过数据管理应用程序的数据完整性功能来实现，其中包括与组织单位组和组集相关的若干完整性检查。

管理行政区域的变更{ #managing-changes-to-administrative-areas }

随着时间的推移，一个国家的行政边界发生变化的情况并不少见，如地区或省份的分割或 合并。就 DHIS2 的配置而言，在某些方面并不需要做太多的工作。值得注意的是，由于数据主要是在组织单位层次结构的最底层（如卫生设施或学校）收集的，因此当设施在地区等之间移动时，数据将在层次结构中正确汇总。

但是，这样做的一个缺点是，一旦组织单位层次结构发生变化，就无法再根据变化前的情况来分析合计数，如果要查看以前时期和/或其他数据源的数据，这一点可能很重要。例如，如果 "A 区 "从 2025 年 1 月起被分为 "A.1 区 "和 "A.2 区"，并且 DHIS2 已更新以反映这一点，那么使用 "A 区 "分析 2024 年的数据可能仍然有用。例如，如果将数据与另一个数据源进行比较，或分析与使用以前的层次结构所做的报告和分析有关的数据，这可能是相关的。DHIS2 可通过使用组织单位组和组集进行配置，以支持使用当前和以前版本的行政层次结构分析数 据：

  • 可创建一个组织单位组集来表示某一时间点的行政等级，如 "2025 年前的地区"。这应作为*数据维度*启用
  • 在某个时间点为每个行政单位创建一个组织单位组，如 "A 区"、"B 区"； - 在某个时间点为每个行政单位创建一个组织单位组，如 "A 区"、"B 区"。
  • 每个卫生机构或学校都会被添加到代表其当时所属行政单位的组中。

更新分析方法后，"2025 年前的地区 "将作为一个新的数据维度出现在 DHIS2 分析工具中，即使行政组织单位发生变化，设施在它们之间移动，也可以使用以前的层次结构对数据进行分析。这种方法的一个局限性是，任何依赖于仅在变更后的行政级别上提供的**数据的指标都将失效（例如，如果地区人口估计数被用于覆盖率指标）。

虽然最低层级（设施）的数据可以用相对简单的方式进行管理，但在行政层级收集的 任何数据都必须单独处理。例如，如果人力资源的年度数据与一个地区相关联，那么如果该地区被拆分，而 DHIS2 的组织单位被重新用于其中一个新的地区，那么这些数据就不准确了。根据数据类型和行政边界的变化，可以用不同的方法来处理这个问题，例如尝试追溯更新 数据，或在 excel 文件中生成摘要，并将其作为 DHIS2 文件资源提供给用户访问。

当涉及到与行政组织单位相关的数据时，分母数据（如人口估计值）尤为重要，在许多情 况下，分母数据只能在地区及以上级别获得。如果 DHIS2 中的行政组织单位发生了变化，但新的行政单位却无法立即提供分母数据，这将严重阻碍数据分析--因为这会导致任何使用这些分母的指标根本无法获得，或者更糟糕的是，会显示错误的数字。理想的情况是，为新的行政单位提供当前和未来时期的分母数据，但在可能的情况下， 也可追溯到过去几个时期，以便于观察一段时间的趋势。

在更改行政边界时，地理坐标也是一个重要的考虑因素。如果在 DHIS2 中应用行政边界变更时没有更新的地理坐标，地图应用程序中的空间分析将无法工作或显示错误的输出。因此，强烈建议尽可能在更改行政边界的同时获取并导入新边界的形状文件。

摘要{ #summary }

  • 大多数常规数据和个案数据不会受到行政区域/组织单位变化的直接影响，因为这与最基层的组织单位（设施、学校等）有关
  • 组织单位组和组集可用于分析基于以前/替代行政边界的数据，但有一些限制。
  • 应尽可能在***对 DHIS2 中的组织单位进行更改之前获得分母数据（如人口估计值）和更新行政区域的地理坐标，以避免破坏分析功能。

下放组织单位管理{ #decentralising-organisation-unit-management }

在 DHIS2 实施过程中，组织单位的数量差别很大，但通常会有几千个组织单位，有时多达上万个。对这些单位进行长期管理，包括正确分配数据集/跟踪程序和组织单位小组成员资格，对于集中管理（如国家）的管理员团队来说是一项挑战。

为此，必须建立一个机制，让地区或卫生机构等国家以下一级的用户要求 DHIS2 核心团队进行更改和更新。这可以通过不同的方式来处理，如使用 DHIS2 的消息功能、WhatsApp、邮件、谷歌表格等，但关键是要让用户清楚地了解请求更改的流程。

另一种解决方法是将组织单位管理任务下放给国家以下一级的管理员，如省和地区。系统设置](#system_access_settings)允许仅有组织单位编辑权的用户管理数据集和计划分配。虽然可以通过应用程序接口实现这一点，但没有办法通过维护应用程序实现这一点， 除非也赋予国家以下一级管理员对数据集/计划的元数据编辑权，而这通常是不可取的。因此，这种方法需要开发一个简单的用户界面（即自定义应用程序）供分散管理员使用。

多个组织单位等级{ #multiple-organisation-unit-hierarchies }

DHIS2 只支持树形结构中的单一组织单位层次结构，只有一个根。每个组织单位都必须有一个*父*组织单位，用户总是可以看到并访问他们可以访问的层次结构中*分支*的所有组织单位。例如，分配到一个省（层次结构中的第 2 层）的用户总是可以访问该省的所有地区（第 3 层）和设施（第 4 层）。

有时，需要收集或分析不同报告层级的数据；例如，卫生部可能有一个独立的卫生区结构，而不是政府内部一般使用的行政区结构，因此需要有一种方法，利用这两种结构来汇总和分析数据。或者，可能需要将*村庄*作为数据收集点，但村庄与设施之间没有明确的关系。

通常可以通过使用[组织单位组和组集]（#organisation-unit-groups-and-group-sets）来引入额外或替代的层次结构进行分析。以独立的卫生区和行政区为例，卫生区可配置为组织单位层次结构的一部分，而行政区可配置为组织单位组集。

如果需要在最底层收集不同层次的数据，而这些数据又与主要的层次结构相冲突，则可能需要建立一个单独的 DHIS2 实例，并将这些组织单位纳入其中：

  • 主要实例：国家 => 省 => 地区 = 卫生机构
  • 替代实例：国家 => 省 => 县 => 村

这在基础设施需求和系统管理方面都会带来一些额外的开销，但这可能比创建一个合并的层次结构更好，因为合并的层次结构会使最终用户感到困惑，并导致分析等方面的问题（所有报告中都默认包含村庄和设施）。

如果建立一个具有替代层次结构的独立实例，可以采取一些措施来简化终端用户对系统的使用。首先，如果同一用户需要访问两个系统（例如，用户需要输入设施和村庄的数据），DHIS2 支持通过 OIDC 进行单点登录，这样用户就可以在两个系统之间移动，而无需多次登录。这里](#configure-openid-connect-with-okta)提供了将 DHIS2 与 Okta 设置为标识平台的示例教程。

其次，[汇总数据交换服务]（#data_exchange）可用于在实例之间定期移动数据，以便在一个实例内进行综合数据分析。继续以村庄和卫生设施为例，在一个实例中从村庄一级收集的数据可以汇总到地区一级，然后推送到有卫生设施的实例，这样就可以对任何相关数据进行综合分析。

在 DHIS2 实例中同步组织单位{ #synchronising-organisation-units-across-dhis2-instances }

许多实施 DHIS2 的机构需要部署一个以上的 DHIS2 生产实例。原因可能包括性能（即分别管理资源需求高的实例）、隐私（即限制实例中敏感数据的用户）或管理（即不同部门或单位拥有/管理实例）。不过，大多数实例都应使用相同的组织单位层次结构。虽然不同的并行层次结构可以由管理员团队手动维护，但如果有严格遵守的良好例行程序，在 DHIS2 实例之间自动同步组织单位是很有优势的。这就需要确定一个 DHIS2 实例作为主组织单位（设施）注册中心，并设置工具确保主实例中组织单位的变更能复制到其他实例中。

DHIS2 本身没有内置组织单位同步功能，但有一个使用 camel 的组织单位同步参考实施。虽然不能直接开箱即用，但它为实施组织单位同步提供了一个良好的起点。DHIS2 社区还开发了其他一些具有相同功能的工具，如乌干达 HISP 开发的*MFL Integrator* 工具。