GSoC 2021: People Management

Owned by Burke Mamlin
Last updated: Mar 02, 2021 by Ian BacherVersion comment
5 min read

 

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