Which Bahmni Docker configuration fits a clinic and which fits a hospital
Choose Bahmni Lite when a clinic or small inpatient setting needs an EMR with a light lab and Crater billing. Choose Bahmni Standard when a hospital needs a full laboratory workflow, back-office billing, inventory and accounting, and PACS imaging in the same deployment. The two configurations come from the bahmni-docker repository, and the supplied facts describe them as two Docker Compose setups. They do not describe two licensed commercial editions, so this is a choice about which services you run, not which tier you buy.
Lite runs OpenMRS, the Bahmni web and apps frontends, a Bahmni Lab service, appointments, patient documents, reports and Crater for billing. Optional profiles add Metabase, Bahmni Mart, SMS and SNOMED Snowstorm Lite. This suits outpatient work and small inpatient wards where lab tests are limited and billing can stay inside Crater. Standard adds OpenELIS for the laboratory, Odoo 16 with an Odoo connector for billing, inventory and accounting, and dcm4chee with a PACS integration service for imaging. Choose Standard if you need a full lab workflow, an accounting system of record, or radiology images stored and viewed through PACS. Each added service is one more database, upgrade path and set of credentials your team must operate.
Before you commit, confirm with the Bahmni Coalition or an experienced implementer whether any commercial distribution, paid support tier or certified configuration exists for either setup. The supplied facts do not establish one. Also list which services your site will actually use on day one, check the bahmni-docker README for the current stable tag for each configuration, and write down who will own patching and backups for each container. Those answers, not the headline feature list, usually decide which configuration is right.
What Lite includes and what Standard adds
This table compares the services in the Bahmni Lite and Bahmni Standard Docker Compose stacks, row by row. Read the change type column first: an addition means Standard runs a service that Lite does not, while a component swap means one tool takes over the job of another. The main takeaway is that the workflow each row supports decides whether a difference matters to your site.
| Capability | Bahmni Lite | Bahmni Standard | Change type |
|---|---|---|---|
| OpenMRS-based EMR | Included as the core medical record | Included as the core medical record | Same in both |
| Bahmni web and apps frontends | Included | Included | Same in both |
| Bahmni Lab service | Included as the lab service | Confirm whether it runs alongside OpenELIS | Component swap, confirm in compose file |
| Appointments, patient documents and reports | Included | Included | Same in both |
| Billing | Crater for clinic billing | Odoo 16 with Odoo connector for billing, inventory and accounting | Component swap |
| Laboratory system | Light lab through Bahmni Lab service | OpenELIS for laboratory management | Addition in Standard |
| Imaging and PACS | Not in the Lite stack | dcm4chee with PACS integration service | Addition in Standard |
| Optional profiles | Metabase, Bahmni Mart, SMS, SNOMED Snowstorm Lite | Confirm which profiles the Standard file exposes | Confirm before planning |
Which setting suits Lite and which suits Standard
An outpatient clinic that sees patients for consultations, follow-ups and routine visits usually needs registration, appointments, clinical notes, simple billing and reports. Lite covers that footprint with OpenMRS, the Bahmni web and apps frontends, appointments, patient documents and reports, with Crater handling billing. Fewer components means fewer services to back up, patch and monitor, which matters most when the clinic has no dedicated infrastructure staff.
- Fewer services to run: Lite's Compose stack does not include OpenELIS, Odoo or dcm4chee, so there are fewer databases, upgrade paths and integration points to test.
- Billing stays lightweight: Crater covers clinic invoicing. Confirm that it produces the receipts, tax handling and reports your local rules require.
- Optional add-ons stay optional: Metabase, SMS and SNOMED Snowstorm Lite are optional profiles you can enable later, so you can start small.
- Fair case for Standard: a clinic that expects to add deeper accounting, inventory or finance controls early may prefer Standard's Odoo 16 connector, accepting a heavier stack.
Before choosing Lite, check that Crater meets the clinic's billing, reporting and data export needs, and write down the migration path in case they do not.
A clinic that runs a small in-house lab, such as point-of-care tests or a limited set of routine analyses, still has to record orders and results against the patient record. Lite includes a Bahmni Lab service inside the OpenMRS-based EMR, so simple laboratory workflows can stay in one system. Whether that is enough depends on the test menu, the instruments connected to the lab and how results must be reviewed and reported.
- Lab workflow inside the EMR: the Bahmni Lab service handles orders and results within the core record. Test it against your actual test menu before committing.
- No separate laboratory system: Lite avoids a second application with its own users, backups and interfaces, which keeps the operating load down for a small team.
- Instrument interfacing is the gate: if analyzers, quality control or result validation rules are part of daily work, compare them against OpenELIS, which is included only in Standard.
- Fair case for Standard: a lab that expects its test menu or formal review steps to grow may want OpenELIS from the start, so the move does not happen later under operational load.
Ask the lab lead to walk through a full order-to-result cycle, including corrections and reporting, in a test instance before deciding.
A hospital with inpatient wards needs admission and ward workflows, clinical documentation across shifts, and a laboratory that handles higher volume and more formal review. Standard adds OpenELIS for the laboratory and Odoo 16 with an Odoo connector for billing, inventory and accounting, on top of the OpenMRS-based EMR. That combination is why Standard is the configuration aimed at this setting, though the wards themselves must be checked against the modules you deploy.
- Dedicated laboratory system: OpenELIS runs as its own application, so laboratory staff work in a system designed for that role.
- Finance back office: Odoo 16 covers billing, inventory and accounting through the connector, which matters where pharmacy stock and ledgers must reconcile.
- More services to operate: each added application needs its own backups, upgrades, access reviews and interface tests. Plan for that effort in advance.
- Fair case for Lite: a smaller hospital with limited inpatient volume, where Crater and the EMR's built-in lab workflow already meet the need, can avoid running OpenELIS and Odoo.
Review the Standard Compose file with your team, then confirm ward workflows, interfaces to existing systems and the finance system of record in a scoped pilot.
A hospital that acquires DICOM images from modalities and needs them stored, retrieved and linked to the patient record is the setting where Standard's dcm4chee component and PACS integration service matter. Lite does not include dcm4chee, so image archiving becomes a separate decision. The core question is whether images must live inside the Bahmni stack or can sit in a PACS the hospital or a regional provider already operates.
- Archive included in Standard: dcm4chee and the PACS integration service run inside the Standard Compose stack, so the archive and the EMR are deployed and upgraded together.
- Storage drives the design: image volume shapes disk, backup and retention planning more than the EMR does. Ask for the modality list, expected study volumes and retention rules before sizing anything.
- Lite with an external PACS: if imaging already sits in an existing PACS, Lite avoids operating dcm4chee, and the integration happens at the workflow level. Confirm how that link would work with your vendor.
- Operational ownership: an in-house archive needs DICOM networking, certificate management, access reviews and tested recovery, all owned by a named team.
Confirm modality connectivity, retention obligations and which team owns the archive before deciding whether dcm4chee belongs in scope.
What license terms cover each component in both configurations
Bahmni Lite and Bahmni Standard combine several open-source components, each with its own license and its own maintainers. Reading the license of each component tells you what you may copy, modify and redistribute, but it does not tell you who supports it or what it costs to run.
OpenMRS core platform
OpenMRS is the medical record engine in both configurations, and the OpenMRS core is released under the MPL 2.0 with a Healthcare Disclaimer. MPL 2.0 is a file-level copyleft license, so changes you make to OpenMRS source files must be shared under the same terms, while your separate modules can carry different terms. Confirm this reading with counsel and check the Healthcare Disclaimer before you ship any modified build.
Bahmni apps module
The clinician-facing frontend, openmrs-module-bahmniapps, is licensed under the MPL 2.0 according to its repository. Because it is the layer clinicians touch in both configurations, a change you make to the frontend affects user workflows directly. Check the LICENSE file in the repository for the version you deploy, since the frontend is released on its own cycle from the Docker files.
OpenELIS laboratory system
OpenELIS appears only in Bahmni Standard, where it runs the laboratory. The facts available here do not state its license, so confirm it in the OpenELIS repository before you approve Standard. Check whether the license permits the modifications your lab workflows will need, and whether any lab-specific interfaces you build carry obligations to publish code.
Odoo billing and accounting
Odoo 16 is the billing, inventory and accounting layer in Bahmni Standard, connected through an Odoo connector. Odoo's editions and license terms differ between its community and enterprise offerings, so confirm which edition the connector targets and which license applies to each module you install. Mixing modules under different terms is a common source of licensing surprises in finance deployments.
Crater billing in Lite
Crater is the billing component in Bahmni Lite, which means clinics using Lite run billing outside Odoo. The facts supplied here do not state the Crater license, so confirm it in the Crater project's repository. If you plan to move a clinic from Lite to Standard later, check that the Crater license and data export terms allow you to retire it without losing billing history.
dcm4chee imaging archive
dcm4chee provides the PACS and DICOM archive in Bahmni Standard, through a PACS integration service. The facts supplied here do not state its license, so confirm the terms in the dcm4chee project's own repository. Imaging archives also hold data that must be retained, so verify that the license and your planned hosting do not restrict how you store or back up studies.
What each configuration costs to run and who gets paid
This table lists the cost components of running Bahmni Lite or Bahmni Standard, who is paid for each one, whether it is one-time or recurring, and what moves it up or down. No fee for either configuration was supplied, so use the rows to structure a written quote and the questions to ask before comparing numbers.
| Cost component | Who is paid, and for what | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Software licensing | Bahmni and its bundled components are open source, so no license fee for either configuration was supplied. Confirm each component's license terms with the vendor before purchase. | Confirm with vendor | Component licenses differ across the stack. Ask for a written list of every bundled component and its license. |
| Cloud or data center hosting | Your cloud provider or data center operator for compute, backups and networking. Lite runs fewer services than Standard. | Recurring | Standard adds OpenELIS, Odoo 16 and dcm4chee, so it needs more memory, CPU and containers. Sizing depends on patient volume and user count. |
| Storage for imaging | Your storage vendor or cloud provider. Applies mainly to Standard, which includes dcm4chee for PACS. | Recurring, growing over time | Imaging volume, retention periods and backup copies. Lite has no PACS component in its base stack, so imaging storage is not a default cost there. |
| Staff time for installation | Your internal team or an implementation partner such as DeployOpen, under a written scope. | One-time | Number of services to configure, your network and identity requirements, and how many sites go live at once. Standard has more moving parts to validate. |
| Interface work between OpenMRS, Odoo and OpenELIS | Integration developers or your implementation partner. Not needed for Lite's single-EMR scope in the same way. | One-time, plus ongoing maintenance | Number of interfaces, custom billing or inventory rules, and lab test mappings. Standard requires this work; Lite requires far less. |
| Support retainers | Your vendor of choice for ongoing support, upgrades and patching. Bahmni Coalition and community support are free, but paid support is separate. | Recurring | Whether you need guaranteed response times, after-hours coverage and help with component upgrades. Ask for the scope in writing. |
| Training | Trainers for clinicians, lab staff, billing and administrators. Standard usually trains more roles. | One-time, with refresher rounds | Number of user roles, staff turnover and how many modules each role uses. Standard's lab, billing and imaging modules add training scope. |
| Upgrade and testing effort | Your internal team or a partner who validates each component version before rollout. | Recurring, per release | Number of components pinned to versions, custom modifications and test coverage. Standard upgrades touch more components than Lite. |
How much more infrastructure and operating effort Standard needs
Standard adds services on top of the Lite stack, so it adds containers to run, databases to back up, interfaces to test and more components to patch. Lite runs OpenMRS, the Bahmni web and apps frontends, the Bahmni Lab service, appointments, patient documents, reports and Crater for billing. Standard keeps that core and adds OpenELIS for the laboratory, Odoo 16 with an Odoo connector for billing, inventory and accounting, and dcm4chee with a PACS integration service for imaging. Each added component has its own configuration, its own data store and its own upgrade path, and each integration point between the EMR and these services is a place where a change in one can break the others. Read the two docker-compose.yml files side by side before you decide, and count the services, volumes and inter-service dependencies in each.
The operating effort is mostly qualitative, and it grows with the number of moving parts rather than with any single component. Expect your team to own backup and restore for more than one database, to test laboratory and billing interfaces after every upgrade, and to track security patches for OpenELIS, Odoo and dcm4chee alongside OpenMRS. Imaging adds a different kind of load, because study storage tends to grow faster than clinical text, so the storage plan matters more on Standard than on Lite. This page does not give resource sizing, storage growth rates or backup schedules, and you should not plan from any figure you see elsewhere without confirming it. Ask your implementer for a sizing estimate based on your expected patient volume, imaging modalities and retention rules, and ask for a written restore test plan that covers every database in the stack.
Before you commit to Standard, decide who will run it after go-live and what that person or team will be responsible for each month. A useful check is to ask the implementer to walk through an upgrade of the full stack in a non-production environment and document how long the interface tests take, which services must be stopped, and how rollback works if the PACS or billing connector fails. Confirm these points with the implementer, with the Bahmni project and with your own infrastructure team, and treat the answers as part of the scope you agree in writing.
How a clinic moves from Lite to Standard without losing patient records
This sequence gives a team a documented path from its current Lite deployment to Standard, with data verified at each stage before any cutover. It produces a tested rollback plan and written evidence that patient records, lab results and billing balances match on both sides.
Inventory the current Lite deployment
Record exactly what runs today: the Bahmni Lite version pinned in the
.envfile (the stable, tested tag the bahmni-docker README points to is 1.0.0), the OpenMRS, Crater and Bahmni Lab containers, enabled optional profiles, database versions and any local customizations. Whoever operates the clinic's Docker host should own this, and the step is done when the inventory is signed off by both the clinical lead and the implementer, with a full backup taken and restore-tested on a separate machine.Decide which Standard components are needed
Compare what Standard adds (OpenELIS for the laboratory, Odoo 16 with the Odoo connector for billing, inventory and accounting, and dcm4chee with the PACS integration service for imaging) against the clinic's actual lab, billing and imaging workflows. Clinical leadership, finance and the lab supervisor should each decide which modules go live and which stay out, and the output is a written component list with an owner for each item.
Stand up a staging environment
Build a non-production copy of the target Standard stack on infrastructure that mirrors the production host's resources and network rules, using the bahmni-standard Docker Compose file as the starting point. Load a sanitized copy of the Lite data so the team can see how the new services start together. The step is done when the staging stack starts cleanly, the health checks pass and a named engineer can rebuild it from documented steps.
Map data and test lab and billing interfaces
Document how each Lite data class maps to its Standard counterpart: patient identifiers, encounters, lab orders and results, charges, payments and any stock or account codes. Test each interface with known sample records (for example, a set of test patients with orders, results and invoices) and check that counts, identifiers and totals reconcile. The step is complete when the mapping document has been reviewed by the lab and finance leads and every test case has a recorded pass or a logged exception.
Confirm the upgrade method with the project and implementer
The supplied facts do not confirm a supported migration path from Lite to Standard. Before committing, ask the Bahmni project and the implementer to confirm in writing whether an in-place upgrade, a data export and import, or a fresh install with reloaded data is supported, which versions it covers, and who carries responsibility for each step. Keep that written confirmation with the change record. Treat any method the project has not confirmed as a hypothesis to test in staging only.
Run parallel validation for a defined period
Keep Lite in production while Standard receives mirrored or re-entered test activity, and compare results daily across patient registration, lab results and billing totals. Record each discrepancy, its cause and its fix. The output is a validation log with reconciled counts and a sign-off from clinical, laboratory and finance owners that the discrepancies are closed or accepted in writing.
Cut over with a tested rollback plan
Schedule the cutover window with the clinic, freeze new Lite entries, run the final data transfer, and verify the same reconciliation checks used in validation. Keep the Lite environment and its backup intact until the business owners accept Standard in writing. The rollback plan must name the trigger for reverting, the steps to restore Lite from backup and the person who can authorize it. The step is complete when the cutover checklist is signed and rollback has been rehearsed in staging.
What do buyers ask before choosing or hiring help for Bahmni Standard?
Can a team run Bahmni Standard without outside help?
Yes, a team with Docker, Linux and PostgreSQL or MySQL skills can start from the bahmni-docker Compose files, but Standard is a multi-service stack. It adds OpenELIS, Odoo 16 with its connector, and dcm4chee with a PACS integration service on top of the OpenMRS-based EMR. Each service has its own configuration, data and upgrade path. The harder questions are clinical workflow configuration, laboratory and billing set-up, and integration testing with your devices and imaging modalities. Decide early which of these your staff can own and which you will buy as scoped work.
How long does a Bahmni Standard deployment take, and what drives it?
The timeline depends on scope more than on the software itself. The main drivers are the number of departments and workflows in use, how many external interfaces must be built and tested (laboratory analyzers, imaging modalities, payment or insurance systems), the state of your legacy patient data, and how many clinicians can join testing sessions. Each driver should appear as a line item in the written scope, and any duration should come from that scope, not from a general rule. Ask the implementer to show which assumptions the timeline depends on.
What does a Bahmni Standard project need from our side?
Expect three kinds of input from your organization. First, staff time: clinical, laboratory, radiology, finance and IT people must review configuration and test real workflows. Second, infrastructure: you provide the hosts or cloud accounts, storage, backup targets, network segmentation and certificates in your own environment. Third, decision owners: a named clinical lead to sign off workflows, and data owners who approve master data such as drug lists, test catalogs and tariffs. Ask the quote to state each role, the expected involvement and who approves changes.
Can we deploy Bahmni Standard in stages?
Often yes, and staged rollout is a common way to reduce risk. Many teams start with the EMR and registration, then add the laboratory, then billing and inventory with Odoo, and then imaging with dcm4chee. Each stage carries its own data migration, interface testing and user training. Stages work best when the dependencies are mapped first, for example which billing items come from lab orders. Ask whether the scope lists each stage as a separate deliverable with its own acceptance criteria.
What does a fixed-scope Bahmni engagement cover?
DeployOpen's engagements are generally fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. A written scope for Standard should name the components in use, the hosting environment, the interfaces to build, the data to migrate, the backup and upgrade procedures, the documentation and the training. It should also state what is excluded, such as new clinical modules or custom reports. Ongoing support, upgrades and continuous testing are available as retainers, which are separate from the initial build.
What recurring costs should we expect after go-live?
The software is open source, so the recurring costs come from people and infrastructure. Plan for hosting in your own cloud or data center, backups and monitoring, patching the components on their separate release cycles, and staff who can maintain Odoo, OpenELIS and dcm4chee configurations. Retainers can cover upgrades and support, but they should be priced from a written scope. Ask any provider to separate one-time build costs from monthly or annual support so you can compare options fairly.
Who is responsible for security and compliance in a Standard deployment?
Your organization stays responsible for its own data, access policies and regulatory obligations. DeployOpen can harden the deployment, document controls and prepare evidence for compliance assessments, but it does not issue audit reports or certifications, and independent auditors and certification bodies do that. Confirm with your compliance lead which regulations apply, which controls you must evidence, and who holds administrator credentials for each component after handover.
How DeployOpen scopes, delivers and supports either Bahmni configuration
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Bahmni, that means the same method applies whether the team needs the lighter Lite stack or the full Standard stack with laboratory, billing and imaging components, with the written scope determining which parts are included.
How we scope
- Confirm which Bahmni configuration fits the sites, departments and workflows in scope before any work begins.
- List every component in the written scope, including OpenMRS, Crater or Odoo, OpenELIS and dcm4chee where applicable.
- Agree the hosting target, whether cloud accounts, a data center or an air-gapped network, in writing.
How we build
- Deploy the chosen Docker Compose configuration into the client's own environment and record the image tags in use.
- Configure integrations, optional profiles and identity connections the scope names, then test each one against agreed cases.
- Harden the stack and run security testing against the deployed services as the agreed scope specifies.
How we hand over
- Document the architecture, configuration, backup procedures and upgrade steps for the chosen configuration.
- Provide the compliance readiness evidence the scope calls for, without issuing audit reports or certifications.
- Walk the client's team through operations and record the handover against the written deliverables.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, sized to the chosen configuration.
- Plan upgrades of each component separately, since Lite and Standard carry different component sets.
- Ask for a quote built from the written scope, which is the basis for all pricing (DeployOpen does not publish a price list).
