GSoC 2021: Metadata Management
Primary mentor |
|
Backup mentor |
|
Assigned to | TBD |
This project is part of [ARCHIVED] GSOC 2021: Modernizing Administration functions for OpenMRS
Description
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
@Ian Bacher
@Burke Mamlin
Skills Needed
Familiarity with Java and JavaScript
Familiarity with React and TypeScript
Good understanding of REST
HTML/CSS
Objectives
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 Mapping | Manage mappings between OpenMRS |
FHIR Encounter Class Mapping | Manage mappings between OpenMRS locations and the values enumerated in FHIR's ActEncounterCode value set. |
FHIR Observation Category Map | Manage mappings between OpenMRS |
Locations
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).
|
Manage Location Tags | List/search, add, edit, retire, and delete location tags.
|
View Location Hierarchy | Configure how locations are displayed in the application (e.g., as Tree or Selector).
|
Manage Location Attribute Types | List/search, add, edit, retire, and delete location attribute types.
|
Manage Address Template | Textarea for editing XML
|
Programs
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.
|
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.
|
Extra Credit
Implement the FHIR administration functions as part of the FHIR Module, serving as an example of how a module can provide a micro frontend and register it within the new Administration functions for OpenMRS.
Resources
Read up on OpenMRS Microfrontend/SPA framework: Frontend - SPA and Microfrontends
Read up on FHIR. Good introductions can be found in this post, in this slide show or this video.
Read up on OpenMRS REST web-services: REST Module