Core-PRD.md

Niramaya

Platform Core PRD

User and Role Management

September 2022

Table of Contents

• Niramaya
• Platform Core PRD
• Table of Contents
• Platform Overview
• Platform Architecture
• Platform Building Blocks
• User Registries
• Roles
• Masters
• Competency Management
• Notes

Platform Overview

1. Overall Objective and Users

The Uttar Pradesh State Medical Faculty (UPSMF) wants to set up an online platform to manage multiple functions regarding educational training, assessments, and job placement of allied healthcare professionals (AHPs) such as nurses, paramedical staff, lab technicians etc. The overall objective of the platform is to improve the quality of AHP medical education in the state, and eventually, improve the overall quality of healthcare delivery.

Following entities will need to be onboarded onto the platform to achieve the platform’s objective:

1. AHP course students
2. Medical institutes
3. Experienced AHPs (nurses, paramedical staff etc.)
4. Hospitals or healthcare centres
5. UP SMF and other allied departments
6. Field assessors (for institute verification and assessments)

ADD following above or below:

• Abbreviations (all abbreviations we use including CASA, NIC, etc)
• Clarifications of entities - ex: Candidates can be students or professionals

1. Modules and Functionalities

Functionalities for the current roadmap of the platform have been identified, bucketed into 5 functional modules:

1. Rating and Affiliation for regular verification and grading of institutes and enable transparent decision-making for prospective students during the admission process
2. Centralised Admissions for prospective candidates looking to enrol in medical institutes for AHP courses (diploma / degree programs) to reduce the burden of institute-specific application process and remove discretion from the admissions process.
3. **Competency based Assessments **of medical students and experienced professionals to enable tracking of role and function wise core competencies required by professionals to perform at their workplace
4. Verifiable Resume to enable ease of access and verification of a professional’s education and work history when applying for jobs in hospitals and health centres
5. **Aspirational Profession **module encompasses two key functionalities - (1) a job discovery and tracking platform to enable institute graduates to search for and apply for jobs, and (2) a learning management system (LMS) to enable access to online skilling courses to bridge the competency gaps identified as part of the competency based assessments

The Q1 scope includes setting up the registries & masters in the core, assessments module & LMS module.

Platform Architecture

A layered architecture is envisioned for building the platform with a **_Core Layer _**including the registries, credentials and masters as per defined standards and specifications. Above that is the **_Transaction Layer _**with transactional event data storage, intelligence engine, and communication engine. The Application Layer includes the five functional modules (described in the previous section) and platform UI. An open API layer connects the core with the application layer.

The platform will be built leveraging open-source Sunbird building blocks, which form the base of Ministry of Education’s (MoE) DIKSHA platform and Department of Personnel and Training’s (DoPT) human resource management platform, iGOT. Having Sunbird form the base of the UP HRH platform, will allow it to be contributed back to Sunbird repository for use by any other government entity in the country.

The diagram below highlights the Sunbird building blocks that will be used to build different components of the platform.

Platform Building Blocks

The following table summarises the different blocks that will form part of the platform and their status of readiness along with the work required to integrate them into the platform.

#	Layer	##	Block	Readiness	Work Required
1	Open Data Standards	1.1	Schemas	To be Built	- To be defined in a generic manner for DPG abstraction
2	Registries and Masters	2.1	Sunbird Lern	Modification Needed	- Enable OIDC / SSO based authentication - Modify authorization instance to manage custom roles
		2.2	Sunbird RC	Modification Needed	- To be deployed as per specified schema - Brownfield approach to insert existing data
		2.3	Sunbird Knowlg	Ready for Use	- Integrating functions, roles, activities and competencies (FRAC) framework
3	Telemetry Events	3.1	Sunbird Obsrv	Ready for Use	- Designing telemetry objects - Creating data products for dashboarding
4	Transactional Data	4.1	Backend	To be Built	- Backend to be setup and managed
4	Intelligence	4.1	Drools	Modification Needed	- Needs to be implemented in UP context (defining rules and triggers) - UI to be modified (Drools UI needs fixing) - Needs to be integrated with Sunbird Obsrv
5	Communication	5.1	Sunbird UCI	Modification Needed	- Admin UI / functionalities will need to be added (manage notifications)
6	Unified Capacity Building APIs	6.1	Open APIs	To be Built	- Sunbird APIs can be leveraged (will need to be selected and defined) - Some additional APIs will need to be written
7	Existing Systems (admissions, attendance, etc.)	7.1	Data Transfer	To be Built	- Scaling for admissions / attendance data transfer (ongoing) - Legacy data transfer for affiliation, exam results (one-time)
8	Reform Modules (accreditation, assessments)	8.1	Sunbird inQuiry	Ready for Use	- Building a mobile app / container for deploying forms
		8.2	Sunbird CoKreat	Ready for Use	- Adding question types: DocInput and DatePicker - Creating workflows out of data-collection forms
9	Reform Modules (verifiable resume)	9.1	Sunbird RC	Modification Needed	- Verifiable Resume: To be implemented in Sunbird RC
10	Reform Modules (aspirational profession)	10.1	Sunbird RC	Ready for Use	- Jobs: Data to be pushed back to Sunbird RC
		10.2	Sunbird Lern	Modification Needed	- LMS: Content marketplace to be setup, courses searchable by FRAC elements
		10.3	Sunbird Knowlg	Modification Needed	- Jobs: Needs to be contextualised for job discovery & lifecycle management
11	Platform Interface	11.1	Sunbird Ed	Modification Needed	- Frontend to be developed contextualised for UP leveraging SunbirdEd UI framework

User Registries

1. Registry Entities

All user entities will be registry compliant to ensure privacy of users’ personal information. Registries allow each user to be in control of their data and can customise which applications (including the frontend of the platform) can access their personal details. A registry-compliant construct ensures that registry specific functionalities can be activated for all modules of the platform.

Sunbird RC will form the base that houses all user entity information to enable secure and privacy-enabled user management.

Currently, a UPSMF portal - CASA, (https://upsmfac.org/) is being used for several functionalities, additional to the modules mentioned in the previous section. The database is powered by MS SQL which houses details of these entities.

Each user on the platform will be part of a registry and will have a unique process of getting onboarded (access & authentication) to the platform. Different workflows have been defined to enable this onboarding process.

The following approach will be followed to ensure a **_single source of truth _**for entity information and **_registry compliance _**for the platform overall.

#	Scenario	Approach
1	Functionalities on CASA being used in parallel to the new UP HRH platform	- CASA to remain as the single source of truth for core entities - students, institutes and faculty - A copy of these entities to be created as registries on Sunbird RC, with the ability to update entries as changes occur in the CASA databases
2	CASA functionalities fully migrated to UP HRH platform and the old platform is sunset	- Set up registries to function as the sole source of truth with full CRUD capabilities (no parallel database maintained on CASA)

Below are the key registry entities with a link to their proposed schema, functions & onboarding workflow:

#	Entity	Current DB (CASA)	Proposed Schema	Functions to be Performed
1	Candidate (Part of User DB)	Master_Student Details	Link	Create: new entity can come from two sources: - students admitted to courses on CASA/ NIC’s admissions portal (once made) - professionals self-register as part of the jobs discovery module (R5) \ Read: Allow admin (state dept.) to view all details through search or filter options (attributes indicated in schema) Update: Only the admin is able to update certain attributes in the schema. These are: - residential address (district, block etc.) - contact details: email, mobile number Delete: Cannot delete - only assign ‘inactive’ status (e.g., dropout student, terminated professional)
2	Institute	Master_College Registration_ Dental_Medical	Link	Create: The information of existing institutes will be fetched from CASA. Read: Allow admin (state dept.) to view all details through search or filter options (attributes indicated in schema) Update: Only the admin is able to update certain attributes in the schema. These are: - contact details: email, mobile number - Institute head details - Location details Delete: Cannot delete - only assign ‘closed’ status
3	Faculty (Part of User DB)	- Details of institute faculty exist in table Master_Institute Tutor	Link	Create: No creation allowed, data pulled in from state database (provided by institute) Read: Allow admin (state dept.) to view all details through search or filter options (attributes indicated in schema) Update: Only the admin is able to update certain attributes in the schema. These are: - contact details: email, mobile number - Location details Delete: Cannot delete - only assign ‘inactive’ status
4	Workplace	Records exist - but not complete	Link	Create: Workplaces can self-register to provide job listings (R5), update employee work history and access verifiable resumes (R4) Read: Allow admin (state dept.) to view all details through search or filter options (attributes indicated in schema) Update: Only the admin is able to update certain attributes in the schema. These are: - contact details: email, mobile number - Location details Delete: Cannot delete - only assign ‘inactive’ status
5	Third Party Entities	Admin approved	TBD	There will be certain module specific entities which will be onboarded on the system by the admin. These entities will not be a part of the CASA system. In Assessments, there will be QR_C, QR_M, PIAA Setter & PIAA_Nodal. And in Ratings, there will be a medical assessor and a non medical assessor. Create: Admin should be able to onboard these third party entities onto the platform through a predefined workflow. Read: Allow admin (state dept.) to view all details through search or filter options (attributes indicated in schema) Update: Only the admin is able to update certain attributes in the schema. These are: - contact details: email, mobile number - Location details - Role details Delete: Can delete or reassign roles to users

There will be different workflows to onboard users onto the platform. These workflows will be defined

< INSERT BLOCK DIAGRAM >

Roles

Ideal State: Roles are defined by the admin and each role is mapped to a series of permissions (global or module specific). Each user of the platform can be mapped to one or multiple roles and all permissions mapped to these roles will be allowed.

Roles will have varying functions depending on the module. The following table lists the modules, suggested applicable roles and suggested authorization for these roles as part of the module.

Roles	Permission
Admin	1. Can view state level analytics 2. Can view telemetry of the platform 3. Can set/reset role level permissions at a module level 4. View all transactional data
Admin	1. Can create data entry forms for ratings 2. Can assign data entry forms to medical/non medical assessors 3. Can view / edit data entry forms received by medical/non medical assessors 4. Can schedule on-ground visits 5. Can reject / request for update of forms
Institute	1. Can view / edit assigned data entry forms 2. Can update forms returned by admin
Medical / Non Medical Assessor	1. Can view / edit assigned data entry forms 2. Can view schedule of visit 3. Can provide feedback for ratings in the module
QR_C	1. Can create new question-sets for assessment 2. Can bulk upload new questions in laid out format 3. View reason of rejection if a QR_M rejects a question 4. Tag a question to competency level
QR_M	1. Can view questions submitted by QR_C 2. Can accept or reject a question 3. Can write a reason for rejection for a question 4. Can edit mapping of a question to a competency
PIAA Setter	1. Can set the blueprint of assessment 2. Can compose assessments packages from questions in directory
PIAA Nodal	1. Can start an assessment for a candidate 2. Can pause/ stop the assessment of a candidate
Candidate	1. Can start a self assessment by entering defined parameters (Eg. roll number/ DOB) 2. View questions in assigned set 3. View the correct answers to assessments 4. View the marks awarded for each assessment 5. View/Download a report card for self assessment & a certificate for proctored assessment at the PIAA centre 6. Report discrepancy in marks
Admin	1. Can issue certificates 2. Can onboard third party entities onto the platform through defined workflow 3. Can reassign roles of users within the module
Admin	1. Can define parameters to be enabled as part of the verifiable resume
Hospital / Institute	1. Can enter work experience / educational details for a candidate
Hospital / Institute	1. Can view details contained in the verified resume of a candidate
Hospital	1. Can post job vacancies on the portal 2. Can view candidate profiles and notify interested candidates
Institute	1. Can provide details of batch placement
Candidate	1. Can search for posted jobs 2. Can apply to posted jobs 3. Can report status of successful employment
Content Provider	1. Can upload content pieces and organise into courses 2. Can tag courses to elements of the FRAC framework
Candidate	1. Can register on the platform and add their Position (FRAC) 2. Can attempt a self-assessment to identify weak competencies 3. Can view recommended courses (as per identified competencies) 4. Can save courses to attempt later 5. Can view content under a course (video, text) 6. Can attempt assessment post course completion 7. Can receive and save a badge to profile on course completion
Admin	1. Can view courses curated by content providers 2. Can review course and approve for publishing 3. Can return / reject course in case of improper tagging / content

Module level - Role entity mapping

Masters

Masters of different types will need to be established to enable consistency in attributes being stored across tables in the database. The table below lists the masters to be created.

Bucket	#	Master	Link
1. Location Masters	1.1	State	link
	1.2	District	link
	1.3	Block	link
	1.4	Constituency	link
	1.5	Village	link
2. Competency Masters (see subsequent section)	2.1	Positions	-
	2.2	Roles	-
	2.3	Activities	-
	2.4	Competencies	-
3. Course Masters	3.1	Regulator	TBD
	3.2	Session	TBD
	3.3	Course	TBD

Competency Management

1. Understanding FRAC¹ framework Professional competence of each AHP student / faculty / professional will be tracked against a FRAC framework (incorporated in DOPT’s iGOT platform) which stands for functions, roles, activities and competencies.

Positions or functions refer to the job role of an individual, e.g., for a lecturer of the nursing degree course, the function is that of a _‘nursing faculty’. _The function of a student hired to administer anaesthesia in a district hospital, the function is that of an an ‘anaesthesia nurse’

Roles refer to bucketing, abstraction of activities that are to be performed by the individual in a particular position. E.g., a general nurse midwife (GNM) will have the following roles - manage normal delivery, caring for normal newborn etc.

Activities offer a higher level of detail and specificity over roles pertaining to a specific position. E.g., the activities for a GNM under the role ‘manage normal delivery’ can be - describe all markers of a normal delivery, describe all steps under normal delivery, perform all steps for normal delivery etc.

**Competencies **refer to the specific behavioural, domain and functional understanding / competence that the individual must possess to be able to successfully perform the activities mentioned above, Examples of competencies for a GNM include - understands components of normal delivery and second stage of labour, understands complications in PW and it’s management, etc. Each competency will have 3 to 5 levels which indicate the level of difficulty or proficiency for that competency.

2. Rules for Competency Management

• Each user (candidate / faculty) will get mapped to a single position i.e., no user will be mapped to 2 or more positions
• Each position will map to a set of roles
• A role can be mapped to one or more positions i.e., mapping of roles to positions is not in a strict hierarchy
• Roles are essentially logical aggregation / bucketing of activities
• An activity can map to more than 1 role - activity to role mapping is not unique
• An activity can map to two roles from either the same positions or two roles from different positions
• Every competency has 3 to 5 levels (L1, L2 and so on)
• Levels of a competency are progressive - i.e., L2 is more complex / difficult than L1, if a candidate is at CXL3, they will be proficient in CXL2 and CXL1
• Competency levels (CXLX) and not competencies (CX) map to activities
• Each activity should map to at least one competency level (CXLX)
• Every competency level should map to at least one activity
• Levels of the same competency can map to different activities (e.g., C1L1 to A1 and C1L2 to A2)
• One competency level (CXLX) can map to two or more activities (same or different role, same or different position)

3. Schemas of Competency Masters

The following table lists down the masters which will store all competency data for use in several modules of the platform.

#	Master	Description	Link
1	Position	Pre-service: course (e.g., ANM / GNM) Post-service: specific job role	link
2	Role	Pre-service: specific subjects under the course Post-service: bucketing of major activities covered under the function	link
3	Activity	Learning outcomes or specific activities to be covered under a position	link
4	Competency	Covers a specific competency / demonstrable outcome (pre or post service). Each competency is tagged to a competency type and competency area. Competencies also have 3-5 levels which denote difficulty of that competency	link

Notes

1. FRAC framework was developed as part of DOPT’s iGoT framework - link