Video tutorial coming soon.
Deploy OpenMRS on Ubuntu with Docker — the globally trusted open-source medical record system used by WHO, MSF, and thousands of clinics worldwide. Modular, multi-language, and designed for resource-constrained environments in developing countries.
Grab the automated bash script from GitHub to follow along with the video.
wget https://raw.githubusercontent.com/mhmdali94/Docker/main/clinic/openmrs/openmrs-ubuntu.sh
chmod +x openmrs-ubuntu.sh
sudo bash openmrs-ubuntu.shFetch the OpenMRS install script from the Prisma Docker library:
wget https://raw.githubusercontent.com/mhmdali94/Docker/main/clinic/openmrs/openmrs-ubuntu.shGrant execute permission before running:
chmod +x openmrs-ubuntu.shThe script installs Docker if needed, then deploys OpenMRS with MySQL. First startup takes a few minutes as the application initialises its database schema.
sudo bash openmrs-ubuntu.shOpen your browser and navigate to port 8080. Log in with the default admin credentials and complete the initial setup wizard to configure your installation.
http://<your-server-ip>:8080/openmrs| Port | Purpose |
|---|---|
| 8080 | OpenMRS Web UI |
| 3306 | MySQL Database (internal only) |
OpenMRS (Open Medical Record System) is an open-source medical record platform that has been running in production clinics across Africa, Asia, and Latin America since 2004. Originally developed by Partners in Health and Regenstrief Institute, it is now maintained by a global community and supported by the WHO, CDC, PEPFAR, and MSF. OpenMRS is architected around a concept dictionary — a flexible metadata system that lets clinics define their own clinical concepts, forms, and workflows without modifying the core code. This makes it uniquely adaptable to different countries' medical terminology, diagnostic systems, and reporting requirements. It powers health systems treating millions of patients in over 40 countries.
OpenMRS is the most battle-tested open medical record system for primary care in low-resource settings. Its concept dictionary architecture means the same platform can serve an HIV clinic in Kenya, a TB programme in India, and a maternal health project in Haiti — each with their own clinical forms, workflows, and reporting requirements. The enormous community means there are hundreds of contributed modules covering nearly every clinical programme type. Being free and open-source with no per-user or per-patient licensing fees makes it the default choice for publicly funded health programmes worldwide.
OpenMRS runs on port 8080 for its web interface. MySQL uses port 3306 internally — this must never be exposed externally. Only port 8080 should be proxied, and only through a reverse proxy with HTTPS. For multi-facility deployments sharing a central OpenMRS instance, use a VPN between sites rather than exposing the web interface to the open internet.
OpenEMR is the best alternative for clinics needing billing, scheduling, and e-prescribing alongside the EMR — more feature-rich for Western-market outpatient practices. GNU Health is better for hospitals needing full HIS coverage (inpatient, surgery, pharmacy). Bahmni is a distribution of OpenMRS combined with an ERP for pharmacy and billing — popular in South Asia. DHIS2 is complementary rather than competitive — it handles population-level aggregate reporting, while OpenMRS handles individual patient records; many programmes use both together. Commercial options include Epic, Cerner, and regional EHR products with certified regulatory compliance.
If your clinic is in a Western country with established EHR certification requirements (e.g., ONC certification in the US, CE marking in the EU), OpenMRS lacks the certified integrations and compliance documentation those markets require — OpenEMR or a commercial system is more appropriate. If you need full hospital management (inpatient beds, surgery, pharmacy), GNU Health covers more ground. If your primary need is disease-level aggregate reporting rather than individual patient records, DHIS2 is more appropriate. If your team has limited IT capacity for ongoing maintenance, consider a managed OpenMRS hosting service rather than self-hosting.
PrismaTechWork provides end-to-end infrastructure services — from initial deployment and security hardening to ongoing monitoring, automated backups, and dedicated support. Whether you need a single-server setup or a multi-site network, our team ensures your infrastructure is built right, secured properly, and maintained reliably.
OpenMRS is used by thousands of health facilities in over 40 countries. Major deployments include AMPATH in Kenya (one of the largest HIV programmes in Africa), Partners in Health in Haiti and Rwanda, MSF (Médecins Sans Frontières) field hospitals, PEPFAR-funded programmes across sub-Saharan Africa, and government health ministries in Uganda, Tanzania, Ethiopia, and other countries. It powers care for millions of patients, predominantly in HIV, TB, and maternal health programmes.
The concept dictionary is a central registry of all clinical concepts used in OpenMRS — diagnoses, observations, medications, tests, and their coded representations (e.g., ICD-10 codes, LOINC codes, SNOMED). Every piece of clinical data recorded in OpenMRS references a concept. The dictionary can be customised for each programme: an HIV clinic adds HIV-specific concepts (viral load, CD4 count, ARV regimens), while a TB clinic adds TB-specific ones. Standard concept sets (CIEL) are available for import to avoid rebuilding from scratch.
The OpenMRS Android Client allows community health workers to collect data offline on a mobile device and sync when connectivity is restored. For full offline deployment (e.g., a clinic with no internet), OpenMRS runs entirely on a local server accessible over the clinic's Wi-Fi network — no cloud connection is needed. The sync mechanism resolves conflicts when the same patient is updated both locally and centrally, though conflict resolution requires careful workflow design.
Bahmni is an open-source hospital system distribution that integrates OpenMRS (for EMR) with OpenERP/Odoo (for pharmacy, billing, and inventory) and a custom web frontend. It provides a more polished, unified interface than vanilla OpenMRS and adds modules for clinical observations, radiology, and pharmacy dispensing. Bahmni is developed by ThoughtWorks and the Bahmni Coalition and is widely deployed in India, Bangladesh, and other Asian countries. Choose Bahmni if you need EMR + pharmacy/billing as a single system.
Install the HTML Form Entry module, then use the form designer or write form XML directly. Each field in the form references a concept from the concept dictionary. The form builder lets you create encounter forms for new patient visits, follow-up consultations, or programme enrolment. Test all forms thoroughly in a staging environment before deploying to production — a syntax error in the form XML will cause the form to fail to render for all users.
Yes — OpenMRS has a built-in reporting framework that supports cohort queries, indicator definitions, and formatted report templates. Reports can be scheduled to run automatically and exported in CSV, Excel, or PDF format. The Reporting module integrates with DHIS2 for automated aggregate data submission to national health information systems. Most PEPFAR and HMIS reporting indicators have pre-built OpenMRS report definitions available in the community module repository.
OpenMRS is primarily Java-based — the backend is a Java EE application running on Tomcat, and modules are Java JARs. The frontend (OpenMRS 3.x) is built with React and the OpenMRS Frontend Framework. Groovy is used for some scripting and report definitions. If you want to build custom modules or extend the system, Java knowledge is required for backend work and React/TypeScript for the new frontend. The REST API allows integrations in any language.
Minimum for a small clinic (under 20 concurrent users): 2 vCPU / 4 GB RAM / 50 GB storage. Recommended for a mid-size facility (20–100 users): 4 vCPU / 8 GB RAM / 200 GB SSD. OpenMRS runs on the JVM and benefits significantly from additional heap memory — allocate at least 2 GB of JVM heap (-Xmx2g). For large national deployments, OpenMRS can be clustered behind a load balancer with a shared database, but this requires careful session management configuration.