feat(#129): cahning file names

content/en/building/concepts/interoperability.md

@@ -7,9 +7,9 @@ description: >
 keywords: interoperability integrations fhir icd openhie openhim
 relatedContent: >
   building/features/integrations
-  building/guides/interoperability/cht_config
+  building/guides/interoperability/cht-config
   building/guides/interoperability/openhim
-  building/guides/interoperability/ltfu_reference_workflow
+  building/guides/interoperability/ltfu
 aliases:
    - /apps/concepts/interoperability
 ---

content/en/building/guides/interoperability/cht_config.md → content/en/building/guides/interoperability/cht-config.md

@@ -8,6 +8,7 @@ keywords: interoperability fhir integrations openmrs
 aliases: 
   - /building/guides/integrations/fhir/
   - /building/guides/interoperability/fhir/
+  - /building/guides/interoperability/cht-config/
 relatedContent: >
   building/concepts/interoperability/
 ---
@@ -297,7 +298,7 @@ Using the above example form, this transition will create a patient document and
 `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`. 
-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]({{< ref "building/guides/interoperability/cht_config#populating-ids" >}}).
+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](#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` should be the codes of the `Observations`. Human readable labels can be added for display.

content/en/building/guides/interoperability/ltfu_reference_workflow.md → content/en/building/guides/interoperability/ltfu.md

@@ -6,7 +6,7 @@ description: >
    Guide to testing the LTFU reference workflow
 keywords: openmrs interoperability
 relatedContent: >
-  building/guides/interoperability/cht_config
+  building/guides/interoperability/cht-config
   building/concepts/interoperability/
 ---
 
@@ -41,7 +41,7 @@ See the [OpenHIM guide]({{< ref "building/guides/interoperability/openhim" >}})
 
 1.  Create a **Patient**
 
-    1. **CHT** - Log in to the CHT platform using the credentials for the `chw` user (if the `chw` user does not already exist, you can [create one]({{< ref "building/contact-management/contact-and-users-1#4-create-the-chw-user" >}}).
+    1. **CHT** - Log in to the CHT platform using the credentials for the `chw` user. If the `chw` user does not already exist, you can [create one]({{< ref "building/contact-management/contact-and-users-1#4-create-the-chw-user" >}}).
     1. **CHT** - Navigate to the `People` tab in the CHT dashboard. From there, select a Facility where you want to create a new `Person`. Click on the `New Person` button and fill in the required details for the Person. Make sure to select `Patient` as the `Person`'s role for this flow.
     1. **CHT** - Once you have created the new `Person`, you need to retrieve their unique identifier from the browser's URL. You can do this by copying the alphanumeric string that appears after `person/` in the URL. Keep this identifier safe as you will need it for the next steps.
     1. **OpenHIM Admin Console** - To verify that the `Patient` creation was successful, navigate to the `Transaction Log` in the OpenHIM Admin Console. You should see two successful API calls recorded in the log, one to `/mediator/patient/` and one to `/fhir/Patient/`.

content/en/building/guides/interoperability/openhim.md

@@ -6,8 +6,8 @@ description: >
    Guide to running OpenHIM and Mediators with Docker Compose
 keywords: openmrs interoperability
 relatedContent: >
-  building/guides/interoperability/cht_config
-  building/guides/interoperability/ltfu_reference_workflow
+  building/guides/interoperability/cht-config
+  building/guides/interoperability/ltfu
   building/guides/interoperability/troubleshooting
   building/concepts/interoperability/
   building/guides/integrations/openmrs/

content/en/building/guides/interoperability/openmrs.md

@@ -6,14 +6,14 @@ description: >
    Exchange data with systems based on OpenMRS using FHIR APIs
 keywords: openmrs interoperability
 relatedContent: >
-  building/guides/interoperability/cht_config
+  building/guides/interoperability/cht-config
   building/concepts/interoperability
   building/guides/interoperability/openhim
 ---
 
 [OpenMRS](https://openmrs.org) is an open-source electronic medical record system used in dozens of countries. Integrating CHT apps with OpenMRS can open up opportunities to improve health outcomes for patients by promoting better coordination of care. For example, referrals by CHWs in the community can be sent electronically to health facilities using OpenMRS so that nurses and clinicians can prepare for their visit and have full access to the assessment done by a CHW.
 
-Integrating CHT apps with OpenMRS can be achieved using the CHT's [Interoperability Tools]({{< ref "building/guides/interoperability/openhim" >}}) and following the guidance in the [Building interoperability with FHIR APIs documentation]({{< ref "building/guides/interoperability/cht_config" >}}). 
+Integrating CHT apps with OpenMRS can be achieved using the CHT's [Interoperability Tools]({{< ref "building/guides/interoperability/openhim" >}}) and following the guidance in the [Building interoperability with FHIR APIs documentation]({{< ref "building/guides/interoperability/cht-config" >}}). 
 
 ## Overview
 
@@ -60,7 +60,7 @@ Depending on what data needs to be exchanged, [outbound push]({{< ref "building/
 
 ### Sending patients CHT->OpenMRS
 
-When sending patient data to OpenMRS, configure an outbound push mapping as described in the [CHT FHIR config documentation]({{< ref "building/guides/interoperability/cht_config#outbound-patients" >}}).
+When sending patient data to OpenMRS, configure an outbound push mapping as described in the [CHT FHIR config documentation]({{< ref "building/guides/interoperability/cht-config#outbound-patients" >}}).
 Patients synced to OpenMRS will have two new [identifier types](https://guide.openmrs.org/getting-started/openmrs-information-model/#patient-identifier): `CHT Document Id`, the uuid of the document that is sent, and `CHT Patient ID`, if there is a `patient_id` field on the patient document.
 These identifier types are created automatically when the OpenMRS Channel is registered.
 
@@ -143,7 +143,7 @@ This sequence diagrams shows the entire flow including the OpenMRS Mediator and
 
 Any data sent from CHT to OpenMRS needs to map to a [concept](https://wiki.openmrs.org/display/docs/Concept+Dictionary+Basics) in OpenMRS. Each concept has a code which will be used to identify the concept in the CHT Application, the FHIR Server, and OpenMRS.
 For any fields to send to OpenMRS, first find or create matching concepts in OpenMRS.
-Then, using the appropriate codes, configure an outbound push as described in the [CHT FHIR config documentation]({{< ref "building/guides/interoperability/cht_config#outbound-reports" >}}).
+Then, using the appropriate codes, configure an outbound push as described in the [CHT FHIR config documentation]({{< ref "building/guides/interoperability/cht-config#outbound-reports" >}}).
 
 In OpenMRS, all form submissions are represented as `Home Visit` encounter types, with a `Visit Note` encounter.
 Any fields in the outbound push config are converted to FHIR observations, which are linked to the `Visit Note`.
@@ -193,7 +193,7 @@ This sequence diagrams shows the entire flow including the OpenMRS Mediator and
 ### Sending forms OpenMRS->CHT
 
 When sending form data to CHT, first find, create, or import the concepts in OpenMRS, and create the forms in OpenMRS.
-Then create a form in CHT to receive the reports [as described in the CHT interop config documentation]({{< ref "building/guides/interoperability/cht_config#outbound-reports" >}}); the codes from OpenMRS are the field names, and labels can be added for human readability.
+Then create a form in CHT to receive the reports [as described in the CHT interop config documentation]({{< ref "building/guides/interoperability/cht-config#outbound-reports" >}}); the codes from OpenMRS are the field names, and labels can be added for human readability.
 When a visit is completed in OpenMRS, the mediator will sync it to the FHIR Server.
 
 After setting up the forms, test that it works in the test environment by submitting the form in OpenMRS.

content/en/building/guides/interoperability/troubleshooting.md

@@ -6,8 +6,8 @@ description: >
    Guide to troubleshooting OpenHIM, Mediators, and configurations for interoperability workflows
 keywords: openmrs interoperability
 relatedContent: >
-  building/guides/interoperability/cht_config
-  building/guides/interoperability/ltfu_reference_workflow
+  building/guides/interoperability/cht-config
+  building/guides/interoperability/ltfu
   building/guides/interoperability/openhim
   building/guides/interoperability/openmrs
   building/concepts/interoperability/