GSoC 2021: People Management

Primary mentor
Backup mentor	@Pahonsi Bebeto Achile
Assigned to	TBD

This project is part of [ARCHIVED] GSOC 2021: Modernizing Administration functions for OpenMRS

Description

Porting administration functions for managing people within OpenMRS to OpenMRS 3.0: A Frontend Framework. This project focuses on user accounts, patients, providers, and their associated person records.

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

@Burke Mamlin
@Daniel Kayiwa

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.

Users

These functions provide the fundamental tools to manage users within OpenMRS. See System Administration > Manage Accounts in the Reference Application.

Reference Application 2.x implementation for Manage Accounts - github pages & fragments
Reference Application 2.x implementation for roles & privileges within Configure Metadata - github
Legacy UI implementation in Advanced Configuration - github

Manage Users*	List and search users, add/edit user form OpenMRS User extends Person, which means creating a user can create a new Person or link to an existing Person In OpenMRS, people provide care for patients through a Provider account (also linked to Person). Many (but not all) users are also providers, so Provider creation is incorporated into user management. New users are auto-assigned a system ID, but may create their own username (must be unique, discourage use of email address) Configurable password requirements must be followed Many of these functions should already be available via the REST API Extra credit Migrating provider and person management to FHIR (Practitioner and Person) Incorporate (optional) user email address Reference Application 2.x implementation in System Administration > User Accounts
Manage Roles*	List, search, add, edit, and delete roles. Prevent system roles from being edited/deleted. Extra credit: Improving role management experience Reference Application 2.x implementation in Configure Metadata
Manage Privileges	List, search, add, edit, and delete privileges. Prevent system privileges from being edit/deleted. Reference Application 2.x implementation in Configure Metadata
Manage Alerts	Create system-wide messages. Legacy UI implementation in Advanced Administration

Person

These functions provide administration for Person entries and associated metadata within OpenMRS. In OpenMRS, a Person is used to store demographic and other person-specific information for Patients, Users, Providers, and people related to patients (children, relatives, caretakers, etc.)

Legacy UI implementation in Advanced Administration - github

Manage Persons

List/search, add/edit Person form, and delete persons.

Legacy UI implementation in Advanced Administration

Manage Relationship Types

List/search, add, edit, retire, and delete Relationship Types. Relationship Types define the types of relationships between Persons. Also manage how relationship types are show to the user (which types are shown by default and in which order).

REST API endpoints will need to be created to manage relationship types.
Relationships have two directions. Some relationships differ depending on the direction; for example, is A is related to B as "Parent", then B is, by definition, related to A as "Child". Other relationships are the same either direction (e.g., the reverse relationship of "Sibling" is also "Sibling").

Legacy UI implementation in Advanced Administration

Manage Person Attribute Types

List/search, add, edit, retire, and delete Person Attributes. These are local (implementation-specific) extensions of a Person. Also control how person attributes are displayed to users.

Some REST API endpoints already exist for managing person attribute types
REST API endpoints may need to be created for managing how person attribute types should be displayed to users

Legacy UI implementation in Advanced Administration

Patients

These functions provide administrative functions for patient records within OpenMRS. Ideally, wherever possible, these functions would be performed via FHIR API calls.

Reference Application 2.x implementation for Patient Identifier Types in Configure Metadata - github
Legacy UI implementation in Advanced Administration - github

Manage Patients	List and search patients, add/edit patient form. All patients should have one preferred identifier and may have other identifiers Patients can have multiple names and addresses Collect (optional) cause of death when marking a patient as deceased Extra credit: Make it easier to record patient contact information (e.g., telephone number, email) using implementation-configured person attributes Legacy UI implementation in Advanced Administration
Find Patients to Merge	Search and list potential patients to merge. Most likely, will require adding new REST API endpoints accessible with appropriate privilege(s). First pass could use existing process/UI for merging patients and focus on new UI for selecting patients for merge. Extra credit: Update UI for merge process Legacy UI implementation in Advanced Administration
Manage Identifier Types	List/search and add/edit form for patient identifier types. Ability to retire or purge a patient identifier type. Purging a patient identifier type should not be possible once it has been used (database foreign key constraints will prevent deletion) Extra credit: Provide some support for users in crafting a regular expression format Reference Application 2.x implementation in Configure Metadata Legacy UI implementation in Advanced Administration
Manage Patient Identifier Sources	List/search, add, and configure patient identifier sources. REST API endpoints will need to be created to manage patient identifier sources Legacy UI implementation in Advanced Administration
Auto-Generation Options	Manage auto-generation features for identifier types. REST API endpoints will need to be created to manage auto-generation options Legacy UI implementation in Advanced Administration
View Log Entries	Search patient identifier generation logs. REST API endpoints will need to be created to access patient identifier log entries Legacy UI implementation in Advanced Administration

Providers

Provides functions for managing Provider accounts within OpenMRS. Provider accounts are used to record who provided clinical care (e.g., within encounters). While provider accounts often refer to users within the system (people who are logging into OpenMRS like doctors & nurses), they can refer to people who are not users of the system (have no User account) and even to providers from other institutions (in which case they may not refer to a Person). There is also a Provider Management module that implements some of these features.

Reference Application 2.x implementation for Provider Attribute Types in Configure Metadata - github
Legacy UI Implementation in Advanced Configuration - github

Manage Providers

List/search, add, edit, retire, and delete provider accounts. Providers may optionally be linked to a Person.

REST API endpoints exist

Legacy UI implementation in Advanced Administration

Manage Provider Attribute Types

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

REST API endpoints exist

Reference Application 2.x implementation in Configure Metadata

Legacy UI implementation in Advanced Administration

Extra Credit

TBD

Resources

Read up on the new OpenMRS Frontend framework: OpenMRS 3.0: A Frontend Framework that enables collaboration and better User Experience
Read up on OpenMRS REST web-services: REST Module
Read up on FHIR. Good introductions can be found in this post, in this slide show or this video.