See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/342004769

System Requirement Specification for Open Source Hybrid Ventilator

Technical Report · May 2020

DOI: 10.13140/RG.2.2.29744.79365

CITATIONS READS

0 1,264

1 author:

Kausik Bhattacharya
Indian Institute of Science
9 PUBLICATIONS   24 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Community shopping system View project

All content following this page was uploaded by Kausik Bhattacharya on 08 June 2020.

The user has requested enhancement of the downloaded file.

 System Requirement Specification
Open Source Hybrid Ventilator
CPDM, IISc

Revision History
Revision Revision Prepared by Description of Change Reviewed and
number Date Approved by
1.0 22/04/2020 Kavyashree Draft (under review)
Venkatesh, Consolidation of basic minimum and
Kausik supplementary requirements for
Bhattacharya ventilator intended to be used for
Covid-19 patients
 Document Name: SRS (System Requirement Specification)
UTSAAH
Document Number: Document Revision: 1.0 Effective Date:
UTSAAH/SRS/001

Table of Contents
1. INTRODUCTION ........................................................................................................................................................................ 3
1.1. PURPOSE AND SCOPE ............................................................................................................................................................................... 3
1.2. REFERENCES ............................................................................................................................................................................................. 3
1.3. DEFINITION, ACRONYMS, OR ABBREVIATIONS.................................................................................................................................... 3
2. PRODUCT DESCRIPTION ....................................................................................................................................................... 4
2.1. PRODUCT OVERVIEW............................................................................................................................................................................... 4
2.2. USER CLASSES AND CHARACTERISTICS ................................................................................................................................................ 4
2.3. ASSUMPTIONS AND DEPENDENCIES...................................................................................................................................................... 4
2.4. CONSTRAINTS ........................................................................................................................................................................................... 4
2.5. OPERATING ENVIRONMENT ................................................................................................................................................................... 5
2.6. USER DOCUMENTATION .......................................................................................................................................................................... 5
3. REQUIREMENTS ....................................................................................................................................................................... 5
3.1. EXTERNAL INTERFACE REQUIREMENTS............................................................................................................................................... 9
3.1.1 User Interfaces ................................................................................................................................................................................. 9
3.1.2 Hardware Interfaces ..................................................................................................................................................................... 9
3.1.3 Software Interfaces ....................................................................................................................................................................... 9
3.1.4 Communications Interfaces ...................................................................................................................................................... 10
3.2. FUNCTIONAL REQUIREMENTS............................................................................................................................................................. 10
3.2.1 Functional requirement 1 ............................................................................................. Error! Bookmark not defined.
3.2.2 Functional requirement 2 ............................................................................................. Error! Bookmark not defined.
3.2.3 So on........ .............................................................................................................................. Error! Bookmark not defined.
3.3. NON FUNCTIONAL REQUIREMENTS ................................................................................................................................................... 10
3.3.1 Performance Requirements ...................................................................................................................................................... 10
3.3.2 Safety Requirements ...................................................................................................................................................................10
3.3.3 Security Requirements ............................................................................................................................................................... 11
3.3.4 Software Quality Attributes ..................................................................................................................................................... 11
3.4. DATA MANAGEMENT............................................................................................................................................................................ 11
3.5. STANDARDS COMPLIANCE ................................................................................................................................................................... 11
3.6. OTHER REQUIREMENTS ....................................................................................................................................................................... 12
4. USER SCENARIOS/USE CASES ............................................................................................................................................ 12
5. REQUIREMENTS TRACEABILITY MATRIX ..................................................................................................................... 12

Page 2
of 12
 Document Name: SRS (System Requirement Specification)
UTSAAH
Document Number: Document Revision: 1.0 Effective Date:
UTSAAH/SRS/001

1. Introduction
1.1. Purpose and Scope
Describe the purpose of this specification and its intended audience. Include a description of what is
within the scope and what is outside of the scope of this specification.

The System Requirements Specification document provides a brief outline on various requirements
and scope of Open Source Hybrid Ventilator intended to be used during COVID 19 pandemic. The
derived requirements of the system are from multiple sources which includes, requirements
derived from user needs; technical requirements from standards and literature [1,2,3,4].

Designer will decide on the applicability of these requirements depending on the use case scenarios
and make appropriate provision in design.

Design requirements are divided into following two parts [5]:

• Part A: “Minimum” requirements – These are minimum design requirements that every
design must satisfy for meaningful performance of the ventilator for COVID-19 patients.
• Part B: “Supplemental” requirements – In addition to the minimum mandatory
requirements, there could be additional requirements for safe operations.

Designer must decide applicability of Part B requirements depending on the use case scenarios and
make appropriate provision in design.

This document is applicable to designers and stakeholders of the system.

1.2. References
Provide the list of all documents to which this SRS refers.

1. Clinical management of severe acute respiratory infection (SARI) when COVID-19

disease is suspected. Source: https://www.who.int/publications-detail/clinical-
management-of-severe-acute-respiratory-infection-when-novel-coronavirus-(ncov)-
infection-is-suspected
2. Rapidly Manufactured Ventilator System – MHRA. Source:
https://www.gov.uk/government/publications/specification-for-ventilators-to-be-used-
in-uk-hospitals-during-the-coronavirus-covid-19-outbreak
3. MIT E-Vent | MIT Emergency Ventilator. Source: https://e-vent.mit.edu/
4. Personal communication from Dr. Supreet Khare, document received on 2nd April 2020.
5. Lung Ventilators for Medical Use — Particular Requirements for Basic Safety and
Essential Performance, IS/ISO 10651-6: 2004
6. Product Requirements Document PB560-520, Medtronic PB560 – ventilator system file

1.3. Definition, Acronyms, or Abbreviations

Provide the definitions of all terms, acronyms, and abbreviations required to properly interpret
the SRS.

Page 3
of 12
 Document Name: SRS (System Requirement Specification)
UTSAAH
Document Number: Document Revision: 1.0 Effective Date:
UTSAAH/SRS/001

• PIP- Peak Inspiratory Pressure

• TV– Tidal Volume
• MV- Minute Volume
• PEEP- Positive End Expiratory Pressure

2. Product Description
2.1. Product Overview
Describe about the product and its intended audience and mention the major components of the
larger system, interconnections, and external interfaces, etc..

The ventilator is designed to be used during the current COVID- 19 pandemic with minimal
requirements and clinical specifications. It is for devices, which are most likely to confer
therapeutic benefit on a patient suffering with ARDS caused by SARS-CoV-2, used in the initial
care of patients requiring urgent ventilation.[2]

2.2. User Classes and Characteristics

Identify the various user classes that you anticipate will use this product. User classes may be
differentiated based on frequency of use, subset of product functions used, technical expertise,
security or privilege levels, educational level, or experience. Describe the important
characteristics of each user class. Certain requirements may pertain only to certain user classes.

This section is not applicable, as no user classes are required for ventilator design.

2.3. Assumptions and Dependencies

Describe the assumptions that can affect the requirements for e.g, equipment availability, user
expertise or issues around the development and operating environment, etc. Also identify any Also
identify any

The ventilator is designed with the intention of utilizing the system in various types of
healthcare facilities including resource constrained settings. The main assumptions are the
availability of trained clinicians for the usage of ventilator. The design of the ventilator
comprises of multiple sensors for various functionalities and there exists a huge dependency
on the availability of these sensors to be used in the system.

2.4. Constraints
Describe any major constraints of the system including architecture, design, and implementation
constraints

The major constraints in manufacturing of ventilators in India is availability of various

pressure and flow sensors during COVID 19 crisis.

Page 4
of 12
 Document Name: SRS (System Requirement Specification)
UTSAAH
Document Number: Document Revision: 1.0 Effective Date:
UTSAAH/SRS/001

2.5. Operating Environment

Describe the environment in which the system will operate, including the hardware platform,
operating system and versions, and any other software components or applications with which it
must interface and coexist.

The ventilator is intended to be used at various healthcare settings to treat patients suffering
from COVID19 and other respiratory failures.

2.6. User Documentation

List the user documentation components (such as user manuals, on-line help, and tutorials) that
will be delivered along with the software.

• Instruction Manual providing instructions on how to use the system

• The Design specification document of the system will also be provided to the users

3. Requirements
Describe all system requirements in enough detail for designers to design a system satisfying the
requirements and testers to verify that the system satisfies requirements. Describe every input into the
system, every output from the system, and every function performed by the system in response to an
input or in support of an output. Each requirement should be numbered (or uniquely identifiable) and
prioritized.

The following definitions are intended as a guideline to prioritize requirements.

• Priority 1 – The requirement is a “must have” as outlined by policy/law

• Priority 2 – The requirement is needed for improved processing, and the fulfillment of the
requirement will create immediate benefits

• Priority 3 – The requirement is a “nice to have” which may include new functionality

In this document, the requirements are prioritized as “minimal” requirements and “supplementary”
requirements as explained in section 1.1 (Purpose and Scope). The Table 1 comprises of various
minimal and basic requirements derived from clinical needs. Table2 consists of supplementary
requirements comprising of regulatory requirements, manufacturing requirements and other
design related requirements.

Minimal Requirements

Subsystem System Requirement

Requirement
ID
Ventilation 1 The system must include Volume Controlled Mode of Ventilation (VCV)

Ventilation 2 Plateau pressure must be limited to 30 cm H20

Page 5
of 12
 Document Name: SRS (System Requirement Specification)
UTSAAH
Document Number: Document Revision: 1.0 Effective Date:
UTSAAH/SRS/001

Subsystem System Requirement

Requirement
ID
Ventilation 3 Peak Inspiratory pressure (PIP) must be limited to 40 cm H20. Design
may include option to allow Maximum pressure at 70 cm H20 for short
period operations.
Ventilation 4 A mechanical failsafe valve should open at the upper limit of 40cm H20

Ventilation 5 PEEP Must be adjustable within the allowable range of 5-30 cm H20

Ventilation 6 Incremental value of PEEP must be less than or equal to 3cm H20

Ventilation 7 Patient breathing system must always remain pressurized to at least the
PEEP level
Ventilation 8 Inspiration Time must be in the range of 0.7 – 2.0s

Ventilation 9 Incremental value of Inspiratory Time must be 0.1s

Ventilation 10
Respiratory rate Must be adjustable within the allowable range 8-40 BPM
Ventilation 11 Incremental value of Respiratory Rate must be 2 BPM

Ventilation 12 Tidal volume must be within the allowable range of 200-800ml

Ventilation 13 Incremental value of Tidal volume must be 50 ml

O2 to 14 User must be able to control inspired oxygen proportion (FiO2) in the

patients range variable between 20 – 100 % in 5% steps
Infection 15 HEPA filtration on the patient’s exhalation is required or between the
Control ventilator unit and the patient (at the end of the endotracheal tube) to
protect clinical staff from certain infection
Infection 16 Heat and moisture exchanger should be used
Control
Monitor and 17 Patients must be under the management and observation of a trained
Control clinician
Monitor and 18 System should display current settings and actually achieved rates of:
Control Plateau pressure, PEEP Air flow (Q), Tidal Volume, FiO2, Minute
Ventilation, Respiratory Rate, Inspiration Time
Monitor and 19 The achieved rates of: Plateau pressure, PEEP Air flow (Q), Tidal Volume,
Control FiO2, Minute Ventilation, Respiratory Rate, Inspiration Time must be
monitored
Monitor and 20 There must be provision for clinicians to set the parameters based on
Control patient's condition
Table 1: Minimal Requirements

Page 6
of 12
 Document Name: SRS (System Requirement Specification)
UTSAAH
Document Number: Document Revision: 1.0 Effective Date:
UTSAAH/SRS/001

Supplementary Requirements

Subsystem System Requirement

Requirement
ID
All gas connectors and hoses must comply with BS EN
Gas and
ISO5359:2014+A1:2017, ISO 5359:2014/AMD 1:2017 and BS 2050:
Power Supply
21 1978 Electrical Conductivity
The system must connect to wall pipeline oxygen supply via BS
Gas and 5682:2015 compatible probes (Schrader). If hose not permanently fixed
Power Supply to machine, then must connect with NIST (Non-Interchangeable Screw
22 Thread to ISO 18082:2014/AMD 1:2017)
Gas and The system must have provision for a gas reservoir will be required to
Power Supply 23 manage peak inspiratory flow rates of up to 100 lpm
Gas and Average oxygen consumption must be no more than 3 lpm
Power Supply 24
Gas and The system can optionally connect to wall pipeline Medical Air (MA4,
Power Supply 25 NOT SA7) via BS 5682:2015 compatible probes.
The system can optionally connect to ISO 7396-2:2007 compatible
Gas and
Anesthetic Gas Scavenging System or an external activated charcoal
Power Supply
26 absorber
Gas and The system can optionally operate using an oxygen concentrator device
Power Supply 27 for input oxygen which will be limited to 10lpm
Gas and
Power Supply 28 The system should connect to 240V mains
Gas and
Power Supply 29 The system PAT tested to the adapted IEC 60601, IEC 62353 standards
Gas and The system must have 20 minutes back up battery in case of mains
Power Supply 30 electricity failure.
Gas and The system can include hot swappable batteries so that it can be run on
Power Supply 31 battery supply for extended period
Gas and The system must avoid harmful RF or EM emissions that could interfere
Power Supply 32 with other critical machinery
PATIENT BREATHING SYSTEMS CONNECTIONS:
The ventilator must present 22mm outside diameter (OD) ‘male’
Gas and
standard connectors to ISO 5356-1:2015 on both outlet and inlet ports
Power Supply
for connection to user supplied 22mm ‘female’ connectors on the
33 breathing system
PATIENT BREATHING SYSTEMS CONNECTIONS:
Gas and
The connectors must be rigid and robust (not plastic) and separated by a
Power Supply
34 minimum of 10 cm between centers to accommodate filter HMEs.
PATIENT BREATHING SYSTEMS CONNECTIONS:
Gas and
All elements in the gas pathway must meet biological safety and low-
Power Supply
35 pressure oxygen safety standards
Infection All parts coming into contact with the patient’s breath must be either
Control 36 disposable or able to be decontaminated between patients
Infection
Control 37 All external surfaces must be cleanable

Page 7
of 12
 Document Name: SRS (System Requirement Specification)
UTSAAH
Document Number: Document Revision: 1.0 Effective Date:
UTSAAH/SRS/001

Subsystem System Requirement

Requirement
ID
Infection
Control 38 The system must account for resistance from external HMEA filters
Infection The system can optionally include facility for hot water humidifier to be
Control 39 included in breathing system
Monitoring
and Alarms 40 Gas and Electricity supply failure alarms should be present
Monitoring Alarm should be given if machine is switched off while in mandatory
and Alarms 41 ventilation mode
Monitoring
and Alarms 42 Alarm to be given if Inspiratory airway pressure exceeded
Monitoring
and Alarms 43 Alarm to be given if Inspiratory and PEEP pressure not achieved
Monitoring
and Alarms 44 Alarm to be given if Tidal volume not achieved or exceeded
Monitoring In pressure support mode there must be real time confirmation of each
and Alarms 45 patient breath and an alarm if below acceptable range
Monitoring
and Alarms 46 The system can optionally include CO2 monitoring
Miscellaneous
47 The system must have 100% duty cycle for up to 14 days
The system must be ideally small and light enough to mount on patient
Miscellaneous
48 bed and orientation independent functioning or can be floor standing
Miscellaneous
49 The system must be as robust as possible
A doctor with some experience of ventilator use should be able to adapt
Miscellaneous
50 the system with basic training
The system must include 'Instructions for Use', ideally built into the
Miscellaneous labelling of the ventilator, mentioning all critical functions and controls
51 using standard terms, pictograms and colours
The design must have transparent design, supply chain, manufacture,
Miscellaneous
52 quality assurance and testing processes
The system must not be excessively cumbersome so that it would
Miscellaneous impede hospital operations or prevent easy movement within hospital
53 premises
The system must be made from materials and parts readily available in
Miscellaneous
54 the Indian supply chain, considering restricted movement.
Advisory standards: BS EN 794-3:1998 +A2:2009 Particular
Miscellaneous
55 requirements for emergency and transport ventilators
Advisory standards: ISO 10651-3:1997 Lung Ventilators for Medical Use
Miscellaneous
56 - Emergency and Transport
Advisory standards: BS ISO 80601-2-84:2018 Medical electrical
equipment. Part 2-84. Particular requirements for basic safety and
Miscellaneous essential performance of emergency and transport ventilators –
especially the parts on ‘patient gas pathway’ safety (very similar to IEC
57 60601)

Page 8
of 12
 Document Name: SRS (System Requirement Specification)
UTSAAH
Document Number: Document Revision: 1.0 Effective Date:
UTSAAH/SRS/001

Subsystem System Requirement

Requirement
ID
Advisory standards: ISO 80601-2-12:2020 Medical electrical equipment
Miscellaneous — Part 2-12: Particular requirements for basic safety and essential
58 performance of critical care ventilators
Advisory standards: BS ISO 19223:2019 Lung ventilators and related
Miscellaneous
59 equipment. Vocabulary and semantics
Table 2: Supplementary Requirements

3.1. External Interface Requirements

3.1.1 User Interfaces

Describe the logical characteristics of each interface between the software product and the
users. (e.g., required screen formats/organization, report layouts, menu structures, error
and other messages, or function keys).

The Requirements with the following System Requirement IDs can be classified as User
Interface Requirements SR06, SR09, SR11, SR13, SR14, SR18, SR20. Design should fulfill
these User Interface Requirements and additional User Interface Requirements identified
during design.

3.1.2 Hardware Interfaces

Describe the logical and physical characteristics of each interface between the software
product and the hardware components of the system. This may include the supported device
types, the nature of the data and control interactions between the software and the
hardware, and communication protocols to be used.

The Requirements with the following System Requirement IDs can be classified as
Hardware Interface Requirements SR28, SR33, SR34. Design should fulfill these
Hardware Interface Requirements and additional Hardware Interface Requirements
identified during design.

3.1.3 Software Interfaces

Describe the connections between this product and other specific software components
(name and version), including databases, operating systems, tools, libraries, and integrated
commercial components. Identify the data items or messages coming into the system and
going out and describe the purpose of each. Describe the services needed and the nature of
communications. Refer to documents that describe detailed application programming
interface protocols. Identify data that will be shared across software components. If the
data sharing mechanism must be implemented in a specific way (for example, use of a
global data area in a multitasking operating system), specify this as an implementation
constraint.

Software Interface Requirements are not applicable to this document.

Page 9
of 12
 Document Name: SRS (System Requirement Specification)
UTSAAH
Document Number: Document Revision: 1.0 Effective Date:
UTSAAH/SRS/001

3.1.4 Communications Interfaces

Describe the requirements associated with any communications functions required by this
product, including e-mail, web browser, network server communications protocols,
electronic forms, and so on. Define any pertinent message formatting. Identify any
communication standards that will be used, such as FTP or HTTP. Specify any
communication security or encryption issues, data transfer rates, and synchronization
mechanisms.

Communication Interface Requirements are not applicable to this document.

3.2. Functional Requirements

The Requirements with the following System Requirement IDs are classified as Functional
Requirements SR01, SR07, SR15, SR16, SR19, SR38, SR45. These are minimum clinical
requirements for a ventilator and there could be additional requirements as identified during
the design.

3.3. Non-Functional Requirements

3.3.1 Performance Requirements

Specify static and dynamic numerical requirements placed on the system or on human
interaction with the system:

• Static numerical requirements may include the number of terminals to be supported,

the number of simultaneous users to be supported, and the amount and type of
information to be handled.

• Dynamic numerical requirements may include the number of transactions and tasks
and the amount of data to be processed within certain time period for both normal
and peak workload conditions.

All of these requirements should be stated in measurable form. For example, "95% of the
transactions shall be processed in less than 1 second" rather than “an operator shall not
have to wait for the transaction to complete”.

The Requirements with the following System Requirement IDs can be classified as
Performance Requirements: SR02, SR03, SR05, SR08, SR10, SR12, SR23, SR24, SR30, SR47.
Designer may include additional performance requirements as identified during design.

3.3.2 Safety Requirements

Specify those requirements that are concerned with possible loss, damage, or harm that
could result from the use of the product. Define any safeguards or actions that must be
taken, as well as actions that must be prevented. Refer to any external policies or

Page 10
of 12
 Document Name: SRS (System Requirement Specification)
UTSAAH
Document Number: Document Revision: 1.0 Effective Date:
UTSAAH/SRS/001

regulations that state safety issues that affect the product’s design or use. Define any safety
certifications that must be satisfied.

The Requirements with the following System Requirement IDs can be classified as Safety
Requirements SR04, SR17, SR32, SR35, SR36, SR37, SR40, SR41, SR42, SR43, SR44.
Designer may include additional safety requirements as identified during design.

3.3.3 Security Requirements

Specify any requirements regarding security or privacy issues surrounding use of the
product or protection of the data used or created by the product. Define any user identity
authentication requirements. Refer to any external policies or regulations containing
security issues that affect the product. Define any security or privacy certifications that
must be satisfied.

Security Requirements are not applicable to this document.

3.3.4 Software Quality Attributes

Specify any additional quality characteristics for the product that will be important to
either the customers or the developers. Some to consider are: adaptability, availability,
correctness, flexibility, interoperability, maintainability, portability, reliability, reusability,
robustness, testability, usability and portability. Write these to be specific, quantitative, and
verifiable when possible. At the least, clarify the relative preferences for various attributes,
such as ease of use over ease of learning.

Requirements related to Software Quality Attributes are not applicable to this document.

3.4. Data Management

Specify the requirements for any information that is to be placed into a database, including types
of information used by various functions, frequency of use, data access rules, data entities and
relationships, integrity constraints, data retention, valid range, accuracy, and/or tolerance, units
of measure, data formats, default or initial values

Requirements related to Data Management are not applicable to this document.

3.5. Standards Compliance

Specify the requirements derived from existing standards, policies, regulations, or laws (e.g.,
report format, data naming, accounting procedures, audit tracing). For example, this could
specify the requirement for software to trace processing activity. Such traces are needed for some
applications to meet minimum regulatory or financial standards. An audit trace requirement
may, for example, state that all changes to a payroll database must be recorded in a trace file
with before and after values.

Page 11
of 12
 Document Name: SRS (System Requirement Specification)
UTSAAH
Document Number: Document Revision: 1.0 Effective Date:
UTSAAH/SRS/001

The Requirements with the following System Requirement IDs can be classified as
Requirements derived from Standards SR21, SR22, SR29, SR55, SR56, SR57, SR58, SR59.
Designer may include additional standards for compliance as identified during design.

3.6. Other Requirements

Define any other requirements not covered. This might include database requirements,
internationalization requirements, legal requirements, reuse objectives for the project, and so on.

The Requirements with the following System Requirement IDs can be classified as Other
Requirements SR25, SR26, SR27, SR31, SR39, SR46, SR48, SR49, SR50, SR51, SR52, SR53, SR54.

4. User Scenarios/Use Cases

Provide a summary of the major functions that the product will perform. Organize the functions to be
understandable to the customer or a first time reader. Include use cases and business scenarios, or
provide a link to a separate document (or documents). A business scenario:

• Describes a significant business need

• Identifies, documents, and ranks the problem that is driving the scenario

• Describes the business and technical environment that will resolve the problem

• States the desired objectives

• Shows the “Actors” and where they fit in the business model

• Is specific, and measurable, and uses clear metrics for success

User Scenarios and Use cases are not applicable to this document.

5. Requirements Traceability Matrix

The traceability matrix is used to verify that all stated and derived requirements from the business
requirements are associated with corresponding design elements, system components, modules and
other project deliverables. This is known as the forward trace. The RTM is also used to verify and
document the original source of the requirements so that if questions should arise by the customer
regarding why certain features were included, there is a comprehensive audit trail. This is known as
the backward trace.

So to ensure the requirement traceability, either you can create a table here or you can provide a
reference to a separate document (Preferably Excel sheet) where the complete traceability of
requirements available.

Requirements Traceability Matrix will be updated in a separate document.

Page 12
of 12

View publication stats