Core-PRD.md

Niramaya

Platform Core PRD

Registries & Masters

Entity & Role Management

September 2022

Glossary/ Acronyms_

CB	Capacity building
FRAC	Framework of Roles, Activities and Competencies
iGOT	Integrated Government Online Training
MCQ	Multiple choice questions
PIAA	Proctored independent, authorised assessment
PRD	Product requirement document
QR	Questions repository
QR_C	Questions repository contributor
QR_M	Questions repository manager
SOP	Standard operating procedure
UPTSU	Uttar Pradesh technical support unit
UP SMF	Uttar Pradesh State Medical Faculty
NIC	National Informatics Centre
CASA	Council Automation Smart Application

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. Candidates - Students enrolled in GNM/ANM courses & professionals
2. Institutes - All government & private medical institutes offering GNM/ANM courses
3. Workplace - Hospitals or healthcare centres where the graduating students are or can be employed
4. Regulatory Body - UP SMF, UP-TSU and other allied departments
5. QR_C
6. QR_M
7. PIAA Setter
8. PIAA Nodal
9. Medical & Non Medical Assessors (for institute verification and ratings)
10. 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

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.

>>>>> gd2md-html alert: inline image link here (to images/image1.png). Store image on your image server and adjust path/filename/extension if necessary.
(Back to top)(Next alert)
>>>>>

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.

>>>>> gd2md-html alert: inline image link here (to images/image2.png). Store image on your image server and adjust path/filename/extension if necessary.
(Back to top)(Next alert)
>>>>>

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 _**for1, 2,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	Regulatory Body	Currently does not exist	TBD	Create: - Entities in the Assessments Module : QR_C, QR_M, PIAA Setter, PIAA Nodal - Issue certificates to candidates who have successfully passed assessments Read: - State/District level analytics - Telemetry events as defined Update: - Entity - Role Mapping - This control will be with the regulatory body Delete: - Cannot delete but can mark an entity - role inactive
2	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)
3	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
4	Faculty (Part of User DB)	- Details of institute faculty exist in table Master_Institute Tutor	Link	Create: No creation allowed, data pulled in fromCASA 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	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
6	QR_C	Currently does not exist	TBD	Create: - Questions in the Assessments module - Bulk upload questions through a csv Read: - Questions that he has created - Edits made by QR_M - Summary of submitted, approved & rejected questions Update: - Questions based on review suggestions provided by QR_M Delete: - Self created questions before submitting them for review
7	QR_M	Currently does not exist	TBD	Create: - Does not create anything Read: - Questions that QR_C has created - Edits made by QR_C - Summary of submitted, approved & rejected questions Update: - Edit questions submitted by QR_C - Reject questions submitted by QR_C - Adds comments for rejected questions Delete: - Cannot delete - can only reject
8	PIAA Setter	Currently does not exist	TBD	Create: - Create blueprint of assessments by defining the competency, competency levels to be tested Read: - View the assessments that have been created Update: - Edit the blueprint of assessments Delete: - Cannot delete
9	PIAA Nodal	Currently does not exist	TBD	Create: - Begin the assessment for a candidate - Certificates for the candidates Read: - View the available assessments Update: - Cannot edit Delete: - Cannot delete
10	Medical Assessor	Currently does not exist	TBD	Update: - Can view and administer assessments - Can enter student performance in the assessment
11	Non Medical Assessor	Currently does not exist	TBD

Entity Role Management

An ** entity **is any individual or organisation that will be using the platform.

Permission is an action that an entity will be entitled to perform.

**Role **is a group of permissions bunched together. **Roles **can be global or module specific.

An **entity **will be mapped to one or more **roles **and each role will have a set of one or more **permissions **within it.

This list of permissions, roles & their mapping to entities only covers the Assessments & Ratings modules currently and will expand as we scope out more modules.

Dictionary of roles & permissions:

Roles	Permission	Module
Super 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 5. Perform entity - role management 6. Can issue certificates to candidates undertaking assessments	Across modules
Admin_E Cred	1. Can enter work experience / educational details for a candidate	E credentials
Admin_Assessments	1. Can issue certificates to candidates undertaking assessments	Assessments
Admin_LMS	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	Aspirational Profession (LMS)
Admin_Ratings	1. Can create data entry forms 2. Can assign data entry forms 3. Can view / edit data entry forms 4. Can schedule on-ground visits 5. Can reject / request for update of forms	Ratings & Affiliation
Repository Contributor	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	Assessments
Repository Manager	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
Question Paper Setter	1. Can set the blueprint of assessment 2. Can compose assessments packages from questions in directory
Test centre Nodal	1. Can start an assessment for a candidate 2. Can pause/ stop the assessment of a candidate
Test Taker	1. Can start a self assessment by entering defined parameters (Eg. roll number/ DOB) 2. Can view questions in assigned set 3. Can view the correct answers to assessments 4. Can view the marks awarded for each assessment 5. Can view/Download a report card for self assessment & a certificate for proctored assessment at the PIAA centre 6. Can report discrepancy in marks
E cred verifier	1. Can enter candidates’ workplace & institute details 2. Can view details contained in the verified resume of a candidate	E Credentials
Job curator	1. Can post job vacancies on the portal 2. Can view candidate profiles and notify interested candidates
Placement verifier	1. Can provide details of batch placement
Job Seeker	1. Can search for posted jobs 2. Can apply to posted jobs 3. Can report status of successful employment	Aspirational Profession (LMS)
Content Provider	1. Can upload content pieces and organise into courses 2. Can tag courses to elements of the FRAC framework
Learner	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

Entity - Role Mapping at a Module Level

Roles	Entity	Module
Super Admin	Regulatory body	Across Modules
Admin_E Cred	Regulatory body	E Credentials
Admin_Assessments	Regulatory body	Assessments
Admin_LMS	Regulatory body	Aspiration Profession
Admin_Ratings	Regulatory body	Ratings & Affiliation
Repository Contributor	QR_C	Assessments
Repository Manager	QR_M
Question Paper Setter	PIAA Setter
Test centre Nodal	PIAA Nodal
Test Taker	Candidate
E Cred Verifier	Institute	E credentials
	Workplace
Job Curator	Workplace
Placement Verifier	Institute
Job Seeker	Candidate	Aspirational Profession (LMS)
Content Provider	Regulatory Body
Learner	Candidate

The focus in the Core Module for Entity - Role - Permission mapping is on the Assessments module that is in scope for Q1. The other mappings will get fleshed out more when the PRDs and workflows for the other modules are taken up.

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

>>>>> gd2md-html alert: inline image link here (to images/image3.png). Store image on your image server and adjust path/filename/extension if necessary.
(Back to top)(Next alert)
>>>>>

• 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

Milestone Phasing

#	Category	Phase	Milestones	Sep	Oct	Nov
1	Platform Core	Requirements	Define Core PRD
			Define schema of registries and databases
			Define competency framework
		Setup	Setup Sunbird Ed (all building blocks)
			Setup registries on Sunbird RC
			Setup databases for common masters (location etc.)
			Sunbird Knowlg configured for tiered competency framework

In the Q1 scope of assessments, the competency masters will be uploaded in the backend by the engineering team.

Notes

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