CareCode HMIS: A Sri Lankan Hospital System That Grew for Two Decades Without a Clean Release

A Two-Decade-Old System With a Contradictory Repository

The README describes a system that has served over 40 healthcare institutions since 2004, became open source in 2012, and now has a version number of 3.0.0.20240813.1. The GitHub repository tells a different story. The default branch is named 'development' and the most recent release is 1.0.0, tagged as OpenHMIS V 1.0.0 on 2019-06-19. The last push to the repository was on that same day. So the README claims a 2024 version, but the repository shows no activity since 2019. This mismatch is the first thing an engineer will notice. You cannot trace the claimed 3.0.0.20240813.1 to any tag or release in the visible material. That is a serious trust issue for anyone planning a deployment.

What the System Actually Covers

The README lists eight modules: Electronic Medical Records, Pharmacy and Laboratory Information Management, Inpatient and Outpatient Management, Appointment and Theatre Management, Human Resource and Payroll Management, and Inventory and Asset Management. This is a broad scope for a hospital system. The project history says it started in 2004 as an EMR for general practice, then expanded through community feedback. That origin explains the module list. It is not a narrow tool. It aims to be a full hospital information system. The primary language listed on GitHub is HTML, which is odd for a Java EE project. It likely reflects the repository's file distribution, not the actual implementation language. Still, it suggests a system where the front end is not a modern framework but server-rendered pages, consistent with its Java EE roots.

How It Works: Java EE, a Database, and Guided Setup

The README gives a sparse but concrete mechanism. You clone the repository, configure a blank database connection in your application server, and run the project. The setup is guided: 'it will guide you through initial setup' is the exact phrase. System requirements are a Java Enterprise Edition compatible server, MySQL or MariaDB, and a modern web browser. There is no mention of a build tool like Maven or Gradle, no WAR file instructions, no configuration keys beyond the database connection. The architecture is classic Java EE: an application server hosts the application, the database holds the data, and the browser is the client. The data flow is standard for that stack. The absence of any API documentation or integration notes means you are expected to know Java EE deployment yourself. For a small hospital IT team, that is a real barrier.

The License Problem: No Assertion on GitHub, AGPL in the README

The GitHub repository metadata says the license is NOASSERTION. The README says 'License: AGPL (see LICENSE.md)' and later repeats 'AGPL License - see LICENSE.md for details.' These two statements conflict. A NOASSERTION value on GitHub means the repository has not declared a standard license file that GitHub can recognize. The README claims an AGPL license, but the actual LICENSE.md file is not visible in the material. This is a legal hazard for adoption. AGPL is a strong copyleft license with network-use provisions. If you deploy a modified version over a network, you may have to release your source code. That is a significant obligation. Before any deployment, you must open LICENSE.md and confirm the exact terms. The README also mentions that the project became open source under MIT license in 2012, which contradicts the AGPL claim. Three different license statements appear in the same README. That is not a minor inconsistency.

Real Institutions, But No Verifiable User Base

The README lists contributing institutions, including Ruhunu MediHospital in Hambanthota since 2012 and University Medical Centre at the University of Colombo from 2025 onwards. These are specific, named users. That is more than most open source projects offer. However, the README also says 'serving over 40 healthcare institutions since 2004' without naming all of them. You cannot verify that number from the repository. The list is a claim, not evidence. For an engineer, the named institutions are useful signals: the system has run in real hospitals in Sri Lanka. But the lack of any deployment documentation, case studies, or technical references in the README means you cannot assess how those institutions use it. The project's history is its strongest asset, but it is not a substitute for verifiable technical documentation.

The Wrong Tool for Modern Integrations

The README mentions no APIs, no HL7 or FHIR support, no web services, no interoperability features. For a hospital system in 2025, that is a critical gap. Modern hospital environments need to exchange data with lab machines, insurance systems, and national health records. The README's module list covers internal functions but says nothing about external communication. Java EE is a server-side platform, so you could build integrations yourself, but you would be doing it from scratch. The project also has no mobile app mention. If your institution needs a patient portal or a mobile interface, this system has nothing visible to offer. This is a case where the system's age shows. It was designed for a time when a hospital system was a self-contained web app. That design may still work for a small clinic, but it is the wrong tool for a hospital that needs to connect to a broader health IT ecosystem.

Alternatives: Compare With a Modern Open Source HMIS

The obvious alternative is Bahmni, an open source hospital information system built on OpenMRS and OpenERP. Bahmni takes a modular approach: it combines an EMR, a hospital management module, and a reporting engine, all with a REST API and a modern JavaScript front end. Unlike CareCode HMIS, Bahmni has active releases, a clear license, and a documented integration layer. The key difference is architectural. Bahmni is designed for extensibility and interoperability from the start, while CareCode HMIS appears to be a monolithic Java EE application. Bahmni also has a global community and a foundation behind it. CareCode HMIS has a single lead developer and a history tied to one country. For an institution that needs to integrate with external systems, Bahmni is a more defensible choice. For a Sri Lankan clinic that wants a system already tuned to local workflows, CareCode HMIS might still be worth a look, but only after you resolve the license and release questions.

Maintenance and Upgrade Cost: The Hidden Burden

The project's maintenance status is the biggest cost factor. The last push was in 2019, and the only tagged release is from that year. The README lists a development team with roles dated 2024, but the repository shows no code changes since 2019. That suggests the project's actual development happens elsewhere, possibly in a private repository, and the GitHub project is a mirror or an archive. If that is the case, you are not getting the latest code from this repository. You would have to contact the team for access to the current version. That is a serious maintenance risk. Upgrades will not come through GitHub. You will depend on the vendor's commercial support, which the README mentions: 'Commercial Support: Available for installations, training, and maintenance.' That support is not free, and its availability outside Sri Lanka is unstated. The upgrade cost is not just code changes; it is vendor dependency. For an open source project, that is a high price.

Editorial conclusion

Adopt CareCode HMIS if you operate a clinic or hospital in Sri Lanka, need a Java EE system with EMR, pharmacy, and payroll modules already in use by local institutions, and can tolerate a project whose default branch is 'development' and whose only tagged release is from 2019. Do not adopt it if you need a stable, actively released product, a clear license, or modern front-end architecture. Before committing, verify the actual license in LICENSE.md, check whether the development branch builds with your Java EE server and MySQL version, and confirm that the claimed version 3.0.0.20240813.1 corresponds to any tag or branch you can deploy. The project's strength is its institutional history, not its release discipline.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes