For the complete DHIS2 documentation index, see llms.txt.

整合概念¶

DHIS2 是一个开放平台，其实施者是积极的贡献者互操作性计划，例如 openHIE。 DHIS2 应用程序数据库的设计考虑到了灵活性。数据结构如可以定义数据元素、组织单位、表单和用户角色通过应用程序用户界面完全自由。这使得系统可以适应多种本地环境和用例。 DHIS2 支持常规数据采集的多种要求以及针对 HMIS 的国家实施中出现的分析场景并作为基础数据采集和管理系统 [物流、实验室管理和金融]（#Integration_and_interoperability）。

集成和互操作性¶

基于其平台方法，DHIS2 能够接收和托管数据来自不同的数据源并将其共享到其他系统和报告机制。集成概念的一个重要区别是数据集成和系统互操作之间的区别：

当谈论**集成**时，我们想到的过程使不同的信息系统显现为一个整体，使得所有相关用户以及统一定义和维度，以便能够以有用的方式组合数据。
一个相关的概念是**互操作性**，这是一种策略实现一体化。我们认为 DHIS2 可以与其他软件应用程序，因为它具有交换数据的能力。例如，DHIS2 和 OpenMRS 是可互操作的，因为它们允许相互共享数据定义和数据。互操作性取决于数据格式、接口、代码和标准术语。理想情况下，这些应得到国际商定标准，但实际上也可能包含事实上的标准（已被广泛接受和使用，但不一定是正式的在标准制定组织中投票）以及其他更多特定背景下的地方协议。

DHIS2 通常用作集成数据仓库，因为它包含来自各种来源的（汇总）数据，例如[母亲和儿童健康，疟疾计划、人口普查数据以及种群和人类数据资源]（#Objectives_of_integration）。这些数据源共享相同的平台 DHIS2，并且都可以从同一个地方获得。这些因此，子系统被视为集成到一个系统中。

此外，互操作性还将集成来自其他方面的数据源软件应用程序。例如，如果人口普查数据存储在专门的[民事登记或人口动态事件] 系统](#Health_information)，该数据库与 DHIS2 意味着人口普查数据也可以在 DHIS2 中访问。

最后，最基本的集成活动（并不总是被采用）在互操作性讨论中考虑）是可能性来自现有纸质系统或并行垂直系统的集成数据进入 DHIS2。数据将直接输入DHIS2，无需通过通过不同的软件应用程序。这个过程是基于创建一致的指标定义并且已经可以大大减少通过整合数据来碎片化并增强数据分析存储库。

整合目标¶

在大多数国家，我们发现许多不同的、**孤立的**健康状况信息系统，带来许多信息管理挑战。公共卫生信息系统经常出现爆炸性的情况过去几年增长不协调。现代信息技术降低实施 ICT4D 解决方案的成本，从而实现解决方案的高度多样性。移动医疗就是一个令人震惊的例子乌干达卫生部于 2012 年发布暂停声明，作为对大约 50 mHealth 的雪崩解决方案这些都是在几年内实施的。其中大部分解决方案是独立的方法，不与其他人共享数据国家系统，很少在试点之外进行开发。

这可能会得出这样的结论：所有系统都应该连接或 互操作性本身就是一个目标。然而 DHIS2 是通常在基础设施薄弱的情况下使用即使是可靠运行基本系统的资源也是稀缺的。碎片化在这方面是一个严重的问题，但是互操作性方法只能解决一些碎片问题 - 并且通常，互操作性方法会导致额外的一层复杂。

示例

加纳物流解决方案的复杂性 在物流或供应链管理领域，通常可以在一个国家/地区找到大量并行、重叠或竞争的软件解决方案。 JSI 2012 年研究指出，仅加纳的公共卫生供应链中就有十八 (18!) 种不同的软件工具被记录使用。

因此，系统互操作性似乎是消除分散和冗余，并为公共卫生官员提供简明的信息以及来自可用数据源的平衡图景。然而，的努力连接许多冗余软件解决方案的成本非常高因此似乎值得怀疑。第一步，重点应该放在 **减少并行系统的数量**并识别最多的并行系统相关系统，之后可以集成这些相关系统。

在此背景下，我们要定义DHIS2的主要目标整合方法：

指标计算：很多指标都是基于来自不同数据源的分子和分母。例子包括死亡率，包括一些死亡率数据作为分子人口数据作为分母、人员覆盖率和人员工作量率（人力资源数据、人口和人数数据）、免疫率等。为了计算，你需要分子和分母数据，因此它们应该集成到单个数据仓库中。数据源越多综合起来，可以生成的指标越多中央存储库。
**减少手动处理**和数据输入：使用不同的数据在同一个地方，无需手动提取和处理指标，或将数据重新输入数据仓库。特别是不同数据类型系统之间的互操作性（例如患者登记册和聚合数据仓库）允许用于子系统计算和共享数据的软件电子方式。这减少了涉及的手动步骤的数量数据处理，从而提高数据质量。
减少冗余：重叠和冗余数据通常是被各个并行系统捕获。例如将 HIV/AIDS 相关数据元素由多个一般咨询和测试计划以及专门的艾滋病毒/艾滋病计划。协调此类数据收集工具程序将减少最终用户的总工作量。这意味着此类数据源可以集成到 DHIS2 中，并且与现有数据元素相协调，其中涉及数据输入和数据分析要求。
改进**组织方面**：如果所有数据都可以由卫生部的一个单位，而不是各个子系统由多个健康计划维护，这一单位可以专业化。与唯一负责数据的员工一起管理、处理和分析，更专业的技能可以发展并合理化信息处理。
**垂直项目**的整合：典型的政府健康域有很多现有的玩家和系统。一个集成的包含各种来源数据的数据库变得更有价值比分散和孤立的更有用。例如当流行病学数据分析与专业知识相结合艾滋病毒/艾滋病、结核病、财务和人力资源数据，或当免疫与物流/库存数据相结合，它将更全面地了解情况。

DHIS2 可以帮助简化和**简化系统架构**，以下问题例如：整合的目标是什么努力？ DHIS2 能否帮助减少系统数量？ DHIS2 可以吗集成有助于以较低的价格提供相关管理信息成本，速度更快，数据质量比现有系统？ DHIS2 是替代其他系统的最佳工具吗？另一种适合用途的解决方案，可以与 DHIS2 互操作更多合适的？有关定义这些目标的更多实用信息可以可以在 6 步实施的第 1 步指南。

健康信息交流¶

由于健康信息有不同的用例，因此不同类型的软件应用程序在健康领域发挥作用部门。我们使用术语“健康信息架构”来描述各种软件应用程序及其特定的计划或概述用途和数据连接。该架构的功能是作为一个计划协调各个子系统的开发和互操作性在更大的卫生信息系统内。建议开发涵盖所有组成部分的计划，包括目前没有运行任何软件，能够充分看到数据共享方面的要求。那么这些要求应该是软件开发后的规范的一部分或采购的。

开放健康信息交换 (openHIE) 是该架构的可互操作解释，带有 HMIS 或 DHIS2 经常在其中发挥重要作用。openHIE 框架具有制定时明确重点关注资源匮乏的国家，通过多个机构的参与和发展合作伙伴，包括奥斯陆 HISP 计划。

下面的示意图概述显示了 openHIE 的主要元素框架，包含组件层、互操作服务层和外部系统。 openHIE 组件层覆盖元或参考数据（术语、客户、设施）、个人数据（员工、患者病史）和国家健康统计数据。目的是确保相同元数据在所有系统中的可用性参与相应的数据交换（例如指标定义、设施命名、编码和分类）。在某些情况下，与主设施登记处的情况一样，该数据也可以使用通过门户网站向公众提供信息。尽管互操作层确保不同系统之间的数据代理系统，外部系统层包含几个子系统，很多在服务级别，功能范围经常重叠。

定义电子医疗架构有不同的方法。在里面在本 DHIS2 指南的背景下，我们区分基于的方法 1:1 连接与基于 n:n 连接的方法（多对多）。

1:1 集成{ #integrationSection }¶

在许多国家，国家 HMIS 通常是第一个推出的系统访问大量设施并管理大量数据按月或按季度。当各国开始发展自己的进一步的卫生系统架构，DHIS2经常会连接到一些其他系统。这种连接通常直接通过简单的脚本，自动执行数据传输。

我们谈论 1:1 连接是因为它仅限于两个系统。在里面如果是 LMIS/HMIS 集成，一个 LMIS 将数据传输到 DHIS2 如脚本中所定义。这种实践方法通常代表第一步，是实现目标的过程中最常见的用例之一可互操作的 openHIE 架构。然而，这种简单性也带来了缺点：如果第二个物流系统想要将数据传输至 DHIS2（例如特定疾病的商品数据程序），必须编写第二个脚本来执行此操作任务。然后，这两个脚本将独立于另一个脚本运行，产生两个独立的 1:1 连接。

n:n 集成¶

另一种方法是基于将专门构建的软件作为**互操作层**或总线方法，管理两侧可能有多个系统之间的数据传输 (n:n)。例如，如果您想收集库存水平，则可能会出现这种情况通过不同的LMIS应用程序收集数据，然后将其共享到中央仓库LMIS、HMIS和一些垂直疾病计划系统。这承担这个角色的openHIE参考软件是“OpenHIM”，但是 “MOTECH” 等系统也已被使用为此目的，如下所述。

虽然这种方法可能会导致更高的初始工作量，但它承诺使进一步的集成项目变得更容易，因为互操作性层正在用定义和映射进行调整，这些定义和映射可以重新用于连接下一个系统。

在实践中，这种方法存在一定的挑战。这需要一个合格资源投入大量精力来激活 API，并任何涉及系统的每个新版本，数据流都需要重新测试以及必要时的调整。另外，要成功这些实施项目通常必须经过一系列 复杂的步骤，例如就纳入国家标准的互操作性方法达成一致电子卫生战略、数据标准的定义和可持续发展维护结构，并获得利益相关者对数据的共识所有权和共享政策。可能会产生一些长期后果当数据和系统结合在一起时 - 它创造了新的角色、工作以及以前不存在且可能未计划的任务（元数据治理、复杂系统管理、边界谈判者等）。

示例

塞内加尔格莱珉 DHIS2/CommCare 中间层 在集成概念中，MOTECH 充当 LMIS 之间的技术中间层，用于医疗机构级别的移动数据收集 (CommCare) 和 DHIS2，允许定义数据映射、转换规则和数据质量检查。该接口设置为每当数据在设施中保存到 CommCare 表格中时，将数据从 CommCare Supply 传输到 DHIS2。对于每种商品，有关消耗、可用库存、损失和缺货数据的数据都会从 CommCare 传输到 DHIS2。塞内加尔方法较高的初始投资暗示着更雄心勃勃的长期系统架构，预计 MOTECH 平台将来可能会适应进一步的互操作性任务。然而，我们没有看到任何国家活动紧密嵌入教科书电子卫生架构中，该架构将明确定义优先领域、每个优先事项的主导系统以及这些不同组件之间的关系和由此产生的 API。有人可能会说，如果之前没有就架构总体规划达成共识，那么互操作性项目就会建立在薄弱的基础上。另一方面，让系统举措有机发展也很有价值，只要它们植根于有充分理由的国家需求。

建筑，标准和制图¶

电子医疗架构的一个重要元素是包含 国际电子医疗标准。标准尤其相关对于 n:n 连接，对于直接 (1:1) 连接则不然。

一些标准是技术层面的（例如传输方法），内容方面的其他内容（例如世界卫生组织 100 项核心指标）。逐步地使国家系统举措与这些标准保持一致可以使各国获得行之有效的解决方案，并受益于医疗和技术创新。

示例

加纳 EPI 加纳案例说明了 WHO EPI 报告要求如何定义 DHIS2 中的标准数据。这种数据集和术语级别的标准化是系统集成的基础。在 DHIS2 领域，正在与 WHO 合作开发标准化数据集，这可能在未来通过提供跨系统元数据的一定一致性并鼓励各国重复使用现有解决方案，为互操作性和效率提升开辟新的机会。

在**语言**级别，需要保持一致定义。如果您有相同数据的两个数据源，则它们需要具有可比性。例如，如果您从以下两个来源收集疟疾数据：标准诊所和医院的数据需要描述如果需要将总计和指标合并起来，情况也是如此。如果一个医院按性别而非年龄组报告疟疾病例，以及其他诊所按年龄组报告，但不按性别报告，该数据不能根据这些维度中的任何一个进行分析（即使总共可以计算案件数量）。因此有必要达成一致统一定义。

除了各个子系统的统一定义之外， 数据要共享，必须采用数据交换标准 电子方式。各种软件应用程序都需要它能够互相理解。 DHIS2 支持多种数据格式用于进出口，包括最相关的标准 ADX。其他软件应用程序也支持这一点，它允许共享数据定义并在它们之间聚合数据。对于 DHIS2，这意味着它支持导入由以下提供的聚合数据其他应用程序，例如 OpenMRS（针对患者管理）和 iHRIS（针对人力资源管理）。

架构的一个关键要素是如何组织数据**映射**。不同系统的元数据通常并不完全匹配。除非卫生部一直在执行相应的数据标准政策、不同的系统对某个设施会有不同的代码和标签。一个系统可能称其为 区医院 - 123，另一个系统可能称其为疟疾治疗中心 - 15。为了能够传输数据数据传输，需要在某个地方存储这两个机构对应的信息。需要存储在某个地方。

在 1:1 连接的情况下，必须完成此映射并且为每个连接维护，以防 n:n 互操作性方法中，定义的一侧可以重复使用。

为了保证数据能够顺利流动，你需要有系统双方关于数据的明确责任维护和故障排除。例如，需要有先前为此类活动定义了标准程序，例如添加、重命名、暂时停用或删除任一设施两个系统。包含在数据库中的字段的更改传输的数据记录还需要以系统的方式进行协调。

汇总和交易数据¶

DHIS2 一直在将其影响范围扩展到许多卫生系统。开始从其熟悉的常规数据聚合数据集基础出发包括患者相关数据以及人力资源、财务、物流和实验室管理，走向运营或交易数据。

我们可以区分事务数据和聚合数据。 A 事务系统（或来自数据仓库的操作系统 Perspective）是一个收集、存储和修改详细信息的系统水平数据。该系统通常用于日常数据处理输入和验证。该设计针对快速插入和更新进行了优化表现。 DHIS2 可以合并来自外部数据的聚合数据来源，通常在空间维度上聚合（组织单位层次结构）、时间维度（多个时期）以及指标公式（包括数据元素的数学表达式）。

当我们查看交易系统时，例如物流软件整个供应链或其中的一部分，有一个基本原则要做出的决定：您是否需要跟踪所有详细交易级别，包括退货、之间转移等操作设施、条码读取、批次和有效期管理？或者你能得到您所需的大部分决策洞察结果都是使用聚合数据得出的吗？

供应链通常可以得到很好的监控，并在某种程度上得到管理，只要数据在需要的时间和地点可靠地可用用于运营决策和监控目的。.主要指标*期末摄入量、消耗量和库存水平*可以无需电子交易即可管理，并且通常足以提供系统性能的大局观，并可能减少对系统的需求投资。

现实地了解需要收集哪些数据、收集频率以及收集对象将使用它们很重要，这样您就不会创建失败的系统由于缺乏使用或对数据的用途抱有不切实际的期望使用。数字化物流管理系统可以很好地运行完全集成到日常工作流程中，旨在使用户的工作更轻松或更高效。

注意

期望更详细的数据可以带来更好的物流管理并不总是得到落实。有时雄心勃勃的尝试定期收集物流交易数据导致数据量减少质量，例如因为数据记录，这可能必须每天发生，而不是每月或每季度发生，是未可靠执行。另一方面，如果交易系统维护和监控良好，更详细的数据可以提供帮助识别不准确性和数据质量挑战，减少浪费（由于到期或 CCE 失败）、支持召回、管理绩效和改善供应链决策。分析详细的数据可能有助于发现某些问题的根本原因从长远来看提高数据质量。

DHIS2 可以在互操作场景中承担不同的角色。普通的互操作场景是 DHIS2 从操作系统，在这种情况下，操作系统将交易，然后将其传递给 DHIS2。然而，DHIS2 可能会一定程度上还可以配置存储详细的交易数据，从外部系统接收或通过直接数据输入 DHIS2。

在此基础上，我们尝试进行比较概述，比较汇总 DHIS2数据管理与外部专业人士的数据管理系统。这可以用作粗略的方向，但不是静态的，因为 DHIS2的功能及其实现者的解释几乎每个版本都在扩展。

区	DHIS2汇总	外部专业系统
后勤	汇总数据，例如月末设施库存水平可以通过DHIS2发送。 DHIS2可以生成简单的库存水平和消耗报告。	供应链管理支持物流系统运营，可以跟踪详细的库存变动（发放、补给、分配、浪费）并记录生产批次号等详细信息。 SCM 系统创建预测、补货和详细的控制报告，允许实时监控库存水平、通知（库存不足、工作流程管理、CCE 故障等）、支持的估算和紧急订单。
金融	汇总数据，例如有关总支出或现金水平的信息可以通过DHIS2发送。 DHIS2可以生成简单的财务概览报告，例如在剩余预算上。	财务管理系统允许根据法律要求对财务交易进行完全可追溯的记录，包括预算，转移，取消，偿还等。交易的多维标记允许分析报告。
病人追踪	DHIS2收集与疾病或程序相关的数据，DHIS2 Tracker还可以简化医疗记录的纵向视图，包括患者病史和多阶段临床路径。	专门的医院管理系统可以覆盖和优化不同部门之间的复杂工作流程（例如，接待，付款柜台，病房，OPD，IPD，实验室，影像，库房，财务和人力资源管理，医疗设备维护等）。
人力资源	DHIS2 收集人力资源相关指标，例如每个设施的计划职位和空缺职位。	专门的人力资源管理系统可以跟踪详细的状态信息以及卫生工作者的变更（资格认证，晋升，休假，职位变更，位置变更，额外培训等）。它带有针对运营监督和计划的预先设计的报告。

不同的DHIS2集成方案¶

上述不同的目标导致不同的集成场景。 DHIS2 可以在系统架构中承担多个**角色**：

数据输入：数据录入（离线、移动）、数据导入（交易型）数据、汇总数据）
使用内置工具（DWH、报告、地理信息系统）
通过Web API，Web应用程序与外部工具（例如DVDMT）共享数据

在下面的段落中，我们讨论数据输入和数据共享方法，然后我们展示垂直的例子 DHIS2 通常承担所有这些角色的集成。

讨论了 DHIS2 在存储、可视化和分析数据方面的作用分别在数据仓库部分。

数据输入¶

DHIS2 如何处理数据输入有几个方面。上最基本的水平，DHIS2 用于取代或至少是镜面纸质数据收集表格，以电子方式整合数据。这会导致在设施或健康场所进行**手动数据输入**活动行政级别。下一个输入选项是**导入数据**。 DHIS2 允许通过用户界面导入数据，这是一种方法需要很少的技术知识，但需要手动执行每次需要提供数据时。详细描述导入功能可以在DHIS2用户指南。

提示

手动数据输入和导入方法需要相对较少的技术工作。它们也可以暂时用于试验数据集成方法。这允许用户通过 1:1 或 n:n 连接来测试指标和报告，而无需使用专用技术资源来开发自动互操作性功能。

共有三种共享场景，（1）简单的data 导出, (2) DHIS2 应用程序和 (3) 连接到 DHIS 网站 API。与数据输入部分中描述的导入功能类似，最方便的数据共享方式是使用数据导出功能可以从用户菜单中获得，几乎不需要任何技术知识。

由于采用模块化设计，DHIS2 可以通过**额外的功能进行扩展软件模块，可以从DHIS2下载**App 商店。这些软件模块可以活与 DHIS2 的核心模块并排，可以集成到 DHIS2 门户和菜单系统。这是一个强大的功能，因为它使得可以在需要时使用额外的功能来扩展系统，如前所述，通常是为了满足国家/地区的特定要求。

软件模块可扩展性的缺点是它把开发过程中的几个限制。开发人员创造额外的功能仅限于 DHIS2 技术编程语言和软件框架，除了 DHIS2 门户解决方案对模块设计的限制。此外，这些模块必须包含在 DHIS2 软件中，当软件是在网络服务器上构建和部署的，而不是动态的运行。

为了克服这些限制并实现更松散的耦合在 DHIS2 服务层和其他软件制品之间， DHIS2 开发团队决定创建 Web API。这个网络API 符合REST架构风格的规则。这意味着那：

Web API 提供了一个可导航和机器可读的界面完整的 DHIS2 数据模型。例如，可以访问完整的数据元素列表，然后使用提供的超链接导航到感兴趣的特定数据元素，然后使用提供了指向该数据元素所属表单列表的超链接部分。例如。客户端只会使用以下方法进行状态转换动态嵌入响应中的超链接。
使用统一接口 (URL) 访问数据众所周知的协议。没有花哨的传输格式或涉及的协议 - 只是经过充分测试、易于理解的 HTTP 协议是当今 Web 的主要构建块。这意味着第三方开发人员可以使用 DHIS2 数据模型和不了解 DHIS2 具体的数据技术或符合 DHIS2 设计约束。
所有数据，包括元数据、报告、地图和图表，称为 REST 术语中的资源，可以在大多数当今 Web 的流行表示格式，例如 HTML、 XML、JSON、PDF 和 PNG。这些格式得到广泛支持应用程序和编程语言，并提供第三方开发人员提供了广泛的实施选项。

该Web API可以被不同的外部信息系统访问。开发新的信息系统和维护所需的努力随着时间的推移，它们往往被大大低估。而不是从从头开始，可以在 Web API 之上构建新的应用程序。

外部系统可以提供不同的可视化选项呈现 DHIS2 数据，例如以仪表板、GIS 和图表的形式成分。针对健康领域的门户网站可以使用 DHIS2 作为汇总数据的主要来源。门户可以连接到 Web API并与地图、图表等相关资源进行通信报告、表格和静态文档。这些数据视图可以动态地根据对组织单位的查询可视化聚合数据，指标或周期维度。门户网站可以增加价值信息可访问性有多种方式。它可以被构造为用户友好的方式并使没有经验的用户可以访问数据。一个例如坦桑尼亚 HMIS 网络门户。

DHIS2成熟度模型¶

考虑到系统架构上的所有上述要素数据类型，DHIS2 实施者对于如何处理有多种选择实施：

专注于交易或汇总数据
专注于数据集成或系统互操作性

鉴于实现系统互操作性所需的努力，许多卫生部正在寻求一体化的务实捷径数据，如基本库存水平数据**直接存入现有的国家 DHIS2**。作为一个快速发展的平台，DHIS2 一直在添加过去几年中提供了很多功能，尤其是 DHIS2 Tracker。以物流数据为例，主要有以下功能：目前可用：

反映广泛使用的报告和申请表的数据输入表格 (R\&R) 纸质形式。设施的数据输入可以通过桌面浏览器或移动应用程序，包括离线模式。这些工作人员可以根据纸质填写电子表格卡片，通常放置在商店中的商品旁边房间。
然后 DHIS2 可以生成中央级绩效报告监控，让商品和项目经理了解物流系统如何运作..取决于物流系统运转起来，这些数据或许也能支撑运营决策虽然更全面的分析首先应进行物流业务流程和用户。
库存数据可以转化为物流指标，即例如，与其他计划指标结合起来交叉参考接受特定治疗的患者数量病理和相应的药物消耗。

尽管我们在用例中看到的每个国家都有自己的系统集成的发展路径，一些共同的经验可以从他们的经验中汲取教训。下面的成熟度模型描述了应对集成和互操作性的进化方法挑战，让不同的利益相关者能够参与国家卫生培养专业分析和数据使用习惯的系统。

成熟度模型建议从聚合数据转向交易数据数据以及从独立系统到可互操作系统（使用以下示例物流数据）。

DHIS2 通常是最早覆盖健康的系统之一一个国家的行政管理和几个设施级别。首先涵盖核心疾病指标（例如对应于 100 项世界卫生组织核心健康指标）。
在第二阶段，不同的利益相关者寻求补充他们使用基本 LMIS 报告疾病和服务提供数据数据。这可以在 DHIS2 中聚合完成，例如经过包括定期报告中的库存水平和消费量。这将提供有关物流系统绩效的高级信息但可能会也可能不会提供足够的见解来支持改进物流系统运作。
在更成熟的阶段，可能有合理的需求专门的物流系统，特别是当一个非常详细的事务视图需要更精细的控制（例如退货、设施之间的转移、批次号和有效期， ETC。）。 DHIS2 Tracker 可以提供一些事件或患者相关数据管理职能，但总不能达到管理的程度其他更专业的解决方案提供的工作流程支持。
在成熟的技术和管理环境下，物流交易可以以聚合形式共享到 DHIS2，从而移动从独立场景到集成场景。

成功实现数据和系统集成的实施步骤¶

本分步 DHIS2 实施指南的目的是为实施者提供创建和支持 DHIS2 的方法集成场景。该指南基于最佳实践和得到教训。该指南倡导国家驱动、迭代、敏捷方法从收集用户故事开始功能要求。该指南旨在作为一个框架，可以适应每个国家的具体情况。内容描述每个步骤的具体示例，详细说明用户故事、数据规范、工作辅助工具和清单来指导使用参考实施软件。基本结构包括6个步骤，基于OpenHIE实现方法：

步骤 1：确定利益相关者和改进设施的动机数据

**步骤2 **：文档设施注册表规范和用户案例

**步骤3 **：设置初始实例

**步骤4 **：通过用户测试确定差距和迭代开发

**步骤5 **：扩展注册表实施

**步骤6 **：提供持续的支持

除了这些与互操作性相关的步骤之外，还回顾一下 DHIS2 的一些常规内容很有趣相关章节中给出的实施经验和最佳实践对国家 HIS 的建议实现和设置一个新的数据库。典型的 DHIS2 实施方法对于互操作性项目是一种**参与式**方法。这种方法强调从项目一开始就包括当地团队具有不同的技能和背景，尽快承担责任可能的。

步骤1：定义策略，利益相关者和数据使用目标¶

第一步，整合项目的目标是定义的。与每个技术项目一样，应该有一个明确的 关于战略和职能目标的共识。技术性创新和可行性不应该是唯一的驱动力，而是而是明确定义的组织目标。因此这一步是也旨在回答这个问题：“为什么我们要连接系统或者将不同来源的数据与 DHIS2 集成？”

在实践层面上，这会导致数据集成方面的问题方法，例如：

您想消除纸质表格甚至消除数据集吗是多余的还是不再需要的？
您可以将（汇总）数据集成到DHIS2中吗？
您能否整合详细信息（例如患者级别或交易级别）使用 DHIS2 跟踪器功能将数据导入 DHIS2？
如果您想在 DHIS2 和另一个系统，你如何定义所有权和责任？

回答这个问题的活动如下所述，并将奠定 DHIS2 互操作性项目的基础。

识别利益相关者和动机¶

互操作性项目的本质是拥有多个利益相关者。来自不同领域的利益相关者需要就共同点达成一致系统方法，例如负责国家 HMIS 的团队（例如机电部门或规划部门）和后勤部门实施 LMIS 时的部门。这两个主要领域经常有细分部门，例如在物流领域，采购部门、仓储单位、运输单位。此外，利益相关者来自针对特定疾病的方案将有自己的治疗方案和商品经理。除了这些本地参与者之外，还有国际合作伙伴（机构、捐助者、非政府组织、咨询机构）也经常参与做决定的过程。

因此，了解这些行为的主要动机是很有趣的。利益相关者以及如何减轻潜在风险利益分歧。

中央卫生部部门，例如**M\&E&**规划部门通常是主要部门利益相关者对指标和 IT 系统的标准化
中央 IT 部门 对以下方面有普遍兴趣（通常本地控制）技术选择和所有权、硬件和软件购买。他们经常处理网络和硬件问题，但缺乏处理复杂的基于网络的经验架构和数据交换。
**专业疾病项目**常常面临交付压力非常针对计划的指标，既针对自己的管理，也针对还响应捐助者驱动的方法。他们可能还会感到更多舒适地控制他们的适当IT系统，以确保他们需求被优先考虑。
专业职能领域（例如人力资源、物流、医院管理）往往处于三明治地位，必须满足多种不同的信息需求利益相关者，同时努力实现运营效率有限的资源。

通过确定谁有兴趣提供或使用数据，主要实施者可以开始组建项目团队来为设计提供信息和实施。描述利益相关者特征的一种方法包括按职能角色对感兴趣的各方进行分组。现有的基础设施和程序对于理解也很重要治理和管理选项。了解利益相关者和他们的相应系统是关键的第一步。

电子卫生保健系统清单¶

清晰地了解整个 IT 系统格局非常重要。这有助于确保进行互操作性投资加强主要系统，投资有助于系统架构的**简化**。例如，如果系统盘点显示存在大量冗余功能系统，例如超过 10 个不同的物流系统或模块国家，互操作性项目应努力促进中期或者使这种情况长期合理化。这可能意味着参与全国共识寻找过程，以确定最面向未来的解决方案，为每个解决方案确定国家“冠军” 专业化并制定路线图来协调这些系统或数据删除未充分利用或冗余的系统。

同样在这种情况下，分析是否简单是很有趣的指标可以在 DHIS2 本身中收集和管理，以及如何做到这一点补充物流系统的改进工作（因为这是后来的在 LMIS 示例中进行了解释。一旦稳定可持续系统已确定，正在计划与 DHIS2 进行数据交换可以开始了。

探索机遇与挑战¶

推动实施的动机可以通过以下方式详细说明：利益相关者所面临的感知机遇或挑战。这有可能包括跨系统共享与健康相关的数据的愿望供应链管理、监测和评估设施，卫生服务提供和许多其他系统。用户故事和使用在第 2 步中将深入记录案例，但高层次的愿景还需要与合作伙伴合作的动机。

组织与人力资源¶

关于数据集成、数据所有权、例程的明确国家政策数据收集、处理和共享，应在项目开始。经常会在一段时间内扰乱正常数据流将在集成过程中发生，因此对于许多长期而言一个更有效的系统的前景必须根据短期干扰。因此，整合通常是一个逐步的过程，需要采取措施才能顺利进行可能的。

示例

加纳 CHIM

利益相关者合作：加纳*健康信息管理中心*(CHIM) 对垂直项目和其他具有适当软件计划的合作伙伴有明确的立场。 CHIM 将 DHIS2 确立为有吸引力的数据收集选项，支持其他 GHS 利益相关者连接到 DHIS2 并制定通用的互操作性策略，根据利益相关者的需求不断发展 DHIS2。 这还包括数据共享协议。

强烈的系统所有权感：CHIM 决心在 CHIM 团队内部建立必要的专业知识来配置和维护系统。 CHIM 团队由健康信息官员组成，他们结合了公共卫生和数据管理技能。

此外，还明确定义了**系统维护和更新程序**当然可以帮助管理互操作性。

示例

加纳 CHIM 例如，就加纳 DHIS2 而言，制定了明确的年度系统更新周期：每年年底，都会创建新指标并发布相应的纸质表格。工作人员将接受培训并准备好数据输入。 EPI 数据的新表格包含在此更新周期中，并且 EPI 工作人员已准备好数据输入，作为该流程的一部分。这一系统化程序使 GHS 能够快速响应 EPI 计划等利益相关者的需求，并通过有限且可预测的投资满足他们的数据和报告需求。它使 CHIM 能够为国家卫生系统架构的合理化和简化做出贡献，在数据输入和分析方面逐步整合更多**垂直项目**的数据管理。

HISP 的一个关键原则是让当地团队参与建设从一开始就在外部专家的指导下建立系统需要，并且不要在项目结束时拖延知识转移执行。所有权首先来自于系统的构建并掌控这个过程的每一步。

步骤2：文档规格和要求¶

收集现有元数据
文件资料规格
记录用户故事

步骤3：执行规格并找出差距¶

实施规范
识别并伪造不完整的用户故事

步骤4：迭代和用户测试¶

敏捷迭代开发
用户测试
收集，核对和上传数据

步骤5：按比例放大¶

确认用户角色和职责
用户培训
关键整合

第6步：持续的支持¶

在实施阶段，临时支撑结构应该可用，之后需要一个永久性的支撑结构被设置。主要挑战是明确职责。在一个理想情况下，我们正在处理两个稳定的系统，每个系统都有已经有自己明确定义的支持结构。

但实际上，可能必须应对一些反复出现的挑战：许多公共卫生系统正在经历动态发展，导致数据收集需求或指标计算的变化。

互操作性往往是一项乏味的技术和组织工作收费。上述三项举措均消耗了合格的**资源**花费大量精力来激活 API。在此外，随着任何相关系统的每个新版本的发布，数据流需要重新测试，并在必要时进行调整。要想成功这些实施项目通常要经历一系列复杂的过程步骤，例如就嵌入的互操作性方法达成一致国家电子卫生战略、数据标准的定义和可持续的维护结构，并获得利益相关者的共识关于数据所有权和共享政策。可能会有一些长期的当数据和系统结合在一起时的后果 - 它创造 需要规划的新角色、任务和劳动类别 用于（元数据治理、复杂系统管理、边界谈判者等）。解决方案可能是讨论新的事先明确职责，将其分配给工作描述、团队以及具体职位。

元数据责任¶

另一个重要领域是**元数据治理**，特别是在数据二次利用的场景中。在独立设置中，元数据，例如设施或商品代码，无需管理即可管理充分考虑其他利益相关者的需求。但在一个互操作环境下，元数据的变化将会对外部产生影响的个体系统。元数据治理可以高度形式化通过注册表或更手动地通过人工流程。

为了确定适当的方法，估计是否有用预期的*元数据维护工作*以及后果不同系统之间的元数据不同步。在这种情况下 LMIS/DHIS2 集成，可能有数千个设施可能不同步的标识符。但通常情况下，设施标识符不会经常改变，因为物理基础设施大多数公共卫生系统相对稳定。就商品而言，尽管制度和优先药物可能会随着时间的推移而改变，但数据集比较小：一个程序的商品列表往往包含少于 20 个产品。因此，通常可行的是手动更新商品，而不是投资于互操作性解决方案，例如自动元数据同步。

特定的集成和互用性用例¶

DHIS2 一直在将其影响范围扩展到许多卫生系统。开始从其熟悉的常规数据聚合数据集基础出发包括患者相关数据以及人力资源、财务、物流和实验室管理。这符合在许多国家/地区开发 DHIS2，其中实施者使使用超出了最初的预期范围。

这也体现在整个系统架构上。自从 DHIS2 的扩展功能降低了引入或维护其他专门系统，潜在数据的数量接口减少。这**降低了系统架构的复杂性** 对于资源有限的卫生系统来说无疑是一种好处。

多年来，DHIS2 不断发展其数据管理活动有机地，允许实际使用有时会导致不可预见的情况解决方案。然而，利用 DHIS2 也存在局限性看起来很有用。在以下部分中，将介绍特殊系统描述。

物流管理¶

** a）简介**

物流管理系统 (LMIS) 或供应链管理系统**(SCM)** 用于替代纸质系统以提高标准化、透明化、采购及时性、效率、安全、成本效益并减少浪费。国家SCMS/LMIS可以涵盖商品规划、预算、采购等职能基本药物的储存、分配和补充消耗品。

** b）在DHIS2中实施LMIS **

供应链通常可以仅通过汇总数据得到很好的控制，例如只要从所有相关级别可靠地提供数据并遵循上。主要指标摄入量、消耗量和库存水平无需电子交易即可管理期末，并且通常足以给出大局，减少对系统的需求投资。作为一个快速发展的平台，DHIS2 已经添加了很多过去几年的功能，特别是 DHIS2 Tracker。这目前主要有以下功能：

反映广泛使用的报告和申请表的数据输入表格 (R\&R) 纸质形式。设施的数据输入可以通过桌面浏览器或移动应用程序，包括离线模式。在在线模式表格可以计算请购建议、报价设施经理修改请求并对其发表评论。这些工作人员可以根据纸质填写电子表格卡片，通常放置在商店中的商品旁边房间。
然后 DHIS2 可以为中央决策生成报告，给出商品和项目经理接受或修改的可能性交货建议。
库存数据可以转化为物流指标，即例如，与其他计划指标结合起来交叉参考接受特定治疗的患者数量病理和相应的药物消耗。

** c）互操作性选项**

LMIS 是一个存在大量平行、重叠或竞争的领域软件解决方案可以在一个国家找到。正如在一个 2012 年 JSI 研究（加纳卫生部，2013 年 7 月：景观使用中的供应链管理工具分析），十八（18\！）不同的软件工具被记录为正在使用仅加纳的公共卫生供应链。

尽管基于聚合数据的基本 LMIS 配置可以帮助您到目前为止，在某些情况下，如果您需要，事务性 LMIS 是必要的跟踪诸如退货、设施之间转移等详细操作，条码读取、批次和有效期管理。还有一些专门的总部创建预测、补货、精细化等功能控制报告通常是用专门的工具完成的。

DHIS2 集成了来自外部系统的聚合数据，例如 openLMIS 和 CommCare 通过自动化数据接口。因此，库存数据可在共享仪表板中获取，显示健康服务和股票数据彼此相邻。