OZ-340: Refactoring from Ozone rebranding.

docs/config-points.md

@@ -0,0 +1,106 @@
+# <small>:construction:</small> Configuration Points
+
+In this section, we provide a comprehensive list of configuration points available in Ozone, organized by EIP services and thereby grouped by pairs of apps.
+
+---
+
+!!! info inline end ""
+
+    {==:oz: Pro==}
+
+## Keycloak-Superset Flows
+
+###### `superset.polling-interval`
+
+- _Location:_<br/>
+`ozone/distro/configs/eip-keycloak-superset/properties/application.properties`
+- _Possible values:_<br/>
+The time in milliseconds. Defaults to 30000 – Controls the polling interval for the `eip-keycloak-superset` service, which regularly fetches the set of roles from Superset to synchronize them with Keycloak.
+
+!!! tip "Sample configuration:"
+
+    ```java
+    superset.polling-interval=30000
+    ```
+
+---
+
+## ERPNext-OpenMRS Flows
+
+###### `erpnext.openmrs.enable.patient.sync`
+
+- _Location:_<br/>
+`ozone/distro/configs/eip-erpnext-openmrs/application.properties`
+- _Possible values:_
+    * [x] `false` – An OpenMRS patient is synchronised as an ERPNext customer when a first billable item is ordered from OpenMRS.
+    * [ ] `true` – An OpenMRS patient is always synchronised as an ERPNext customer.
+
+!!! tip "Sample configuration:"
+
+    ```java
+    erpnext.openmrs.enable.patient.sync=false
+    ```
+
+---
+
+## Odoo-OpenMRS Flows
+
+###### `concept.complex.uuid`
+
+- _Location:_<br/>
+<br/>
+- _Possible values:_<br/>
+<br/>
+
+###### `create.customer.if.not.exist`
+
+- _Location:_<br/>
+<br/>
+- _Possible values:_<br/>
+<br/>
+
+###### `emr.weight.concept`
+
+- _Location:_<br/>
+<br/>
+- _Possible values:_<br/>
+<br/>
+
+###### `openmrs.identifier.type.uuid`
+
+- _Location:_<br/>
+<br/>
+- _Possible values:_<br/>
+<br/>
+
+###### `results.encounterType.uuid`
+
+- _Location:_<br/>
+<br/>
+- _Possible values:_<br/>
+<br/>
+
+---
+
+## OpenMRS-SENAITE Flows
+
+###### `concept.complex.uuid`
+
+- _Location:_<br/>
+<br/>
+- _Possible values:_<br/>
+<br/>
+
+###### `openmrs.identifier.type.uuid`
+
+- _Location:_<br/>
+<br/>
+- _Possible values:_<br/>
+<br/>
+
+###### `results.encounterType.uuid`
+
+- _Location:_<br/>
+<br/>
+- _Possible values:_<br/>
+<br/>

docs/create-distro.md

@@ -16,7 +16,7 @@ Ozone provides a series Apache Maven-based tools to facilitate the assembly of y
 
 The Ozone Maven Archetype generates a foundational skeleton project, providing a customizable base for any specific implementation requirements.
 
-## **1**   Configure Maven
+### 1) Configure Maven
 
 Edit your Maven `settings.xml` file (usually located at `~/.m2/settings.xml`) and add the following block to it:
 ```xml
@@ -45,7 +45,7 @@ Edit your Maven `settings.xml` file (usually located at `~/.m2/settings.xml`) an
 </activeProfiles>
 ```
 
-## **2** &nbsp; Generate the archetype
+### 2) Generate the archetype
 
 Use Maven's archetype tools to generate a new Ozone implementation project structure:
 
@@ -67,19 +67,19 @@ This will prompt you for several key variables for your Maven project:
 This will create a bare-bones Ozone implementation project that should look like this:
 ```bash
 ozone-gruzinia/
-  ├── README.md
-  ├── configs
-  │     └── openmrs
-  │         ├── frontend_config
-  │         └── initializer_config
-  ├── pom.xml
-  ├── readme
-  │     └── impl-guide.md
-  └── scripts
-      ├── mvnw
-      ├── mvnw.cmd
-      ├── mvnwDebug
-      └── mvnwDebug.cmd
+├── README.md
+├── config
+│     └── openmrs
+│         ├── frontend_config
+│         └── initializer_config
+├── pom.xml
+├── readme
+│     └── impl-guide.md
+└── scripts
+    ├── mvnw
+    ├── mvnw.cmd
+    ├── mvnwDebug
+    └── mvnwDebug.cmd
 ```
 
 ## Available commands
@@ -88,6 +88,8 @@ ozone-gruzinia/
 |:----|:----|:----|
 |**Build** the distribution|<pre>./scripts/mvnw clean package</pre>|Assembles and packages your distribution, incorporating any configurations and customizations you've applied.|
 |Access start/stop/destroy commands|<pre>source target/go-to-scripts-dir.sh</pre>|Navigates to the directory containing the scripts for starting, stopping, and destroying the distribution, making these commands readily accessible.|
-|**Start** the distribution|<pre>./start-demo.sh</pre>|Initiates and launches all components of the Ozone HIS, bringing up the system.|
+|**Start** the distribution|<pre>./start-demo.sh</pre>|Initiates and launches all apps of the Ozone HIS, bringing up the system.|
 |**Stop** the distribution|<pre>./stop-demo.sh</pre>|Gracefully halts all Ozone HIS services, effectively shutting down the system.|
-|**Destroy** the distribution|<pre>./destroy-demo.sh</pre>|Completely removes the distribution, clearing all its components and data, ideal for resetting the system or rectifying persistent issues ahead of a restart or a rebuild and restart.|
+|**Destroy** the distribution|<pre>./destroy-demo.sh</pre>|Completely removes the distribution, clearing all its apps and data, ideal for resetting the system or rectifying persistent issues ahead of a restart or a rebuild and restart.|
+
+You are now ready to tailor Ozone to fit your specific requirements. Proceed to the following page for guidance on how to override default configurations.

docs/devs/conventions.md

@@ -1,14 +1,17 @@
 # <small>:construction:</small> Conventions
 
-In this section, we provide a comprehensive list of conventions followed in Ozone, organized by the type of conventions and thereby grouped by components.
+!!! info "Coming soon:"
+
+    * Listing our conventions, organized by the type and grouped by app/service.
+    * Code Conventions.
 
 ## Naming
 
 ### EIP Service
 
 - Should be named in the format `eip-<a>-<b>`. Where `<a>` and `<b>` are the names of the two systems being integrated, in alphabetical order. For example, `eip-erpnext-openmrs`.
 - The name should be in lowercase and use hyphens to separate words.
-- The preceding name should be used for(whenever possible):
+- The preceding name should be used for (whenever possible):
     - GitHub repository name.
     - Docker Compose service.
     - Configuration directory.
@@ -17,4 +20,4 @@ In this section, we provide a comprehensive list of conventions followed in Ozon
 
 ## Code Conventions
 
-### Java
+### Java

docs/devs/e2e-tests.md

@@ -1,13 +1,13 @@
 # Automated End-to-End Tests
 
-All data flows within Ozone and the actions performed on its HIS components are rigorously validated using a comprehensive suite of automated end-to-end (E2E) tests.
+All data flows within Ozone and the actions performed on its HIS apps are rigorously validated using a comprehensive suite of automated end-to-end (E2E) tests.
 
 This section is designed to help Ozone developers familiarize themselves with [`ozone-e2e`](https://github.com/ozone-his/ozone-e2e), the repository where all end-to-end tests for Ozone are maintained. It will guide you through the architecture of a typical end-to-end test case and provide the necessary knowledge and practical steps to develop your own test cases.
 
 !!! info "Some facts about `ozone-e2e`"
 
     - We use [Playwright <small>:fontawesome-solid-arrow-up-right-from-square:</small>](https://playwright.dev/), the automation testing framework.
-    - We test our data flows through the actions and effects that they have on Ozone HIS components.
+    - We test our data flows through the actions and effects that they have on Ozone HIS apps.
     - We focus on how these actions and effects are experienced by end users.
 
 !!! tip "Software Prequisites"
@@ -39,7 +39,7 @@ e2e
        as well as methods required by the tests to run.
 ```
 
-The data flows resulting from the integration between specific component pairs (e.g., between Odoo and OpenMRS) are typically tested through a designated test file for each pair (e.g., `odoo-openmrs-flows.spec.js`). All test files are located in the [`e2e/tests` directory](https://github.com/ozone-his/ozone-e2e/tree/main/e2e/tests). We encourage you to explore and review the current set of tests to understand the testing process better and evaluate the extent of their coverage.
+The data flows resulting from the integration between specific app pairs (e.g., between Odoo and OpenMRS) are typically tested through a designated test file for each pair (e.g., `odoo-openmrs-flows.spec.js`). All test files are located in the [`e2e/tests` directory](https://github.com/ozone-his/ozone-e2e/tree/main/e2e/tests). We encourage you to explore and review the current set of tests to understand the testing process better and evaluate the extent of their coverage.
 
 ### Project configuration
 
@@ -65,7 +65,7 @@ TEST_PRO=false
 
 All configuration variables are set to the desired values by editing and saving the [`.env` file <small>:fontawesome-solid-arrow-up-right-from-square:</small>](https://github.com/ozone-his/ozone-e2e/blob/main/.env) prior to running the tests.
 
-Additionally, the `.env` file contains a range of configuration variables that specify the URLs for accessing the various HIS components in each test environment, as well as the credentials needed to execute the test cases.
+Additionally, the `.env` file contains a range of configuration variables that specify the URLs for accessing the various HIS apps in each test environment, as well as the credentials needed to execute the test cases.
 
 ### Running tests against a local instance
 
@@ -92,7 +92,7 @@ SENAITE_URL_QA=
 SENAITE_URL_DEMO=
 # ...
 ```
-Continue this pattern for all components running locally by identifying their local URL in your development environment, and edit the `.env` file accordingly.
+Continue this pattern for all apps running locally by identifying their local URL in your development environment, and edit the `.env` file accordingly.
 
 ## Running Tests
 
@@ -104,7 +104,7 @@ npx playwright test
 ```
 
 ### Running specific tests
-To focus on testing data flows between specific pairs of HIS components, you can run tests contained in a specific file. For example, to test the integration data flows between Odoo and OpenMRS:
+To focus on testing data flows between specific pairs of HIS apps, you can run tests contained in a specific file. For example, to test the integration data flows between Odoo and OpenMRS:
 
 ```
 npx playwright test odoo-openmrs-flows
@@ -121,25 +121,25 @@ npx playwright test --project=chromium
 
 - **Passed**: When all tests within the suite pass without encountering any errors, the overall result is marked as "Passed". This means that the application behaved as expected under the test conditions.
 
-- **Failed**: If any test within the suite encounters an error or assertion failure during execution, the overall result is marked as "Failed". Determine whether the failure is specific to the test case, a particular component or feature, or the entire application. Once you've identified the root cause of the failure, implement a fix to address the issue. This may involve modifying test assertions, updating application code, or addressing environmental dependencies.
+- **Failed**: If any test within the suite encounters an error or assertion failure during execution, the overall result is marked as "Failed". Determine whether the failure is specific to the test case, a particular app or feature, or the entire application. Once you've identified the root cause of the failure, implement a fix to address the issue. This may involve modifying test assertions, updating application code, or addressing environmental dependencies.
 
 - **Skipped**: Sometimes, tests are intentionally skipped based on certain conditions or configurations. These skipped tests are not executed during the test run and are marked as "Skipped" in the test result.
 
 ## Developing Test Cases
 
 ### Naming test files
 
-Our test cases cover the data flows between Ozone HIS components and we have taken the convention to group test cases by pairs of components. For example all data flows between OpenMRS and SENAITE are grouped together in a file named `openmrs-senaite-flows.spec.js` that lives in the `e2e/tests`. This file contains all test cases for data flows going from OpenMRS to SENAITE as well as those going from SENAITE to OpenMRS.
+Our test cases cover the data flows between Ozone HIS apps and we have taken the convention to group test cases by pairs of apps. For example all data flows between OpenMRS and SENAITE are grouped together in a file named `openmrs-senaite-flows.spec.js` that lives in the `e2e/tests`. This file contains all test cases for data flows going from OpenMRS to SENAITE as well as those going from SENAITE to OpenMRS.
 
-The naming is alphabetical per convention. The data flows going both ways between hypothetical HIS components _Foo_ and _Bar_ would live in a file named `bar-foo-flows.spec.js` and so on and so forth for all pairs of HIS components.
+The naming is alphabetical per convention. The data flows going both ways between hypothetical HIS apps _Foo_ and _Bar_ would live in a file named `bar-foo-flows.spec.js` and so on and so forth for all pairs of HIS apps.
 
 ### Testing actions and effects
 
-While Ozone relies on its components default behaviour and features, we do encompass in our E2E test suite the actions performed when using the user experience of the components and the effects observed throught the user experience of those components. This ensures that test are truly end-to-end with a focus on the end-user experience.
+While Ozone relies on its apps default behaviour and features, we do encompass in our E2E test suite the actions performed when using the user experience of the apps and the effects observed throught the user experience of those apps. This ensures that test are truly end-to-end with a focus on the end-user experience.
 
 To write a test case:
 
-- Identify the user interactions and functionalities to test between a pair of HIS components.
+- Identify the user interactions and functionalities to test between a pair of HIS apps.
 - Use Playwright’s API to script the actions within each test scenario, such as navigating pages, clicking buttons, filling forms, and verifying UI elements.
 
 ### Utilizing Playwright
@@ -212,6 +212,6 @@ We observe that the test structure is broken down between a **setup**, the actua
 
 - **Setup**: Omitted here. All aspects of the setup have been performed in the `beforeEach()` method.
 - **Replay**: Navigation to the lab order form, add a lab test, and save the form.
-- **Verification**: Navigation to the SENAITE HIS component and search for the client by name. Verify that the client's name is visible in the clients list.
+- **Verification**: Navigation to the SENAITE HIS app and search for the client by name. Verify that the client's name is visible in the clients list.
 
 **Cleanup**: The post-test cleanup consists of deleting the test patient and closing the browser page.

docs/devs/index.md

@@ -1,62 +1,62 @@
 !!! info ""
 
-    This section of the Ozone Docs is designed for **software architects, engineers, and developers**. It provides comprehensive information on Ozone's architecture, guides on integrating new software components, and technical advice on developing within Ozone.
+    This section of the Ozone Docs is designed for **software architects, engineers, and developers**. It provides comprehensive information on Ozone's architecture, guides on integrating new software apps, and technical advice on developing within Ozone.
 
 # Architecture Overview
 
 ## Ozone Platform
 
-Ozone Platform serves as the interoperability layer that seamlessly integrates HIS components by enabling data flows between them:
+The Ozone Platform serves as the interoperability layer that seamlessly integrates HIS apps by enabling data flows of FHIR resources between them:
 
 <figure markdown>
   ![alt text](oz-plat-1.jpg){ width="600" }
-  <figcaption>HIS components glued with configurable data flows.</figcaption>
+  <figcaption>HIS apps glued with configurable data flows.</figcaption>
 </figure>
 
 Ozone Platform is a decenstralised mesh of peer-to-peer interoperability services, each an instance of Ozone's **EIP Client**.
 
-Each service connects a pair of HIS components of Ozone's digital health sofware suite:
+Each service connects a pair of HIS apps of Ozone's digital health sofware suite:
 
 <figure markdown>
   ![alt text](oz-plat-2.jpg){ width="600" }
-  <figcaption>Mesh of peer-to-peer services integrating HIS components.</figcaption>
+  <figcaption>Mesh of point-to-point services integrating apps within the HIS.</figcaption>
 </figure>
 
 ## Ozone's EIP Client
 
-The core of the Ozone Platform is powered by the EIP Client(1), a Spring Boot application that runs Apache Camel routes. This application acts as the ETL[^etl] agent between two components of the HIS.
+The core of the Ozone Platform is powered by the EIP[^eip] Client, a Spring Boot application that runs Apache Camel routes. This application acts as the ETL[^etl] agent between two apps of the HIS.
 { .annotate }
 
-1.  <a target="_blank" href="https://camel.apache.org/components/4.0.x/eips/enterprise-integration-patterns.html"><b>E</b>nterprise <b>I</b>ntegration <b>P</b>atterns</a>
+[^eip]: Enterprise Integration Patterns
 
 [^etl]: Extract, Transform, Load
 
 <figure markdown>
   ![alt text](eip-client-1.jpg){ width="600" }
-  <figcaption>Peer-to-peer service between two HIS components.</figcaption>
+  <figcaption>Point-to-point service between two apps of the HIS.</figcaption>
 </figure>
 
-The EIP Client facilitates the **exchange of FHIR resources** between two components of Ozone's digital health software suite. This exchange of FHIR resources is precisely what makes the data flows of Ozone HIS.
+The EIP Client facilitates the **exchange of FHIR resources** between two apps of Ozone's digital health software suite. This exchange of FHIR resources is precisely what makes the data flows of Ozone HIS.
 
 Development in Ozone primarily involves assembling peer-to-peer services using the EIP Client. This client is equipped with several built-in features, simplifying the development process:
 
 - It's a ready-to-use application designed for implementing Camel routes.
 - It manages authentication:
 
-    * With Ozone FOSS's HIS components.
+    * With Ozone FOSS's HIS apps.
     * With Ozone Pro's Identity Provider (IdP). &nbsp;&nbsp;{==:oz: Pro==}
 
 - It includes a variety of common libraries to implement data flows that can be reused across different services.
 
 ## Missing :fhir:FHIR APIs
 
-Many software components do not provide a FHIR API, often because they are not healthcare-specific, such as ERP systems. When this occurs, there are two possible solutions:
+Many software apps do not provide a FHIR API, often because they are not healthcare-specific, such as ERP systems. When this occurs, there are two possible solutions:
 
 ### **1** &nbsp; Lobby for the inclusion of a FHIR API
 
 The ideal solution is to advocate for the software editor or development community to include a FHIR API as part of the software itself.
 
-Generally, this can be achieved gradually with minimal effort by focusing on the subset of FHIR resources most needed to accomplish the desired flows within Ozone HIS. Often, only a couple of resources are required, and not all operations need to be supported for those resources.
+Generally, this can be achieved gradually with minimal effort by focusing on the subset of FHIR resources most needed to accomplish the desired flows within the Ozone HIS. Often, only a couple of resources are required, and not all operations need to be supported for those resources.
 
 ### **2** &nbsp; Development of a Camel FHIR facade
 

docs/eip-config-points.md

@@ -1,6 +1,6 @@
 # <small>:construction:</small> EIP Configuration Points
 
-In this section, we provide a comprehensive list of configuration points available in Ozone, organized by EIP services and thereby grouped by pairs of components.
+In this section, we provide a comprehensive list of configuration points available in Ozone, organized by EIP services and thereby grouped by pairs of apps.
 
 ---