Business Requirements Document (BRD)

Telemedicine, HWC and MMU

Version 1.0

Document Revision History

Table of Contents

Introduction 1.1 Document Purpose 1.2 About Piramal Swasthya

Scope of Work 2.1 Functional Specification Document: Test Severity Identification and Data Fidelity Validation

User Interface 3.1 Reports Section - Doctor Module

Functional Requirements 4.1 Test Severity Identification 4.2 Data Fidelity Validation

Non-Functional Requirements

1. Introduction

1.1 Document Purpose

The purpose of this document is to capture and describe the business and application requirements of a change request that needs to be incorporated into the HWC (Health and Wellness Center), MMU (Mobile Medical Unit), and Telemedicine applications.

NOTE: This version of the BRD (Business Requirements Document) / SRS (Software Requirements Specification) is subject to changes depending on the feedback provided during the course of document evaluations by various stakeholders. A final version of the BRD will be shared once there is an official sign-off by the stakeholders on agreeing to freeze the requirements.

1.2 About Piramal Swasthya

Piramal Swasthya Management and Research Institute (PSMRI) is an initiative under the aegis of Piramal Foundation and is one of the largest not-for-profit organizations in India. Piramal Swasthya aims to bridge the public healthcare gaps by supplementing and complementing the Government of India's vision to achieve Universal Health Coverage. It focuses on Maternal, Child, and Adolescent Health, as well as Non-communicable Diseases in the primary public healthcare space.

Piramal Swasthya operates several healthcare innovations at scale to address the primary healthcare needs of underserved and marginalized populations across India. One of its innovations is the AMRIT (Accessible Medical Records via Integrated Technologies) platform, a digital health platform that stores electronic health records of beneficiaries for use in public primary healthcare service delivery and decision-making. The platform enables the connection between beneficiaries, health facilities, and frontline workers in an integrated ecosystem through technology.

The services and features under the AMRIT platform include:

• HWC Application: A comprehensive application with 12 service packages.
• MMU Application: Offline and online application to support operations in outreach programs.
• HIHL Application: Helpline CRM to support services like 104, 1097, MCTS, and ECD with inbound and outbound facility.
• Telemedicine Solution: Video consulting facility.
• Smart Phone Applications: SAKHI/ Utprerona Android Mobile App for ASHAs.
• Point of Care Device: AMRIT is integrated with PoCT devices like Fetosense and Healthcube, etc.
• ABDM Compliant: AMRIT is integrated with ABDM for ABHA with all three milestones (M1, M2, M3).

1. Scope of Work

2.1 Functional Specification Document: Test Severity Identification and Data Fidelity Validation

1. Introduction

The objective of the data fidelity validation is to ensure the accuracy and reliability of the provided clinical test results within the specified test ranges. This validation process involves checking if the data falls within the minimum and maximum values for each test and whether the results are within the defined normal range for clinical interpretation. The Test Severity Identification feature will categorize the test results as high, low, or medium based on predefined ranges.

1. Scope

This section defines the scope of the Test Severity Identification and Data Fidelity Validation feature:

2.1 Test Severity Identification

The Test Severity Identification feature will be implemented in the Medical Information System and will involve the following components:

• Test Parameters: Test Name, Subcomponent, Test Units, Test Field Validations, Test Result Clinical Interpretations.
• Test Severity Categorization: The system will categorize the test results as high, low, or medium based on predefined ranges for each test parameter.

2.2 Data Fidelity Validation

The Data Fidelity Validation will be applied to the Reports section in the Case Record section of the Doctor module and will display the results based on the range of parameters, color coding, and clinical interpretations.

1. User Interface

3.1 Reports Section - Doctor Module

The Reports section in the Case Record section of the Doctor module will display the test results with the following elements:

1. a) Test Name: The name of the conducted test.
2. b) Subcomponent: The subcomponent of the test.
3. c) Test Units: The units in which the test is measured.
4. d) Test Field Validations: The predefined minimum and maximum values for the test.
5. e) Test Result: The actual test result value.
6. f) Test Severity: The categorization of the test result as high, low, or medium based on the predefined ranges.
7. g) Color Coding: Color coding to visually indicate the test severity (e.g., red for high, yellow for medium, green for low).
8. h) Clinical Interpretations: Clinical interpretations of the test results provided by the doctor and lab technician.

Note :-Reports section should also be configurable from the Admin Module for the color coding

1. Functional Requirements

4.1 Data Fidelity Validation

1. a) Display Test Results: The Reports section in the Case Record of the Doctor module should display test results along with their corresponding Test Severity, Color Coding, and Clinical Interpretations.
2. b) Color Coding: The system should apply the appropriate color coding (e.g., red, orange, green) to visually indicate the test severity level.

Data Fidelity Validations - Reference Ranges

The below mentioned point outlines the reference ranges for various medical test parameters. These reference ranges are utilized for data fidelity validations and serve as guidelines for evaluating the validity of test results. The ranges are determined based on clinical standards and are intended to assist in interpreting the clinical significance of test outcomes

 Lab Investigations

Lab Test Field Definitions and Validations

As per the above screen RBS is updated as 60 which is red and that means the severtity is at High Risk

Dynamic Color Coding for Test Results in Doctor Module Based on Beneficiary's Age, Gender, and Severity

In the Doctor Module, a dynamic color-coded system for test results is proposed to enhance visual representation and understanding. This system aims to assign colors such as Red, Orange, and Green to test results, considering the age and gender of the beneficiary as well. Moreover, the severity of the test results within these color categories will be tailored to align with the age and gender attributes of the beneficiary.

There are two scenarios here which are

Scenario 1: High-Risk Female Beneficiary (e.g., pregnancy):

Red category tests related to pregnancy complications may be prioritized.

Scenario 2: Age-Related Tests for Cardiovascular Health:

Beneficiaries in a certain age range may have additional cardiovascular tests in the orange category.

Below are the Information which shows the Test results as well as the clinical Interpretations

1. Non-Functional Requirements

1. a) Security: The application must implement proper authentication and authorization mechanisms to ensure that only authorized users can access test results and modify test parameters.
2. b) Performance: The system should handle multiple concurrent requests efficiently and respond quickly.
3. c) Usability: The user interface should be user-friendly and intuitive for doctors and lab technicians to interpret test results easily.
4. d) Compatibility: The Doctor module and Lab Technician module should be compatible with major web browsers.