commit 9fe9d764e42b0f9a36b35a85de925f656e2e7dc2 Author: shihab.sikder Date: Tue Jun 25 15:21:53 2024 +0600 added initial files diff --git a/1.png b/1.png new file mode 100644 index 0000000..93e8238 Binary files /dev/null and b/1.png differ diff --git a/2.png b/2.png new file mode 100644 index 0000000..be42ccd Binary files /dev/null and b/2.png differ diff --git a/3.png b/3.png new file mode 100644 index 0000000..e028e07 Binary files /dev/null and b/3.png differ diff --git a/4.png b/4.png new file mode 100644 index 0000000..214ada0 Binary files /dev/null and b/4.png differ diff --git a/readme.md b/readme.md new file mode 100644 index 0000000..7984e11 --- /dev/null +++ b/readme.md @@ -0,0 +1,235 @@ +# OpenMRS Service Integration + +This project integrates with OpenMRS to manage patient records, visits, location hierarchy, and clinical data. The service leverages OpenMRS's robust API to ensure seamless interoperability between our application and OpenMRS. + +## Table of Contents + +1. [Overview](#overview) +2. [Patient Records Management](#patient-records-management) +3. [Visit Management](#visit-management) +4. [Location Hierarchy Management](#location-hierarchy-management) +5. [Clinical Data Management](#clinical-data-management) +6. [Environment Configuration](#environment-configuration) +7. [Helper Code](#helper-code) + +## Overview + +The integration with OpenMRS allows our application to: + +- Check for existing patients in the OpenMRS system. +- Register new patients and update existing patient records. +- Manage patient visits. +- Handle a hierarchical location structure to support multiple hospitals. +- Store and manage clinical data, such as medical concepts. + +We are using OpenMRS version 2.5 without any modifications. We are utilizing the core modules and the REST API to interact with the OpenMRS system. Below is a table listing the modules and their versions that we are using: + +| Module Name | Version | Author | +| -------------------------- | ------------- | --------------------------- | +| Registration Core Module | 1.12.0 | OpenMRS Developers | +| ID Generation | 4.10.0 | Partners In Health | +| Event Module | 2.10.0 | OpenMRS | +| Provider Management Module | 2.14.0 | Mark Goodrich | +| Visit Management Module | 1.0 | OpenMRS | +| FHIR2 | 1.3.0 | OpenMRS FHIR Squad | +| App Framework Module | 2.17.0 | djazayeri | +| Open Web Apps Module | 1.13.0 | Saptarshi, Namrata, Sandeep | +| Admin UI Module | 1.6.0 | Ujjwal Arora | +| UI Commons Module | 2.24.0 | OpenMRS | +| App UI Module | 1.17.0 | OpenMRS | +| Rest Web Services OMOD | 2.41.0.756cb3 | OpenMRS | +| OpenMRS UI Framework | 3.24.0 | OpenMRS | +| Legacy UI Module | 1.16.0 | Tharunya | +| Bed Management Module | 5.13.0 | Thoughtworks | +| UI Library Module | 2.0.7 | djazayeri | + +## Patient Records Management + +### Check Existing Patient + +We can check if a patient already exists in the OpenMRS system using their identifier (patientId). This helps avoid duplicate records. + +```typescript +const existingPatient = await openmrsService.checkExistingPatient(patientId); +``` + +### Register New Patient + +If a patient does not exist, we register them in the OpenMRS system. + +```typescript +const newPatient = await openmrsService.registerPatient({ + name: "John Doe", + patientId: "12345", + locationId: "1", + gender: "male", + birthdate: new Date("1990-01-01"), + address1: "123 Main St", + cityVillage: "Dhaka", + postalCode: "1234", + attributes: [{ attributeType: "Phone Number", value: "0123456789" }], +}); +``` + +### Update Patient + +If the patient already exists, we update their details. + +```typescript +const updatedPatient = await openmrsService.updatePatient({ + name: "John Doe", + openmrsId: existingPatient.results[0].uuid, + patientId: "12345", + locationId: "1", + gender: "male", + birthdate: new Date("1990-01-01"), + address1: "123 Main St", + cityVillage: "Dhaka", + postalCode: "1234", + attributes: [{ attributeType: "Phone Number", value: "0123456789" }], +}); +``` + +#### Registration Encounter triggered via API + +![Patient Registration](./4.png) + +## Visit Management + +We manage patient visits by creating and retrieving visit types and visits. + +### Create Visit Type + +```typescript +const visitType = await openmrsService.createVisitType( + "General Visit", + "A general check-up visit." +); +``` + +### Create Visit + +```typescript +const visit = await openmrsService.createVisit( + "patient-uuid", + "visit-type-uuid", + "2023-06-01T08:00:00Z", + "Routine check-up", + "location-uuid" +); +``` + +## Location Hierarchy Management + +OpenMRS supports a hierarchical location structure which allows us to manage multiple hospitals and their sub-locations. + +### Create Location + +Locations represent different hospitals or units within hospitals. + +```typescript +const location = await openmrsService.createLocation( + "Main Hospital", + "456 Another St" +); +``` + +### Check Existing Location + +Before creating a new location, we check if it already exists. + +```typescript +const existingLocation = await openmrsService.checkExistingLocation( + "Main Hospital" +); +``` + +### Location Hierarchy + +The location hierarchy is managed in a way that allows us to link sub-locations (like departments or wards) to parent locations (main hospital buildings). This hierarchical structure facilitates the management of multiple hospitals within a single OpenMRS instance. + +## Clinical Data Management [Under Development] + +OpenMRS is used to store various types of clinical data, including medical concepts. + +### Medical Concepts + +Medical concepts are used to standardize and manage clinical data. They represent diagnoses, procedures, and other clinical information. + +### Create Medical Concept + +We interact with the OpenMRS API to create and manage medical concepts. (Under Developent) + +## Helper Code + +### OpenMRS Client Helper + +The `openmrs.py` script handles the communication with the OpenMRS API to update location information and establish parent-child relationships among locations. + +`openmrs.py` + +```python +import json +import requests + +base_url = "http://***.***.***.**:****/openmrs/ws/rest/v1" +auth = ("****", "****") + +with open("seeded-openmrs.json", "r") as json_file: + data_dict = json.load(json_file) + +def update_location(location_id, parentLocation): + url = f"{base_url}/location/{location_id}" + headers = { + "Content-Type": "application/json", + "Access-Control-Allow-Origin": "*" + } + body = { + "parentLocation": parentLocation + } + try: + response = requests.post(url, json=body, headers=headers, auth=auth) + if response.status_code == 200: + return True + else: + print(f"Failed to update location with ID {location_id}") + return False + except requests.exceptions.RequestException as e: + print("Request Exception:", e) + return False + +for key, values in data_dict.items(): + if not data_dict[key].get("parentLocationId"): + continue + print("Updating location with ID: ", data_dict[key]["openmrsId"], "with parent location: ", data_dict[data_dict[key]["parentLocationId"]]["openmrsId"]) + update_location(data_dict[key]["openmrsId"], data_dict[data_dict[key]["parentLocationId"]]["openmrsId"]) +``` + +### Parent-Child Location Helper + +The `parent-child.py` script defines the `LocationHierarchy` class, which provides methods for creating new locations and checking for existing locations, thereby helping to build and manage the hierarchical structure of locations. + +`parent-child.py` + +```python +from openmrs import OpenMRSClient + +class LocationHierarchy: + def __init__(self, client: OpenMRSClient): + self.client = client + + def create_location(self, name: str, address: str): + return self.client.create_location(name, address) + + def check_existing_location(self, name: str): + return self.client.check_existing_location(name) +``` + +### Building the Location Hierarchy + +1. **Creating Locations**: The `LocationHierarchy` class in `parent-child.py` is used to create new locations by calling the `create_location` method. This method interacts with the OpenMRS API to register the location in the system. +2. **Updating Locations**: The `update_location` function in `openmrs.py` is used to update an existing location's information and set its parent location. This establishes the parent-child relationship necessary for the hierarchical structure. +3. **Establishing Parent-Child Relationships**: The `openmrs.py` script reads location data from a JSON file (`seeded-openmrs.json`) which contains information about each location and its parent. It then iterates over this data to update each location with its corresponding parent location using the `update_location` function. + +![Location Hierarchy](./1.png) +![Location Hierarchy](./2.png)