Revision Management

This document describes the structured process for managing changes and revisions to DCI global interoperability standards endorsed by USP2030.

Governance Structure

A governance structure is established to promote accountability, transparency, and formal decision-making in the management and revision of standards. This structure includes:

For a detailed overview of the governance structure, consult the Governance Document, which describes the purpose, composition, and responsibilities of each team.

Process for Managing Change Requests

The change request process ensures that modifications to SPDCI schemas, APIs, and modules are implemented in a controlled and predictable manner.

Cycle Initiation

Revisions to the standards can be initiated in two ways:

• Triggered Reviews – Requests submitted via the SPDCI Git repository tracker.

• Scheduled Reviews – Annual review cycle conducted by the DCI Standards Development Team to assess adoption and identify needed updates.

Submission & Documentation

All change requests are submitted via the SPDCI Git repository tracker using the Proposed Change Documentation (PCD) template, which must include:

• Requester details

• Description of the change

• Reason for the change

• Impact assessment (technical and operational)

• Proposed timeline for implementation

The requester must also:

• Select the repository where the change is suggested

• Identify the affected module(s)

The DCI Standards Development Team validates the request, adds assessment details, and confirms the proposed timeline.

Review Process

Change Type	Reviewed by	Approval Required from	Notes
Bug Fix	DCI Repository Management Team	DCI Standards Development Team	No impact on schema/API functionality
Minor Non-Altering Change (e.g., documentation update)	DCI Repository Management Team	DCI Standards Development Team	Must not affect interoperability
Enhancement / Feature Addition	DCI Standards Development Team	Relevant Module Committee	New fields, new endpoints, or module-specific extensions
Breaking Change (affecting compatibility)	DCI Standards Development Team	Relevant Module Committee	Requires migration/transition plan
Core Change (affecting all modules)	DCI Standards Development Team	Special Committee (multi-sector)

Key Rules:

• Bug fixes and minor changes → DCI standards development team approves and implements directly.

• Module-specific changes → Reviewed by Module Committee before implementation.

• Core-wide changes → Convene special multi-sector committee for approval.

Implementation

• Bug Fixes / Minor Changes – Implemented directly by the DCI Repository Management Team.

• All Other Changes – Implemented after committee approval.

For non-trivial changes, the DCI Standards Development Team prepares an implementation plan, including:

• Risk mitigation strategies

• Testing and validation approach

• Migration/deprecation considerations

• Communication plan for stakeholders

Standard Revision Categories

Standards revisions are categorized by impact:

Category	Description	Process
Patch	Minor technical modifications or clarifications	Reviewed and approved by DCI Standards Development Team
Minor	Small enhancements or updates (e.g., new endpoint)	Requires DCI Standards Development Team +Steering Committee review and approval
Major	Changes affecting core functionalities or data objects	Requires DCI Standards Development Team + Steering Committee approval

Versioning

Objective: Maintain accurate history and traceability of changes.

Semantic Versioning:

• Major Update: X+1.0.0 → Significant changes

• Minor Update: X.Y+1.Z → Small improvements

• Patch Update: X.Y.Z+1 → Bug fixes or clarifications; documented for transparency

Action Steps:

• Use GitHub for version control

• Tag each revision with version number, date, and summary

• Maintain records of approvals, meeting minutes, and forms

Compatibility Management Process

This process applies when a proposed or implemented change to the DCI standards creates a compatibility issue that affects interoperability across systems or country's implementations. (i.e. change of type of a field, removing of a field ... )

Process:

1- Detection

• Compatibility issues may be identified during:

  • Technical review of proposed changes in the SPDCI tracker.

  • Regression and interoperability testing conducted by the DCI Repository Management Team.

  • Feedback from country implementers, partners, or other stakeholders after deployment.

2- Assessment

• The DCI Repository Management Team evaluates the issue to determine:

  • Which module(s) or APIs are affected.

  • Whether the issue is minor (limited operational impact with workarounds possible) or major (interoperability breakage with no feasible workarounds).

3- Escalation

• Minor issues (e.g., patch-level fixes) are resolved directly by the DCI Standards Development Team.

• Major issues are escalated to the relevant Module Committee for review and resolution.

• If the issue impacts the DCI core standards (cross-cutting and affecting all modules), a Special Committee with members from multiple sectors is convened to ensure broad consensus.

4- Resolution Planning

• The responsible body (DCI Standards Development Team, relevant Committee) develops a resolution plan, which may include:

  • Issuing a corrective patch or hotfix.

  • Providing dual-version support

5- Implementation

• Once approved, the DCI Repository Management Team applies the fix in the Git repository.

• Testing and validation are conducted to confirm that the resolution restores interoperability without introducing new issues.

6- Communication & Documentation

• All compatibility issues and resolutions are logged in the Git-based Change Log and reflected in GitBook.

• Stakeholders (e.g., country implementers, development partners) are notified of the issue, the resolution, and any required actions.