OpenMRS vs Bahmni: which to choose

OpenMRS or Bahmni: which should you start from?

If you are choosing a medical record foundation for a clinic, hospital or program, the first question is scope. OpenMRS is the platform layer, a patient-based medical record system designed for resource-constrained environments, while Bahmni is a bundled hospital system built on it, combining OpenMRS with OpenELIS for laboratory, Odoo for billing, inventory and accounting, and dcm4chee with a PACS integration service for imaging. Choose plain OpenMRS when you need the clinical record and want to assemble the surrounding systems yourself, or when your team already has Java and OpenMRS module skills to build the rest. Choose Bahmni when a hospital needs lab, billing and imaging working together from the first release and prefers a tested integration over custom build.

The decision turns on three questions. First, are lab, billing and imaging in scope on day one? Bahmni Lite covers the EMR with lab services, billing through Crater and appointments, while Bahmni Standard adds OpenELIS, Odoo 16 and dcm4chee. Ask which of those components your sites must run at launch and which can follow later. Second, how much custom build can your team own? Plain OpenMRS leaves integration, interface work and upgrades of each added system with you, so count the developers you can commit over the life of the stack. Third, who governs the stack? OpenMRS Inc. is a 501(c)(3) nonprofit supporting the project with the volunteer community and implementer organizations, and Bahmni is managed by the Bahmni Coalition. Ask each vendor and implementer who signs off on upgrades and who supports the bundled components.

Which scenarios favor OpenMRS and which favor Bahmni

This table maps common deployment situations to the platform that usually fits better, and states the condition that tips the choice. Read each row as a starting point: the deciding factor is usually who will build and support the clinical modules, and whether lab, billing and imaging are needed on day one.

Scenario	Better fit	Condition that makes it so
A single clinic that needs only a patient record	OpenMRS	Plain OpenMRS covers registration and clinical records, and a small site avoids running lab, billing and imaging components it will not use. Confirm that any billing or lab workflow is handled outside the system.
A hospital that needs lab and billing from the start	Bahmni	Bahmni Standard adds OpenELIS for the laboratory, Odoo 16 for billing, inventory and accounting, and dcm4chee for imaging. Confirm that these bundled components meet local requirements before committing.
A program building its own clinical modules	OpenMRS	Plain OpenMRS exposes the platform, SDK and module model directly, so a team can build and version its own modules. Bahmni's bundled stack adds layers that the program must also understand and maintain.
A site with an existing OpenMRS 2.x implementation	OpenMRS	Staying on the 2.x platform or planning a move to O3 is a migration decision, not a Bahmni decision. Adopting Bahmni means reviewing how its configuration and bundled services would be introduced to live data.
A low-resource site that wants a quick pilot	Bahmni	Bahmni Lite offers a Docker Compose stack with a stable tagged image, which can shorten the first install. Confirm hardware, network and staff skills against the stack before deciding.
A team that wants only the Bahmni clinical frontend	Either, depending on scope	The Bahmni EMR frontend is an MPL 2.0 module on OpenMRS. Confirm whether the team needs the full Bahmni configuration or only selected components before choosing.
A program that must limit the number of moving parts	OpenMRS	Fewer bundled services mean fewer components to patch, back up and monitor. This advantage holds only if the program can supply its own lab, billing and reporting integrations.
A network that expects to grow into multi-service hospital operations	Bahmni	Bundled lab, billing and imaging services reduce the number of separate projects needed at the outset. Confirm that the bundled versions will be supported through the planned operating period.

How OpenMRS and Bahmni are built and deployed

OpenMRS is a platform you assemble and run yourself, while Bahmni is a packaged hospital stack built on OpenMRS with more components to operate. The cards below cover what each deployment option contains, and what that means for upgrades, hosting footprint and who maintains each part.

OpenMRS as a Java platform

The OpenMRS core is written in Java, built with Maven, and runs on Tomcat or Jetty. You choose the database from MySQL, MariaDB or PostgreSQL, so your DBA team, backup tooling and hosting standards apply from the start. Confirm which Java and servlet container versions your target release expects before you size the host, and confirm that your chosen database is supported for the release you plan to run.

Four ways to get OpenMRS

OpenMRS ships as a Standalone package with an embedded database, an SDK for module development, the O3 Reference Application container stack, or a WAR file for Tomcat with an existing MySQL database. The Standalone package suits evaluation, the SDK suits teams building modules, and the WAR file suits teams that already run Tomcat. Pick the form that matches your staff skills before you pick a version, because switching packaging later means re-testing your modules and deployment scripts.

Bahmni Lite as a Compose stack

Bahmni Lite runs as a Docker Compose stack that brings together OpenMRS, the Bahmni web and apps frontends, a Bahmni Lab service, appointments, patient documents, reports and Crater for billing. Metabase, Bahmni Mart, SMS and SNOMED Snowstorm Lite are optional profiles you enable only when needed. The bahmni-docker .env file pins the 1.0.0 image tag for Lite, so check whether that tag still matches your validated release before you deploy.

Bahmni Standard adds three systems

Bahmni Standard adds OpenELIS for the laboratory, Odoo 16 with a connector for billing, inventory and accounting, and dcm4chee with a PACS integration service for imaging, on top of the OpenMRS-based EMR. Each addition has its own database, release cycle and configuration. Ask the Bahmni community or your implementer which Odoo and dcm4chee versions are validated with your Bahmni release, and who applies their security patches.

Upgrades touch more components

With plain OpenMRS, an upgrade covers the core, the modules you installed and your own configuration. With Bahmni, the same work extends to the frontends, the Lab service and each added system, and the pieces must move together. Bahmni's EMR frontend, openmrs-module-bahmniapps, is licensed under the MPL 2.0 and is a separate repository you should track. Plan a test environment that mirrors the full stack, and budget for regression testing across every component.

Who maintains each component

In plain OpenMRS, your team or implementer owns the platform, modules and database, with OpenMRS Inc. providing fiscal and legal foundation and the community supplying the code. In Bahmni, the Bahmni Coalition manages the project, and each bundled system keeps its own upstream community. Confirm in writing which parts your implementer patches, which parts you patch yourself, and who answers when an upstream component ships a security fix.

What Bahmni adds on top of OpenMRS and what you take on with it

Bahmni adds four capabilities that plain OpenMRS does not ship with: a laboratory system, billing and inventory, imaging, and a bundled clinical frontend. In the Bahmni Standard stack, OpenELIS handles laboratory management, Odoo 16 with an Odoo connector covers billing, inventory and accounting, and dcm4chee with a PACS integration service handles imaging, all on top of the OpenMRS-based EMR. Bahmni Lite replaces the Odoo layer with Crater for billing and omits OpenELIS and dcm4chee, so its scope is narrower. Before you choose, map each function your facility needs (lab orders and results, charging, stock, imaging workflows) to one of these components and confirm whether a Lite deployment covers it or whether you need the Standard stack. The Bahmni project lists the component set in its docker-compose files, which is the right starting point for that check.

Every added component is another system to patch, back up, integrate and train staff on. Each one has its own database, upgrade path and failure modes, and each boundary between them, such as the lab-to-EMR result feed, the Odoo connector or the PACS integration service, is an interface that can break silently after an upgrade. The stack is only as easy to operate as its weakest part. A practical test is to ask who will own each component after go-live, how restores are rehearsed across all the databases together, and which version combinations have been tested as a unit. Bahmni publishes Docker Compose setups as a starting point, but production hardening, backup design and integration testing are your responsibility or your implementer's, and should be written into the scope and quote.

Starting from plain OpenMRS means you only operate the systems you choose to add, which is often the better fit for a team with limited operations capacity or a single, well-defined clinical workflow. You can add an external laboratory or billing system later through the FHIR2 and integration interfaces, at the cost of building and maintaining that integration yourself. Bahmni is the better starting point when you need an integrated package across clinical, lab, billing and imaging from the outset and have the staff to run it. In either case, ask your implementer to show a restore test that covers the full stack and a written upgrade plan for every component before committing to a configuration.

How the two platforms compare on fit, identity and extensibility

This table sets plain OpenMRS against the Bahmni distribution on scope, FHIR, identity, frontend and database choices, so you can see what Bahmni already supplies and what you would build yourself. Read each row as a question to answer in your own environment, because several capabilities depend on the modules and stack you choose.

Capability	OpenMRS (platform)	Bahmni (distribution)
Scope out of the box	Patient-based medical record platform for resource-constrained settings; lab, billing and imaging come from modules or other systems you select	Bundles OpenMRS with OpenELIS for lab, Crater billing in Lite, Odoo 16 for billing, inventory and accounting in Standard, and dcm4chee for imaging in Standard
FHIR support	FHIR2 module provides the FHIR REST API, focused on FHIR R4 with translation support for R3; confirm the module version and resources your use case needs	Built on OpenMRS, so FHIR depends on the OpenMRS modules included in the chosen stack; confirm the FHIR endpoints exposed in your Lite or Standard build
SMART on FHIR and OAuth2	openmrs-module-smartonfhir supports the SMART App Launch Framework with FHIR2 and uses Keycloak as the default authorization server; OAuth2 Login module replaces basic authentication with an OAuth 2.0 provider	Inherits OpenMRS identity options; whether SMART and OAuth2 modules are enabled in your configuration is a question to confirm with the Bahmni configuration you deploy
Frontend	O3 is a micro-frontend user interface in the 3.x Reference Application; 2.x uses the legacy interface	Bahmni EMR frontend (openmrs-module-bahmniapps) is written in AngularJS and React, licensed under MPL 2.0; confirm how it aligns with your O3 plans
Database options	Core supports MySQL, MariaDB and PostgreSQL; the O3 Docker setup uses MariaDB	Docker Compose setups use the OpenMRS database stack provided in the bahmni-docker configuration; confirm any change to the database layer with the Bahmni Coalition or your implementer
What must be built or integrated	Lab, billing, pharmacy, imaging and any national reporting links are typically built or integrated by your team or implementer	Lab, billing and imaging are included in Standard, but you still integrate with national systems, identity providers and any custom forms; confirm the scope with your implementer

What the licenses and editions mean for each platform

The OpenMRS core is released under the Mozilla Public License 2.0 and carries a Healthcare Disclaimer, with copyright held by OpenMRS Inc. The openmrs-core repository is the place to read the license and disclaimer text in full, and your legal and clinical governance teams should review both before you deploy.

Copyright holder: OpenMRS Inc. holds the copyright listed in the core repository and operates as a 501(c)(3) nonprofit.
Fiscal and legal foundation: OpenMRS Inc. supplies the fiscal and legal base and infrastructure for the project, which is separate from the code you run.
Volunteer community: Much of the development comes from volunteers, so release timing and feature priorities depend on community capacity and contributions.
Implementer organizations: Firms that customize and deploy OpenMRS are separate parties, and their own contracts set the support, hosting and warranty terms you receive.
Healthcare Disclaimer: The disclaimer shapes how responsibility for clinical use is allocated, so confirm its effect on your organization's risk acceptance.

Confirm with your counsel what file-level obligations MPL 2.0 places on any modifications you make, and check whether your chosen implementer has any commercial terms attached to the platform.

How governance and the implementer community affect your long-term risk

Governance decides who sets your direction and who is accountable when a component needs a fix, so check it before you choose. OpenMRS Inc. is a 501(c)(3) nonprofit that provides the fiscal and legal foundation for the project, while the volunteer community and implementer organizations build, customize and deploy the platform. Plain OpenMRS therefore has many independent implementers and no single company that owns the roadmap. That spreads influence across the ecosystem, but it also means no one party is obligated to you by default. Bahmni is structured differently. It is an open-source project managed by the Bahmni Coalition, which SNOMED International has joined. Coalition membership signals a wider group of stakeholders, but on its own it does not tell you who commits to patch timing or how long a release stays supported.

The distribution you pick ties your roadmap to a bundle's release cycle. Bahmni Lite and Bahmni Standard are published as Docker Compose setups that combine OpenMRS with other components, such as Odoo 16 for billing and OpenELIS for the laboratory in Standard, so a Bahmni release moves those parts together. You gain a stack assembled for you, but if you need a newer OpenMRS core fix or a change to one bundled component, you wait for the next combined release or carry that change yourself. Plain OpenMRS runs on its own track. The latest Platform is 2.8.1 and the latest O3 Reference Application is 3.7.1, so you can plan core and frontend upgrades separately. Illustrative: a clinic that needs a laboratory change may find the fix sits in a component whose version the bundle locks, which turns a small upgrade into a whole-stack decision.

Before you decide, get the following in writing: the release cadence for each component you would run, the support window for each version, and the named maintainers or paid parties who commit to security fixes. Ask Bahmni how long the 1.0.0 tag referenced in the bahmni-docker .env file will receive updates, and which OpenMRS core versions each Bahmni release tracks. Ask any implementer you hire the same questions for the parts it customizes, because those changes become your maintenance burden. Finally, ask how you would exit: whether you can move data and configuration from a bundle to plain OpenMRS without re-keying patient records. The written answers to these questions will shape your long-term risk more than the governance structure alone.

What drives running cost for each stack

Infrastructure cost follows the number of hosts, the database engine and the storage each stack needs. Plain OpenMRS is a Java application that runs on Tomcat or Jetty with MySQL, MariaDB or PostgreSQL, so its footprint depends on the application server, the database and the number of environments you keep. Bahmni Standard adds more services on the same hosts or on additional ones, and its sizing depends on laboratory and imaging load.

Application tier: OpenMRS runs on Tomcat or Jetty, while Bahmni packages its services into Docker Compose stacks that you host yourself.
Database: Plain OpenMRS supports MySQL, MariaDB and PostgreSQL. Confirm which database engines a proposed Bahmni build uses and whether your support plan covers them.
Imaging storage: The dcm4chee service in Bahmni Standard stores images, so storage grows with study volume.
Environments: Each test, staging and production copy repeats the full stack, which multiplies hardware for Bahmni faster than for a plain OpenMRS deployment.
Hosting location: Cloud, data center and air-gapped hosting change the bill mostly through staffing, backup and patching effort rather than through the software license itself.

Check the sizing assumptions in any quote against your expected patient volume, study volume and number of environments.

How to move from plain OpenMRS to Bahmni, or back, without losing data

This sequence moves patient and encounter data between a plain OpenMRS deployment and a Bahmni stack in a controlled order, so each step ends with a verified output before the next one starts. Patient records and core clinical data carry over, while custom modules, lab interfaces and billing connectors are rebuilt and tested against the target system.

Inventory the data model and installed modules
Start by listing everything the current system holds: concepts, forms, encounter types, observation types, patient identifiers, user roles, installed OpenMRS modules and any custom code or database changes. Your clinical informatics lead and the implementing developer should own this together, because module-level differences decide what a Bahmni target can accept without rework. Confirm the exact OpenMRS platform version and database engine (MySQL, MariaDB or PostgreSQL) from the running instance. The step is done when you have a written inventory that a second person has reviewed and that names every item as carried over, replaced or retired.
Decide which Bahmni components replace local tools
Compare each local tool in the inventory against the Bahmni component that would take its place. Bahmni Lite bundles OpenMRS with the Bahmni web and apps frontends, a Bahmni Lab service, appointments, patient documents, reports and Crater for billing. Bahmni Standard adds OpenELIS for the laboratory, Odoo 16 with a connector for billing, inventory and accounting, and dcm4chee with a PACS integration service for imaging. Mark any local tool that has no equivalent, since it will need an interface or a retained system. The step closes with a signed-off mapping table that states which Lite or Standard components you will run and which existing systems stay in place.
Map patient and encounter data to the target model
Build a field-level mapping from the source patient identifiers, person attributes, encounters, obs and orders to the target OpenMRS concepts and encounter types used by the Bahmni configuration. Concept dictionaries often differ between sites, so map to a shared dictionary and record every unmapped code with an owner. Run the mapping against an anonymized extract, and count records per encounter type on both sides. The step is complete when source and target counts reconcile for each mapped type and every unmapped concept has a documented decision, such as a new concept, a free-text value or a deliberate exclusion.
Rebuild forms, reports and integrations
Custom forms, reports and interfaces do not move automatically between the two stacks, so rebuild them on the target. For plain OpenMRS forms, check whether the O3 form schema route applies, since a community tool exists for migrating legacy HTML forms to that schema. Rebuild lab and billing interfaces against the components you chose in step two, and test each message path with sample data. Custom modules that depend on OpenMRS APIs must be re-verified against the target version before they are reinstalled. The step closes when each rebuilt form, report and interface has a test case with recorded expected output.
Run parallel validation with real workflows
Run the source and target side by side for a defined set of clinical and administrative workflows, such as registration, admission, a lab order and result, a billing event and a discharge. Staff enter the same test scenarios in both systems, and the implementation team compares outputs, including identifiers, timestamps, concept values and billing totals. Log every discrepancy with a severity and an owner, and retest after each fix. The step is done when no open discrepancy blocks a workflow and the clinical lead signs off on the results in writing.
Cut over and freeze the source
Schedule the cutover with a written rollback plan that states the point after which the source is read only and who can authorize reverting. Take a verified backup of the source database and the target database before the final data load, and run the final incremental extract and load with reconciliation counts. Confirm that users can log in, that identifiers resolve and that interfaces send and receive test messages. The step closes when the reconciliation report matches the freeze point and the operations owner confirms the target as the system of record.
Retire the old systems and keep the evidence
Once the target has run in production for a period you agree in writing with clinical leadership, decommission the source. Before deletion, archive the source database, configuration, module list, mapping tables and validation records, and confirm that the archive can be restored and read. Remove access, revoke service accounts and update the asset inventory and backup policy. The step is complete when the archive has been restore-tested and the decommissioning record is signed by the data owner.

Where OpenMRS and Bahmni implementations usually run long

The schedule risk in most OpenMRS and Bahmni projects sits in decisions made early and reopened late. Form and workflow design is the first place time disappears: admission, triage, lab ordering and discharge each need clinical sign-off, and every change to a form has to be re-tested against the workflow it supports. Bahmni adds more surfaces to agree on, because a single patient journey can touch the EMR, the Bahmni Lab service, appointments and billing. Ask the implementer to list every form and workflow in scope before build starts, and to name the clinical owner who signs each one off.

Integration and identity tend to take longer than teams expect. In Bahmni Standard, the EMR has to hand orders and results to OpenELIS, billing to Odoo 16 through its connector, and imaging to dcm4chee through the PACS integration service, and each handover needs its own test data and error handling. On the access side, the OpenMRS OAuth2 Login module replaces basic authentication with an OAuth 2.0 provider, and the SMART on FHIR module defaults to Keycloak. Settling which identity provider, which roles map to which OpenMRS privileges, and who runs the realm before go-live is a decision your own identity team must make, not something to defer to the build phase. Data migration from legacy registers or other systems is the third common delay, since patient identifiers and duplicate records are rarely clean.

A fixed scope agreed in writing limits drift because every addition becomes a visible change order against named deliverables, with its own timeline and cost. It does not remove the work your staff must do. Your clinical leads have to approve forms and test scripts on time, your data owners have to resolve identifier conflicts, and your team has to release staff for clinician training, which usually runs close to go-live and is often the last thing to finish. Ask any implementer to show how scope changes are recorded, who approves them on your side, and how many staff hours each phase assumes from your organization, and confirm those commitments in the statement of work before signing.

Questions buyers ask before choosing OpenMRS or Bahmni

Is Bahmni more work to run than plain OpenMRS?

Usually yes, because Bahmni runs more systems. Bahmni combines OpenMRS with OpenELIS for the laboratory, Odoo for billing, inventory and accounting, and dcm4chee for imaging in its Standard configuration, according to the bahmni-docker compose files. Each added service has its own database, upgrade path, backup routine and failure modes. Plain OpenMRS leaves you with one core platform plus whichever modules and front end you choose, so the operating surface is smaller. The trade-off is that you assemble and integrate the clinical, lab and billing workflows yourself, which is work that Bahmni has already done. Ask any vendor or implementer to list every running service, its database and its upgrade cadence before you compare effort.

Can our own IT team run Bahmni without outside help?

It can, if your team has Docker or Linux administration skills, a plan for backups and someone who can read Java and application logs when a module fails. The Bahmni/bahmni-docker repository provides Docker Compose setups for Bahmni Lite and Bahmni Standard, so the first deployment is not a blank-sheet build. Day-two work is different. You will need to own upgrades across several components, clinical configuration changes, user and role management and integration testing with the lab and billing services. Small teams often find that the lab and billing components need the most attention. Decide early whether your staff will own this, whether a partner will support it under a retainer, or whether a mix of both fits your risk tolerance.

What work still needs local clinical and technical staff?

Several parts of the work depend on people who know your site, regardless of platform. Clinical leads must define forms, workflows, concept dictionaries and reporting needs, because no platform can infer how your clinics actually operate. Local staff also own data quality decisions, such as how legacy patient identifiers are mapped and which records are merged. Technically, someone must hold credentials, approve changes, manage backups and respond to incidents on your network. Bahmni reduces some of the clinical design work because its workflows are already defined, but local adaptation is still needed. Ask who on your side signs off on each of these tasks before the work is scoped.

How long does migrating an existing record system take?

Migration length depends on data volume, data quality, the number of sites and how many workflows must change at once. The supplied facts do not give a migration duration, so treat any single figure from a vendor with caution and ask for the assumptions behind it. Start by inventorying the source system, its data model, its custom fields and its interfaces to labs and billing. Then plan a mapping exercise, a test migration, clinical user acceptance testing and a cut-over window with a rollback path. Moving to Bahmni may add lab and billing migration work on top of the record migration. Ask for the planned phases, the data each phase covers and the exit criteria for each one.

Is Bahmni Lite enough for a pilot?

Lite can be enough for a pilot that focuses on clinical records, appointments and basic reporting, because its Docker Compose stack includes OpenMRS, the Bahmni web and apps frontends, a Bahmni Lab service, appointments, patient documents, reports and Crater for billing. The bahmni-docker .env file points to the 1.0.0 image tag as the stable, tested version of Bahmni Lite v1.0.0. A pilot that must integrate with an existing dcm4chee PACS, a full OpenELIS laboratory or an Odoo accounting back end needs the Standard stack. Define the pilot's success criteria first, then check which services those criteria depend on. Confirm with the Bahmni community which image tags are current before you commit.

What should we confirm before signing an implementation contract?

Confirm the written scope, the deliverables, the timeline and the responsibilities on each side before work begins. Ask which Bahmni or OpenMRS versions the work targets, which services are in scope, and whether lab, billing and imaging integrations are included or only planned. Check how upgrades, backups, monitoring and incident response are handled after go-live, and whether those are covered by a retainer. Ask who owns the source changes you fund, how documentation is delivered and what exit support looks like if you change partners. Also confirm how data protection and access control are designed for your jurisdiction, and which compliance evidence you will receive. DeployOpen plans and implements in the client's own infrastructure and prepares evidence for assessments, but independent auditors issue any attestations.

Does Bahmni's licensing create obligations we should review?

The Bahmni EMR frontend, openmrs-module-bahmniapps, is licensed under the MPL 2.0, and OpenMRS core is also released under the MPL 2.0 with a Healthcare Disclaimer. MPL 2.0 is a file-level copyleft license, so changes to MPL-covered files generally must be shared under the same license, while your own separate code can usually remain under other terms. The bundled services, such as OpenELIS, Odoo and dcm4chee, carry their own licenses, which you should review individually. Ask counsel to map each component and its license before deployment. This is a general description, not legal advice, and your legal team should confirm the obligations for your use.

How DeployOpen helps you choose, implement or migrate

DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For OpenMRS vs Bahmni, we start by writing down which stack your sites actually need, then build and hand over only what that scope requires.

How we scope

Written scope that states whether plain OpenMRS, Bahmni Lite or Bahmni Standard fits your clinical and lab workflows
Inventory of required integrations such as laboratory, billing, imaging and identity systems before any build work starts
Agreed deliverables and timelines in writing, since most engagements are fixed-scope
Confirmed hosting target, whether cloud accounts, data center or air-gapped network, and the data residency rules that apply

How we build

Deployment of the chosen OpenMRS or Bahmni configuration inside your environment with Docker Compose or Tomcat as scoped
Customization of forms, modules and identity integration, such as OAuth 2.0 login, as defined in the written scope
Testing of clinical workflows, backups and restores, and security hardening against the agreed acceptance criteria
Documentation of configuration, data flows and control evidence that your compliance assessors can review

How we hand over

Runbooks covering installation, upgrades, backup schedules and recovery steps for your operations team
Knowledge transfer sessions so your staff can administer the platform without depending on us
Clear record of which components are Bahmni-maintained and which are OpenMRS modules you will need to track
Written list of open items and the decisions your governance group still needs to make

How we support

Ongoing support, upgrades and continuous testing available as a retainer after handover
Review of OpenMRS and Bahmni release notes before each upgrade, scoped in the retainer
Coordination with your independent auditors or certification bodies, since DeployOpen prepares evidence but does not issue attestations
Quote based on your written scope, with no published price list, so you can compare the cost of support against in-house effort

OpenMRS vs Bahmni