Marley Health: a hospital information system built as a Frappe app

A health domain added to ERPNext, not a hospital in a box

Marley Health is described as an open source and easy-to-use hospital information system for all healthcare organisations, and the readme calls it an open source and easy-to-use hospital information system, a HIS, for healthcare organisations.

The mechanism is the important part. Marley Health enables the health domain in ERPNext and is built on Frappe, described as a full-stack, meta-data driven web framework, and it integrates with ERPNext, which the readme calls the most agile ERP software. The product is the health domain, and the ERP is the platform.

That framing tells you what you are adopting. A standalone hospital information system has to implement patient registration, scheduling, billing, inventory, staff and reporting itself. Marley Health sits on a base that already has purchasing, stock, human resources, accounting and asset management, and adds the clinical layer: patients, outpatient and inpatient episodes, procedures, rehabilitation, laboratory work and the medical code sets.

The design is based on HL7 FHIR, Fast Health Interoperability Resources, for most of what it does, which is the right foundation for a system that has to exchange records with other healthcare software, and the topical tags on the repository reflect the same emphasis with ehr, emr, erp, erpnext, hims, hmis and opd.

The audience is healthcare organisations, from clinics to hospitals, and the readme points at both a hosted instance on Frappe Cloud and a self-hosted path.

The clinical feature set and the code standards it supports

The key feature sets named in the readme cover the clinical core: patient management, outpatient and inpatient management, clinical procedures, rehabilitation and physiotherapy, and laboratory management.

What sits underneath that is a configurability story, and this is where a hospital system earns its keep. The application supports configuring multiple medical code standards, which is how a deployment encodes the coding scheme its regulators and insurers expect. It also allows mapping any healthcare facility as service units and specialities as medical departments, which is the mechanism by which a hospital with several buildings or wards appears in the system as a set of units rather than one undifferentiated location.

Those two capabilities are what make the same code usable across sites, and they are also the source of most of the configuration work an adopter takes on. The design is data driven in the Frappe sense, so the shape of a deployment is defined in doctypes, and the cost of getting it right is proportional to how unusual your hospital is.

The clinical modules are also the part with the strictest data handling requirements, and the readme does not discuss compliance, audit or data residency. That is not a criticism of the code, it is a description of the documentation, and for an evaluation it means these questions have to be asked directly rather than assumed from the presence of a feature list.

What you inherit from ERPNext, and the patient portal

The readme is explicit that integrating with ERPNext means the features of ERPNext can also be used, and it lists them: managing pharmacy and supplies, purchases, human resources, accounts and finance, asset management, and quality.

That list is the strongest argument for the project, because each of those is a department that every hospital needs and that most clinical systems either ignore or integrate with badly. A pharmacy needs stock and a reorder process, a hospital needs a chart of accounts, equipment needs asset management, and a quality system needs incident and audit trails. Taking them from the ERP means the clinical module and the back office speak the same data model.

On top of the ERP and the clinical features, the readme lists the platform characteristics: authentication and role based access permissions, RESTfulness, extensibility and responsiveness, along with setting up a website, payment integration and a patient portal.

The patient portal is worth calling out as a separate piece of engineering rather than a feature. The repository has a patient_portal directory at the top level, and the JavaScript manifest treats it as a workspace alongside frappe-ui, with its own install, build and test scripts, and it is a Vue application built with Vite and Tailwind. A patient facing portal has different requirements from an internal clinical tool, different security assumptions and a different release rhythm, and the fact that it is a workspace of its own rather than a Frappe page is a sign the authors thought about that.

Installation through bench, in three commands

The install path assumes you are already running Frappe through bench, and the readme says so: using bench, install ERPNext, with a link to the bench installation instructions.

Once ERPNext is installed, the health app is added to the bench.

$ bench get-app healthcare

And the app is then installed on the specific site you want it on.

$ bench --site demo.com install-app healthcare

That three step sequence is the whole of the documented installation, and it is worth reading for what it implies. The health app is a Frappe app distributed through the bench workflow, not a standalone service you can run with a command, and the second command is where a site's data model is created, which is why the readme and the project both talk about a demo site in their examples.

For the JavaScript side, the manifest wires the portal build into the same repository.

    "scripts": {
        "postinstall": "cd patient_portal && yarn install --check-files",
        "build": "cd patient_portal && yarn build",
        "test": "cd patient_portal && yarn test"
    },

The portal is built with Vite, the Vue plugin, PostCSS and Tailwind, and the workspace also includes frappe-ui, which is the shared component library for Frappe front ends.

The complete documentation is at marleyhealth.io/docs, and there is a hosted instance reachable through Frappe Cloud, which is the fastest way to see the product before you have a bench of your own.

Inside the repository: a Frappe app, a Vue portal and a lot of tooling

The layout shows a full application rather than a library, and the parts worth knowing about are the ones that describe how the project is maintained.

The healthcare directory holds the Frappe application itself, and the patient_portal directory holds the Vue front end. Around them sit the files that say how the work is done: a .prettierrc.yaml for formatting, a .releaserc for the release configuration, commitlint.config.js with a commit message convention, a .mergify.yml for merge automation, a crowdin.yml for translations, codecov.yml for coverage, a .pre-commit-config.yaml and a dev-requirements.txt for the development tooling.

The Python side is configured in pyproject.toml, and two details there are practical rather than cosmetic. The build backend is flit_core, and the version is dynamic, which means it is derived rather than written by hand. The dependencies are short, with responses for HTTP mocking in tests and python-barcode for the barcodes a pharmacy and specimen workflow need.

The lint configuration is unusually explicit for a Frappe app. Ruff runs with a line length of 110 against Python 3.10, and the selected rules include F, E, W, I, UP, B and RUF, with a long list of individual ignores, each carrying a comment explaining it, from the assertRaises rule to the tab indentation rule. The isort configuration declares custom sections for frappe, erpnext and healthcare, which is how a project with three tightly related import roots keeps its import order stable.

There is also a bench-specific dependency section, which is how the app declares the Frappe version it expects.

Where Marley Health is the wrong choice

Four limits, and they all follow from the decision to build on ERPNext.

The first is the coupling. Adopting Marley Health means adopting ERPNext, Frappe and bench, with the database and site management that a Frappe deployment brings, and the manifest declares a minimum Frappe version. A hospital that has already standardised on something else cannot use the clinical module on its own, and even a new installation has to accept the whole stack rather than a component.

The second is the upgrade path. Because the clinical app and the ERP share a doctype model, a customisation that assumes a particular Frappe or ERPNext version is a liability on the next upgrade, and the readme does not describe a compatibility policy for customised sites. In a system that holds clinical records, a failed upgrade is a serious event rather than an inconvenience.

The third is the scope of the clinical feature set as described. Patient management, outpatient and inpatient management, procedures, rehabilitation and laboratory management is a solid starting point, and it is also the start of a longer list that any given hospital will have, from imaging and pharmacy dispensing to insurance claims and national reporting formats. The architecture supports extending that with custom doctypes, but the work is yours.

The fourth is that the documentation is thin on the parts that matter for a hospital. The readme does not cover the audit trail, the data residency options, the access control model in detail, or the patient record export. Those are questions to ask the maintainers rather than gaps to be filled by reading the code.

Licence, releases and the state of the project

The licence is GNU GPL V3, stated in the readme with a link to the license.txt file in the develop branch, so the code can be used, modified and redistributed with the notice kept and the derived work kept under the same licence. That is a stronger copyleft than many clinical deployments want for their customisations, and it is worth a legal review before you build on it. This is not legal advice.

The release history shows active work. Version 16.6.0 was published on 2026-09-19, 16.6.1 on 2026-09-22, and there is an assets-develop tag dated 2026-10-05 for the assets used by the develop branch. The last push was on 2026-10-22 and the repository is not archived. The default branch is develop rather than master, which is the Frappe convention, since the app is developed against the develop branch of the framework.

The provenance is worth noting as well. The repository is earthians/marley, but the readme points at the Frappe Healthcare logo and the health app is fetched with bench get-app healthcare, so the app is distributed under the healthcare name and this repository is the home of the front end and the build tooling around it. The organisation behind it is earthians Health Informatics Pvt. Ltd., and the project is also offered hosted through Frappe Cloud, with a signup link in the readme.

For an evaluation, the practical order is: sign up for the hosted instance to see the clinical screens, read the documentation site, then build a bench and install ERPNext and the health app to see what a real deployment of it involves.

Editorial conclusion

Marley Health is the right tool for a clinic or hospital that already runs on ERPNext, or that wants an ERP with a clinical module rather than a standalone hospital system, since the accounting, inventory and human resources layers come with it. It is the wrong choice for an organisation that has decided against ERPNext, for a workload whose requirements are covered by a specialised clinical product, and for a deployment where the coupling to a specific Frappe version is a problem. Before adopting, install it with bench on a scratch site and check the clinical screens against your own workflows, and read the tool.bench.frappe-dependencies section, because the Frappe version floor in the manifest decides whether your environment is compatible.

Frequently asked questions

Official sources

1. earthians/marley on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases