GitBook Version Change Control Process

This is the GitBook Version Change Control Process for the OpenHIE Specification. It's designed to better understand the process for which change requests go through.

Versioning and Classification In Releases

+ 1.0 Use a full version release if changes or additions impact the data exchange standards, the substance of the specification including the diagram or content of the specification.

• Content Additions (ie. new workflows)

• Content Improvements (ie. changes to existing content like digram)

+.1 Use a point release if the changes are clarifications or corrections that do not impact the technical meaning of the specification. This version reflects minor changes (ie. spelling, links)

• Minor updates are changes that do not have impact on data exchange (ie. small wording changes or updates that do not impact data exchange)

** The secretariat will make small updates (i.e. spelling or links) to ensure usability that is not accounted for in the version releases

Proposal Process

Changes can be submitted by any community members.

• Proposal Change - submitting via a Change Request Form (Google form?)

• Summary of Impact - capture the request in a log and for large changes the OHIE-TC review the impact against scope, budget and schedule

• Decision - decisions that impact data exchange (OpenHIE workflows section of the document or the OpenHIE diagram) will be made by OHIE-TC on whether to accept the change

• Implementing Change - Update plan, gain extra funding (ie. translation), secure resources to accommodate the change

• Closing Change - Update the Change Log once the change is complete

+1.0 Versioning Process

Implementation process is completed by OpenHIE Secretariat.

1. Post changes to discourse and give the community one week to respond. No response will be interpreted as community approval.

   1. If major changes are requested changes will be brought back to the OHIE-TC for review and the process starts over again.

2. Duplicate most current specification release, rename as ‘Staging Branch’ and incorporate community approved changes.

3. Staging branch updates are reviewed by the OHIE-TC to ensure clarity.

4. OHIE-TC approved changes are added to the Staging branch

5. All approved updates in the staging are released as a new version of the specification

+0.1 Versioning Process

1. Post changes to discourse and give the community one week to respond. No response will be interpreted as community approval.

2. Duplicate most current specification release, rename as ‘Staging Branch’ and incorporate community approved changes.

3. All approved updates in the staging are released as a new version of the specification