OpenHIE Architecture Specification
5.2-en
DEVStaging5.2-en5.0-es5.0-fr4.03.02.0
5.2-en
DEVStaging5.2-en5.0-es5.0-fr4.03.02.0
  • Specification Overview
    • GitBook Version Change Control Process
    • How to use the Specification
    • Version Change Log
    • How to Provide Feedback and Input
  • Architecture Specification
    • Architecture
    • Architectural Principles
    • Standards and Profiles
  • OpenHIE Component Specifications
    • Non-Functional Requirements
    • Client Registry (CR)
    • OpenHIE Facility Registry (FR)
    • OpenHIE Finance and Insurance Service (FIS)
    • OpenHIE Health Management Information System (HMIS)
    • OpenHIE Health Worker Registry (HWR)
    • OpenHIE Interoperability Layer (IOL)
    • OpenHIE Logistics Management Information System (LMIS)
    • OpenHIE Product Catalogue (PC)
    • OpenHIE Shared Health Record (SHR)
    • OpenHIE Terminology Service (TS)
    • Point-Of-Care Systems
  • Data Exchange Specification
    • Aggregate Reporting Workflows
      • Export Aggregate Data
      • Validate and Save Aggregate Data
    • Alerting / Sending Reminders or Information
      • Send Client Alert Workflow
      • Send Health Worker Alert Workflow
    • Care Services Discovery
      • Query Health Worker and/or Facility Records Workflow
      • Query Care Services Records Workflow
      • Search Care Services Workflow
      • Request Care Services Updates Workflow
    • Laboratory Work Flows
      • Order Laboratory Test
      • Report Lab Results
    • Patient Identity Management Workflows
      • Create Patient Demographic Record Workflow
      • Update Patient Demographic Record Workflow
      • Query Patient Demographic Records by Identifier Workflow
      • Query Patient Demographic Records by Demographics Workflow
    • Shared Health Record
      • Save Patient-level Clinical Data Workflow
      • Query Patient-level Clinical Data Workflow
    • Terminology Service Workflows
      • Expand Value Set
      • Translate Code
      • Verify Code Existence
      • Verify Code Membership
      • Query Value Set
      • Query Code Systems
      • Query Concept Maps
      • Lookup Code
    • Vaccine Workflows
    • OpenHIE Finance and Insurance Services Workflows
      • HFW-001: Enroll Beneficiary
      • HFW-002: Query Beneficiary
      • HFW-003: Check Coverage Eligibility
      • HFW-004: Claiming
      • HFW-005: Claim Tracking
Powered by GitBook
On this page
  • Versioning and Classification In Releases
  • Proposal Process
  • +1.0 Versioning Process
  • +0.1 Versioning Process
  1. Specification Overview

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

PreviousSpecification OverviewNextHow to use the Specification

Last updated 10 months ago