# 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)