-
-### CHT configuration with Docker
-
-The following steps apply when running CHT via the Docker setup provided in this repository:
-
-1. CHT can be accessed via `http://localhost:5988`, and the credentials are `medic`/`password`.
-2. Create a new user in the CHT instance with the username `interop-client` using these [instructions](https://docs.communityhealthtoolkit.org/apps/tutorials/contact-and-users-1/#4-create-the-chw-user). For the role you can select `Data entry` and `Analytics` roles. Please note that you can use any username you prefer but you would have to update the config with the new username. You can do that by editing the `cht-config/app_settings.json` file and updating the `username` value in the `outbound` object e.g. on this [line](https://github.com/medic/interoperability/blob/main/cht-config/app_settings.json#L452).
-3. Securely save the `interop-client` user's password to the database using the instructions [here](https://docs.communityhealthtoolkit.org/apps/reference/api/#credentials). Change the values `mykey` and `my pass` to `openhim1` and your user's password respectively. An example of the curls request is below:
-
-```bash
-curl -X PUT -H "Content-Type: text/plain" http://medic:password@localhost:5988/api/v1/credentials/openhim1 -d 'interop-password'
-```
-
-### Local setup of CHT Configuration
-
-The following steps apply when running CHT locally in development mode and when making configuration changes locally:
-
-#### CHT Development Environment
-
-1. Set up a local CHT instance using [these instructions](https://docs.communityhealthtoolkit.org/apps/tutorials/local-setup/).
-2. Create a new user in the CHT instance with the username `interop-client` using these [instructions](https://docs.communityhealthtoolkit.org/apps/tutorials/contact-and-users-1/#4-create-the-chw-user). For the role you can select `Data entry` and `Analytics` roles. Please note that you can use any username you prefer but you would have to update the config with the new username. You can do that by editing the `cht-config/app_settings.json` file and updating the `username` value in the `outbound` object e.g. on this [line](https://github.com/medic/interoperability/blob/main/cht-config/app_settings.json#L452).
-3. Securely save the `interop-client` user's password to the database using the instructions [here](https://docs.communityhealthtoolkit.org/apps/reference/api/#credentials). Change the values `mykey` and `my pass` to `openhim1` and your user's password respectively. An example of the curls request is below:
-
-```bash
-curl -X PUT -H "Content-Type: text/plain" http://medic:password@localhost:5988/api/v1/credentials/openhim1 -d 'interop-password'
-```
-4. After updating the mediator code or cht configuration, you need to run `./startup.sh up-dev` to upload the changes to docker compose.
-
-#### CHT Configuration
-
-1. Go into the `cht-config` directory by running `cd cht-config`.
-1. Run `npm install` to install the dependencies.
-1. Create a file named `.env` under `/mediator` folder, copy over the contents of `/mediator/.env.template` and update the `CHT_USERNAME` and `CHT_PASSWORD` values with the admin credentials of your CHT instance.
-1. Set up a proxy to your local CHT instance by running using something like [nginx-local-ip](https://github.com/medic/nginx-local-ip) or [ngrok](https://ngrok.com/) and update the `CHT_URL` value in the `.env` file with the new URL.
-1. Ensure you have [cht-conf](https://www.npmjs.com/package/cht-conf) installed and run `cht --local` to compile and upload the app settings configuration to your local CHT instance.
-1. To verify if the configuration is loaded correctly is to create a `Patient` and to access a URL like `https://*****.my.local-ip.co/#/contacts/patientUUID/report/interop_follow_up`. This should retrieve correctly the follow up form.
-1. To verify if the configuration in CouchDB, access `http://localhost:5984/_utils/#database/medic/settings`.
-
-### Shutdown the servers
-
-- To shut-down the containers run `./startup.sh down` to stop the instances.
-- To then restart the containers, run `./startup.sh up`. You do not need to run `init` again like you did in the initial install above.
-- To shut-down and delete _everything_, run `./startup.sh destroy`. You will have to subsequently run `./startup.sh init` if you wish to start the containers.
+Read more detail on the [CHT docs site](https://docs.communityhealthtoolkit.org/building/interoperability/).
diff --git a/TROUBLESHOOTING.md b/TROUBLESHOOTING.md
deleted file mode 100644
index 0a1a00c5..00000000
--- a/TROUBLESHOOTING.md
+++ /dev/null
@@ -1,31 +0,0 @@
-# Troubleshooting
-
-## Error "bind: address already in use"
-Users encountering:
-
-> Error response from daemon: Ports are not available: exposing port TCP 0.0.0.0:5000 -> 0.0.0.0:0: listen tcp 0.0.0.0:5000: bind: address already in use
-
-when running `./startup.sh init` need to update ports to available values in the `/docker/docker-compose.yml` file, under the `ports` verb.
-
-## Error when running mediator `curl` request
-If the mediator `curl` request fails, visit [http://localhost:9000/#!/clients](http://localhost:9000/#!/clients) and click on the icon the red arrow points to in the image below.
-
- 
-
-## Error "Preset ts-jest is invalid:" when running `npm test`
-Users encountering the error below when running `npm test`:
-
-> Preset ts-jest is invalid:
-> The "id" argument must be of type string. Received null
-> TypeError [ERR_INVALID_ARG_TYPE]: The "id" argument must be of type string. Received null
-
-need to run `npm i --save-dev ts-jest` before running `npm test`.
-
-## Error "unsuccessful npm install" when running `npm install`
-Users encountering the error when running `npm install`:
-
-> npm ERR! code EACCES
-> npm ERR! syscall unlink
-> npm ERR! path /Users/phil/interoperability/cht-config/node_modules/.package-lock.json
-
-need to run `npm install` as root user.
diff --git a/WORKFLOW.md b/WORKFLOW.md
deleted file mode 100644
index 959b5766..00000000
--- a/WORKFLOW.md
+++ /dev/null
@@ -1,412 +0,0 @@
-# LTFU Workflow Testing
-
-This document outlines the steps for testing the Loss To Follow-Up (LTFU) workflow, in addition to documenting the various endpoints available on the mediator. It provides a comprehensive guide on navigating the LTFU workflow and utilizing the endpoints to facilitate the necessary actions.
-
-## Environments
-
-The document provided includes placeholders for URLs. Replacing these placeholders with the appropriate endpoints for your specific environment is essential to utilize the document correctly. Below are the endpoints provided for each available environment. It is important to note that if your setup differs from the documentation provided, you may need to use different endpoints. By ensuring that the correct endpoints are used, you can be confident in successfully implementing and utilizing the LTFU workflow.
-
-### Docker - Local Setup
-
-- **Mediator (`${MEDIATOR_ENDPOINT}`)** - http://localhost:5001/mediator
-- **OpenHIM Admin Console** - http://localhost:9000/
-- **CHT with LTFU configuration** - http://localhost:5988/
-
-## Steps
-
-The following steps assume that you successfully logged in into OpenHIM and the CHT instances.
-
-1. Create an **Endpoint** and an **Organization**
-
- 1. **HTTP Request** - Use Postman to create an `Endpoint` Resource in the Mediator. You can view the API documentation for creating an `Endpoint` [here](#endpoint-resource). Once you send the request, the Mediator will return a JSON response containing the `id` of the newly created endpoint.
-
- 1. **HTTP Request** - Create an `Organization` Resource in the Mediator using as `endpoint.reference` the example value replacing `${ENDPOINT_ID}` with the actual `id` of the `Endpoint` you created in the previous step. Once you send the request, the Mediator will return a JSON response containing the `id` of the newly created `Organization`. You can view the API documentation for creating an `Organization` [here](#organization-resource).
-
-
-> It is important to note that you only need to create an `Organization` once, which you can use for future requests. So, after creating the `Organization`, you can save the `organization.identifier[0].value` value and use it for all future `ServiceRequest` requests.
-
-
-1. Create a **Patient**
-
- 1. **CHT** - Log in to the CHT platform using the credentials for 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/`.
- 
-
-1. Request the LTFU for the Patient
-
- 1. **HTTP Request** - To trigger the LTFU process for the newly created patient, you need to create a `ServiceRequest`. You can refer to the API documentation available [here](#servicerequest-resource) to learn how to create a `ServiceRequest`. Replace the `requester.reference` and the `subject.reference` with the `Organization` and `Patient` identifiers respectively. Once the `ServiceRequest` is received by the mediator, it will initiate the LTFU workflow for the patient, which includes reminders for follow-up appointments and check-ins.
-
- 1. **HTTP Request** - Verify that the `ServiceRequest` was successful in both OpenHIM Mediator & FHIR Resource. Navigate to the `Transaction Log` in the Admin Console. You should see three successful API calls, as in the image below:
- 
-
-1. Handle LTFU Task
-
- 1. **CHT** - Navigate to the `Tasks` tab. There should be an automatically created `Task` for the Patient. If it is not the case, sync data via `Sync now` option. The `Task` should look like in the image below:
-
- 
-
- 1. **CHT** - Select an option (Yes or No) and submit the `Tasks`.
- 1. **OpenHIM Admin Console** - Verify that the Encounter creation was successful in both OpenHIM Mediator & FHIR Resource. Navigate to the `Transaction Log` in the Admin Console. You should see two successful API calls, one to `/mediator/encounter/` and one to `/fhir/Encounter/`, as in the image below.
- 
- 1. If your callback URL test service was set up correctly, you should receive a notification from the mediator.
-
-
-An API test collection that can be used with Postman or similar tools can be found under `/docs/local-test`. This collection allows testing the LTFU flow while running the instances locally.
-
-## Resources
-
-The following [FHIR Resources](https://www.hl7.org/fhir/resource.html) are used to implement the flow above:
-
-- [Patient](https://www.hl7.org/fhir/patient.html)
-- [Encounter](https://build.fhir.org/encounter.html)
-- [Subscription](https://build.fhir.org/subscription.html)
-- [Organization](https://build.fhir.org/organization.html)
-- [Endpoint](https://build.fhir.org/endpoint.html)
-
-The payload samples in the documentation contain placeholder values you must replace with the actual content. To do so, replace the entire `${}` placeholder with the appropriate value. Be aware that some placeholder keys have the format `_\_IDENTIFIER` and refer to the value in the `Resource.identifier[0].value` field. These keys differ from the `_\_ID` placeholders used in the request, which refer to the `Resource.id` field. It is important to make this distinction, as using the wrong value may cause unexpected behavior in the system. Therefore, always ensure you use the right value in the right context to avoid errors.
-
-
-> **Note:** The payload only contains the required fields or a subset of the possible options. Please refer to the appropriate FHIR resource specifications to view all the available fields.
-
-
-### `ServiceRequest` Resource
-
-The FHIR `ServiceRequest` resource represents a request for a healthcare service to be performed, such as a diagnostic test or a treatment. It contains information about the requested service, including the **type of service**, the **patient** for whom the service is requested, the **date/time the service is requested**, and the **healthcare provider or organization** making the request. In the context of the LTFU workflow, this resource is used to request a CHW follow-up in the CHT.
-
-#### `POST ${MEDIATOR_ENDPOINT}/service-request`
-
-This endpoint triggers the creation of a `record` on `CHT` and a `Subscription` resource on FHIR. The endpoint associated with the `Organization` resource in the requester is used as the callback URL for the `Subscription` which gets called when FHIR receives an `Encounter` resource with matching `Patient` identifier. The callback endpoint receives a FHIR `Subscription` response as its payload whenever the request is fulfilled. To learn more about FHIR
-subscriptions, you can visit the official documentation [here](https://build.fhir.org/subscription.html).
-
-##### Request
-
-```http
-POST ${MEDIATOR_ENDPOINT}/service-request
-
-{
- "intent": "order",
- "subject": {
- "reference": "Patient/${PATIENT_IDENTIFIER}"
- },
- "requester": {
- "reference": "Organization/${ORGANIZATION_IDENTIFIER}"
- }
- ,
- "status": "active"
-}
-```
-
-##### Response
-
-```json
-{
- "resourceType": "Subscription",
- "id": "4",
- "meta": {
- "versionId": "1",
- "lastUpdated": "2023-04-19T04:41:17.656+00:00",
- "tag": [
- {
- "system": "http://hapifhir.io/fhir/StructureDefinition/subscription-matching-strategy",
- "code": "IN_MEMORY",
- "display": "In-memory"
- }
- ]
- },
- "status": "requested",
- "reason": "Follow up request for patient",
- "criteria": "Encounter?identifier=003b24b5-2396-4d95-bcbc-5a4c63f43ff0",
- "channel": {
- "type": "rest-hook",
- "endpoint": "https://callback.com",
- "payload": "application/fhir+json",
- "header": ["Content-Type: application/fhir+json"]
- }
-}
-```
-
-### `Endpoint` Resource
-
-The FHIR `Endpoint` resource describes the network address of a system or service where messages or payloads can be exchanged. It defines the communication characteristics for sending and receiving messages, such as the **transport protocol**, the **payload format**, and the **messaging endpoint's address**. The `Endpoint` resource can specify where to send data for specific purposes, such as notifications, alerts, or reports. It can be used in various contexts, such as clinical care, public health, or research, where different systems or services need to exchange data seamlessly.
-
-#### `POST ${MEDIATOR_ENDPOINT}/endpoint`
-
-In the LTFU workflow, the `Endpoint` is crucial in creating a `ServiceRequest`. It is obtained from the `Organization` attached to the `ServiceRequest` as the requester. The `Endpoint` represents the destination where the FHIR server sends notifications about matching `Encounter` resources. When the FHIR server receives a matching `Encounter` resource, it sends a notification to the endpoint. The endpoint is used as a **callback URL** for the FHIR server to notify the requester about the status of the `ServiceRequest`. Therefore, ensuring that the endpoint is accurate and valid for successful communication between the FHIR server and the requesting system is important.
-
-- **ENDPOINT_ID:** _(Optional)_ A preferred `id` for the `Endpoint`. By default, the mediator will generate an `id` for the `Endpoint`.
-- **ENDPOINT_IDENTIFIER:** An identifier for the `Endpoint` that can be used when querying the FHIR database in the future.
-- **ORG_CALLBACK_URL:** A callback URL that the mediator can use to contact the requesting system (`Organization`) in the future when a `ServiceRequest` has been fulfilled.
-
-> **NOTE** The FHIR `Subscription` that will be created ulteriorly requires `ORG_CALLBACK_URL` to accept HTTP `PUT` requests matching this path `${ORG_CALLBACK_URL}/:resourceType/:resourceId` and return a 200. In this workflow, the callback should expect to receive an `Encounter` resource sent back to the requesting system on `${ORG_CALLBACK_URL}/Encounter/:id`.
-
-##### Request
-
-
-```http
-POST ${MEDIATOR_ENDPOINT}/endpoint
-
-{
- "id": "${ENDPOINT_ID}",
- "identifier": [
- {
- "system": "official",
- "value": "${ENDPOINT_IDENTIFIER}"
- }
- ],
- "connectionType": {
- "system": "http://terminology.hl7.org/CodeSystem/endpoint-connection-type",
- "code": "hl7-fhir-rest"
- },
- "payloadType": [
- {
- "text": "application/json"
- }
- ],
- "address": "${ORG_CALLBACK_URL}",
- "status": "active"
-}
-```
-
-##### Response
-
-
-```json
-{
- "resourceType": "Endpoint",
- "id": "1",
- "meta": {
- "versionId": "1",
- "lastUpdated": "2023-04-19T04:40:44.401+00:00"
- },
- "identifier": [
- {
- "system": "official",
- "value": "ENDPOINT_ID"
- }
- ],
- "status": "active",
- "connectionType": {
- "system": "http://terminology.hl7.org/CodeSystem/endpoint-connection-type",
- "code": "hl7-fhir-rest"
- },
- "payloadType": [
- {
- "text": "application/json"
- }
- ],
- "address": "https://callback.com"
-}
-```
-
-### `Patient` Resource
-
-The FHIR `Patient` resource represents an individual receiving or awaiting healthcare services. It includes **patient demographics**, **clinical observations**, and **medical history**. It is a foundational resource in healthcare and can be used to track patient progress, manage care plans, and facilitate communication between healthcare providers.
-
-#### `POST ${MEDIATOR_ENDPOINT}/patient`
-
-This endpoint creates a `Patient` in the LFTU workflow. Patients are created by CHT automatically whenever a new Patient is added to the system.
-
-##### Request
-
-```http
-POST ${MEDIATOR_ENDPOINT}/patient
-
-{
- "identifier": [
- {
- "system": "official",
- "value": "${PATIENT_IDENTIFIER}"
- }
- ],
- "name": [
- {
- "family": "Doe",
- "given": [
- "John"
- ]
- }
- ],
- "gender": "male",
- "birthDate": "2000-01-01"
-}
-```
-
-##### Response
-
-
-```json
-{
- "resourceType": "Patient",
- "id": "3",
- "meta": {
- "versionId": "1",
- "lastUpdated": "2023-04-19T04:41:01.217+00:00"
- },
- "text": {
- "status": "generated",
- "div": "| Identifier | 003b24b5-2396-4d95-bcbc-5a4c63f43ff0 |
| Date of birth | 01 January 2000 |