chore: Fix typos in CHT Sync and CHT Interoperability documentation (#…

…1591)

content/en/building/guides/data/analytics/production.md

@@ -19,19 +19,19 @@ We recommend running [CHT Sync](https://github.com/medic/cht-sync) in production
 - Helm: The Kubernetes package manager. You can install it using the [helm installation guide](https://helm.sh/docs/intro/install/).
 
 ## Database disk space requirements
-The disk space required for the database depends on a few things including the size the of CouchDB databses being replicated, and the [models]({{< relref "building/guides/data/analytics/building-dbt-models" >}}) defined. The database will grow over time as more data is added to CouchDB. The database should be monitored to ensure that it has enough space to accommodate the data. To get an idea of the size requirements of the database, you can replicate 10% of the data from CouchDB to the Postgres and then run the following command to see disk usage.
+The disk space required for the database depends on a few things including the size the of CouchDB databases being replicated, and the [models]({{< relref "building/guides/data/analytics/building-dbt-models" >}}) defined. The database will grow over time as more data is added to CouchDB. The database should be monitored to ensure that it has enough space to accommodate the data. To get an idea of the size requirements of the database, you can replicate 10% of the data from CouchDB to Postgres and then run the following command to see disk usage:
 ```shell
 SELECT pg_size_pretty(pg_database_size('your_database_name'));
 ```
 
-If postgres is running in a Kubernetes cluster, you can use the following command to get the disk usage.
+If Postgres is running in a Kubernetes cluster, you can use the following command to get the disk usage:
 ```shell
 kubectl exec -it postgres-pod-name -- psql -U postgres -c "SELECT pg_size_pretty(pg_database_size('your_database_name'));"
 ```
 
-You can then multuply this figure by 10 to get an estimate of the disk space required for the full dataset and then add some extra space for indexes and other overhead as well as future growth.
+You can then multiply this figure by 10 to get an estimate of the disk space required for the full dataset and then add some extra space for indexes and other overhead as well as future growth.
 
-For example if the size of the database is 1GB, you can expect the full dataset to be around 10GB. If the COuchDb docs grow by 20% every year then you can compound this growth over 5 years to get an estimate of the disk space required. 10GB * 1.2^5 = 18.5GB and you can add an extra 20% for indexes and overhead to get an estimate of 22.2GB.
+For example if the size of the database is 1GB, you can expect the full dataset to be around 10GB. If the CouchDB docs grow by 20% every year then you can compound this growth over 5 years to get an estimate of the disk space required: `10GB * 1.2^5 = 18.5GB`. You can add an extra 20% for indexes and overhead to get an estimate of 22.2GB.
 
 Please note that this is just an estimate and the actual disk space required may vary so actively monitoring the disk space usage and making necessary adjustments is recommended.
 

content/en/building/guides/integrations/fhir.md

@@ -12,24 +12,24 @@ relatedContent: >
 ## Overview
 
 CHT has an interoperability tool which supports building FHIR workflows.
-You can see more details of the tool [here](https://github.com/medic/cht-interoperability). The following [FHIR resources](https://hl7.org/fhir/) are supported:
+You can see more details of the tool [in the cht-interoperability repository](https://github.com/medic/cht-interoperability). The following [FHIR resources](https://hl7.org/fhir/) are supported:
 1. Sending [Patient](https://build.fhir.org/patient.html) data from the CHT to interoperating systems.
 2. Sending reports as [Encounters](https://build.fhir.org/encounter.html) with [Observations](https://build.fhir.org/observation.html) from the CHT to interoperating systems.
 3. Sending [Patient](https://build.fhir.org/patient.html) data created in interoperating systems to CHT applications.
 4. Sending health information represented as [Encounters](https://build.fhir.org/encounter.html) with [Observations](https://build.fhir.org/observation.html) from interoperating systems to CHT applications.
 
 ## Sending Data
-When sending data to an interoperating system, we use [outbound push](/building/reference/app-settings/outbound/) to configure which documents should be sent and at what point.
+When sending data to an interoperating system, [outbound push](/building/reference/app-settings/outbound/) is used to configure which documents should be sent and at what point.
 A [mediator](http://openhim.org/docs/configuration/mediators/) then converts these documents to FHIR resources and orchestrates sending them to interoperating systems.
-The default mediator makes any resources sent to it queryable via a FHIR api using [HAPI](https://hapifhir.io/).
+The default mediator makes any resources sent to it queryable via a FHIR API using [HAPI](https://hapifhir.io/).
 
 ## Receiving data
-When receiving data from an interoperating system in a CHT application, configure [forms](/building/reference/app-settings/forms/) and [transitions](/building/reference/app-settings/transitions/) to map the incoming data to CHT documents.
-A [mediator](http://openhim.org/docs/configuration/mediators/) is responsible for getting these resources from an interoperating system (either by exposing API endpoints or pulling them from an API), and converting from FHIR resources to a format that can be submitted to [the records API](/building/reference/api/#records).
+When receiving data from an interoperating system in a CHT application, [forms](/building/reference/app-settings/forms/) and [transitions](/building/reference/app-settings/transitions/) are configured to map the incoming data to CHT documents.
+A mediator is responsible for getting these resources from an interoperating system (either by exposing API endpoints or pulling them from an API), and converting from FHIR resources to a format that can be submitted to [the records API](/building/reference/api/#records).
 
 ## Outbound Patients
 
-When sending [Patient](https://build.fhir.org/patient.html) data collected from CHT to an interoperating system, first identify which documents represent patients. In the example below, a patient is a document with type person and role 'patient'. This may not apply to all CHT applications.
+When sending `Patient` data collected from CHT to an interoperating system, first identify which documents represent patients. In the example below, a patient is a document with type person and role `patient`. This may not apply to all CHT applications.
 Then, create an outbound push configuration to send these documents to the interoperating system.
 
 The outbound push config contains the following fields.
@@ -42,20 +42,20 @@ The outbound push config contains the following fields.
 Add a condition in the `relevant_to` field; whenever any documents matching this condition are created or updated, a request will be sent to the url specified in `base_url` and `path`.
 
 The fields in the patient document need to be mapped to the FHIR format.
-It is possible to convert the document to a FHIR [Patient](https://build.fhir.org/patient.html) resource in outbound push config (an example can be found in the [reference application](https://github.com/medic/cht-interoperability/blob/6318b9f0fba8d8293dfec890004e18e489af538c/cht-config/app_settings.json#L445)).
+It is possible to convert the document to a FHIR Patient resource in outbound push config (an example can be found in the [reference application](https://github.com/medic/cht-interoperability/blob/6318b9f0fba8d8293dfec890004e18e489af538c/cht-config/app_settings.json#L445)).
 This can be difficult to configure correctly, so the default mediator also accepts a shorter form which is the `id`, `name`, `phone`, `date_of_birth` and `patient_id` fields from the document itself.
 
 The mapping field in outbound push config contains the following fields.
 |Field|Description|
 |--|--|
 |`_id`|CouchDB's unique identifier of the record. This will be converted to an [Identifier](https://build.fhir.org/datatypes.html#identifier) with type `CHT Document Id`.|
-|`name`| Patients name.|
-|`phone`| Patients phone number.|
+|`name`| Patient's name.|
+|`phone`| Patient's phone number.|
 |`date_of_birth`| Patient's date of birth.|
 |`sex`| Patient's sex.|
 |`patient_id`| If a separate `patient_id` is generated, it can be sent here. This will be converted to an [Identifier](https://build.fhir.org/datatypes.html#identifier) with type `CHT Patient Id`.|
 
-This example outbound push config selects documents where `patient_id` exists, and `doc.role === patient`
+This example outbound push config selects documents where `patient_id` exists, and `doc.role === patient`:
 ```json
 {
   "patient": {
@@ -83,11 +83,11 @@ This example outbound push config selects documents where `patient_id` exists, a
 
 ## Outbound Reports
 
-To send reports from the CHT to an interoperating system, an [Encounter](https://build.fhir.org/encounter.html) resource is created to represent the encounter between the patient and the CHW. Any data in the report that is sent to the interoperating system is represented as [Observations](https://build.fhir.org/observation.html) linked to the [Encounter](https://build.fhir.org/encounter.html).
+To send reports from the CHT to an interoperating system, an `Encounter` resource is created to represent the encounter between the patient and the CHW. Any data in the report that is sent to the interoperating system is represented as `Observations` linked to the `Encounter`.
 
-[Encounters](https://build.fhir.org/encounter.html) have a reference to [Patients](https://build.fhir.org/patient.html), so setting up outbound patients is a requirement for outbound reports.
+`Encounters` have a reference to `Patients`, so setting up outbound patients is a requirement for outbound reports.
 
-Similarly to patients, create an outbound push configuration with the `relevant_to` field having `doc.type === 'data_record' && doc.form === '{{the form to be sent}}'`
+Similarly to patients, create an outbound push configuration with the `relevant_to` field having `doc.type === 'data_record' && doc.form === '{{the form to be sent}}'`.
 
 The outbound push config contains the following fields.
 |Field|Description|
@@ -96,16 +96,16 @@ The outbound push config contains the following fields.
 |`base_url`| The url of the OpenHIM instance where the mediator is hosted.|
 |`path`| `/mediator/cht/encounter`|
 
-The fields in the form that need to be exchanged need to be mapped to a format that a mediator can convert to [Observations](https://build.fhir.org/observation.html).
-[Observations](https://build.fhir.org/observation.html) need to have a [Code](https://build.fhir.org/datatypes.html#code) that is understood by the interoperating system, and the response values may need to be converted to a different format.
+The fields in the form that need to be exchanged need to be mapped to a format that a mediator can convert to `Observations`.
+`Observations` need to have a [Code](https://build.fhir.org/datatypes.html#code) that is understood by the interoperating system, and the response values may need to be converted to a different format.
 
 For example a yes/no question may need to be converted to the presence (if yes) or absence (if no) of an observation with a code.
 
-'Does the patient show signs of fever?' can be converted to an observation with the code for fever if the answer was yes, or be omitted entirely if the answer was no.
+"Does the patient show signs of fever?" can be converted to an observation with the code for fever if the answer was `yes`, or be omitted entirely if the answer was `no`.
 
-Another example is multiple choice questions, which can be converted to a coded question where each of the choices is assigned a code
+Another example is multiple choice questions, which can be converted to a coded question where each of the choices is assigned a code.
 
-'Which danger signs does the patient show?' can be converted to [Observations](https://build.fhir.org/observation.html) with the code for pregnancy danger signs, and for each danger sign selected, the value is the code of the danger sign.
+"Which danger signs does the patient show?" can be converted to `Observations` with the code for pregnancy danger signs, and for each danger sign selected, the value is the code of the danger sign.
 
 The mapping field in outbound push config contains the following fields.
 |Field|Description|
@@ -119,7 +119,7 @@ The mapping field in outbound push config contains the following fields.
 |`observation.n.valueDateTime`| For datetime questions, the date for the value.|
 |`observation.n.valueString`| For string questions, the value.|
 
-In this example, a `danger signs` question is converted into [Observations](https://build.fhir.org/observation.html) where `danger signs` has code `17a57368-5f59-42c8-aaab-f2774d21501e`, and the yes/no questions `fever` and `breathlessness` with codes `43221561-0600-410e-8932-945665533510` and `070dca86-c275-4369-b405-868904d78156` are present if the response was `yes` or absent if the response was `no`.
+In this example, a `danger signs` question is converted into `Observations` where `danger signs` has code `17a57368-5f59-42c8-aaab-f2774d21501e`, and the yes/no questions `fever` and `breathlessness` with codes `43221561-0600-410e-8932-945665533510` and `070dca86-c275-4369-b405-868904d78156` are present if the response was `yes` or absent if the response was `no`.
 
 ```json
 {
@@ -170,11 +170,11 @@ In this example, a `danger signs` question is converted into [Observations](http
 It is also possbile to create patients in the CHT from patients that were created in external systems.
 Patients in CHT applications are represented as [contacts](building/contact-management/contacts/), and require a parent to be assigned to a CHW, facility, or other location. This requires a mediator to have the ids of contacts in CHT and currently cannot be done automatically by the default mediator. A custom mediator needs to be created which assigns a field to use as the `parent_id`.
 
-To create data in CHT, a mediator converts a FHIR [Patient](https://build.fhir.org/patient.html) to a json object that it submits as a request to [the records API](/building/reference/api/#records).
+To create data in CHT, a mediator converts a FHIR `Patient` to a json object that it submits as a request to [the records API](/building/reference/api/#records).
 This requires a [form](/building/reference/app-settings/forms/) to be configured in the CHT; the incoming data will be saved as a report.
 Then, the actual patient document is created by assigning a [create patient transition](/building/reference/app-settings/transitions/#add_patient) to the form.
 
-Because the patient creation form is a CHT form like an other, messages, validations and other transitions can be assigned to it to build more complex workflows.
+Because the patient creation form is a CHT form like any other, messages, validations and other transitions can be assigned to it to build more complex workflows.
 
 This example form allows an interoperating system to create a patient with some common fields: `patient_name`, `age_in_days`, `phone_number`, and an `id` in the external system.
 In this example, `location_id` is used as the `parent_id` field; this field will usually have to be configured in a custom mediator.
@@ -291,15 +291,15 @@ Using the above example form, this transition will create a patient document and
 
 ## Inbound Reports
 
-[Encounters](https://build.fhir.org/encounter.html) and [Observations](https://build.fhir.org/observation.html) created by interoperating systems can be sent to the CHT to be visible to CHT users.
+`Encounters` and `Observations` created by interoperating systems can be sent to the CHT to be visible to CHT users.
 Similarly to patients, a mediator converts the FHIR resources to a json format that is submitted to the records API.
-Reports need to be linked to patients using a `patient_id` field which is the uuid of the patient document in CHT. The mediator extracts this id from the `CHT Document ID` identifier of the fhir patient. 
+Reports need to be linked to patients using a `patient_id` field which is the uuid of the patient document in CHT. The mediator extracts this id from the `CHT Document ID` identifier of the FHIR `Patient`. 
 For patients created by CHT, they need to have been sent to the interoperating system before receiving any reports. For patients created by the interoperating system, the `CHT Document ID` needs to have been set; see the section below on [Patient Ids](building/guides/integrations/fhir/#populating-ids).
 
 A CHT form needs to be configured to receive the reports via the records API.
-In the form configuration, the names of fields which should be extracted from [Observations](https://build.fhir.org/observation.html) should be the codes of the [Observations](https://build.fhir.org/observation.html). Human readable labels can be added for display.
+In the form configuration, the names of fields which should be extracted from `Observations` should be the codes of the `Observations`. Human readable labels can be added for display.
 
-Because these forms are CHT forms like an other, messages, validations and other transitions can be assigned to them to build more complex workflows.
+Because these forms are CHT forms like any other, messages, validations and other transitions can be assigned to them to build more complex workflows.
 
 This example configures the form for a typical antenatal care form.
 ```json
@@ -377,10 +377,9 @@ This example configures the form for a typical antenatal care form.
 
 When patients from an interoperating system are sent to a CHT application, the mediator needs to maintain a link between the CHT patient and the external patient by saving the document and patient ids from CHT, and forwarding them back to the interoperating system. Because the patient document is created aynschronously with the request to create the patient, the mediator exposes a callback endpoint to add these ids asynchronously. 
 
-To use this endpoint, create another outbound push config with `patient_id` and `external_id`.
-relevant to should be `doc.type === 'data_record' && doc.form === {{the code of the patient creation form}}`.
+To use this endpoint, create another outbound push config with `patient_id` and `external_id`, and `relevant_to` being `doc.type === 'data_record' && doc.form === {{the code of the patient creation form}}`.
 
-Mapping contains three fields, `id`, `patient_id`, and `external_id`.
+The mapping contains three fields, `id`, `patient_id`, and `external_id`.
 
 |Field|Description|
 |--|--|