What an OpenMRS implementation involves
OpenMRS is free to license but not free to deploy. The MPL 2.0 license costs nothing, so the budget goes into the planned build of a patient record system for a clinic network or national program, running on infrastructure the client controls. An implementation covers the hosting design, the concept dictionary and metadata, forms, any custom or community modules, user accounts and roles, training, and rollout to each site. Each of those pieces needs a named owner and a written scope before work starts.
Most projects start from one of four triggers: a new clinical program that needs structured records, a replacement for paper registers or spreadsheets, the adoption of a national distribution such as KenyaEMR, or a move to the O3 frontend. The trigger shapes the work. A paper replacement needs data capture and clinical workflow design from scratch, while a national distribution brings a tested metadata set that has to be adapted rather than invented. Confirm which trigger applies before estimating anything.
Two starting points are in common use. The O3 Reference Application is at version 3.7.1 and the OpenMRS Platform is at version 2.8.1, and the choice between them should be made against the program's forms, modules and frontend needs. Confirm the current release notes and supported database engines with the OpenMRS project before you fix the stack, because the release calendar moves.
In-house or partner? A team with strong Java, relational database and clinical informatics skills can build an OpenMRS system alone. Most first rollouts still need outside help for metadata design, which is hard to get right without clinicians in the room, and for the site rollout sequence. Ask any partner to show how they will hand metadata ownership and runbooks to your staff, and ask your own team which of these skills it actually has today.
What drives cost and duration
Each row names a driver that moves OpenMRS implementation effort, explains why it does so, and gives the lever that keeps it under control, so you can check whether a quote reflects your scope.
| Driver | Why it moves the effort | How to keep it down |
|---|---|---|
| Number of sites and users | Every site adds installation or hosting setup, network checks, local training and a cutover. Concurrent users drive server sizing and load testing. | Pilot at one or two sites, then roll out in waves that reuse the same build. Ask the quote to price the site template once and the repeat rollout separately. |
| Connectivity at sites | Intermittent or low-bandwidth links affect whether a central instance is viable, whether offline data entry is needed and how sync or failover is tested. | Survey each site's bandwidth, uptime and power before choosing hosting. Confirm the connectivity assumptions in writing so site variants are scoped, not guessed. |
| Concept dictionary and metadata size | Concepts, concept sets, locations, encounter types and privilege definitions must be agreed clinically, mapped and loaded. Large or unreconciled dictionaries add review cycles. | Reuse an existing standard such as a national or distribution dictionary where it fits. Limit the first release to agreed clinical content and add the rest later. |
| Number and complexity of forms | Each form needs clinical sign-off, field logic, validation and testing. Complex forms with repeating groups, calculations or cross-form rules take longer than simple data capture. | Prioritize forms by workflow value. Reuse common sections across forms and freeze form versions before build starts. |
| Custom modules versus configuration | Configuration uses the platform's own tools. Custom modules need Java development, code review, testing and a maintenance commitment for every platform upgrade. | Configure first and document every gap. Approve custom code only for requirements configuration cannot meet, and ask for the module's upgrade effort in the quote. |
| Number and complexity of integrations | FHIR2 APIs, SMART on FHIR apps, OAuth2 login to an identity provider, laboratory or pharmacy systems each need interface design, mapping, security review and end-to-end testing with the other system's owner. | Confirm which interfaces are required at go-live and which can follow. Ask for each integration to be priced as a separate line with its test dependencies named. |
| Data migration volume and quality | Record count, duplicate patients, missing identifiers and paper or legacy formats determine cleaning, mapping, reconciliation and clinical validation effort. | Profile the source data before estimating. Agree in advance which records are migrated and which are archived or left in the source system. |
| Hosting model | Client cloud, a data center or an air-gapped network each changes who builds the environment, how patches reach it, how backups are moved and how access is granted. | Choose one hosting model per tier of sites and state it in the scope. Ask the quote to separate infrastructure setup from application configuration. |
| Database choice (MySQL, MariaDB or PostgreSQL) | OpenMRS core supports MySQL, MariaDB and PostgreSQL. The choice affects installation, backup tooling, skills available in your team and how the database is operated and patched. | Match the database to the skills and standards your operations team already runs. Confirm which databases the chosen platform release and modules support before committing. |
| Languages and training audiences | Each language needs translated labels and forms. Each user group, such as clinicians, data clerks and administrators, needs its own training material and sessions. | Limit the first release to the languages in use. Train through a small group of local champions who can repeat sessions at each site. |
| Compliance and data protection requirements | Requirements such as access logging, encryption, retention rules, data residency and evidence for a compliance assessment add design, configuration and documentation work across the whole build. | Name the applicable obligations at the start and map each to a control or configuration item. DeployOpen prepares controls and evidence, but audits and certifications come from independent auditors and certification bodies. |
What the work includes and what you receive
Each workstream below is a distinct piece of an OpenMRS 3 rollout, and each one changes the quote. The written deliverables at the end are what your team keeps after the implementation partner leaves.
Hosting and environments
Choose the deployment shape first: the Standalone package with an embedded database, a WAR file for Apache Tomcat on an existing MySQL or MariaDB database, or the O3 Docker Compose stack of MariaDB, backend, Nginx frontend, Nginx gateway and optional Certbot. Ask the partner to confirm which shape fits your sites, how TLS is handled, and how staging and production are separated.
Concept dictionary and metadata model
Concepts, concept sets, encounter types, forms references and locations form the metadata that every clinical screen depends on. Agree who owns clinical terminology, how changes are versioned between environments, and whether the metadata set is loaded by script so that a rebuild produces the same result.
Forms design and conversion
Inventory every paper or legacy HTML form before estimating. Forms that need conversion to the O3 form schema take more clinical review than new forms, and the community migration tool built by Palladium Kenya is a starting point rather than a finished conversion. Ask for a forms inventory that lists each form, its source, its conversion status and its reviewer.
Module selection and configuration
Each module added to the platform is a version you must test and keep current. Settle the module list early, confirm version compatibility with the platform and O3 release you chose, and ask who maintains each module after go-live. Configuration of global properties, privileges and locations is part of this workstream.
FHIR2 and SMART enablement
Enable this workstream only when a named system or app needs FHIR REST access or SMART on FHIR app launch. The FHIR2 module and the SMART on FHIR module depend on each other and the SMART module uses Keycloak as its default authorization server. Confirm the consuming systems, the FHIR resources they read and whether identity is delegated.
User roles and privileges design
Map each job role, such as registration clerk, nurse, clinician, data manager and auditor, to the privileges it needs and nothing more. Decide early whether logins stay local or move to an OAuth 2.0 provider, because that choice changes how roles are assigned. Ask for a role matrix signed off by the clinical lead.
Training and documentation
Training is scoped by role and by site, and it recurs whenever staff turn over or forms change. Ask for training materials built from your configured forms and workflows, not from the default demo data, and confirm who delivers sessions and who maintains the material after handover.
Site rollout
Sites differ in connectivity, devices, staffing and records already on paper. Plan a sequence of pilot and subsequent sites with go or no-go criteria for each, and price the travel, on-site support and connectivity separately from the central build. Confirm how records from a site will be migrated or started fresh.
Deliverables in writing
Before work starts, agree the written set you will receive: environment build records, the configured metadata set, the forms inventory with test results, training materials, a runbook and a handover record. Ask for each item to be versioned and stored in your infrastructure, so the knowledge does not depend on the partner.
Project phases and what each produces
The sequence moves from clinical requirements to a tested, piloted and supported OpenMRS deployment, with each phase closing on a written output that the next phase depends on.
Run discovery and capture clinical requirements
Your clinical leads, data managers and IT staff work with DeployOpen to map the care pathways, forms, reports, user roles and existing paper or legacy records in scope. The phase closes with a requirements document that clinical owners sign off, which becomes the baseline for every later change request.
Decide architecture and hosting
The team compares hosting options in your cloud accounts, data centers or on-premises network, covering the database engine, the Standalone package, the O3 Reference Application container stack or a WAR on Tomcat, and how sites connect. The output is a hosting and architecture design that records backup, TLS, identity and connectivity choices.
Design the concept dictionary and metadata
Concepts, concept sources, forms metadata and program definitions are specified against the requirements, with naming rules and ownership agreed with your terminology lead. The output is a metadata specification and a loadable metadata package, which can be tested on a non-production instance before anything reaches users.
Build forms and modules
Forms are built or converted to the O3 form schema, and any custom or community modules are configured, extended or pinned to tested versions. Each form is reviewed against the requirements, and the phase closes with a build that is versioned in source control and deployable from a documented procedure.
Build and test integrations
Interfaces to laboratory, pharmacy, national registries, identity providers or reporting tools are built, including FHIR endpoints where the design calls for them. The phase closes with an integration test report covering message formats, error handling and access controls for each interface.
Test and run clinical user acceptance
Functional, regression, performance and security tests run on the built system, and clinical staff execute scripted scenarios against the requirements. Defects are triaged and resolved, and the phase closes with a signed acceptance record that names any accepted limitations.
Train users and run a pilot site
Training materials are prepared for each role and delivered, then the system runs at one site with real workflows under supervision. The output is a pilot report listing defects, workflow gaps, training gaps and the go or no-go recommendation for wider rollout.
Roll out phased and hand over support
Remaining sites go live in the sequence set in the written scope, each with its own cutover checks, and the project ends with handover documentation, runbooks and a support arrangement that covers upgrades, backups and module patching. Ask for the handover package and the support terms in the quote so both are fixed before work starts.
What to keep in-house and what to outsource
This table shows which OpenMRS work areas clinical and IT owners usually keep, which a partner usually carries, and the skills each side needs, so you can name the people who will run the system after handover.
| Work area | Usually kept in-house | Usually outsourced | Skills required |
|---|---|---|---|
| Clinical content ownership | Clinical leads decide which conditions, encounters, workflows and reporting needs the system must support | Facilitating workshops and documenting the decisions clinical leads make | Clinical domain knowledge, workflow mapping, decision records |
| Concept dictionary and metadata design | Named terminology owner approves concepts, codes and naming standards | Building concept sets, mappings and metadata packages in the configuration tooling | Terminology standards, OpenMRS data model, metadata tooling |
| Form design and the O3 form schema | Clinical leads approve field lists, validation rules and form sequence | Authoring O3 form schemas, converting legacy HTML forms and testing rendering | O3 frontend, JSON form schema, clinical informatics |
| Java and Maven build work | Internal engineer owns the module list, version pins and the build pipeline after handover | Customizing modules, building the WAR or distribution and resolving dependency issues | Java, Maven, Tomcat or Jetty, OpenMRS module SDK |
| Database and hosting operations | Infrastructure team owns servers or cloud accounts, backups and access approvals | Setting up the MySQL, MariaDB or PostgreSQL databases, Docker Compose stacks and deployment runbooks | Linux administration, database administration, container operations, backup testing |
| Integration work | Owners of laboratory, pharmacy and national systems approve interfaces and data-sharing terms | Building FHIR2 and other interface work and testing message flows end to end | FHIR R4, HL7 concepts, API security, integration testing |
| Training delivery | Site leads choose trainers and release staff time for sessions | Writing role-based training materials and delivering sessions for the first rollout waves | Instructional design, clinical workflow knowledge, local language support |
| Site rollout | Site managers set go-live dates, staffing and data cleaning responsibilities | Planning cutover steps, rollback criteria and on-site support during go-live | Project management, change control, site readiness assessment |
What usually goes wrong and how to prevent it
Most OpenMRS delays and cost overruns trace back to a handful of decisions made too late or too casually. Each card below names one of them and the choice to settle early.
Metadata built ad hoc
Concepts, forms and encounter types created directly in the running system without a governed dictionary become hard to change once records and reports depend on them. Decide early who owns the concept dictionary, how changes are reviewed, and whether metadata will be managed as versioned configuration so that test and production stay in step.
Forms copied from paper
Digitizing paper forms field by field carries over layouts that were never designed for data entry, reporting or clinical safety. Assign clinical reviewers to each form before build starts, and confirm which fields feed reports, so that required fields and answer options reflect how care is actually delivered.
Distribution chosen late
Deciding between a national distribution such as KenyaEMR and a custom build after configuration has begun forces rework in metadata, forms and training. Make the distribution decision at scoping, because it sets the starting concept dictionary, the modules included and the support path your program inherits.
Connectivity and power underestimated
Clinic sites often have intermittent links and unreliable power, which affects hosting location, backup windows and whether users can work offline. Survey each site's bandwidth, power and device inventory before choosing a hosting model, and ask the implementer how the plan handles outages at the site.
Custom modules where configuration suffices
Writing Java modules for needs that forms, metadata or existing modules could meet adds code to upgrade and test on every platform release. Before approving a module, check whether configuration or an existing community module covers the requirement, and record the upgrade cost of any custom code in the quote.
Data migration started after the build
Planning to load legacy or paper-derived records only after the system is built forces mapping decisions into the final weeks and exposes gaps in the concept dictionary. Start patient and data mapping in parallel with the build, and agree which legacy fields are required for go-live.
Training delivered too late
Training scheduled after the system is declared ready leaves pilot users learning on live records and generates support load at the worst moment. Plan role-based training for pilot users against a stable test environment, and budget for refresher sessions at each new site.
No named owner after go-live
Without a named owner for configuration, releases, user access and backups, fixes queue up and platform knowledge leaves with the implementation team. Name the owner before go-live, assign an internal technical contact and agree how support will be provided after the handover.
Version path left undefined
Choosing between the 2.x Platform and the 3.x Reference Application without a plan for the other path leaves an implementation stranded or forces a migration later. Record which line you are building on, what the 2.x and 3.x paths mean for your forms and modules, and when you will revisit the decision.
How the work changes by starting point
A new network starts from the O3 Reference Application, so the plan is mostly configuration rather than migration. The Docker Compose setup for O3 runs a MariaDB database, the OpenMRS backend, an Nginx frontend, an Nginx gateway and an optional Certbot service, which gives a known baseline to design around.
- Scope: concept dictionary, metadata, forms and location hierarchy are built from the start, with no legacy data to map.
- Hosting: confirm where the stack runs for each site and who operates it.
- Ask for: the O3 release the quote targets, the number of sites, and whether the Certbot option is in scope or handled by your gateway.
- Ask for: a written list of modules included in the baseline and who approves additions.
A national program usually builds on an existing distribution such as KenyaEMR, so the first decision is how much of the distribution to keep. Changes to a distribution affect every site that runs it, which shifts the plan toward shared governance and upgrade control.
- Scope: map which distribution components you adopt unchanged, which you extend, and which you replace.
- Governance: agree who approves changes to the shared metadata and module set.
- Ask for: how the proposed customizations will be carried through future distribution releases.
- Ask for: the test environments needed to validate upgrades across all participating sites before rollout.
A site leaving paper or spreadsheets needs data capture and workflow redesign before any software configuration is final. The plan spends more time on the people and records side, and the cost depends on how clean the source data is.
- Scope: inventory the forms, registers and spreadsheets in use, and decide which fields become structured data.
- Data: plan record cleaning, duplicate handling and the patient identifier strategy before import.
- Training: budget for staff who have never used an electronic record, with time away from clinics.
- Ask for: the data cleaning steps included in the quote and what the site must provide to support them.
The hosting model changes the build and operations work more than the clinical design. Docker Compose suits a single site or a small set of sites, while Kubernetes adds cluster operations that someone must own after handover.
- Compose: the plan covers host hardening, volume backups and a restart and recovery procedure.
- Kubernetes: the plan adds cluster version management, ingress, secrets handling and a platform team responsible for upgrades.
- Ask for: which platform team or vendor will run the cluster and who is on call for it.
- Ask for: the backup and restore test for the database, including how often it runs.
A client that must run in an air-gapped network changes how software, images and updates reach the environment. Packages, container images and module updates must be moved in by controlled transfer, which adds planning time before any build starts.
- Delivery: agree how release artifacts are verified and imported into the isolated network.
- Dependencies: list every library, image and database package needed, since no live downloads are possible.
- Updates: plan the cadence for bringing in patches and the review steps that come with each transfer.
- Ask for: the offline installation procedure and the artifact manifest that will accompany the quote.
A client that needs FHIR and SMART app launch from day one adds integration design and authentication work to the core build. The FHIR2 module provides the FHIR REST API with a focus on R4, and the SMART on FHIR module uses Keycloak as its default authorization server.
- Interfaces: define which FHIR resources and SMART apps are required before configuration begins.
- Identity: plan the OAuth2 or Keycloak setup alongside the core build, not after it.
- Testing: budget for conformance and app launch testing with each external app.
- Ask for: the FHIR version the quote assumes, the list of apps to launch, and who owns the authorization server.
What the client needs to provide
The quote for an OpenMRS 3 rollout depends on a short list of client inputs, and the schedule depends on how quickly the client supplies them. Named clinical and program owners with decision rights should be confirmed before scoping starts. Concept dictionary and form decisions stall when no one can approve a term, a workflow or a report layout, and each open decision adds review cycles to the build.
Hosting and network access drive the infrastructure line and the site plan. Name who controls the cloud account, data center or air-gapped network that will run the O3 Reference Application stack, and who grants access to it. For each clinic, confirm connectivity, device counts and whether the site needs an offline plan. Late network decisions move site rollout dates more than any software task.
Existing paper records and electronic data need an owner, a sample and a quality check. Ask for a representative extract, a data dictionary and an estimate of duplicate or incomplete patient records. Migration effort, cleaning rules and the number of mapping cycles all follow from that sample. Provide the list of required forms and reports early, because each form adds conversion and testing effort and each report adds data validation.
Identity and approvals close the scope. Decide whether single sign-on is required and which identity provider will be used, since the OAuth2 Login and SMART on FHIR work depends on it. Name the data protection officer, the security approver and the ethics or records approval contact, and the budget owner who signs the written scope. Training audiences and locations, with headcounts per site, set the training days and travel costs in the quote.
Questions buyers ask before hiring help
What does an OpenMRS implementation cost and why do quotes differ?
Quotes differ because the work behind them differs, so compare the scope before comparing totals. One-time costs usually include discovery, concept dictionary and metadata design, form building, any module configuration, data migration, training and site rollout. Recurring costs include hosting, database backups, patching, module upgrades and support staff. Ask each bidder to itemize these components, state which are fixed and which are estimated, name the number of sites and user groups covered, and list what the client must provide. A quote that omits hosting, testing or training is not comparable with one that includes them.
How long does an OpenMRS rollout take and what sets the timeline?
The timeline is set by scope and client readiness, not by the software installation itself. The main drivers are the number of clinical workflows and forms, how much concept dictionary and metadata must be agreed by clinical leads, the number of sites and their connectivity, the volume and quality of any legacy data to migrate, and how many training cycles are needed. Approval turnaround from the client's clinical and governance groups often matters more than build effort. Ask the partner for a phased plan with named milestones and the client decisions each phase depends on, rather than a single end date.
Can a clinic team deploy OpenMRS without a partner?
A capable technical team can install OpenMRS from the published downloads, but the harder parts are usually the clinical and data work. Standing up the server is the easier step. Difficult tasks include designing a concept dictionary that matches local practice, building and validating forms, configuring roles and privileges, securing TLS and database access, testing module upgrades, and migrating records with clean mappings. Staff also need to own backups, patching and incident response after go-live. Assess honestly which of these your team has done before and which it would learn on the live system.
What does the work need from our own staff?
Expect to commit clinical leads, a data or metadata owner, an infrastructure contact, a security or privacy reviewer and trainers from your own organization. Clinical leads approve workflows and terminology. The data owner signs off mappings and migration results. Infrastructure staff provide hosting access, network rules and certificates. Without named people with time allocated, phases slip. Ask the partner to list these roles per phase in the written scope, so the client can see the commitment before work starts.
Does OpenMRS have a license fee, and why does deployment still cost money?
OpenMRS is released under the Mozilla Public License 2.0 with a Healthcare Disclaimer, and it has no paid edition, so there is no license fee to purchase. Deployment still costs money because someone must host the system, configure it for local clinical practice, migrate data, train users and keep it patched. Those are labor, infrastructure and operations costs. Implementers and partners are paid for this work, and the project is maintained by a volunteer community and a nonprofit foundation. Confirm the license terms and any module license with the component owner before building.
Should we start with the O3 frontend or the 2.x Platform?
The right starting point depends on your program, your existing system and the current release of each component, so confirm both against the current download page before deciding. New programs often evaluate O3 for its newer user interface, while sites running customized 2.x distributions may need to keep them running during transition. The choice affects forms, custom modules and training. Read the migration topic for the decision steps, forms conversion and phased cutover, and use the upgrades topic for ongoing version planning.
How DeployOpen scopes, delivers and hands over OpenMRS work
DeployOpen plans and deploys OpenMRS inside your own infrastructure, whether that is your cloud accounts, data centers or air-gapped networks, and works from a written scope that sets out hosting, metadata, forms, modules, training and site rollout before build begins. Engagements are fixed-scope, so the quote follows from what is agreed on paper.
How we scope
- The written scope lists hosting targets, OpenMRS release line (Platform 2.x or O3 Reference Application) and the sites in the rollout.
- Concept dictionary, metadata and form inventory are sized and listed so the quote reflects real configuration work.
- Modules, identity needs (local accounts or OAuth 2.0 via Keycloak), integrations and training audiences are named and confirmed in writing before the start.
How we build
- Environments are deployed in your infrastructure, with database, TLS gateway and backup design agreed before configuration starts.
- Concept dictionary, metadata, forms and any custom modules are built and tested against the agreed scope in staging.
- Each site rollout is tested with its own user roles, data entry workflows and reporting before it goes live.
How we hand over
- Handover includes configuration documentation, metadata records, deployment runbooks and the module versions in use.
- Your staff receive training on administration, metadata changes and day-to-day clinical workflows, as set out in the scope.
- Backup restore checks, access reviews and the open items list are completed and signed off by your team before closure.
How we support
- Ongoing support, upgrades and module testing can be contracted as a retainer after the initial rollout.
- Upgrade planning covers Platform and O3 Reference Application changes, with test environments and rollback steps defined.
- Ask for the support hours, response channels and upgrade responsibilities to be written into the quote and the retainer terms.
