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

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 `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 "http://loinc.org" and "http://snomed.info/sct", respectively.
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 `ConceptClass` and the values enumerated in FHIR's observation category value set.

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). 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

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. 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

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

Wiki Spaces

Get Help from Others

Projects

Page tree