Emergency Use Ventilator Evaluation and Assessment: Open-Source

Hardware, Performance, Regulatory Requirements and Technology

Readiness

by

Soumya Ranjan Mishra

A thesis submitted in conformity with the requirements

for the degree of Master of Applied Science
Graduate Department of Applied Science and Engineering
University of Toronto

©Copyright by Soumya Ranjan Mishra, 2021.

 Emergency Use Ventilator Evaluation and Assessment:
Open-Source Hardware, Performance, Regulatory
Requirements and Technology Readiness.
Soumya Ranjan Mishra
Master of Applied Science
Graduate Department of Applied Science and Engineering
University of Toronto
2021

ABSTRACT
Emergency ventilators have attracted a lot of attention and resources during the COVID-19

pandemic due to which many groups have adopted open-source hardware development models.

This study reviews enforceable guidelines as presented by various public health agencies and

regulators and creates an assessment framework to determine the said system’s open-source

information, performance, and its compliance towards regulatory benchmarks. The study also

proposes a modified Technology Readiness Level (TRL) framework accommodating the relevant

changes in the development pathways due to emergency circumstances. Furthermore, it

investigates the efficacy of cardinal maturity assessment systems over preceding ordinal models.

A novel method of Weighted Technology Readiness Level (WTRL) is proposed to quantify the

degree of technology maturity of a system. The proposed model is then applied towards the

maturity assessment of emergency ventilation systems while highlighting its importance. The

model is also applied to ascertain the maturity of 7 NASA technologies and is compared against

pre-existing cardinal frameworks.

ii
ACKNOWLEDGMENTS
I take this moment to share my heartfelt gratitude for the encouragement, invaluable commentary,
and dedication my supervisor Professor Kamran Behdinan has shown. He introduced me to the
development of emergency use medical devices and took a steadfast approach for contributing
actively towards the COVID19 Pandemic. I am honoured to be presented with an opportunity to
work with him. This dissertation would not have been feasible without his genuine supervision,
patience, and constant encouragement.

I am thankful for the enormous support by Natural Sciences and Engineering Research Council of
Canada (NSERC), for contributing its precious resources for supplementing this study. [COVID19
NSERC Alliance Grants # ALLRP 550058 – 20].

I am especially thankful to Dr. Azad Mashari for sharing his knowledge and technique in
Anesthesiology and Ventilation. I would also like to thank and acknowledge Ms. Kate Kazlovich
for her keen insights. Her above and beyond aid has shaped this research extensively. I am grateful
to Mr. Nirmal Pol for his precious assistance and insights contributed.

I would wish to thank Dr. Jesse May, Dr. Aviv Gladman, and all members of my commission. I
am deeply thankful and hope to have expressed their outstanding guidance and true views.

Importantly, despite being mentioned after everyone else, I would like to sincerely thank my loved
ones: my parents, sister, and friends. This work was not possible without their unreserved love and
the sacrifices they have made on my behalf. I will forever be grateful for your love.

iii
 TABLE OF CONTENTS
LIST OF TABLES .............................................................................................................................. VI
LIST OF FIGURES ............................................................................................................................ VII
ACRONYMS ................................................................................................................................... VIII
1. INTRODUCTION ........................................................................................................................ 1
1.1. Motivation ....................................................................................................................... 3
1.2. Outline............................................................................................................................. 4
2. LITERATURE REVIEW ............................................................................................................... 5
2.1. Emergency Use Ventilators & Regulatory Affairs ......................................................... 5
2.2. Technology Readiness Level .......................................................................................... 7
3. METHODOLOGY ..................................................................................................................... 10
3.1. Overview of Currently Available Regulatory Guidelines on Emergency Ventilation
Systems ..................................................................................................................................... 10
3.2. Reconciliation of Terminology ..................................................................................... 11
3.3. Levels of Evaluation ..................................................................................................... 12
3.4. Mapping regulations (TRA) .......................................................................................... 13
3.5. WTRL ........................................................................................................................... 14
4. ASSESSMENT FRAMEWORK .................................................................................................... 16
4.1. Level 1: Open Access Availability ............................................................................... 16
4.2. Level 2: Performance Assessment: ............................................................................... 17
4.3. Level 3: Regulatory Compliance .................................................................................. 18
4.3.1. General Requirements ........................................................................................... 18
4.3.2. Risk Management Process .................................................................................... 19
4.3.3. Mechanical Design................................................................................................ 19
4.3.4. Electrical Design ................................................................................................... 20
4.3.5. Software Design .................................................................................................... 20
4.3.6. Human Factors ...................................................................................................... 21
4.3.7. Documentation ...................................................................................................... 21
5. CASE STUDY I ........................................................................................................................ 23
5.1. APPLYING THE FRAMEWORK ............................................................................................. 23
5.1.1. MIT E-Vent ........................................................................................................... 24
Assessment............................................................................................................................ 24
5.1.2. Apollo BVM ......................................................................................................... 25
Assessment............................................................................................................................ 25

iv
 5.1.3. Partially RepRapable automated open source BVM-based ventilator .................. 26
Assessment............................................................................................................................ 26
5.1.4. AIR Project ........................................................................................................... 27
Assessment............................................................................................................................ 27
5.2. Assessment Results ....................................................................................................... 28
5.2.1. Level 1 Assessment Results .................................................................................. 28
5.2.2. Level 2 Assessment Results .................................................................................. 29
5.2.3. Selection for development .................................................................................... 30
6. MEDICAL DEVICE DEVELOPMENT UNDER EUA ..................................................................... 31
6.1. Modified TRL ............................................................................................................... 31
6.2. Applying the Modified TRL ......................................................................................... 34
7. MULTI-LEVEL WTRL MATURITY ASSESSMENT .................................................................... 37
7.1. WTRL Maturity Assessment Method ........................................................................... 37
7.1.1. Step 1: Mapping sub-criteria ................................................................................. 38
7.1.2. Step 2: Cardinality of Sub-Criteria ....................................................................... 38
7.1.3. Step 3: Time Dependence ..................................................................................... 40
7.1.4. Step 4: Maturity Assessment ................................................................................ 40
7.2. Maturity Assessment of Emergency Use Biomedical Devices..................................... 41
8. CASE STUDY II....................................................................................................................... 44
8.1. Maturity Assessment of 7 Nasa Technologies .............................................................. 44
9. CONCLUSION.......................................................................................................................... 49
10. CONTRIBUTIONS ................................................................................................................ 50
11. FUTURE WORK................................................................................................................... 50
REFERENCES .................................................................................................................................. 51
APPENDIX A: LEVEL 1 ASSESSMENT CHECKLIST ........................................................................... 57
APPENDIX B: LEVEL 2 ASSESSMENT CHECKLIST ........................................................................... 64
APPENDIX C: AHP ADJUSTED TRL, CONROW [37]. ...................................................................... 67
APPENDIX D: BWM SOLVER RESULTS .......................................................................................... 68

v
 LIST OF TABLES
Table I: Level 1 Assessment Comparison ................................................................................................... 28

Table II: Level 2 Assessment Comparison .................................................................................................. 30

Table III: Assessment Summary .................................................................................................................. 30

Table IV: Modified Biomedical TRL for Emergency Ventilators .............................................................. 32

Table V: Required Standards for Development of Emergency Use Ventilator. .......................................... 33

Table VI: TRL Assessment Comparison ..................................................................................................... 36

Table VII: Quality Variable Designation .................................................................................................... 39

Table VIII: Local Weights of Subcriteria using BWM Method. ................................................................. 40

Table IX: Subcriteria Maturity Comparison ................................................................................................ 42

Table X: TRL 5 Maturity Comparison ........................................................................................................ 42

Table XI: Overall Maturity Comparison ..................................................................................................... 43

Table XII: TRL Transition Time of 7 NASA Technologies, Piesen et al. [66]. ......................................... 44

Table XIII: NASA Technologies Maturity Comparison ............................................................................. 45

Table XIV: Schedule Benchmarking of NASA Technologies. ................................................................... 46

Table A1: Level 1 Assessment Checklist .................................................................................................... 57

Table B1: Level 2 Assessment Checklist .................................................................................................... 64

Table C1: AHP Adjusted TRL, Conrow [37] ............................................................................................. 67

vi
 LIST OF FIGURES
Figure 1: MIT E-Vent, Massachusetts Institute of Technology [57]. .......................................................... 24

Figure 2: Apollo BVM, Prototype I, Rice University [59]. ......................................................................... 25

Figure 3: Partially Reprapable automated opensource BVM based ventilator [61]. ................................. 26

Figure 4: AIR Project, University of Waterloo [62]. .................................................................................. 27

Figure 5: EUA Approved Ventilators (24th March – 1st October, 2020) ................................................... 35

Figure 6: Mapping Sub-criteria influence on TRL ...................................................................................... 38

Figure 7: Maturity Progress of Technology at TRL 5. ................................................................................ 43

Figure 8: TRL Maturity, Forecast and Schedule Benchmarking using WTRL. .......................................... 47

Figure 9: (A) Cardinal Coefficients Calculated by Fahimian et al. (B) Normalized Aggregated Sum of

Maturity Time. ............................................................................................................................................. 47

Figure 10: WTRL Cardinal Coefficient. ...................................................................................................... 48

Figure C1: BWM Solver Results.................................................................................................................. 68

vii
 ACRONYMS
COVID19 Corona Virus Disease of 2019

ARDS Acute Respiratory Distress Syndrome

AHP Analytical Hierarchy Process

Association for the Advancement of Medical

AAMI
Instrumentation

BVM Bag Valve Mask

BWM Best Worst Method

CDRH Centre for Devices and Radiological Health

CS Collateral Standard

DRL Design Readiness Level

DMR Device Master Record

EUA Emergency Use Authorization

EUV Emergency Use Ventilator

FDA Food and Drug Administration

GS General Standard

HC Health Canada

HALO High Acuity Limited Operability

IRL Integration Readiness Level

MRL Manufacturing Readiness Level

MDCG Medical Devices Coordination Group

MECA Medical Equipment Compliance Association

viii
MHRA Medicines and Healthcare products Regulatory Agency

MDA Milestone Decision Authority

MCDM Multi Criteria Decision Making

OSHWA Open Source Hardware Association

PS Particular Standard

PDP Product Development Process

SARS Severe Acute Respiratory Syndrome

SRL System Readiness Level

TRA Technology Readiness Assessment

TRL Technology Readiness Level

TGA Therapeutic Goods Administration

WTRL Weighted Technology Readiness Level

ix
1. INTRODUCTION
Corona Virus Disease of 2019 (COVID19) discovered on 31st December 2019 was recognized
as a respiratory disease that causes Severe Acute Respiratory Syndrome (SARS) [1]. The disease
was then classified as a pandemic on 11th March 2020 by the WHO [2]. As of currently, on 17th
November 2020, a cumulative of 55,147,032 cases have been identified globally with a death toll
of 1,329,556. [3]. It was found that the disease exhibits symptoms which are typically mild-to-
moderate. However, in severe cases it was observed that patients can develop Acute Respiratory
Distress Syndrome (ARDS) [4].

According to a study conducted by Wu et al., it was found that most of the deaths resulted was due
to the onset of ARDS in patients [5]. The symptom causes severe inflammation of the lung
passages which prevents one from breathing, thus a patient is subjected to ventilator care for
treatment. Shortly thereafter, an acute shortage of ventilators was identified globally [6, 7].
Preliminary reports suggested that Ontario only had a few dozen ventilators per 100,000 people in
March [8]. Similar shortages were soon reported across the globe. The device vital to counter the
aftermath associated with the respiratory disorder has been heavily circulated through every
medical health care facility to sustain patients through the recovery cycle [9]. Hence a need for the
development of High Acuity Limited Operability (HALO) Open-Source Ventilators was identified
to facilitate the advent of this pandemic.

The importance of ventilators was realised to counter the ARDS, however, the world was caught
off guard with the sudden outbreak of COVID19. Several innovative developers proactively
provided short-scale affordable workarounds to provide automated resuscitation solutions over the
open channels. Some authors have proactively maintained online databases over numerous open-
access channels to supplement necessary information and resources towards the effective
utilization of these open-source designs [10, 11]. However, such solutions are not vetted for safe
usage in the infection ridden environment. Also, many such devices were found to be only
achieving a basic principle of operation and lacked any practical use as reported by clinicians. A
study conducted by Pearce highlighted the major discrepancies of open-source projects which
claim to provide effective solutions but were in only in prototype stages of development and
ineffective [12].

1
Due to exponential demand of such devices, many health care organizations such as Health Canada
(HC), Food and Drug Administration (FDA), Medicines and Healthcare products Regulatory
Agency (MHRA), Therapeutic Goods Administration (TGA), etc. released their respective sets of
minimal specifications which must be achieved by these emergency devices for authorized use
during the state of emergency. Although, majority of information was disclosed to encourage
emerging developers to create and release innovative solutions, the information was found to be
fragmented and highly complex for immediate assimilation.

Although several Product Development Process (PDP) models have been proposed to effectively
map the Medical Device Development process, they were found to be suitable for large enterprises
and would require large amount of investment and resources for their adaptation [30]. Therefore,
the need for a simpler and ingenious framework was identified to absolve these requirements. The
NASA’s Technology Readiness Level (TRL) framework which is tailored towards the
development of medical devices by the DOD’s Technology Readiness Assessment was found
suitable for this purpose. The overall process of technology development is then considered,
thereby, expanding the scope of observation. Due to the unique circumstantial requirements, the
need of iterating the 9 Levels of readiness towards the development of biomedical devices was
identified while considering the effects of the active Emergency Use Authorization (EUA).
Furthermore, it is observed that the framework used many qualitative parameters towards the
determination of the device’s safe functionality for the said purpose. Therefore, newer models for
carrying out quantitative evaluations of Biomedical technologies are investigated. A quantitative
model is formulated and applied to demarcate the intricacies of closely related systems using
cardinal factors.

This study utilizes the various directives and references to create a novel framework for identifying
and examining viable open source ventilatory devices. It provides a 3 Level assessment framework
for determining the usability of opensource design projects available. A revised biomedical TRL
is proposed while considering the relevant changes in the regulatory pathway during an emergency
declaration. The qualitative model is further supplemented with a cardinal TRL model to assess
the quantitative readiness of the said technologies and is compared against pre-existing
frameworks.

2
 1.1. MOTIVATION
The development of medical devices is an established and regulated process. However, with
the current demand of rapid development of such critical devices, the quality and safety factors
must be scrutinized before usage. An evaluation and development framework have thus been
formulated based on the current global needs in accordance with regulatory standards. The
framework is intended to provide a general overview to developers, investors, and clinicians to
grasp the nuances of performance in the development of these electromechanical systems. This
objective is accomplished with the formulation of a comprehensive 3-tiered framework of
Emergency Use Ventilator (EUV) assessment. Furthermore, a revised biomedical TRL model is
suggested to effectively track the development and readiness of these emergency use medical
devices under the EUA umbrella. The subjective framework is supplemented with a cardinal
maturity assessment model centred on TRL cardinal coefficients. The Analytical Hierarchy
Process (AHP) and Best Worst Method (BWM) models of Multi Criteria Decision Making
(MCDM) techniques are used to ascertain the quantitative values of maturity of the associated
TRLs while considering end-point functions.

The objectives of this thesis are thus summarized as follows:

• Compiling a list of relevant standards, directives, and guidelines towards the development
of emergency use ventilators.
• Devising a framework for evaluating opensource emergency use ventilators based on the
following criteria:
o Level 1: Open-Source Availability
o Level 2: Specification Fulfillment and Performance
o Level 3: Regulatory Standards, Device Safety and Approval
• Investigating the TRLs for biomedical devices and modifying the said framework to
assimilate the effects of the currently employed EUA regulations and pathways.
• Formulating a novel cardinal TRL framework to assess the maturity of the said biomedical
technologies and general systems.

3
 1.2. OUTLINE
The thesis’s layout is as follows. Firstly, a literature review is conducted highlighting the
current trends towards the development of medical devices and the challenges faced during the
process (Chapter 2). The methodology (Chapter 3) then summarizes the process and intent behind
the consolidation of data acquired into the proposed evaluation frameworks and provides an
overview of each method of evaluation. In Section 4, the 3-tiered framework is then presented
while highlighting its use case and limitations under which it may be applicable. Section 5
provides a case study example of assessment of open-source emergency ventilators under the
qualitative framework and conducts a comparison study based on the derived results. In section 6,
the TRL of a medical device is elaborated upon and the modified TRL is presented. Additionally,
a case study example is provided towards the assessment of biomedical devices under the EUA.
In the following section (Section 7) a cardinal TRL Framework is introduced to assess the maturity
of the system quantitatively and to overcome the limitations of the ordinal TRL method for its
application towards medical devices. Section 8 expands on its application providing a case study
example of NASA’s 7 Technologies. The findings reported in this dissertation are then finally
concluded.

4
2. LITERATURE REVIEW
2.1. EMERGENCY USE VENTILATORS & REGULATORY AFFAIRS
As COVID19 began, a global scarcity of ventilators was experienced. A research undertaken
by Wells et al. in the US identified a serious shortage in both essential care and non-invasive
ventilators [13]. An estimate of the demand was recorded to be 80,000 non-invasive and 50,000
critical care ventilators will be required in addition to the pre-existing equipment to support those
in need [13]. On 24 March 2020, an EUA was announced to modify and develop EUVs [14].
Several other related emergency notifications were released worldwide to allow the production of
inexpensive but practical devices [15,16,17]. Many other organizations have offered vast services
in accordance with these criteria to promote involvement from diverse backgrounds [18-24].

After evaluating the criteria as proposed by the various health associations, it was observed that
while limited to their basic forms, the recommendations nevertheless embodied much influence
over the development of the product for risk identification and hazard mitigation. An active
database generated by Robert et al. showed that many open-source ventilator projects
were found to be insufficiently operational or unusable [10]. A survey analysis showed that 62%
of medical device development is primarily influenced by regulatory and clinical influences [25].
The EUA mentions many ISO / IEC specifications to be referenced when designing emergency
ventilators.

The FDA, Medical Devices Coordination Group (MDCG – Europe) and HC identify an emergency
ventilator (non-critical care) as a Type II or IIa device [26-28]. The differentiation as per the degree
of danger exhibited by a Class I product classified as the least demonstrated danger, to Class IV
being the most [30]. In addition to the planned application of the unit, these classifications are
focused on certain elements; its life cycle; invasiveness, followed by the presence of a
pharmaceutical drug in the medical device environment.

A research performed by Gail et al. provided a summary of the steps involved in FDA production
and approval of a typical medical device [29]. Developing a preliminary prototype stage is also
followed by initializing a patent procedure. Followed by benchmarking and then animal
monitoring, this recursive period generally lasts 2-3 years.

5
Throughout COVID-19 pandemic, the advent and proliferation of open-source ventilator
prototypes has resulted in many attempts to compile and identify projects which ascertain the
openness, technical readiness, and feasibility of implementation. The analysis by Joshua M. Pearce
[12], which offers a review of the current trends and prevalent barriers, is one of the most notable
of these. The study pointed to a database collected by readers and peers that monitors all publicly
released emergency ventilator projects and offers a high-level score for each project in terms of
transparency, buildability, community participation, practical monitoring, durability, suitability
for COVID-19, and clinical friendliness. The objective of this initiative is to have a score on a
scale of 1-5 for each appraisal category [12].

The need of a structured, transparent assessment process that discusses critical design and
efficiency indicators in a manner compatible with current multi-lateral regulatory criteria persists.
Such a structure shall have two important uses: firstly, it will be used to evaluate various ventures
and recognize trends of technological shortcomings in the sector, thereby directing focused
research work and financing; secondly, it should offer guidelines for the development process itself
in a way that incorporates efficiency and safety requirements from the beginning and facilitates
them.

In emergency circumstances, traditional standards are too restrictive for the acquisition of certain
life-saving equipment to mitigate the immediate need to supplement those critically ill. The EUA
is a directive released in crisis, enabling developers to include minimum yet substantive protection
requirements for applicable medical goods. Therefore, many compromises are rendered, given the
reasoning behind each condition to be met. The reduced specifications allow developers and
producers to save time and resources, resulting in a quick and efficient production cycle. While
specifications are rendered more versatile, the procedure is still baffling to developers without
professional oversight of regulatory affairs.

6
 2.2. TECHNOLOGY READINESS LEVEL
Developing a medical device is done by a complicated collection of PDPs that entail
tremendous oversight to ensure conformity to regulatory requirements. Several techniques have
been developed and implemented to execute multiple PDP phases to ensure that the product meets
the customers in its best form [30]. It was also stated that medical device creation involves the
active participation of multidisciplinary teams and diligent implementation to resolve the
difficulties faced in the PDP cycle [31]. Thus, the method involves an aggressive uptake on the
developer's end to ensure the product assuages the multifaceted industry's numerous requirements.
The medical device development cycle is mapped in various ways and methods whilst accounting
for countless FDA directives and new product development techniques. Ocampo et al. published
a systematic analysis of PDPs, demonstrating the extensive regulatory system impact during the
production phase [30].

Like the structures presented in the former, in 2009, the DOD developed a Technology Readiness
Assessment (TRA) Deskbook allowing one to determine the sophistication of a medical device,
drug or information technology pertaining to their respective TRL frameworks [31]. The TRL is a
technology assessment term established by NASA for a wide range of product production
processes in varying industries [32]. The research lets us categorize a project's major benchmarks
and track its progress effectively. However, these experiments were generalized and relevant to
traditional production teams for typical use case medical device development.

The versatility of TRL has inspired the formulation of various other assessment frameworks such
as Integration Readiness Level (IRL) and System Readiness Level (SRL) by Sauser [33], Software
Readiness level by Blanchette et al. [34], Manufacturing Readiness Level (MRL) by Department
of Defense [35] and Design Readiness Level (DRL) by Revfi et al. [36]. In a study conducted by
Conrow [37] it was found that the stages of TRL were ordinal in nature and thus used the AHP for
the determination of cardinal values of the multi-staged model (Appendix C). This model enabled
one to apply mathematical functions and distinguish the degree of complexity of each level of
maturity from the other. The method integrated the use of flexible assignation of correlation
parameters based on expert opinion as directed by the AHP proposed by Saaty et al. [38]. The
cardinality of 7 NASA projects were also determined based on the development time consumed
by each technology by Fahimian and Behdinan [39]. The study resulted in the formulation of a

7
consistent method of maturity evaluation across different technologies. According to a study
conducted by Kujawski [40], some major discrepancies in the application of TRL, IRL and SRL
were highlighted. He concluded that the ordinal systems of the evaluation levels arranged the data
in rank order and mathematical applications over such stages are inconsistent. The primary aim of
utilizing TRLs is to assist management to make decisions regarding technological growth and
change. It can be used as one of the resources used to monitor the success of an organization’s
R&D operation. Olechowski et al. [41] demarcated the several shortcomings and limitations of the
framework. The model has been widely used to determine the overall risk of the system while
considering the readiness level of each component and attempts to enhance it. It was observed that
due to the uncertainty and complexity of a large system, some assessments could be skewed and
may require further investigation. Mankins [42] also proposed an integrated framework which
augmented risk management with TRL which would help discern if the technology is matured or
risk mitigation strategies must be employed to further facilitate R&D pathways.

Customized standard guidelines have now been established by U.S. Department of Defense (DOD)
for the use of TRLs in complex system growth, including protection, oil and gas, and infrastructure
[43-45]. The mandate plays a vital role in acquisition projects over various sectors of the industry
and expanded the scope of its usage exponentially. The DoD elaborates in its TRA Deskbook that,
“TRLs are not a measure of design validity. . . They do not indicate the difficulty in achieving the
next TRL level” [31]. The utilization of these frameworks is directed towards the assessment of
the maturity of various sectors of technology with multiple uses.

The multiple TRL altercations described above showed that there is a lack of definition towards
the assessment of sub-system maturity and related processes which directly affect the overall
technology development. The TRA, though defines the TRL for biomedical technologies, only
provides a suggestive pathway for the medical device development processes and may not be
suitable for the assessment of specific medical technologies and circumstantial developments.
Therefore, to encourage emerging developers via the EUA emergency care device, this study
reforms the recommended TRL thresholds and offers additional details in consideration of
regulatory requirements. This research seeks to provide an early insight to developers about the
criteria posed by regulators, which may accelerate the overall development phase.

8
The methods employed in the frameworks provide a static method of model definition and fail to
fully incorporate the process related influences for maturity assessment. Due to the complexities
of the proposed frameworks, risk assessment of sub-system/sub-criteria technologies is found to
be difficult. The methods use time-dependent algorithms which, due to mathematical conventions,
utilize a set minimum scale of reference for the process to yield results. These results are therefore
limited to elapsed time analysis and may be inaccurate for real-time development tracking. Thus,
this study demarcates and eliminates these limitations while proposing a novel method of maturity
estimation using the pre-established TRL framework.

9
3. METHODOLOGY
3.1. OVERVIEW OF CURRENTLY AVAILABLE REGULATORY GUIDELINES ON
EMERGENCY VENTILATION SYSTEMS
The Open Emergency Ventilator Assessment method is based on a thorough review of current
recommendations of emergency ventilation systems. At the time of this undertaking, during the
COVID-19 pandemic, Health Canada, US FDA, UK MHRA, Australia's TGA developed English-
language recommendations or guidance documents addressing emergency use ventilators [14-17].
1These documents were examined by authors and debated in frequent panel meetings. Other
regulatory and national or international technical criteria have been exhaustively traced and
collated in a database. Classification systems used in primary sources were retained, and authors
introduced a synthesized cohesive classification system. The following summarizes primary
source documents and their material.

Health Canada, FDA, MHRA and TGA developed and distributed updated standards for
emergency medical equipment in response to an anticipated shortage of ventilators. Each
organization provided various levels of detail and guidance such as updated design
specifications, checklist, and templates. Medical Equipment Compliance Association (MECA)
provided guidance on risk control, human factors guidance on labelling and warning
specifications, and specific assessment criteria for vital ventilator components [46]. In response to
the pandemic situation and in lieu of the increased demand, the ISO has recently published a new
standard “ISO 80601-2-84:2020 Medical electrical equipment – Part 2-84: Particular
requirements for the basic safety and essential performance of ventilators for the emergency
medical services environment” [68].

Similar to the above organizations, the Association for the Advancement of Medical
Instrumentation (AAMI) developed a consensus study for the production of EUV considering the
pandemic's needs [37].The report guides one through the limitations and extent of the application
of the General Standard "IEC 60601-1:2012: Medical Electrical Equipment – Section 1: General
Critical Protection and Important Performance Criteria" and provides additional requirements for

1
The formulation of Level 1 Evaluation parameters was with the kind contributions of Ms. Kate Kazlovich and Mr.
Nirmal Pol. Categorization and structure of the framework was discussed and finalized upon with consensus
agreement of the panel.

10
ventilator development [77] and the ventilation standards of “80601-2-80:2019 Medical Electrical
Equipment - Part 2-80: Particular Requirements for Basic Safety and Essential Performance of
Ventilatory Support Equipment for Ventilatory Insufficiency.” [69]. The organization provided an
End User Disclosure guidance document and a draft of Test Report for emergency ventilators.

Our team performed a detailed review and developed a complete list of all regulatory standards as
an 2open-access database and a handbook that provides explanation about the use and purpose of
said regulations.

3.2. RECONCILIATION OF TERMINOLOGY

Synthesis of the documents required standardization of terminology pertaining to the necessity of
specific requirements referenced in the documents. For example, the MHRA classifies
requirements into: “’must’ - identifying mandatory minimum viable product requirements;
‘should’ - identifying highly desirable features that enhance therapeutic benefits; and ‘could’ -
identifying features that are desirable, but which do not significantly enhance the performance of
the system.” [16].

Similarly, the ISO regulations use auxiliary verbs to define levels of mandated requirements. As
stated by the ISO: “For the purposes of the document, the auxiliary verb: ‘shall’- means that
conformance with a requirement or a test is mandatory for conformance with this document;
‘should’ - means that conformance with a requirement or a test is recommended but is not
mandatory for conformance with this document; ‘may’ - is used to describe permission (e.g. a
permissible way to achieve conformance with a requirement or test); ‘can’ - is used to describe a
possibility or capability; and ‘must’, is used to express an external constraint.” [66].

To synthesize and coordinate all applicable regulatory information, our team undertook a thorough
analysis of requirements and checklists available to the public and accessible or bought online. All
assessment checklists provided by the reference agencies were reviewed and integrated into the
framework (notably AAMI and MECA).

2
The database was remunerated with major contributions of Mr. Nirmal Pol and Ms. Kate Kazlovich. For the purposes
of this dissertation, the material used in the database shall not be fully utilized.

11
 3.3. LEVELS OF EVALUATION
The Framework is structured into three sequential levels, with each successive level analyzing data
from previous stages at higher resolution. Level 1 assess the availability and adequacy of
information provided for the design under evaluation. Level 2 assess basic performance
parameters. Level 3 then determines compliance to all other requirements.

Level 1 – Data Adequacy & Documentation: This stage tests the adequacy of usable open-source
data for further concept evaluation. Although the Framework is explicitly tailored to open-source
projects, it can also be extended to closed-source projects if the data defined here are available to
the evaluator. Level one requires licensing evaluation and completeness of given technical
documentation for independent application, replication, and further development. The evaluation
checklist used in this segment is based on suggestions from the Open-Source Hardware
Association (OSHWA). These concentrate mainly on technical system design requirements.
However, because OSHWA does not explicitly focus on medical devices, these guidelines do not
reflect the need to determine compliance with international standards such as ISO / IEC. In medical
hardware, additional information such as testing data and documentation is also important.
Without the availability of test data, further assessment would be substantially incomplete unless
the evaluator is able to develop and test each design independently. Further work is needed to
establish effective data adequacy criteria and access unique to medical hardware.

Level 2 – Performance Parameters: Second level offers guidelines for determining critical points
towards device efficiency criteria to ensure sufficient patient care. This stage focuses mainly on
what the design under review does (functionality), as opposed to how it does it (mechanism), which
is Stage 3 's priority. This segment is focused primarily on the documentation issued by the
regulatory agencies mentioned above. The checklist provides minimum feasible performance
criteria that would follow all of the Framework 's legislative standards for emergency usage
ventilators. The checklist cannot be used to test or compare complexity of nominee designs but
may be used as part of a readiness evaluation.

Level 3 – Standards Compliance: Level 3 is a combination of checklists and criteria that the
concept must conform to for provisional clearance by Health Canada, FDA, MHRA, and TGA.
This appraisal standard reflects on processes, underlying characteristics, and anticipated operator
experiences in which the system achieves Level 2 functional criteria to reduce secondary risks and

12
adverse effects. This level is further broken down into parts that analyse designs in terms of
hardware, software, mechanical and electrical systems, risk, labelling, and human factors. The
suggested breakdown assessment was influenced by regulatory guidelines and checklists published
by ISO and AAMI process [67,47]. Each assessment criteria provides a detailed checklist that
helps users to meet regulatory guidelines and related assessments.

3.4. MAPPING REGULATIONS (TRA)

Developing a medical device is challenging and lengthy, involving corroborative activities of
multidisciplinary teams of different skillsets [48]. Efficient collaboration, prioritization and job
styles play a critical role in integrated product development [49]. PDP method description is an
inane term that effectively leads to organizing and managing a new product development project.
According to Ocampo et al. research, a strong segmentation of engineering and medical process is
witnessed needing synchronicity in the two segments' development [30]. While several
requirements need to be implemented, they are not mapped through different implementation
phases as they differ from developer discretion. Therefore, based on the reviewed medical device
development PDPs, which account for the requirements and include the lifecycle of medical
devices, ventilator development requirements are mapped according to the proposed PDP [30].

The process is further mapped to DOD 's suggested Technology Readiness Evaluation Framework
[31]. The current paradigm being extended for multiple types of medical instruments, offers an
outline of applicable technology maturity levels. Therefore, specific adjustments are made to the
TRL considering the redacted criteria as per the EUA for emergency ventilator creation. The
research also explores the total production period of these emergency instruments to assess the
estimated development time consumed towards maturity. Data endorsed under the EUA and
readily available to the public was investigated for the precision of the timeline. A comparative
analysis is performed to demarcate a developed device's gap from one under growth.

It was observed that most ventilators presented on the Open Access data lists [10,11] did not
assimilate and receive the Emergency Use Authorization or the relevant acknowledgments from
their respective regulators, rendering those designs unavailable for legible clinical use. It was then
proposed that, rather than reaching the output criteria, one must provide well-documented evidence
of their designated research methods utilized and data collected. Thus, the varied prerequisites for
accepting these medical devices posed a challenge to emerging developers for mapping and

13
satisfying the necessary specifications. These requirements play a crucial role in upholding the
safety of the device for both the consumer and the user and, considering the dire need, must
announce conformity with applied quality controls as outlined.

In addition, contrasting the characteristics provided in the regulatory growth guidance, the PDP
mechanism was mapped using the TRL system to evaluate the maturity of Class II Ventilator
emergency for use [26-28]. The approval of an EUA for an emerging product which differ
depending on how developers satisfy criteria such as technical specifications, risk management,
danger prevention, protection, and labelling criteria. There must be recorded proof to satisfy the
different qualities. Hence, EUA mapping in the proposed TRL is focused on the assessment of
previously disclosed knowledge by producers that have already acquired EUA for their product.

It is necessary to note that EUA is not a definitive product certification and will continue to
undergo additional production for potential promotion and delivery after the EUA expires. “When
an EUA declaration is terminated, then any EUA(s) issued based on that declaration will no longer
remain in effect. Before an EUA declaration terminates, the Secretary of HHS must provide
advance notice that is sufficient to allow for the disposition of an unapproved product, and of any
labeling or other information provided related to an unapproved use of an approved product
(section 564(b)(3)). The EUA will be effective until the declaration that circumstances exist
justifying the authorization of the emergency use of products during the COVID-19 pandemic is
terminated under section 564(b)(2) of the FD&C Act or the EUA is revoked under section 564(g)
of the FD&C Act.” [40]. Modifications to current devices shall conform to the compliance
guidelines as provided in place of the pandemic encapsulating the relevant certification
specifications in conjunction with FDA recognized standards [50].

3.5. WTRL
The cardinality of the TRL system plays a crucial role in the consistency and functioning of the
maturity appraisal computational model. Conrow [37] claimed that the original structure
developed by NASA was strictly ordinal and used subjective parameters for maturity
determination and the transition of technology to a certain degree of readiness. It therefore used
the MCDM approach of AHP developed by Saaty [38] to ascertain the cardinality of the TRL. The
approach utilises pairwise comparisons to evaluate the hierarchy of parameters based on the
professional judgement of their respective technologies. The system allows users to assess the

14
weights of arbitrary criteria dependent on human feedback. Applying this approach in the sense of
the TRL, it was suggested that a jury of experts could attribute the complexity/difficulty of each
stage of technical readiness on a scale of 1 to 9 to assess the weights of each level of readiness.
These weights, when normalized, would shape the cardinal coefficients of the TRL on which
mathematical functions could be applied to extract relevant information.

This method has a significant impact on the total efficacy of the cardinal co-efficient used in the
system and is the first drawback in this framework. In this analysis, we will use the cardinal model
suggested by Conrow [37] to measure the overall maturity of the structures. It should be noted that
the implementation of these co-efficiencies is not sufficient for the precision of this case study and
needs an extensive expert-oriented formulation in conjunction with the AHP approach as
suggested by Saaty [38]. Hence the framework is termed as a Weighted Technology Readiness
Level (WTRL) Method. However, this paradigm adopts an open layout for its implementation via
separate functional parameters. This would encourage one to use their native framework of the
cardinal hierarchy optimized toward the technologies.

15
4. ASSESSMENT FRAMEWORK
4.1. LEVEL 1: OPEN ACCESS AVAILABILITY
The following parts address the high-level specifications of the OSHWA under the Creative
Commons Attribution-ShareAlike 4.0 International License [51]. OSHWA offered an open-source
hardware architecture criterion to satisfy the definition of an open-source project. 3They have
created a checklist that helps certify the project as open source to follow the standard requirements.
The assessment parameters are based on the following:

a. Documentation that includes description of the components involved for building the project
from scratch as well as documentation that describes its purpose [51];

b. Design files that can be modified and distributed by others. These files should be in the
preferred formats that allow for changes (i.e. native file formats compatible with the open-
source CAD) [51];

c. Bill of materials that make up the hardware. While it might be possible to infer from the
design files which parts make up a piece of hardware, it is important to provide a separate bill
of materials [51]. This can be a spreadsheet (e.g. CSV, XLS, Google Doc) or simply a text
file with one part per line [51];

d. Instrumentation and explanation. Adequate instructions and explanations must accompany

any open-source project in relationship to design, assembly and use of the shared ventilator
prototype [51];

e. Licensing materials [51];

f. Software codes and accompanying documentation [51];

g. Hosting of project data. There are a wide variety of digital platforms that can host the open-
source project such as GitHub and GitLab. Regardless of the platform that is used for the
project, there are some examples of best practices that can be followed [51].

3 The pre-existing checklist as presented by OSHWA was structured by Ms. Kate Kazlovich and Mr. Nirmal Pol to
formulate the Level 1 Framework. Refer Table A1.

16
 4.2. LEVEL 2: PERFORMANCE ASSESSMENT:
Having assessed the repository specifications to assess the transparency of the chosen project, it is
important to better grasp the concept's parametric capabilities. The Level 2 assessment indicates
general conformity with the distinct regulatory criteria. The structure summarises these devices'
necessary requirements depending on the chosen regulatory body for successful design and
generalises standard parameters. (Refer Table B1)

Note: The criteria in this test stage may not be exhaustive due to real-time changes and updates
and encourages users to further investigate a design for essential design requirements.

This degree of assessment is an important feature of investigation which may be conducted for
both real-time examination of the capabilities of a system in a clinical setting or to assess the
overall output of an open-source project before development.

17
 4.3. LEVEL 3: REGULATORY COMPLIANCE
Based on the results, it was decided that the 2-level assessment system will confirm the openness
and parametric enforcement of emergency ventilators in line with regulatory requirements. The
former, though, does not recognise the standard and protection procedures built into the units.
Thus, to provide the quality assurance requirements, the 3rd assessment tier is proposed. This
appraisal stage encapsulates distinct facets of quality assurance procedures and systematic
manufacturing standards to be pursued for the legalised production, delivery, and use of such
products. This segment provides a surface-level description and helps define core remarks of a
ready-to-use or future project given the regulator’s rigorous specifications and norms.

4.3.1. GENERAL REQUIREMENTS

There are various criteria to review for emergency medical device assessment, depending on the
regulator concerned. Some essential prerequisites, nevertheless, must be provided ensuring rapid
development and safety measures. It is of paramount significance that the material collection for
the product is carried out while acknowledging the essence of the patient's interaction with the unit
or accessory. The component's biocompatibility shall be disclosed with applicable standard
supplier details. Emerging developers are advised to take into consideration the different criteria
of biocompatible content selection:

ISO 10993: Fifth Edition 2018-08: Biological Evaluation of Medical Devices - Part 1: Evaluation
and Testing Within a Risk Management Process [70].

ISO 18562-1 First Edition 2017-03: Biocompatibility Evaluation of Breathing Gas Pathways in
Healthcare Applications - Part 1: Evaluation and Testing Within a Risk Management Process [71].

ISO 18562-2 First Edition 2017-03: Biocompatibility Evaluation of Breathing Gas Pathways in
Healthcare Applications - Part 2: Tests for Emissions of Particulate Matter [72].

ISO 18562-3 First Edition 2017: Biocompatibility Evaluation of Breathing Gas Pathways in
Healthcare Applications - Part 3: Tests for Emissions of Volatile Organic Compounds [73].

ISO 18562-4 First Edition 2017-03: Biocompatibility Evaluation of Breathing Gas Pathways in
Healthcare Applications - Part 4: Tests for Leachables in Condensate [74].

18
Although providing a "predicate device" plays a key role in analysing these medical devices, it is
of tremendous significance that there is a substantial amount of overlap that can be justified,
allowing for straightforward comparisons. With supporting proof, the disparity in architecture with
identical concepts may be clarified. These products must also be produced by accredited suppliers
with "ISO 13485:2016 Medical Devices – Quality Control Programs – Regulatory Purposes
Requirements" [75].

4.3.2. RISK MANAGEMENT PROCESS

Risk assessment mechanism plays a major role in deciding MEDICAL DEVICE 's secure use and
efficiency. Adherence to the method from the early phases of design creation would help aspiring
developers. Different ISO / IEC specifications define the function and its attributions. The
procedure incorporates the guidelines outlined in "ISO 14971: Application of Risk Management
to Medical Devices" and must be further assimilated with evidence presented [76].

The risk identification, assessment and control method is a general practise guideline and thus has
no strict requirements to adopt, allowing developers the ability to aggregate the above specifics in
their own readable manner. Several pointers have been offered to implement these concepts,
enabling users to quickly adjust them [52,53].

4.3.3. MECHANICAL DESIGN

The principle of low-cost scalability for catering to broad user classes guides the design of
emergency ventilators. However, to determine the integrity of the developed system
considering an emergency “ISO 80601-2-84:2020 Medical electrical equipment - Part 2-84:
Particular requirements for the basic safety and essential performance of ventilators for the
emergency medical services environment” shall be applied [68]. This standard further enhances
upon the GS and provides additional requirements for ventilator development.

The inclusion of different pressure regulators and control equipment was strongly recommended
depending on the ventilation system chosen for the ventilator designs. Most HALO ventilators use
the Bag Valve Mask (BVM) automation to achieve volume-controlled ventilation methods. It
should be remembered that, depending on the method of ventilation followed by the prototype,
method-specific checks are needed to ensure consistency with normal criteria for active use. Other

19
tests needed include hook testing, metal finger testing, drop testing, humidity, particulate
resistance, etc.

4.3.4. ELECTRICAL DESIGN

It is believed that emergency care equipment does not need a very large wattage system and do not
need extremely intricate architecture. However, electrical system activity can trigger
electromagnetic interference with other nearby critical medical devices. Therefore,
electromagnetic protection must be supervised closely in compliance with the concepts in “IEC
60601-1-2: 2014: Medical Electrical Equipment Part 1-2: General Requirements for Basic Safety
and Essential Performance – Collateral Standard: Electromagnetic Disturbances – Requirements
and Tests” [78]. This test condition has been waived as stated in EUV, but some preliminary factors
should be used and justified.

Also, engineers must uphold many other standards and requirements about power supply, backup
power supply, circuit protection and troubleshooting, etc. It should be remembered that the
mechanical tests can hamper electrical systems, thus impacting the overall performance of the unit,
thereby the device should function considering all the tests that the system may experience. One
shall specifically describe hazard-prone circuit sections and include essential guidance for usage
and troubleshooting procedures for typical errors and anomalies that may occur. The unit shall also
be liable to conscious tampering with its control mechanisms, hence having different signs with
unwanted situations in the form of alarms / prompts / lights. The switch used must be a two-way
on / off switch without a standby location, and an emergency stop button should be included in the
system.

4.3.5. SOFTWARE DESIGN

Product's software architecture determines mechanical and electrical component performance in

synchronicity. Software creation must explain the parametric philosophy of the version-controlled
firmware and associated control device parameters to be utilised by the user. Software creation
shall also be carried out considering the software life cycle ideology as stated in “IEC 62304: 2015:
Medical Device Software – Software Life Cycle Processes” [79]. Because software development
standards for medical devices are not heavily defined in the General Standard, risk management
steps must be carried out with recorded proof as recommended by MHRA [16]:

20
 • Software Development plan.

• System and software requirements specifications.

• Appropriate software architecture and software design documents.

• A risk management plan and report.

• Software verification and validation plans and reports.

• A software release note.

4.3.6. HUMAN FACTORS

The GS finds the usability criteria analogous to the sciences of human factor heeded by industry.
There are various provisions enumerating critical overview of the device's requisite labelling and
marking for consistent demarcation of hazard-prone zones, but it is recommended that developers
initially recognise the specifications provided by the respective regulators to allow them to satisfy
the reduced pandemic specifications. Placement and interface symbols are further defined in the
GS.

The device's usability is often strongly influenced by the control system's operational
specifications. These criteria were instilled into parametric specifications and are not explicitly
differentiated unless required. Developers must also include instructions for use by qualified
operators to detail the activity modes, alerts, disclaimers and recommendations for
troubleshooting. Lay Individual guideline provision was waived.

4.3.7. DOCUMENTATION

Proof of product conformity with reference to the requirements must be performed in depth and
reported effectively. The required documents focused on individual regulator specifications can
be contained in numerous guidelines such as HC's Interim Order, FDA 's Emergency Use
Authorization, and MHRA 's Rapidly Manufactured Ventilation System Guideline.

The following collection of records are, therefore, suggested to be assembled for meeting the
above standards:

21
• Risk Management File

• Design History File

• Instructions of Use

• Declaration of Conformity

• Test Report

• Labelling and Marking Report

• Design Summary

22
5. CASE STUDY I
5.1. APPLYING THE FRAMEWORK
This portion of the study addresses implementing the above method to test openly available
ventilator designs. These ventures were chosen depending on the following criteria:

1. Popularity: MIT E-Vent

2. EUA Certified: Apollo BVM

3. Most Informative: Partially RepRapable automated open-source bag valvemask-based

ventilator

4. Arbitrary Selection: Air Project

The above projects were analyzed based on details disclosed for public use to assess their capacity
for further growth or expenditure. Therefore, no physical prototyping or simulation was done for
assessment.

23
 5.1.1. MIT E-VENT

MIT E-Vent is an emergency ventilator built by Massachusetts Technology Institute, USA [57].
https://emergency-vent.mit.edu hosts the related project files. The architecture uses a BVM Bag
concept for its function. Importantly, explaining different requirements and architecture
considerations is quite elaborately shared with its project users. A moderated website has been
hosting experts to further suggest and explore the project's different facets. Links to project files
may be acquired through easy registration, which allows for secure and administered material
delivery. The project was decentralized using main categories like clinical, mechanical, electrical,
and control-system based development. A section of experiments and findings follows, that
illustrates significant organizational facets and recommends concept iterations accordingly. It was
noticed that developers have not explicitly declared the proposed design standard accomplished
and have instead listed regulators' recommended specification. For this evaluation, it is believed
that the proposed criteria were integrated into the design. The prototype has not been approved by
EUA currently. [Refer Figure 1]

ASSESSMENT

Level 1: Pass

Findings: The project disclosed the required specifications as

proposed by the OSHWA checklist and should be viewed as a
completely open-source project centered on the available
knowledge to its expected users.

Level 2: Pass

Findings: The project met the regulatory functional criteria

proposed in the framework. The developed system can be
considered effective for use in the pandemic.

Level 3: Fail

Findings: Information applicable to Level 3 framework

Figure 1: MIT E-Vent, Massachusetts Institute of Technology evaluation was not available. The experimental results section,
[54]. however, exposed the design’s testing concept being ISO
80601-2-80 and ISO 80601-2-79 [69,67].

24
 5.1.2. APOLLO BVM

Apollo BVM is a Rice University, Texas, USA emergency ventilator [55]. The project details can
be found here: http://oedk.rice.edu/apollobvm/ . The project uses a BVM-operated architecture to
satisfy the FDA 's specifications. The concept obtained EUA clearance on August 26, 2020 in
partnership with Stewart & Stevenson Healthcare Technologies, LLC. Nevertheless, the project
link shares the earlier prototype of the system to be explored with the proposed structure. Nearly
3,000 registered participants in 115 countries were reported to have downloaded the plans [56].
Similar to MIT E-vent, resources shall be obtained upon nominal registration. The project is
categorized under distinct categories such as: Download Mechanical Files, Box and Electronics
Assembly, Motor Mount Assembly, Motor Assembly, Bumper Assembly, BVM Adjustable
Mount, Parts BOM, Software and Controls, User Interface, Key Specifications and Testing
Results. [Refer Figure 2]

ASSESSMENT

Level 1: Pass

Findings: The project disclosed the required specifications as

proposed by the OSHWA checklist and should be viewed as a
completely open-source project centered on the available
knowledge to its expected users.

Level 2: Partially Fulfilled

Findings: The project struggled to fulfil all emergency

ventilator specifications. However, the proposed solutions to
the proposed parameters were justified.

Level 3: Fail

Findings: The information relevant to the assessment of

Level 3 framework was not available.
Figure 2: Apollo BVM, Prototype I, Rice University [55].

25
 5.1.3. PARTIALLY REPRAPABLE AUTOMATED OPEN SOURCE BVM-BASED VENTILATOR

The project shared as an article written by Aliaksei et al. is open access [57]. See
https:/osf.io/fjdwz/ for the project's root file repository. The device is a BVM-based system
utilizing 3D Printed parts for its enclosure. The project is divided into the following sections:
Hardware Description, Bill of Materials, Build Instructions, Operation Instruction, Validation and
characterization and Limitations and Future work. The research exposes substantial facets of
medical product production issues and was considered particularly insightful relative to others.
The author tested the ventilator with a basic configuration using a Michigan Instruments Lung
Simulator. [Refer Figure 3]

ASSESSMENT

Level 1: Pass

Findings: The project disclosed the required specifications as

proposed by the OSHWA checklist and should be viewed as a
completely open-source project centered on the available
knowledge to its expected users.

Level 2: Partially Fulfilled

Findings: The project failed to satisfy all the requirements of

the emergency ventilator requirements. However, solutions to
overcome or achieve the suggested specifications were
justified.

Level 3: Slightly Fulfilled

Findings: The information relevant to the assessment of Level

3 framework was not fully available, however, the project
Figure 3: Partially Reprapable automated opensource BVM
based ventilator [57]. disclosed a minimal risk assessment with its operational
parameters. The project referred to the MHRA guidelines and
has addressed some of the requirements.

26
 5.1.4. AIR PROJECT

The Automated Inhalation Resuscitator (AIR) initiative is a capstone open access design at the
University of Waterloo, Canada [58]. The architecture uses a mechanism run by BVM. The project
is shared via link: https:/the-air-project.github.io, developed alongside Baylis Medical. The
concept was prototyped with professional guidance from Sick Kids Clinics, Respiratory Therapy
program, and Leeds Greenville Paramedic unit. Project walkthrough is classified with an assembly
guide with Mechanical and Electrical Files. No test reports or requirements relevant to the device's
output were disclosed. Refer Figure 4.

ASSESSMENT

Level 1: Partially Fulfilled

Findings: While the project included the core design

specifications required to replicate the system, no formal Bill
of Materials or Licensing disclosure was provided for users.
Therefore, its conformity with level 1 requirements cannot be
assessed.

Level 2: Fail

Findings: The developers gave no criteria for the concept to

be evaluated and therefore failed to fulfil the requirements of
this evaluation stage.

Figure 4: AIR Project, University of Waterloo [58]. Level 3: Fail

Findings: The developers gave no criteria for the concept to

be evaluated and therefore failed to fulfil the requirements of
this evaluation stage.

27
 5.2. ASSESSMENT RESULTS
After conducting the individual evaluation of the chosen open-source projects, separate
distinctions may be drawn based on the user's requirement. In this review, we shall review these
findings from a developer's viewpoint and choose the best concept to emulate. Selection
requirements shall rely on outcomes as checked by the suggested evaluation standards.

5.2.1. LEVEL 1 ASSESSMENT RESULTS

This test level allows consumers to consider how far projects can be used without violating any
intellectual property rights. It also evaluates the volume of information available to the developer.
After carefully analyzing and contrasting the individual ventilator evaluation findings as seen in
Table I, it was noticed that the Reprapable ventilator met the fulfilment requirements provided by
Level 1 assessment. The MIT e-vent and the Apollo BVM proceeded closely. The AIR initiative
portrayed some inconsistencies and may be believed not to be entirely open source.

Table I: Level 1 Assessment Comparison

Instruction of
Bill of Software
Ventilator use and Design Files Licencing Test Results
Materials Information
assembly

Mechanical: Test Setup:

Intent of Design:
Declared Open Clearly
Clearly Explained Mechanical: Firmware:
Source Illustrated and
Assembly Mechanical: Clearly Listed Available
Electrical: Explained
Instructions: Provided Electrical: Logic
MIT e-Vent Declared Open Standardized
Clearly Explained Electrical: Clearly Listed Nuances:
Source Specifications:
Operating Provided Accessories: Vaguely
Software: Not Clearly
Instructions: Clearly Listed Explained
Declared Open Illustrated but
Clearly Explained
Source Explained

Intent of Design: Mechanical: Test Setup:

Vaguely Declared Open Clearly
Mechanical: Firmware:
Explained Source Illustrated and
Mechanical: Clearly Listed Available
Assembly Electrical: Explained
Provided Electrical: Logic
Apollo BVM Instructions: Declared Open Standardized
Electrical: Clearly Listed Nuances:
Clearly Explained Source Specifications:
Provided: Accessories: Vaguely
Operating Software: Clearly
Clearly Listed Explained
Instructions: Declared Open Illustrated and
Clearly Explained Source Explained

28
 Instruction of
Bill of Software
Ventilator use and Design Files Licencing Test Results
Materials Information
assembly

Test Setup:
Intent of Design:
Clearly
Clearly Explained Mechanical: Mechanical: Firmware:
Illustrated and
Assembly Mechanical: Clearly Listed Clearly Listed Available
Explained
Rep Instructions: Provided Electrical: Electrical: Logic
Standardized
Rapable Clearly Explained Electrical: Clearly Listed Clearly Listed Nuances:
Specifications:
Operating Provided Accessories: Software: Clearly
Clearly
Instructions: Clearly Listed Clearly Listed Explained
Illustrated and
Clearly Explained
Explained

Intent of Design: Mechanical:

Clearly Explained Vaguely Test Setup:
Mechanical: Firmware:
Assembly Listed Not Explained
Mechanical: Not Listed Available
Instructions: Electrical: Standardized
The Air Provided Electrical: Logic
Clearly Explained Vaguely Specifications:
Project Electrical: Not Listed Nuances:
Operating Listed Not Illustrated
Provided Software: Vaguely
Instructions: Accessories: and Vaguely
Not Listed Explained
Vaguely Vaguely Explained
Explained Listed

5.2.2. LEVEL 2 ASSESSMENT RESULTS

For ease of assessment from the second tiered assessment (Table B1) primary functional
parameters such as PEEP, Tidal Volume, Respiratory Rate and I: E Ratio, are observed considering
that the ventilation device does not control pressure. Furthermore, the requirements may be
extended as proposed in the key assessment criteria in Section 4.2 as per user requirement (See
Table II). It was found that MIT e-Vent completely met the efficiency criteria presented by
different regulators. Reprapable and Apollo BVM ventilator proceeded closely. The Air project
did not report any output details relating to its prototype, thereby failing the assessment. A
significant finding is made while evaluating the Apollo BVM and the Reprapable ventilator, the
former fails to entirely fulfil the Tidal Volume criteria, while the latter fails to meet the
recommended PEEP. It is necessary to note that a system must be chosen while considering the
variables that trigger these anomalies and the amount of work needed to fix them. For e.g., many
BVM kits include a physical PEEP valve with fixed valves that can be cheap to implement. In
comparison, the adjustment of the tidal volume may be strenuous as the root cause may be in the
software code, the architecture of the mechanism or the configuration of the primary developer's
accessories.

29
Table II: Level 2 Assessment Comparison

Recommended MIT e-Vent

Parameter Apollo BVM Rep Rapable Air Project
Parameters (Suggested)
PEEP (cmH2O) 5-20 5-15 5-20 2-11 NA
Tidal Volume
50 - 800 200-800 300-650 100-846 NA
(ml)
Respiratory Rate
4 - 45 6-40 5-30 5-45 NA
(BPM)
Inspiratory &
1:1 to 1:4 1:1 to 1:4 1:2 to 1:4 1:1 to 1:4 NA
Expiratory Ratio

5.2.3. SELECTION FOR DEVELOPMENT

Based on the findings obtained from the above sections, each ventilator 's total assessment can be
inferred as shown in Table III. Clearly, the Reprapable ventilator is marginally easier when
addressing the complexities of construction and validation of the emergency usage ventilator as
compared to the others. However, it lacks efficiency criteria as seen in the Level 2 assessment
relative to those provided by MIT e-Vent. The Apollo BVM strongly resembles previous selection
choices and requires more refinement and resources. The AIR Project does not share many details
allowing developers to differentiate its working from those mentioned in this case study. Based on
the total 3-Tiered examination of these ventilators, it can be inferred that the ventilators can be
rated accordingly to their suitability:

MIT E-Vent > Partially Reprapable BVM > Apollo BVM > AIR Project

Table III: Assessment Summary

MIT e-Vent
Parameter Apollo BVM Reprapable Air Project
(Suggested)
Level 1 Pass Pass Pass Partially Fulfilled

Level 2 Pass Partially Fulfilled Partially Fulfilled Fail

Level 3 Fail Fail Slightly Fulfilled Fail

30
6. MEDICAL DEVICE DEVELOPMENT UNDER EUA
6.1. MODIFIED TRL
Descriptions of biomedical TRLs include a structured means of evaluating and communicating to
the Milestone Decision Authority (MDA) the level of maturity of a given technology or the
combination of technologies and the level of maturity required for the effective development of a
product. The Modified TRL is illustrated in Table IV.

Scientific literature reviews conducted help in mapping the mitigations to specific issues regarding
the manufacturing process or the technology of the device itself. After a clear emphasis on the
problems found, the next development stage is initiated to articulate experimental designs and
hypotheses associated with the defined problems. Concepts and hypotheses are tested, and study
endpoints are defined. Given the current pandemic, the EUA has outlined the minimum
requirements needed for the device that should be addressed. The product history log, design
analysis, and a Device Master Record (DMR) are initiated if required. It is important that the design
incorporates to the fullest degree the purpose of the recommended specifications. Applications for
EUA are prepared and forwarded to the Centre for Devices and Radiological Health (CDRH). The
outcome of the IDE analysis by CDRH will decide whether the development of the unit will begin.
A final prototype is produced and tested. Product production will commence after the approval of
the device by the CDRH. Finally, the product is marketed followed by post market trials as shown
in Table IV.

However, with the requirement for rapidly developed emergency equipment, it is determined that
only a few such requirements will be attained. The table categorizes these as General, Mechanical,
Electrical and Software standards which are further subcategorized as Primary and Auxiliary in
nature as shown in Table V. The primary requirements must be adopted with high priority as the
auxiliary requirements might be valid in essence or at MEDICAL DEVICE component level.
Although some of these requirements entail a variety of validation procedures, it is advised that
they be used as guidelines to the overarching account for their purpose, and the checks used in the
Test Report template are prioritised for the emergency [59].

31
Table IV: Modified Biomedical TRL for Emergency Ventilators

TRL Definition Description

Initiation of initial market surveys and scientific literature reviews are
Basic principles observed and assessed.
1
reported
Defined problems are met with potential scientific applications.
Intense academic emphasis on the problem with the production of
Technology concept and/or scientific "paper studies" that analyse and produce research ideas,
2
application formulated theories, hypotheses, and experimental designs to answer the
associated science issues.
Hypothesis is tested by basic research, data collection and analysis.
Alternative concepts are being explored hence component
technologies to get identified and evaluated. Initial tests of design
concept and evaluation of candidate(s) are performed. Study endpoints
Analytical and experimental critical defined. Design verification, critical component specifications, and
3 function and/or characteristic proof- tests if necessary are conducted.
of-concept
Under an emergency, one may not have to fulfil all the requirements
as presented by a fully developed device. The EUA outlines the
minimal requirements which would be necessary to address the
need.
Procedures are defined to be used in the assessment of candidate
devices/systems. The product history log, design analysis, and a
Device Master Record (DMR), if needed, are initiated.
Component and/or breadboard
4 The required standards, testing and validation guidelines for the
validation in laboratory environment
development of emergency ventilator are to be referenced. It is
necessary that the design incorporates the intent of the
recommended standards to its utmost extent.
Devices compared to current modalities and indications for use and
equivalency demonstrated in model systems. All suppliers/vendors of
components are identified and qualified; vendors for critical
components are audited for compliance with cGMP/Quality System
Component and/or breadboard Regulation (QSR). Verification of component checks, drawings of
5 components, design history file, design review and any DME is
validation in a relevant environment
performed. Product Development Plan is drafted.
EUA application is prepared and submitted to CDRH. IDE review
by CDRH results to determine if the production of the device can
begin.

System/subsystem model or prototype Update and verify the component tests, component drawings, design
6 demonstration in a relevant history log, design review, and any DMR. Through production-scale
environment cGMP plant qualification, production technology is demonstrated.

The final prototype and/or initial commercial-scale system are

System prototype demonstration in an produced and tested.
7
operational environment
CDRH approves clinical endpoints and test plans.

Approval of the device by the CDRH will initiate the production.

Corroboration of QSR compliance, the design history log, design
Actual system completed and qualified
8 analysis, and any DMR are completed and validated, and the
through test and demonstration
development of devices is accompanied by accuracy and/or
reproducibility studies.
The medical product may be marketed/distributed. Post-marketing
Actual system proven through
9 trials may be required (non-clinical or clinical) and are planned in
successful mission operations
compliance with the FDA. Surveillance for post-marketing.

32
Table V: Required Standards for Development of Emergency Use Ventilator.

Categorization Recommended Standards

General Standard • IEC 60601-1 [77]

• ISO 80601-2-13 [87]

• ISO 80601-2-69 [88]
• ISO 80601-2-70 [90]
• ISO 80601-2-74 [89]

Particular Standards • ISO 80601-2-79 [67]

• ISO 80601-2-80 [69]
• ISO 80601-2-84 [68]
• IEC 60601-1-11 [80]
• ISO 80601-2-12 [81]
• ISO 5356-1 [93]
• ISO 5366 [94]
• ISO 10651-5 [85]
• ISO 10993 [70]
• ISO 13485 [75]
• ISO 14971 [76]
• ISO 17510 [86]
• ISO 18190 [95]
Collateral Standards
• ISO 18652 Part 1 to 4 [71-74]
• IEC 60601-1-2 [78]
• IEC 60601-1-6 [84]
• IEC 60601-1-8 [83]
• IEC 62304 [79]
• ISO 62366 [82]
• AAMI TIR69 [91]
• ANSI/IEEE C63.27 [92]

33
 6.2. APPLYING THE MODIFIED TRL
The following sections intends to highlight the application of the modified TRL as proposed in
section 6.1. For purpose of this study, 3 open-source development projects and 3 EUA certified
products are investigated for evaluation. The assessment utilizes the specification information
presented by each project/product. However, it is of critical importance to understand that the
information available is not comprehensive and the applications submitted for the EUA are
enclosed under the privacy act.

1. MIT E-Vent developed by the Massachusetts Institute of Technology, USA [54].

2. Apollo BVM developed by the Rice University, Texas, USA [55].

3. The Partially Reprapable automated open-source BVM-based project is shared as a

published article by Aliaksei et al. [57].

4. MICo Medical CoroVent developed by the MICo Medical s.r.o. [60].

5. The World Ventilator Foundation’s (WVF) – WorldVent [61].

6. The AdultLife Pro Ventilator [62].

Upon comparing the various features and functionalities as disclosed by the developers it was
observed that the Apollo BVM and the Reprapable BVM failed to achieve all recommended
functional parameters as presented by the EUV and would still need further development. Due to
the designs being in their initial prototype forms and presenting a proof of concept for the
attainability of the said requirements, they could be attributed to the TRL 3. The MIT E-Vent was
found to fully satisfy the operation outputs as necessitated by the regulators but lacks the testing
modules for the validation of the said systems and thus was categorized as TRL 4 maturity. The
EUA certified devices are considered to attain TRL 5 however due to them being intended for use
under an emergency, they do not satisfy all the regulatory standards required to their fullest. The
declaration of conformity released by each developer was also recorded. (Refer Table VI)

34
The maturity of a system in the same level may vary due to the flexible evaluation and sanction of
EUA approvals based on the circumstances. The demarcation of maturity in the same level is thus
carried out by the extent of standard validations fulfilled by a device. The declaration of conformity
by the manufacturers enables one to freely assess the maturity of such a device based on one’s
requirement.

With the need for rapidly developed emergency use devices, it was found that 120 Devices have
been approved by the EUA for usage in the US [17]. Many of these devices were either developed
in a very short span or imported and sanctioned through other channels. The average time of
development of such devices is considered as 6 weeks from the announcement date of the EUA
(24th March 2020) to the last sanctioned provision (23rd September 2020). By plotting the month
of issuance versus the number of devices sanctioned with the EUA a steep decline of these
approvals is witnessed according to the data as illustrated in Figure 5.

EUA Approved Ventilators

(24th March - 1st October, 2020)
60
52
50

40
34

30

20
14
10
10
5
1 2
0
March April May June July August September

Figure 5: EUA Approved Ventilators (24th March – 1st October, 2020)

35
The results as illustrated in Table VI evidently show that multiple devices in the same stage of
development (TRL 5) show different rates of maturity. To assess the progress of development and
maturity, it is important to map the underlying development processes on to the TRL scale to track
the progress of an ongoing development project.

Table VI: TRL Assessment Comparison

Manufacturer / Development Declaration of EUA

Ventilator TRL
Developer Time Conformity Approved

Massachusetts
MIT E-Vent Institute of Ongoing NA No 4
Technology

Apollo BVM V1 Rice University Ongoing NA No 3

RepRapable Aliaksei et al. NA NA No 3

MICo Medical
MICo Medical s.r.o. 21 weeks IEC 60601-1 Yes 5
CoroVent

WorldVent World Ventilator IEC 60601-1

12 weeks Yes 5
Ventilator Foundation (WVF) ISO 80601-2-80

18652-1
18652-2
18652-3
AdultLife Pro NeoNatal Rescue,
12 weeks 18652-4 Yes 5
Ventilator LLC
ISO 80601-2-80
ISO 80601-2-12
13485

36
7. MULTI-LEVEL WTRL MATURITY ASSESSMENT
7.1. WTRL MATURITY ASSESSMENT METHOD
According to AHP, the cardinal values would be highly dependent on the correlation set by
consensus agreement of experts towards a specific problem set of ratio systems. For the application
of analytical models over the ordinal TRL, this study utilizes a generic cardinal framework of TRL
as proposed by Conrow [37] (Table C1) . It suggests a basic comparison of AHP Adjusted TRL
(TRLc) stages which would aggregate the complexity of each stage into cardinal stages. The
formulation of cardinal coefficients is derived based on the pairwise comparison of 9 TRLs with
respect to each other while considering a relative complexity ratio scale to describe each level. The
method for comparing 9 criteria would use 36 pairwise comparisons (No of comparisons: n(n-1)/2)
to estimate the weights of TRLs which would influence the attributes studied under the said
framework. To ensure the consistency of comparisons made for large decision-making processes,
the consistency ratio (CR) ascertains the accuracy of the comparison. The weights, otherwise
known as cardinal coefficients, are then related to quantitative attributes for further investigating
the dependence of the complexity of each maturity stage towards the latter. Thus, it is highly
advised that a defined roadmap is utilized for the formulation of the cardinal TRL while accounting
for the well-defined complexity parameters by expert opinion. This proposed framework
supplements to the cardinal TRL while accounting for multi-levelled milestone complexities which
can be quantized and therefore be applied to a cardinal framework for maturity assessment.

Furthermore, to account for the influence of milestone/endpoint processes through each

technology, the result of each stage shall also be accounted for based on the successful completion
of the former. The greatest challenge to acclimatize the effects of linear subjective or immensely
vast factors such as design complexity, technology standardization, functionality integration, etc.
is their ordinality. However, the computation of comparison over these broad scope methods using
the AHP is challenging, hence, the Best Worst Method (BWM) formulated by Rezaei [64] is
employed to achieve a consistent and accurate relative comparison like that of AHP. The process
uses fewer pairwise comparisons (No. of comparisons: 2n-3) and uses predetermined precedence
relations towards its operation.

37
 7.1.1. STEP 1: MAPPING SUB-CRITERIA

The definition of the technological development pathway for medical devices is considered in
accordance with the modified TRL mentioned in Table IV. Many factors affect the progress of
technology at each level of maturity. These factors are termed as sub-criteria of development which
complements to the initial TRL’s principle criteria. To analyze the effects of various sub-criteria
over each stage of technology readiness, a generic map is illustrated in Figure 6. The mapping of
the sub-criteria, SC1, SC2, SC3…. is an essential process to determine maturity or development
accomplished of each stage and the overall process. The sub-criteria are milestone processes and
can only be considered applicable towards the assessment upon completion.

TRL 1 TRL 2 TRL 3 TRL 4 TRL 5 TRL 6 TRL 7 TRL 8 TRL 9

SC1 SC3 Quality SC5 SC7 SC10 SC11

• General
Standards
SC2 SC4 • Particular
Standards
SC6 SC8 SC12
• Collateral
Standards
SC9

Figure 6: Mapping Sub-criteria influence on TRL

For the selection of a ventilator, it has been established that regulatory standards play a major role
in quality, safety, and performance maturity of the technology. The study thus maps these
standards on to TRL 5 as shown in Figure 6. To determine the cardinality of the sub-criteria the
BWM is employed.

7.1.2. STEP 2: CARDINALITY OF SUB-CRITERIA

Any applicable method can be employed towards the determination of cardinal coefficients of the
sub-criteria. Here we apply the BWM for the ease of complexity and its homogeneity when
compared to the AHP attributes. First, we determine the overall standards applicable to the
evaluation of maturity for our intents and purposes. The quality of the medical device is highly
controlled through various regulatory processes. The major sub-criteria at TRL 5 are thus
considered Quality. To associate the concept of quality milestones easily, the entailed standards
are primarily classified as “General Standard” (GS) which provides general requirements of
medical electrical equipment for safety assurance. Followed by “Particular Standard” (PS) which

38
encapsulates the directives to implement and safely adapt the said technology, in this case, a
mechanical ventilator. And lastly “Collateral Standard” (CS) the enactment of which ensures the
various safety features of the medical device. The application of these standards may differ based
on the type of medical device but can be further broken down if necessary. For the uses of this
study, we shall address the various standards which may be required for the development of a fully
safe ventilator, however, it is realised that the listed standards may not be exhaustive and may not
be fully required for the approval of the ventilator and can therefore be modified.

According to the best worst method, we arrange the said standards in the order of their precedence,
being:

GS > PS > CS

The arrangement of the CS can be further carried out based on their relevance, an exploratory
model is shown as listed in Table VII.

Table VII: Quality Variable Designation

Categorization Variable Recommended Standards

General Standard 𝑥𝑔𝑠 1. IEC 60601-1

Particular Standard 𝑥𝑝𝑠 2. ISO 80601-2-80

3. ISO 14971
4. ISO 10993
5. IEC 60601-1-2
Collateral Standards 𝑥𝑐𝑠 6. ISO 18652-1
7. ISO 18652-2
8. ISO 18652-3
9. ISO 18652-4

The local weights are then calculated for determining the cardinality of the said sub-criteria. The
open-access BWM solver developed by Rezaei is used for expedited computation [65]. We classify
these weights as the cardinal coefficients of the quality factor. An example based on Table VII
hierarchy is illustrated in Table VIII. (For further information on the calculation of the said local

39
weights refer to Appendix D). We obtain the consistency ratio for the model to be 0.04 which
concludes the comparison to be consistent. The local weights obtained are normalized and are
applicable to the stage of maturity (TRL 5). The influence of each stage is to be obtained with the
pairwise comparison performed and therefore must be strictly based on expert consensus for
accuracy and well-defined process for analysis.

Table VIII: Local Weights of Subcriteria using BWM Method.

Sub-
𝒙𝒈𝒔 𝒙𝒑𝒔 𝒙𝒄𝒔𝟑 𝒙𝒄𝒔𝟒 𝒙𝒄𝒔𝟓 𝒙𝒄𝒔𝟔 𝒙𝒄𝒔𝟕 𝒙𝒄𝒔𝟖 𝒙𝒄𝒔𝟗
Criteria

Local
0.22 0.22 0.11 0.11 0.088 0.063 0.063 0.063 0.063
Weights

7.1.3. STEP 3: TIME DEPENDENCE

The expended time of development is a crucial factor for assessing the progress of development
according to the stipulated or planned development strategy. Also, time is a consistent variable
affecting each stage of readiness and can be used to navigate the current progress of a project.

Time being a cardinal quantity does not need to undergo any transformation for usability.
However, for increased usability and efficient tracking of development with respect to a stipulated
time frame, a normalized Time Ratio (TR) is used to assimilate the time parameter. TR is the ratio
of Elapsed Time of Development in a specified TRL (Te) to the Planned Time of Development
(Td) as shown in (1).

(1)
𝑇𝑒
𝑇𝑅 =
𝑇𝑑

7.1.4. STEP 4: MATURITY ASSESSMENT

The cardinal coefficients of the TRLc can be classified as global weights which affect the entirety
of the development framework. Therefore, to study the effects of the sub-criteria over the entire
process, the local weights are converted to global weights. The maturity at a certain TRL “Ma ”
∀ 𝑎 ∈ [1,2,3, … ,9] can be determined according to (2).

40
 𝑇𝑅𝐿𝑐 × (𝑇𝑅 + ∑𝑛𝑖=1 𝑆𝐶𝑖 ) (2)
𝑀𝑎 =
𝑛+1

Where,
"𝑇𝑅𝐿𝑐 " is the cardinal coefficient of the said TRL, “𝑇𝑅” is the Time Ratio, "𝑆𝐶𝑖 " is the maturity
constant of the sub-criteria and 𝑛 is the number of sub-criteria used (∀ 𝑛 ∈ 𝑁).

The Maturity Constant (𝑆𝐶𝑛 ) is defined as the sum of completed local sub-criteria cardinal
coefficients (𝑥𝑗 ) as illustrated in Equation 3. The maximum value of 𝑆𝐶𝑖 is 1 which would imply
that the said sub-criteria is fulfilled and may not influence the maturity at the said stage any further.

𝑛 (3)
𝑆𝐶𝑖 = ∑ 𝑥𝑗
𝑗=1

The maximum value of the maturity at each level is the corresponding 𝑇𝑅𝐿𝑐 coefficient which
justifies the overall maturity of the system shall be attained upon its completion. Since the
𝑇𝑅𝐿𝑐 coefficients are normalized, the full maturity of technology is attained when the sum of all
preceding levels is 1.

7.2. MATURITY ASSESSMENT OF EMERGENCY USE BIOMEDICAL DEVICES

To select the most technologically feasible ventilator, the degree of maturity of the ventilators on
a specific level must be discerned. From the data obtained from Table VI, we assume that the time-
period of TRL 5 is their respective development time. Considering the validity of the EUA being
for a year, planned development time of all models is thus considered the same. The sub-criteria
of assessment are based on the declaration of conformity for Quality (SC1) and the completion of
those compared against the list of standards as shown in Table VII. The calculation of local weights
(𝑥𝑗 ) is modelled based on the BWM results obtained and illustrated in Figure C1. The assignation
of the local criteria is only done based on the completion of the said standard or its equivalent. SC1
for each model is shown in Table IX.

41
Table IX: Subcriteria Maturity Comparison

Declaration of Completed process sub-

Model SC1
conformity criteria coefficients
MICo Medical
IEC 60601-1 𝑥𝑔𝑠 0.22
CoroVent

WorldVent IEC 60601-1

𝑥𝑔𝑠 , 𝑥𝑝𝑠 0.22 + 0.22 = 0.44
Ventilator ISO 80601-2-80
ISO 18652-1
ISO 18652-2
ISO 18652-3 𝑥𝑝𝑠 , 𝑥𝑐𝑠3 , 𝑥𝑐𝑠4, 𝑥𝑐𝑠6,
AdultLife Pro 0.22 + 0.11 + 0.11 + 0.6 + 0.6 +0.6
ISO 18652-4
Ventilator 𝑥𝑐𝑠7 , 𝑥𝑐𝑠8, 𝑥𝑐𝑠9 , + 0.6 = 0.68
ISO 80601-2-80
ISO 80601-2-12
ISO 13485

Comparing the data in Table VII and Table IX, it is evident that the Adult Life Pro fulfilled most
of the sub-criteria based on the evaluation boundary conditions, but the standards were not found
identical to those proposed for assessment. Hence the equivalence of the standard is considered
based upon the weight assignation. The ISO 80601-2-12 [81] and ISO 13485 [75] were considered
as CS as they did not fulfil the technical amendments proposed by the GS and PS. The sub-criteria
maturity constants (SC1) were thus found as Adult Pro Life being scored at 0.68, WorldVent
Ventilator at 0.44 and MICo Medical Corovent at 0.22 as illustrated in Table X.

Table X: TRL 5 Maturity Comparison

Te
Model TRL TRLc TR SC1 M5
(in weeks)
MICo
Medical 5 0.07 21 0.4 0.22 0.0215
CoroVent
WorldVent
5 0.07 12 0.22 0.44 0.0231
Ventilator
AdultLife Pro
5 0.07 12 0.22 0.68 0.0315
Ventilator

Furthermore, the TR was calculated while comparing the elapsed development time in weeks (Te)
to 52.15 weeks (Td) as composed in a year. The TRL5 Maturity constant was thus calculated based
on (2) as illustrated in Table X.

The maturity of each ventilator at TRL 5 is thus found to be varying unlike results obtained through
originally assessed ordinal TRL. Unlike most maturity time-based assessments, the inclusion of
sub-criteria influences the maturity score obtained in this model. The varying maturity level’s

42
progress localized to TRL 5 are shown in Table XI. This can be observed with MICo Medical
CoroVent being the most time mature due to its rapid development but lacks in the quality
assessment criteria as shown. The Adult Life pro has the same time of development as the
WorldVent Ventilator but has a higher maturity percentage due to the same reason.

Time maturity plays an important role in determining the number of resources invested in the
development of the technology. The indicator enables one to account for the overall operating
costs which cannot be branched out as sub-criteria requirements.

Table XI: Overall Maturity Comparison

MICo Medical AdultLife Pro
WorldVent Ventilator
CoroVent Ventilator
Time Maturity (%) 40 22 22
Quality Maturity (%) 22 68 44

Total Maturity at TRL 5 (%) 30.7 45 33

This method effectively allows the inclusion of various sub-criteria towards the assessment of
maturity as shown above. The framework can be used to effectively track the maturity progress
(as shown in Figure 7) of a development project using milestone objectives to further improve its
complexity at each stage of development. The total maturity of the project can also be calculated
by considering the cumulative of maturity constants of various levels as shown in Equation 4. The
ideal value of Total Maturity is considered 1 due to the normalized TRLc used.

9 (4)
𝑇𝑜𝑡𝑎𝑙 𝑀𝑎𝑡𝑢𝑟𝑖𝑡𝑦 = ∑ 𝑀𝑎
𝑎=1

Maturity of Ventilators Technologies at TRL 5

AdultLife Pro Ventilator 45

WorldVent Ventilator 33

MICo Medical CoroVent 30.7

0 10 20 30 40 50 60 70 80 90 100
TRL 5 Maturity in %

Figure 7: Maturity Progress of Technology at TRL 5.

43
8. CASE STUDY II
8.1. MATURITY ASSESSMENT OF 7 NASA TECHNOLOGIES
To assess the maturity of the 7 NASA Technologies, we shall use the recorded transition period of
each TRL as reported by Piesen et al. [66] to attain TRL 6. We consider the technology has
achieved its maturity at TRL 6. The maturation period to TRL 1 is not recorded due to the fuzzy
characteristic of the process, hence it is presumed that the elapsed time to TRL 1 is 0 as shown in
Table 1. The proposed approach needs more evidence to enhance its precision, for example, where
the time spent is related to the overall time of growth towards maturity of TRL 6. It is
recommended that the expected growth period of each stage be compared and that the total
maturity be the sum of the specific stages of maturity.

At each step, the maximum maturity value is the corresponding cardinal TRL. Due to the
normalized form of the coefficients, the maximum maturity is 1. However, in this study it may not
be true due to the assumptions made and we only obtain an overall scheme of development.

For example, to determine the maturity of Carbon 6 transitioning from TRL 3 to 4, the elapsed
time is 0.4 and the total time for development to TRL 6 is 1.9 as shown in Table XII. The Time
Ratio is determined to be 0.21. Since there are no sub criteria’s in the same level of Technology
which may influence this maturity any further, we then multiply it to the TRLc of the end state, i.e
0.04. Therefore, the maturity or readiness of the technology when affected while transitioning to
TRL 4 is 0.002. This factor is a relative measure to the total amount of time spent over developing
the technology.

Table XII: TRL Transition Time of 7 NASA Technologies, Piesen et al. [66].

TRL
Carbon
Fibre Non- Thrust Low
6 Tailless Direct
(Time Preform Destructive Vectoring Emission
Thermal Fighter To
in Seal Evaluation Nozzle Combustion
Barrier
Years)
𝑇𝑒1 0 to 1 0 0 0 0 0 0 0
𝑇𝑒2 1 to 2 0.4 1 0.5 3 0.3 1 0.2
𝑇𝑒3 2 to 3 0.4 1.5 1 1 0.3 1 0.1
𝑇𝑒4 3 to 4 0.4 1.5 1 1 0.4 1 0.1
𝑇𝑒5 4 to 5 0.5 1.5 1 1 2 2 1.1

44
 𝑇𝑒6 5 to 6 0.2 6 1 2 2 4 0.1
𝑇𝑑 0 to 6 1.9 11.5 4.5 8 5 9 1.6

As seen in Table XIII, we can now clearly determine the amount of time spent on the basis of the
cardinal coefficient assigned to each stage of growth. i.e., the conviction of the cardinal coefficient
first assimilates the associated complexity of technological growth using subjective influences and
professional judgement. When paired with the time dimension, we observe the trend of time
distribution and capital investment for each TRL for current or potential development ventures. It
is clear that the "Fibre Preform seal" used the greatest amount of time to hit TRL 6 from TRL 5
and the "Direct to" least. Here the cardinal coefficients are believed to be uniform for all 7
technologies and thus the complexity of each TRL is comparable. In the same manner, the
allocation of assets in an organisation may be conveniently tracked. The framework enables quick
readability and monitoring of the slippage schedule as seen in Figure 8.

Table XIII: NASA Technologies Maturity Comparison

WTRL WTRL WTRL WTRL WTRL WTRL
Technology
0-1 1-2 2-3 3-4 4-5 5-6
Carbon 6 Thermal Barrier 0 0.001 0.003 0.002 0.007 0.002
Fibre Preform Seal 0 0.002 0.010 0.008 0.021 0.067
Non-Destructive Evaluation 0 0.001 0.007 0.005 0.014 0.011
Tailless Fighter 0 0.005 0.007 0.005 0.014 0.022
Thrust Vectoring Nozzle 0 0.001 0.002 0.002 0.028 0.022
Low Emission Combustion 0 0.002 0.007 0.005 0.028 0.044
Direct To 0 0.000 0.001 0.001 0.015 0.001

The approach makes it possible for other strategic initiatives to develop around it. A trend line may
be drawn through the whole project to quickly assess the timing of slippage and construction
threats. For eg, whether the selected phase is set to be 5 years in order to achieve TRL 6. in this
case, the placement of the trend line would be the product of the desired time and the cardinal
coefficient, i.e., 5 x 0.01 = 0.05. The benchmark for each TRL may be further adjusted to attain
a higher degree of control as seen in Table XIV. In addition, forecasting models may be used to
predict the amount of capital that will be required to further evolve the technologies. A linear
forecast function is seen in Figure 8 indicating the resource distribution criteria for Fiber Preform
Seal and Direct To technologies. The linear forecast line is created using the Microsoft Excel chart

45
function, which uses the linear regression model to calculate the forecast.

While the system suggested by Fahimian and Behdinan used the cardinal coefficient to determine
the maturity of the technology using the AHP equation, the TRL was progressive and assumed to
be the aggregate function of time to compensate for its complexity. According to the mathematical
approach the accuracy of the matrix is often assumed to be reasonable. The consistency ratio as
originally defined by Saaty indicates that there are no human errors conducting pairwise
comparisons and that the conceptual credibility of the scores is preserved. Related conclusions as
suggested by the former can be obtained using aggregate time maturity and normalizing the
available data as seen in Figure 9. It was found that the method struggled to yield significant results
when assimilating the cardinal coefficients. The WTRL Method proposed in this study clearly
demarcated the trend of individual technologies using the AHP attributed TRL coefficients as
shown in Figure 10.

Table XIV: Schedule Benchmarking of NASA Technologies.

TRL 0 to 1 1 to 2 2 to 3 3 to 4 4 to 5 5 to 6
Benchmarking Time
0 2 1 2 1 3
(In Years)

Cardinal Value 0 0.004 0.007 0.01 0.014 0.033

46
 TRL Maturity of 7 NASA Technologies
Carbon 6 Thermal Barrier Fibre Preform Seal Non-Destructive Evaluation Tailless Fighter

Thrust Vectoring Nozzle Low Emission Combustion Direct To Schedule Benchmark

Linear (Fibre Preform Seal) Linear (Direct To)

0.07

0.06
Cardinal Coefficients

0.05

0.04

0.03

0.02

0.01
TRL
0
1 2 3 4 5 6 7

Figure 8: TRL Maturity, Forecast and Schedule Benchmarking using WTRL.

Figure 9: (A) Cardinal Coefficients Calculated by Fahimian et al. (B) Normalized Aggregated Sum of Maturity Time.

47
 WTRL Cardinal Coefficient
Carbon 6 Thermal Barrier Fibre Preform Seal Non-Destructive Evaluation Tailless Fighter

Thrust Vectoring Nozzle Low Emission Combustion Direct To

0.07

0.06
Cardinal Coefficients

0.05

0.04

0.03

0.02

0.01

0
1 2 3 4 5 6
TRL

Figure 10: WTRL Cardinal Coefficient.

48
9. CONCLUSION
The study identifies and attempts to tackle the setbacks caused due to lack of information for the
rapid development of emergency medical devices. It is found that other than industry specialists,
emerging developers and engineers must incorporate the necessary intricacies during medical
device development. The selection and perusal of emergency ventilators and medical devices in
general can be complex on multiple fronts. To ascertain the compatibility and demarcate the traits
of the medical system, it is of great importance that all avenues of its operation and functioning
are considered. Thus, the current study proposes frameworks attributed towards the assessment of
numerous factors such as open-source availability, performance, safety, regulatory compliance,
and technology maturity. The open-world requirements for developing an emergency use
ventilator are effectively mapped based on regulatory processes. A compilation of performance
measures towards the treatment of COVID19 subjected patients through mechanical ventilation
are presented. A globally acceptable and accurate regulatory pathway towards the development of
the said devices is presented. Furthermore, a novel technology development framework for
emergency is proposed based on the traditional TRL. The framework highlights the critical aspects
for development planning and decision making and the relevant changes applicable during an
emergency. The TRL model is scrutinized for its ordinality regarding which a flexible WTRL
method is proposed to determine the cardinal maturity of a system. Based on the varied results of
the study conducted, a glaring need for the formulation of mathematically accurate models towards
the assessment of technology maturity is observed. Hence, the proposed method uses a simple but
concise allocation of underlying endpoint processes towards the determination of quantitative
maturity growth models. The model however is determined to be lacking while considering the
complexities of large systems and development practices. It is concluded that a global need persists
towards the formulation of an industry specific technology development model which may yield
mathematically accurate data to ensure efficient and reasonable management of systems.

49
10. CONTRIBUTIONS
• In this dissertation we introduce a novel 3-tiered technological framework to discern the
various characteristics and effectiveness of the open-source technology models for
biomedical devices.
• The thesis eloquently demarcates the application of the TRL framework for biomedical
devices while effectively bounding it in the purview of current global necessities.
• Furthermore, well established techniques have been adopted and aligned towards the
expansion and identification of cardinal factors for maturity determination. An unique,
open structured equation is created which would readily enable its users for customized
applications specific to the relevant area of application.
• The formula is further applied and compared against its predecessors while effectively
neutralizing their major limitations.

11. FUTURE WORK

Despite the current findings, several gaps still remain which would require further efforts to
absolve. Listed below are some of the limitations and a suggestive future scope of work in line of
which these gaps could be addressed:
• The 3-Tiered assessment framework though informative, is a skeletal framework which
does not account for the deep-rooted complexities which may be faced during medical
device development. The former utilizes generalized selection parameters which could be
furthermore optimized for the use of biomedical applications.
• The biomedical TRL is an established, generalized framework to augment the requirements
of its specific users. This study attempts to remodel it for the sole purpose of identifying
emergency directives under current circumstances and may not be applicable otherwise.
Therefore, tailored frameworks could be investigated for the suitability of the specific
industry while improving its accuracy.
• The WTRL model is a 1-D model and fails to integrate the various other concurrent
processes involved in technology development. As compared to several other cardinal
models such as IRL, SRL, MRL and DRL, the open structure can be further expanded to
account for the various other influential characteristics.

50
REFERENCES
[1] World Health Organization. 2020. Pneumonia Of Unknown Cause – China. [online] Available at:
<https://www.who.int/csr/don/05-january-2020-pneumonia-of-unkown-cause-china/en/> [Accessed 23
November 2020].
[2] World Health Organization. 2020. WHO Director-General's Opening Remarks At The Media Briefing On
COVID-19 - 11 March 2020. [online] Available at: <https://www.who.int/dg/speeches/detail/who-director-
general-s-opening-remarks-at-the-media-briefing-on-covid-19---11-march-2020> [Accessed 23 November
2020].
[3] ArcGIS Dashboards. 2020. Arcgis Dashboards. [online] Available at:
<https://gisanddata.maps.arcgis.com/apps/opsdashboard/index.html#/bda7594740fd40299423467b48e9ecf6
> [Accessed 23 November 2020].
[4] Consult QD. 2020. Progression to ARDS In COVID-19: Here’S What It Looks Like. [online] Available at:
<https://consultqd.clevelandclinic.org/progression-to-ards-in-covid-19-heres-what-it-looks-like/> [Accessed
23 November 2020].
[5] Wu, C., Chen, X., Cai, Y., Xia, J., Zhou, X., Xu, S., Huang, H., Zhang, L., Zhou, X., Du, C., Zhang, Y., Song,
J., Wang, S., Chao, Y., Yang, Z., Xu, J., Zhou, X., Chen, D., Xiong, W., Xu, L., Zhou, F., Jiang, J., Bai, C.,
Zheng, J. and Song, Y., 2020. Risk Factors Associated With Acute Respiratory Distress Syndrome and Death
in Patients With Coronavirus Disease 2019 Pneumonia in Wuhan, China. JAMA Internal Medicine, 180(7),
p.934.
[6] Ranney, M., Griffeth, V. and Jha, A., 2020. Critical Supply Shortages — The Need for Ventilators and Personal
Protective Equipment during the Covid-19 Pandemic. New England Journal of Medicine, 382(18), p.e41.
[7] McMahon, D., Peters, G., Ivers, L. and Freeman, E., 2020. Global resource shortages during COVID-19: Bad
news for low-income countries. PLOS Neglected Tropical Diseases, 14(7), p.e0008412.
[8] CBC. 2020. Ontario Has One Of The Lowest Rates Of Ventilators Per Capita In Canada | CBC News. [online]
Available at: <https://www.cbc.ca/news/canada/ottawa/ontario-ventilator-covid19-coronavirus-1.5509454>
[Accessed 23 November 2020].
[9] Guérin, C. and Lévy, P., 2020. Easier access to mechanical ventilation worldwide: an urgent need for low
income countries, especially in face of the growing COVID-19 crisis. European Respiratory Journal, 55(6),
p.2001271.
[10] Robert, R., Patel, K. and Poushin, N., 2020. Evaluation Of Open Source Ventilators. [online] Google Docs.
Available at:
<https://docs.google.com/spreadsheets/d/1inYw5H4RiL0AC_J9vPWzJxXCdlkMLPBRdPgEVKF8DZw/edit
?usp=sharing> [Accessed 23 November 2020].
[11] Airtable. 2020. Grid View - Airtable. [online] Available at:
<https://airtable.com/shr01Ys1n32nwT4R5/tbl7hMA18kmI63JDk?backgroundColor=red&viewControls=on
> [Accessed 23 November 2020].
[12] Pearce, J., 2020. A review of open source ventilators for COVID-19 and future pandemics. F1000Research, 9,
p.218.
[13] Wells, C., Fitzpatrick, M., Sah, P., Shoukat, A., Pandey, A., El-Sayed, A., Singer, B., Moghadas, S. and
Galvani, A., 2020. Projecting the demand for ventilators at the peak of the COVID-19 outbreak in the
USA. The Lancet Infectious Diseases, 20(10), pp.1123-1125.
[14] Food and Drug Administration, 2020. Emergency Use Authorization. [online] Available at:
<https://www.fda.gov/media/136423/download> [Accessed 23 November 2020].
[15] Canada, H., 2020. Interim Order Respecting Clinical Trials For Medical Devices And Drugs Relating To
COVID-19 - Canada.Ca. [online] Canada.ca. Available at: <https://www.canada.ca/en/health-
canada/services/drugs-health-products/covid19-industry/interim-order-respecting-clinical-trials-medical-
devices-drugs.html> [Accessed 23 November 2020].

51
[16] GOV.UK. 2020. Exemptions From Devices Regulations During The Coronavirus (COVID-19) Outbreak.
[online] Available at: <https://www.gov.uk/guidance/exemptions-from-devices-regulations-during-the-
coronavirus-covid-19-outbreak> [Accessed 23 November 2020].
[17] Therapeutic Goods Administration (TGA). 2020. Ventilators And Other Devices Intended For Respiratory
Support For COVID-19. [online] Available at: <https://www.tga.gov.au/behind-news/ventilators-and-other-
devices-intended-respiratory-support-covid-19> [Accessed 23 November 2020].
[18] ISO. 2020. COVID-19 Response: Freely Available ISO Standards. [online] Available at:
<https://www.iso.org/covid19> [Accessed 23 November 2020].
[19] Bsigroup.com. 2020. COVID-19 Response - Ventilators. [online] Available at:
<https://www.bsigroup.com/en-GB/topics/novel-coronavirus-covid-19/ventilators/.> [Accessed 23 November
2020].
[20] American National Standards Institute - ANSI. 2020. ANSI News Search. [online] Available at:
<https://www.ansi.org/news_publications/news_story?menuid=7&articleid=27ba33a0-7482-47c5-b3a7-
faa8a55518eb> [Accessed 23 November 2020].
[21] Astm.org. 2020. ASTM Standards & COVID-19. [online] Available at: <https://www.astm.org/COVID-19/.>
[Accessed 23 November 2020].
[22] IEEE. 2020. Covid19. [online] Available at: <https://standards.ieee.org/covid-19/index.html.>
[23] CSA Group. 2020. COVID-19 Response Standards & Handbooks - CSA Group. [online] Available at:
<https://www.csagroup.org/news/covid-19-response-standards-handbooks/> [Accessed 23 November 2020].
[24] Coronavirus Resources from the Field 2020. AAMI Coronavirus Resources. [online] Available at:
<https://www.aami.org/news-resources/covid-19-updates/coronavirus-resources-for-the-field> [Accessed 23
November 2020].
[25] Guru, G., 2020. 2020 State Of Medical Device Product Development & Quality Management. [online]
Greenlight.guru. Available at: <https://www.greenlight.guru/state-of-medical-device> [Accessed 23
November 2020].
[26] U.S. Food and Drug Administration. 2020. Classify Your Medical Device. [online] Available at:
<https://www.fda.gov/medical-devices/overview-device-regulation/classify-your-medical-device> [Accessed
23 November 2020].
[27] European Commission. 2020. [online] Available at:
<https://ec.europa.eu/docsroom/documents/38669/attachments/1/translations/en/renditions/pdf> [Accessed
23 November 2020].
[28] Canada, H., 2020. Guidance Document - Guidance On The Risk-Based Classification System For Non-In Vitro
Diagnostic Devices (Non-Ivdds) - Canada.Ca. [online] Canada.ca. Available at:
<https://www.canada.ca/en/health-canada/services/drugs-health-products/medical-devices/application-
information/guidance-documents/guidance-document-guidance-risk-based-classification-system-non-vitro-
diagnostic.html#a32> [Accessed 23 November 2020].
[29] Van Norman, G., 2016. Drugs, Devices, and the FDA: Part 2. JACC: Basic to Translational Science, 1(4),
pp.277-287.
[30] Ocampo, J. and Kaminski, P., 2019. Medical device development, from technical design to integrated product
development. Journal of Medical Engineering & Technology, 43(5), pp.287-304.
[31] US Department of Defense ,2009. Technology Readiness Assessment (TRA) Deskbook. [online]
Skatelescope.org. Available at:
<https://www.skatelescope.org/public/2011-11-18_WBS-
SOW_Development_Reference_Documents/DoD_TRA_July_2009_Read_Version.pdf> [Accessed 23
November 2020].
[32] Mankins, J.C., 1995. Technology Readiness Levels. NASA office of Space and Technology White Paper, p.5.

52
[33] B. Sauser, J. Ramirez-Marquez, R. Magnaye and W. Tan, 2009. A Systems Approach to Expanding the
Technology Readiness Level within Defense Acquisition. Stevens Institute of Technology, School of Systems
and Enterprises, Castle Point on Hudson, Hoboken, NJ. Available at:
<https://apps.dtic.mil/docs/citations/ADA530242> [Accessed 23 November 2020].
[34] S. Blanchette, Jr., C. Albert and S. Garcia-Miller, 2010. Beyond Technology Readiness Levels for Software:
U.S. Army Workshop Report, Software Engineering Institute, Carnegie Mellon University, Pittsburg, PA.
Available at: <https://resources.sei.cmu.edu/asset_files/TechnicalReport/2010_005_001_15305.pdf>
[Accessed 23 November 2020].
[35] US Department of Defense, 2011. Manufacturing Readiness Level (MRL) Deskbook V2. Available:
http://www.dodmrl.com/MRL_Deskbook_V2.pdf. [Accessed 13th November 2020]
[36] Revfi, S., Wilwer, J., Behdinan, K. and Albers, A., 2020. Design Readiness of Multi-Material Concepts:
Manufacturing And Joining Technology Integrated Evaluation Of Concept Maturity Levels Using Cardinal
Coefficients. Proceedings of The Design Society: Design Conference.
[37] Conrow, E., 2011. Estimating Technology Readiness Level Coefficients. Journal of Spacecraft and Rockets,
48(1), pp.146-152.
[38] Saaty, T., 1990. How to make a decision: The analytic hierarchy process. European Journal of Operational
Research, 48(1), pp.9-26.
[39] M. Fahimian and K. Behdinan 2017. On characterization of technology readiness level coefficients for
design. DS 87-2 Proceedings of the 21st International Conference on Engineering Design (ICED 17) Vol 2:
Design Processes, Design Organisation and Management, Vancouver, Canada.
[40] Kujawski, E., 2013. Analysis and Critique of the System Readiness Level. IEEE Transactions on Systems,
Man, and Cybernetics: Systems, 43(4), pp.979-987.
[41] Olechowski, A., Eppinger, S., Joglekar, N. and Tomaschek, K., 2020. Technology readiness levels:
Shortcomings and improvement opportunities. Systems Engineering, 23(4), pp.395-408.
[42] Mankins, J.C, 2009. Technology readiness and risk assessments: A new approach, Acta Astronautica, vol. 65,
no. 9-10, pp. 1208-1215.
[43] Assistant Secretary of Defense for Research and Engineering (ASD(R&E)), 2011. Readiness Assessment
(TRA) Guidance, Washington, DC.
[44] Department of Homeland Security Science and Technology Directorate, 2009. Department of Homeland
Security Science and Technology Readiness Level Calculator (ver 1.1) Final Report and User’s Manual,
Department of Homeland Security Science and Technology Directorate, 900 S. Quincy Street, Arlington.
[45] Hook-Barnard, I., Norris, S., Alper, J., Policy, B., Sciences, B., Medicine, I. and Council, N.,
2020. Technology Readiness Levels In The Department Of Defense. [online] Ncbi.nlm.nih.gov. Available at:
<https://www.ncbi.nlm.nih.gov/books/NBK201356> [Accessed 23 November 2020].
[46] MECA - Medical Equipment Compliance Associates. 2020. IEC 60601-1: Download Free Compliance
Documents | MECA. [online] Available at: <https://60601-1.com/information/> [Accessed 23 November
2020].
[47] AAMI. 2020. AAMI Coronavirus Resources. [online] Available at: <https://www.aami.org/news-
resources/covid-19-updates/coronavirus-resources-for-the-field> [Accessed 23 November 2020].
[48] Heron, D. and Tindale OBE, P., 2015. Healthcare technology co-operatives: Innovative about
innovation. Journal of Medical Engineering & Technology, 39(7), pp.378-381.
[49] Pietzsch, J., Aquino, L., Yock, P., Paté-Cornell, M. and Linehan, J., 2007. Review of U.S. Medical Device
Regulation. Journal of Medical Devices, 1(4), pp.283-292.
[50] U.S. Food and Drug Administration, 2020. FAQs on Emergency Use Authorizations (EUAs) for Devices -
COVID-19. [Online]. Available at: <https://www.fda.gov/medical-devices/coronavirus-disease-2019-covid-
19-emergency-use-authorizations-medical-devices/faqs-emergency-use-authorizations-euas-medical-
devices-during-covid-19-pandemic.> [Accessed 23 November 2020].

53
[51] OSHWA, (2020). Open-Source Hardware Certification. [Online]. Available:
<https://certification.oshwa.org/process.html> [Accessed 23 November 2020].
[52] Grob A, Biersach B and Peck J., 2015. Risk Management And IEC 60601-1: Assessing Compliance.
Biomedical Instrumentation & Technology 49:55-59.
[53] Flood D, McCaffery F, Casey V, McKeever R and Rust P, 2015. A roadmap to ISO 14971 implementation.
Journal of Software: Evolution and Process 27:319-336.
[54] MIT Emergency Ventilator. 2020. MIT Emergency Ventilator | Design Toolbox. [online] Available at:
<https://emergency-vent.mit.edu> [Accessed 23 November 2020].
[55] Oedk.rice.edu. 2020. OEDK - Rice University - Apollobvm. [online] Available at:
<http://oedk.rice.edu/apollobvm/> [Accessed 23 November 2020].
[56] News.rice.edu. 2020. FDA Oks Manufacturer’S Version Of Rice Ventilator. [online] Available at:
<https://news.rice.edu/2020/08/04/fda-oks-manufacturers-version-of-rice-ventilator-2/> [Accessed 23
November 2020].
[57] A. Petsiuk, N. Tanikella, S. Dertinger, A. Pringle, S. Oberloier and J. Pearce, 2020. Partially RepRapable
automated open source bag valve mask-based ventilator, HardwareX, vol. 8, p. e00131.
[58] The Air Project. 2020. Home. [online] Available at: <https://the-air-project.github.io/.> [Accessed 23
November 2020].
[59] U.S. Food and Drug Administration. 2020. Enforcement Policy. [Online]. Available at:
<https://www.fda.gov/media/136318/download> [Accessed 23 November 2020].
[60] Micomedical.cz. 2020. Product Info Corovent. [online] Available at: <https://www.micomedical.cz/product-
info-corovent#detail-info> [Accessed 23 November 2020].
[61] WorldVent | World Ventilator Foundation. 2020. Worldvent™ Ventilator Overview | WVF. [online] Available
at: <https://www.worldvent.org/worldvent-overview> [Accessed 23 November 2020].
[62] Via Global Health. 2020. Product Specification. [online] Available at: <https://viaglobalhealth.com/wp-
content/uploads/2020/09/Neonatal-Rescue-AdultLife-Pro-Product-Guide.pdf> [Accessed 23 November
2020].
[63] U.S. Food and Drug Administration. 2020. Ventilators And Ventilator Accessories Euas. [online] Available
at: <https://www.fda.gov/medical-devices/coronavirus-disease-2019-covid-19-emergency-use-
authorizations-medical-devices/ventilators-and-ventilator-accessories-euas> [Accessed 23 November 2020].
[64] Rezaei, J., 2015. Best-worst multi-criteria decision-making method. Omega, 53, pp.49-57.
[65] Rezaei, J., 2015. BWM Solver. [online] Bestworstmethod.com. Available at:
<https://bestworstmethod.com/wp-content/uploads/2019/07/BWM-Solver-4.xlsx> [Accessed 23 November
2020].
[66] Peisen, D.J., Schulz, C.R., Golaszewki, R.S., Ballard, B.D. and Smith, J., 1999. "Time Required to Mature
Aeronautic Technologies to Operational Readiness", SAIC Report.
[67] ISO 80601-2-79: 2018: Medical electrical equipment — Part 2-79: Particular requirements for basic safety and
essential performance of ventilatory support equipment for ventilatory impairment, Geneva, Switzerland.
[68] ISO 80601-2-84:2020. Medical electrical equipment – Part 2-84: Particular Requirements for the Basic Safety
and Essential Performance of Ventilators for the Emergency Medical Services Environment. International
Organization for Standardization, Geneva, Switzerland, 2020.
[69] ISO 80601-2-80:2019. Medical Electrical Equipment - Part 2-80:2019 Particular Requirements for Basic
Safety and Essential Performance of Ventilatory Support Equipment for Ventilatory Insufficiency.
International Organization for Standardization, Geneva, Switzerland, 2019.
[70] ISO 10993: Fifth Edition 2018-08: Biological Evaluation of Medical Devices - Part 1: Evaluation and Testing
Within a Risk Management Process, International Organization for Standardization, Geneva, Switzerland.

54
[71] ISO 18562-1 First Edition 2017-03: Biocompatibility Evaluation of Breathing Gas Pathways in Healthcare
Applications - Part 1: Evaluation and Testing Within a Risk Management Process, International Organization
for Standardization, Geneva, Switzerland.
[72] ISO 18562-2 First Edition 2017-03: Biocompatibility Evaluation of Breathing Gas Pathways in Healthcare
Applications - Part 2: Tests for Emissions of Particulate Matter, International Organization for Standardization,
Geneva, Switzerland.
[73] ISO 18562-3 First Edition 2017: Biocompatibility Evaluation of Breathing Gas Pathways in Healthcare
Applications - Part 3: Tests for Emissions of Volatile Organic Compounds, International Organization for
Standardization, Geneva, Switzerland.
[74] ISO 18562-4 First Edition 2017-03: Biocompatibility Evaluation of Breathing Gas Pathways in Healthcare
Applications - Part 4: Tests for Leachables in Condensate, International Organization for Standardization,
Geneva, Switzerland.
[75] ISO 13485:2016 Medical Devices – Quality Management Systems – Requirements for Regulatory Purposes,
International Organization for Standardization, Geneva, Switzerland.
[76] ISO 14971: Application of Risk Management To Medical Devices, International Organization for
Standardization, Geneva, Switzerland.
[77] IEC 60601-1: 2012: Medical Electrical Equipment – Part 1: General Requirements for Basic Safety and
Essential Performance, International Electrotechnical Commission, Geneva, Switzerland.
[78] IEC 60601-1-2: 2014: Medical Electrical Equipment Part 1-2: General Requirements for Basic Safety and
Essential Performance – Collateral Standard: Electromagnetic Disturbances – Requirements and Tests,
International Electrotechnical Commission, Geneva, Switzerland.
[79] IEC 62304: 2015: Medical Device Software – Software Life Cycle Processes, International Electrotechnical
Commission, Geneva, Switzerland.
[80] IEC 60601-1-11:2015: Medical electrical equipment — Part 1-11: General requirements for basic safety and
essential performance — Collateral standard: Requirements for medical electrical equipment and medical
electrical systems used in the home healthcare environment, Geneva, Switzerland.
[81] ISO 80601-2-12:2020: Medical electrical equipment — Part 2-12: Particular requirements for basic safety and
essential performance of critical care ventilators, Geneva, Switzerland.
[82] IEC 62366-1:2015/AMD 1: 2020: Medical devices — Part 1: Application of usability engineering to medical
devices — Amendment 1, Geneva, Switzerland.
[83] IEC 60601-1-8: 2006: Medical electrical equipment — Part 1-8: General requirements for basic safety and
essential performance — Collateral standard: General requirements, tests and guidance for alarm systems in
medical electrical equipment and medical electrical systems, Geneva, Switzerland.
[84] IEC 60601-1-6:2010+AMD1:2013+AMD2:2020 : Medical electrical equipment - Part 1-6: General
requirements for basic safety and essential performance - Collateral standard: Usability, Geneva, Switzerland.
[85] ISO 10651-5:2006: Lung ventilators for medical use — Particular requirements for basic safety and essential
performance — Part 5: Gas-powered emergency resuscitators, Geneva, Switzerland.
[86] ISO 17510:2015: Medical devices — Sleep apnoea breathing therapy — Masks and application accessories,
Geneva, Switzerland.
[87] ISO/DIS 80601-2-13: Medical electrical equipment — Part 2-13: Particular requirements for basic safety and
essential performance of an anaesthetic workstation, Geneva, Switzerland.
[88] ISO 80601-2-69:2014: Medical electrical equipment — Part 2-69: Particular requirements for basic safety and
essential performance of oxygen concentrator equipment, Geneva, Switzerland.
[89] ISO 80601-2-74:2017: Medical electrical equipment — Part 2-74: Particular requirements for basic safety and
essential performance of respiratory humidifying equipment, Geneva, Switzerland.

55
[90] ISO 80601-2-70:2015: Medical electrical equipment — Part 2-70: Particular requirements for basic safety and
essential performance of sleep apnoea breathing therapy equipment, Geneva, Switzerland.
[91] AAMI TIR69:2017: Risk Management of Radio-Frequency Wireless Coexistence For Medical Devices And
Systems.
[92] IEEE/ANSI C63.27-2017: American National Standard For Evaluation Of Wireless Coexistence
[93] ISO 5356-1:2015: Anaesthetic and respiratory equipment — Conical connectors — Part 1: Cones and sockets,
Geneva, Switzerland.
[94] ISO 5366:2016: Anaesthetic and respiratory equipment — Tracheostomy tubes and connectors, Geneva,
Switzerland.
[95] ISO 18190:2016: Anaesthetic and respiratory equipment — General requirements for airways and related
equipment, Geneva, Switzerland.

56
APPENDIX A: LEVEL 1 ASSESSMENT CHECKLIST
Table A1: Level 1 Assessment Checklist by OSHWA [51].

Requirement Open Source: Documentation

The hardware must be released with documentation including design files and must
Must
allow modification and distribution of the design files.

Where documentation is not furnished with the physical product, there must be a well-
Must publicized means of obtaining this documentation for no more than a reasonable
reproduction cost, preferably downloading via the Internet without charge.

The documentation must include design files in the preferred format for making
Must
changes, for example the native file format of a CAD program.

Must Deliberately obfuscated design files must not be allowed

Intermediate forms analogous to compiled computer code — such as printer-ready

Must
copper artwork from a CAD program — are not allowed as substitutes
The license may require that the design files are provided in fully documented, open
Could
format(s).
The documentation for the hardware must clearly specify what portion of the design, if
Must
not all, is being released under the license.

Your open-source hardware project should include a general description of the

Should
hardware’s identity and purpose, written as much as possible for a general audience

Requirement Open Source: License

If the licensed design requires software, embedded or otherwise, to operate properly and
fulfill its essential functions, then the license may require that one of the following
conditions are met:
a) The interfaces are sufficiently documented such that it could reasonably be
Must considered straightforward to write open source software that allows the device to
operate properly and fulfill its essential functions. For example, this may include the use
of detailed signal timing diagrams or pseudocode to clearly illustrate the interface in
operation.

b) The necessary software is released under an OSI-approved open source license.

The license shall allow modifications and derived works and shall allow them to be
Must
distributed under the same terms as the license of the original work.

The license shall allow for the manufacture, sale, distribution, and use of products
Must
created from the design files, the design files themselves, and derivatives thereof.
The license shall not restrict any party from selling or giving away the project
Must
documentation
The license shall not require a royalty or other fee for such sale. The license shall not
Must
require any royalty or fee related to the sale of derived works.

57
 The license may require derived documents, and copyright notices associated with
devices, to provide attribution to the licensors when distributing design files,
manufactured products, and/or derivatives thereof.
Could

The license may require that this information be accessible to the end-user using the
device normally but shall not specify a specific format of display.

The license may require derived works to carry a different name or version number
Must
from the original design

Must The license must not discriminate against any person or group of persons

The license must not restrict anyone from making use of the work (including
Must manufactured hardware) in a specific field of endeavor. For example, it must not restrict
the hardware from being used in a business, or from being used in nuclear research.

The rights granted by the license must apply to all to whom the work is redistributed
Must
without the need for execution of an additional license by those parties.

The rights granted by the license must not depend on the licensed work being part of a
particular product. If a portion is extracted from a work and used or distributed within
Must
the terms of the license, all parties to whom that work is redistributed should have the
same rights as those that are granted for the original work.

The license must not place restrictions on other items that are aggregated with the
licensed work but not derivative of it. For example, the license must not insist that all
Must
other hardware sold with the licensed item be open source, nor that only open source
software be used external to the device.

No provision of the license may be predicated on any individual technology, specific

Must
part or component, material, or style of interface or use thereof.
Note that the definition of open-source hardware specifies that you must allow
Must modification and commercial re-use of your design, so do not use licenses with a no-
derivatives or non-commercial clause.
When licensing your project, keep in mind that someone who makes a derivative of
your hardware will probably also want to build on your software, instructions, and other
Should
documentation; you should license not just the hardware design files but also these
other elements of your project.
Requirement Open Source: Original and Auxiliary Design Files
Share the original source files that you would use to make modifications to the
hardware’s design. Ideally, your open-source hardware project would be designed using
a free and open-source software application, to maximize the ability of others to view
and edit it.
Examples of Original Design Files include:
Must
• 2D drawings or computer-aided design (CAD) files, such as those used to describe
two-dimensional laser cut, vinyl cut, or water-jet cut part, in their original format.

Example formats: Native 2D design files saved by Corel Draw (.cdr), Inkscape (.svg),
Adobe Illustrator (.ai), AutoCAD, etc.

58
 • 3D designs that can be 3D printed, forged, injection molded, extruded, machined, etc.
Example formats: Native files saved by SolidWorks (.sldprt, .sldasm), Rhino, etc.
• Circuit board CAD files such as capture files (schematics) and printed-circuit board
(layout) design files. Example formats: Native files saved by Eagle, Altium, KiCad,
gEDA, etc.
• Component libraries (symbol, footprint, fastener, etc.) necessary for native
modification of CAD files.
• Additional technical drawings in their original design formats, if required for
fabrication of the device.
• Additional artwork that may be used on the device and is included as part of the
OSHW release, such as an emblem, or cosmetic overlay in the original design format.

Examples of alternative formats that could constitute original design files under special
circumstances include:

• Hand-coded G-code for a machined part. (G-code)

• Scans of hand-drawn blueprints. (JPEG)
• Detailed 3D scans of a hand-carved resin-casting mold. (STL)
• Mask pattern for etching a single-side circuit board, as drawn in MS Paint. (PNG)

Hardware design files created in proprietary programs and stored in proprietary formats
Must are still required to be shared. They are the very files that someone will need in order to
contribute changes to a given design.

Organize files in a logical way; comment complex aspects; note any unusual
Should
manufacturing procedures; etc.

Original design files need to be presented in their native file format as well as in more
accessible formats so that it can be opened or imported by other CAD programs.

Examples of auxiliary design files include:

• 2D drawings or CAD files, in a 2D export or interchange format. Example formats:
DXF, SVG
• 2D drawings or CAD files, in an easily viewable 2D export format. Example formats:
PDF, JPEG, PNG, etc. (Where possible, vector formats are preferred over bitmap
formats.)
• 3D designs or CAD files, in a 3D export or interchange format. Example formats:
STEP, IGES
Should
• 2D or 3D designs in manufacturing-ready export formats Example formats: G-code,
STEP-NC, STL, AMF
• Circuit board design files in export or interchange formats. Example formats: EDIF,
Open JSON
• Circuit board designs in manufacturing-ready formats Example formats: Gerber RS-
274X, Excellon
• Additional technical drawings in their original formats, if required for fabrication of
the device, in a commonly-readable format such as PDF.

• Additional artwork, for example different colored skins for an instrument panel.

59
 It is also helpful to provide ready-to-view outputs that can easily be viewed by end
users who wish to understand (but not necessarily modify) the design. For example, a
PDF of a circuit board schematic, or an STL of a 3D design. These auxiliary design files
Should allow people to study the design of the hardware, and sometimes even fabricate it, even
without access to particular proprietary software packages. However, note that auxiliary
design files are never allowed as substitutes for original design files

Requirement Open Source: Bill of Materials

While it might be possible to infer from the design files which parts make up a piece of
hardware, it is important to provide a separate bill of materials. This can be a
Should spreadsheet (e.g. CSV, XLS, Google Doc) or simply a text file with one part per line. If
your CAD package has integrated or add-on BOM management tools, those are also a
good option. (Examples include the built-in tools in SolidWorks and bom-ex for Eagle.)

Useful things to include in the bill of materials are part numbers, suppliers, costs, and a
Should
short description of each part.

Make it easy to tell which item in the bill of materials corresponds to which component
Should in your design files: use matching reference designators in both places, provide a
diagram indicating which part goes where, or otherwise explain the correspondence.

Requirement Open Source: Software and Firmware

You should share any code or firmware required to operate your hardware. This will
allow others to use it with their hardware or modify it along with their modifications to
your hardware. Document the process required to build your software, including links to
Should
any dependencies (e.g. third-party libraries or tools). In addition, it’s helpful to provide
an overview of the state of the software (e.g. “stable” or “beta” or “barely-working
hack”).

Requirement Open Source: Photos

Photos help people understand what your project is and how to put it together. It’s good
to publish photographs from multiple viewpoints and at various stages of assembly. If
Should you don’t have photos, posting 3D renderings of your design is a good alternative.
Either way, it’s good to provide captions or text that explain what’s shown in each
image and why’s it’s useful.

Requirement Open Source: Instructions and Other Explanations

Making the hardware: To help others make and modify your hardware design, you
should provide instructions for going from your design files to the working physical
Should hardware. As part of the instructions, it’s helpful to link to datasheets for the
components / parts of your hardware and to list the tools required to assemble it. If the
design requires specialized tools, tell people where to get them.
Using the hardware: Once someone has made the hardware, they need to know how to
Should use it. Provide instructions that explain what it does, how to set it up, and how to
interact with it.
Design rationale: If someone wants to modify your design, they’ll want to know why it
Should is the way it is. Explain the overall plan of the hardware’s design and why you made the
specific choices you did.

60
 Keep in mind that these instructions may be read by someone whose expertise or
training is different from yours. As much as possible, try to write to a general audience,
Should
and check your instructions for industry jargon, be explicit about what you assume the
user knows, etc.
The instructions could be in a variety of formats, like a wiki, text file, Google Doc, or
PDF. Remember, though, that others might want to modify your instructions as they
Should
modify your hardware design, so it’s good to provide the original editable files for your
documentation, not just output formats like PDF.
Requirement Open Source: Designing your Hardware

Use free and open-source software design (CAD) tools where possible. If that’s not
Should
feasible, try to use low-cost and/or widely used software packages.
Use standard and widely available components, materials, and production processes.
Should Try to avoid parts that aren’t available to individual customers or processes that require
expensive setup costs.
Requirement Open Source: Hosting and Distributing

All files (design, bill-of-materials, assembly instructions, code, etc) should be version
Should
controlled where possible.

Provide links to the source (original design files) for your hardware on the product
Should
itself, its packaging, or its documentation.

Should Make it easy to find the source (original design files) from the website for a product.

Label the hardware with a version number or release date so that people can match the
Should
physical object with the corresponding version of its design files.

Use the open-source hardware logo on your hardware. Do so in a way that makes it
Should
clear which parts of the hardware the logo applies to (i.e. which parts are open-source).

Should In general, clearly indicate which parts of a product are open-source (and which aren’t).

Don’t refer to hardware as open-source until the design files are available. If you plan
Should
on open-sourcing the product in the future, say that instead.

Requirement Open Source: Github

Include your project name in the README. Your project’s name is the first thing
Should people will see upon scrolling down to your README and is included upon creation of
your README file.
Include a description in the README. A good description is clear, short, and to the
Should
point. Describe the importance of your project, and what it does.

Optionally, include a table of contents in order to allow other people to quickly navigate
Should
especially long or detailed READMEs.
Include an installation section in the README. Tell other users how to install your
Should project locally. Optionally, include a gif to make the process even more clear for other
people.
Include a usage section in the README, in which you instruct other people on how to
Should use your project after they’ve installed it. This would also be a good place to include
screenshots of your project in action.

61
 Larger projects often have sections on contributing to their project in the README, in
which contribution instructions are outlined. Sometimes, this is a separate file. If you
Should
have specific contribution preferences, explain them so that other developers know how
to best contribute to your work.
Include a section for credits in the README in order to highlight and link to the
Should
authors of your project.
Should Include a section for the license of your project in the README file
Your README should contain only the necessary information for developers to get
Should started using and contributing to your project. Longer documentation is best suited for
wikis.

Finally, open source projects use the following tools to organize discussion. Reading
through the archives will give you a good picture of how the community thinks and
works. Ask, does the project has one or all the following:

Issue tracker: Where people discuss issues related to the project.

Should Pull requests: Where people discuss and review changes that are in progress.

Discussion forums or mailing lists: Some projects may use these channels for
conversational topics. Others use the issue tracker for all conversations.

Synchronous chat channel: Some projects use chat channels (such as Slack or IRC) for
casual conversation, collaboration, and quick exchanges.

Requirement Open Source: Building on Open-Source Hardware

Must Respect the trademarks of others
Should Share your changes and improvements with the creator of the original hardware.

Be emotionally prepared to allow your project to be copied (unless your trademark is

Should
violated, then act according to trademark law).

While direct commercial use of existing open source hardware designs is explicitly
Should allowed, it is better — when possible — to make useful improvements to the design and
to release that improved version as open source hardware.

Consider registering the project under your trademark. Trademark law prevents other
people from using your brand name or logo on their own hardware. But it does not stop
Should
them from copying your product’s function so long as they do not copy its trademark-
protected design.
HARDWARE

Have you provided links to your original design files for your hardware on the product itself or its
documentation?

Have you made it easy to find your original design files from the website for a product?
Have you clearly indicated which parts of a product are open-source (and which aren’t)?

62
Have you applied an open source license to your hardware?
After certification, remember to:

· Label your hardware with a version number or release date, so people can match the physical object
with the corresponding version of its design files.

· Use the OSHWA certification mark logo on your hardware. Do so in a way that makes it clear which
parts of the hardware the logo applies to (i.e. which parts are open-source).

SOFTWARE
Have you made your project’s software publicly available?
Have you applied an open source license to your software?

The OSHWA definition requires all software that is necessary for the operation of your hardware to be
licensed under an OSI-approved license.

DOCUMENTATION
Have you made your original design files publicly available?
Have you made your any auxiliary design files publicly available? (optional)
Have you made a bill of materials publicly available?
Have you made photos of your product at various stages of assembly publicly available? (optional)
Have you made any instructions or other explanations publicly available? (optional)
Have you properly licensed your design files so that others may reproduce or build upon them?
BRANDING
Does your product have any branding elements?
Have you chosen original brand names, product names, logos, and product designs (if applicable)?
Have you read the USPTO Trademark Basics Guide?
Have you consulted with a trademark lawyer, or registered your trademarks on your own?

63
APPENDIX B: LEVEL 2 ASSESSMENT CHECKLIST
Table B1: Level 2 Assessment Checklist.

Parameter
FiO2
Must accommodate the range of 21-100%.
FiO2 over the range of 21 % (ambient) to 95 % of the source oxygen concentration input to the EUV in no
more than 10 % steps.
PEEP
Must provide a range 5 – 20 cm H2O adjustable in 5 cm H2O increments.
PEEP must be maintained during expiration.
Inadvertent PEEP: The positive expiratory pressure at the end of the expiratory phase shall not exceed 2
cm H2O.
Inadvertent continuing expiratory pressure: Means shall be provided to prevent the build-up of continuing
positive pressure from exceeding 2 cm H2O.
Set PEEP (i.e. BAP) (5 to 20) cmH2O in no more than 5 cmH2O steps.
Flowrate
Flow Rates must provide for a gas reservoir to manage peak inspiratory flow rates in the range of 0 -
100lpm.
Tidal Volume
Must accommodate the range of 50-1500 ml (can be scaled back to 1000) as patients VT are based on 4 -
8 ml/kg.
Could provide increments of 50 ml.
Must have at least one setting of 400ml with +/- 10 ml increments.
Upper limit of tidal volume could be set to 800 ml.
Tidal volume (350 to 450) ml ±10 % in no more than steps of 50 ml, preferably a lower range of 250 ml
and an upper range of 600 ml or 800 ml.
Minute Ventilation
Must be able to accommodate the range of 5 – 10 L/minute.
Respiratory Rate
Resp Rate: 4-45 bpm
Must provide a range 10 - 30 breaths per minute in increments of 2 (only in mandatory mode) that can be
set by the user.
Inspiratory/Expiratory Ratio
Must provide an adjustable range of 1:1 – 1:4.
Must provide 1:2.0 (i.e. expiration lasts twice as long as inspiration) as the default setting.
The inspiratory and expiratory resistances measured at the patient connection port shall, during spontaneous
breathing and normal operation, not exceed 6 cmH20 at flowrates of 60 I/min for adult use, 30 I/min for
pediatric use and 5 I/min for neonatal use.

64
Parameter
I:E ratio (ratio of inspiratory to expiratory time) of 1:2 preferably adjustable from 1:1 to 1:3.
Inspiratory Airway Pressure
Where applicable, inspiratory pressure limit (15 to 40) cmH2O preferably adjustable in steps of no more
than 5 cmH2O.
To help prevent contaminating the environment (and particularly the clinicians), filters need to be placed
in the expiratory pathways. Particular attention needs to be placed on the exhaust port.
Plateau pressures should be limited to a maximum of35 cm H2O.
Peak pressure should be no more than 2 cm H2O greater than plateau pressure.
If VCV is used, the user must be able to set inspiratory airway pressure limit in the range at least 15 - 40
cmH2O in at least increments of 5 cmH2O.
There must be a mechanical failsafe valve that opens at 80 cmH2O.
Inspiratory resistance during the resuscitator expiratory phase
During the expiratory phase, the pressure at the patient connection port shall not exceed 6 cm H2O below
atmospheric pressure at an inspiratory airflow of 60 l/min for resuscitators intended for patients with a body
mass greater than 10 kg and of 6 l/min for resuscitators intended for patients with a body mass up to 10
kg.
Spontaneous breathing with the gas input pressure outside the rated range
When operating with the gas input pressure outside the rated range and during the inspiratory phase, either
the resuscitator shall generate a delivered volume and inspiratory time within ± 25 % of that achieved
during normal use, or the resuscitator shall be designed to allow spontaneous breathing.

Under these spontaneous breathing conditions, the pressures below and above atmospheric pressure at the
patient connection port shall not exceed 6 cm H2O, at airflows of 30 l/min for resuscitators intended for
patients with a body mass greater than 10 kg and of 3 l/min for resuscitators intended for patients with a
body mass up to 10 kg.
Expiratory resistance
In the absence of a removable positive end-expiratory pressure (PEEP) valve or with an integral positive
end expiratory pressure function set to its minimum value, the pressure at the patient connection port during
the expiratory phase shall not exceed 6 cm H2O above atmospheric pressure at an expiratory airflow of 60
l/min for resuscitators intended for patients with a body mass greater than 10 kg and of 6 l/min for
resuscitators intended for patients with a body mass up to 10 kg.
Resuscitator dead space and dead space of airway accessories
The resuscitator dead space shall not exceed 5,5 % of the minimum delivered volume from the Resuscitator.
Inspiratory flow
A resuscitator with a pre-set flow, intended for use with patients with greater than 40 kg body mass (adult
use), when set to deliver > 85 % O2, shall deliver inspiratory flows between 25 l/min and 40 l/min, both on
free flow to atmosphere and against a back-pressure of 20 cmH2O.

Such resuscitators with operator-adjustable flows shall have a range of adjustment that overlaps this range.
Threshold pressure for initiation of flow
The pressure at the patient connection port needed to initiate gas flow from the demand valve shall not be
numerically greater than 2 cm H2O below atmospheric pressure.

65
Parameter
Peak inspiratory flow
The minimum peak inspiratory flow shall be 100 l/min for at least 2 s, with a pressure at the patient
connection port not numerically greater than 8 cm H2O below atmospheric pressure. This flow shall be
attained within 250ms.
Pressure limitation under normal use
The pressure at the patient connection port shall not exceed 60 cm H2O during normal use. A setting for
the pressure-limiting device higher than 60hPa may be made available for certain patients, although the
selection of such a setting requires medical advice.

66
APPENDIX C: AHP ADJUSTED TRL, CONROW [37].
Table C1: AHP Adjusted TRL, Conrow [37].

TRL AHP Adjusted TRL (TRLc)

1 0.01
2 0.02
3 0.03
4 0.04
5 0.07
6 0.1
7 0.16
8 0.25
9 0.33

67
APPENDIX D: BWM SOLVER RESULTS

Figure C1: BWM Solver Results.

68