Wiki Spaces


Get Help from Others

Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack


Page tree
Skip to end of metadata
Go to start of metadata
Primary mentor

Backup mentor
Assigned toTBD


Porting administration functions for managing metadata within OpenMRS to OpenMRS 3.0: A Frontend Framework. This project focuses on location, program definitions, and FHIR metadata.

The primary goal of this project is to creating working micro frontend module(s) for these administration functions that can plug into the Administration Dashboard, meaning these functions will be expected to be developed using the best practices defined by the OpenMRS 3.0 Frontend Framework (Carbon Design, React/TypeScript) and register with the administration dashboard (mechanism to be determined), providing a title and a React component to render the administration function(s). The dashboard project will be responsible for organizing available administration functions, overall screen layout, and navigation between administration functions.

This project may include writing Java code to extend the REST Module to create needed REST endpoints. Those functions that have been implemented as Open Web Apps (OWAs) likely have the necessary REST endpoints, but functions that exist only in the legacy UI may not have yet been exposed as REST endpoints. The REST of Administration project can help in filling these gaps.

"OWA" refers to Mozilla's Open Web Apps (OWA), a legacy standard from 2010 that existed before frontend frameworks like React, Angular, Vue, etc. were popular. In the early 2010s, OWAs were an attempt in the OpenMRS community to use a standard to create client-side applications. OWAs are not recommended for new development; new development is encouraged to adopt conventions of the new Frontend Framework.

Project Champions

Skills Needed

  • Familiarity with Java and JavaScript
  • Familiarity with React and TypeScript
  • Good understanding of REST


  • Create a "Hello World" ESM module to plug into the Administration Dashboard following conventions of the Frontend Framework (React, TypeScript, Carbon Design). See this page for an overview of the plan. The module should register itself as an administration function and, when selected, display it's "Hello World" within the Administration Dashboard's content pane.
  • Implement the following administration functions as ESM module(s), each registering as an administration function.
  • For those administration features that do not have existing REST endpoints, create (or coordinate with the GSoC 2021: The REST of Administration project to create) those endpoints by extending the REST Module.

Below are the administration functions to be recreated in the new frontend framework. Examples of existing versions of each functions (in the Reference Application, as an OWA, or in the Legacy UI of OpenMRS 1.x) are provided for reference.

FHIR Metadata

The following FHIR metadata functions are new administration functions, so there aren't any examples of pre-existing implementations of them.

FHIR is an emerging standard for healthcare interoperability. OpenMRS has been an early adopter of the FHIR standard, but there is still more we could add to the FHIR module. This part of the project involves creating a simple and effective User Interface (UI) within the Micro frontend / SPA framework to make CRUD (Create, Read, Update and Delete) operations easier for FHIR metadata tables.

In our FHIR module, we currently have three FHIR metadata tables. These tables are pretty straight-forward mappings between some piece of OpenMRS-specific metadata and the corresponding FHIR-specific metadata.

FHIR Concept Source MappingManage mappings between OpenMRS ConceptSource  and the URL for the corresponding FHIR CodeSystem . These are basically key-value pairs to be able to map from OpenMRS concept sources like "LOINC" and "SNOMED CT" to FHIR's URL-based representations of these like "" and "", respectively.

FHIR Encounter Class Mapping

Manage mappings between OpenMRS locations and the values enumerated in FHIR's ActEncounterCode value set.
FHIR Observation Category MapManage mappings between OpenMRS ConceptClass  and the values enumerated in FHIR's observation category value set.


Provides functions to manage location metadata within OpenMRS.

  • Legacy UI implementation – github
Manage Locations

List/search, add, edit, retire, and delete locations. This includes tagging locations and the ability to create a hierarchy (parent/child relationships between locations).

  • REST API endpoints exist

Legacy UI implementation in Reference Application Advanced Administration

Manage Location Tags

List/search, add, edit, retire, and delete location tags.

  • REST API endpoints exist

Legacy UI implementation in Reference Application Advanced Administration

View Location Hierarchy

Configure how locations are displayed in the application (e.g., as Tree or Selector).

  • This feature may not be needed or may need to be implemented differently in the new frontend.

Legacy UI implementation in Reference Application Advanced Administration

Manage Location Attribute Types

List/search, add, edit, retire, and delete location attribute types.

Legacy UI implementation in Reference Application Advanced Administration

Manage Address Template

Textarea for editing XML

Legacy UI implementation in Reference Application Advanced Administration


Provides functions to manage programs within OpenMRS. Programs represent treatments programs or studies. A program can have associated workflows and each workflow can have states. Patients placed in a program can be assigned any state within a workflow in that program. This allows, for example, to identify all patients in the "HIV Program" in the "On active treatment" state. Programs, workflows, and states are all concepts.

  • Legacy UI implementation - github
Manage Program

List/search, add/edit program form, and ability to retire programs. Programs can have one or more workflows and each workflow can have states a list of valid states within that workflow. 

  • REST API endpoints will need to be created to manage programs, workflows, and states

Legacy UI implementation in Reference Application Advanced Administration
Manage Triggered State Conversions

Define concepts (presumably an observation) that should automatically trigger conversion of a patient from one state to another within a workflow.

  • Need to confirm if this is being used in production by implementations
  • REST API endpoints would need to be created to manage triggered state conversions

Legacy UI implementation in Reference Application Advanced Administration

Extra Credit