# GitBook Version Change Control Process

### 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)<br>

+.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)<br>

\*\* 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&#x20;

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.&#x20;
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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://guides.ohie.org/arch-spec/readme/gitbook-version-change-control-process.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.