Description:
Technical Field
[001] This disclosure relates generally to data management and data logging, and more particularly to a method and a system for logging ventilator data, based on user selection.

Background
[002] Ventilators are medical devices long known to have been used to provide supplemental oxygen support to patients. The ventilators include a source of pressurized oxygen which is fluidly connected to the patient through a conduit. Further, some ventilators are designed to automatically adjust to changes in a patient's respiration. The rise in respiratory diseases especially after the pandemic due to the novel Corona Virus (2020) has spurred a huge demand for the ventilators. As such, manufacturing of ventilators has seen surge as well.
[003] Data logging in ventilators forms an important step in the functioning and testing of the ventilators. For example, data logging may allow developers to design subsequent steps of existing applications or design new applications, based on the data log. However, due to computational-heavy processing involved in data logging, data logging may make the computing systems sluggish. Further, certain modules in the computing system associated with the ventilators may lack sufficient data storage and therefore data logging capability. For example, some microcontroller-based modules may have data capacity only in terms of a few kilobytes which may not be sufficient for data logging.
[004] There is, therefore, a need for improved data logging techniques, especially for the ventilators, that allow for selective custom data logging to thereby make the process efficient in terms of computing capacity. Further, there is a need for logging techniques that allow to create and maintain sufficient space for the data logging to continue.

SUMMARY
[005] A method of logging ventilator data is disclosed. The method may include receiving status data associated with one or more peripherals associated with a ventilator. The status data, for example, may be received from a real-time communication channel associated with the ventilator. The method may further include receiving at least one selection of a verbose level from a plurality of verbose levels. Each of the plurality of verbose levels may be configured to format the status data into an associated custom message format. The method may further include formatting the status data into at least one associated custom message format corresponding to at least one selected verbose level. The method may further include rendering the status data in the at least one associated custom message format along with a predefined default message format.
[006] In some embodiments, the method may further include generating a log file associated with the status data corresponding to each of the associated custom message format and the predefined default message format. For example, the log file may include a “*.log” extension. Further, the log file may be configured to be compressed to reduce size of the log file. In some embodiments, each of the plurality of custom message formats may correspond to an associated amount of information to be rendered.
[007] In some embodiments, the method may further include sending the status data to a server based on at least one of a predefined periodic interval and a request from a user. The method may further include attaching a time stamp to the status data received from the real-time communication channel. The time stamp may be based on at least one of a Date-and-Time format and a Systick-Time format. The method may further include receiving a selection of predefined priority level from a plurality of predefined priority levels, inserting a selected predefined priority level to the status data, and formatting the status data into the at least one associated custom message format corresponding to at least one selected verbose level and the selected predefined priority level.
[008] Further, a system for logging ventilator data is disclosed. The system includes a processor and a memory communicatively coupled to the processor. The memory stores a plurality of processor-executable instructions, which on execution by the processor, cause the processor to receive status data associated with one or more peripherals associated with a ventilator, and receive at least one selection of a verbose level from a plurality of verbose levels. Each of the plurality of verbose levels may be configured to format the status data into an associated custom message format. The plurality of processor-executable instructions, on execution by the processor, may further cause the processor to format the status data into at least one associated custom message format corresponding to at least one selected verbose level, and render the status data in the at least one associated custom message format along with a predefined default message format.
[009] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS
[010] The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles.
[011] FIG. 1 illustrates a block diagram of a system for logging ventilator data is illustrated, in accordance with an embodiment of the present disclosure;
[012] FIG. 2 illustrates a functional block diagram of the data logging device for logging ventilator data, in accordance with an embodiment;
[013] FIG. 3 illustrates a functional block diagram of a system for logging ventilator data, in accordance with an embodiment;
[014] FIG. 4 illustrates a block diagram of a system for logging ventilator data, in accordance with an embodiment;
[015] FIG. 5 is a flowchart of a method of logging ventilator data, in accordance with an embodiment;
[016] FIG. 6 is a snapshot of an example format of a message, in accordance with some embodiments;
[017] FIG. 7 is a snapshot of another example format of a message showing four verbose levels, in accordance with some embodiments;
[018] FIG. 8 is a snapshot of another example message, in accordance with some embodiments;
[019] FIG. 9 is a snapshot of different example messages, in accordance with some embodiments; and
[020] FIG. 10 is a flowchart of a method of formatting status data based on a selected predefined priority level, in accordance with some embodiments.

DETAILED DESCRIPTION
[021] Exemplary embodiments are described with reference to the accompanying drawings. Wherever convenient, the same reference numbers are used throughout the drawings to refer to the same or like parts. While examples and features of disclosed principles are described herein, modifications, adaptations, and other implementations are possible without departing from the spirit and scope of the disclosed embodiments. It is intended that the following detailed description be considered as exemplary only, with the true scope and spirit being indicated by the following claims. Additional illustrative embodiments are listed below.
[022] One or more techniques are disclosed for logging ventilator data. Data from a ventilator control board (VCB) is received by a back-end module. A logging module API is used across all back-end modules, for logging data. As such, the logging module API is invoked every time an entry is added in the log. The logging format for different data parameters can be specified separately. Further, a network manager is provided that sends the data across to a server periodically or depending on when the data is requested. The back-end module includes a central main control thread which manage all the other modules. Further, a store manager is provided that acts as a cache before writing data into a database manager. The database manager manages the data written in and out of the database in an efficient manner. A packet parser is provided that parses the frames received from the VCB and extracts meaningful data therefrom. Other functionalities like log compressing etc. are managed in the main thread itself by invoking call to another program.
[023] In order to log data, a simple log file with *.log format may be created. Further, the log file can be compressed significantly so that log size can be reduced. In particular, the compression may take place by way of post-processing and the data may be stored in a compressed form, instead of compressing it after the file is created. The techniques further provide for a verbose mode control which allows a user to turn ON/OFF certain fields depending on the verbose level defined. The techniques provide for additional functionalities in terms of verbose level with the custom messages that can be implemented throughout the code. Further, each of the custom messages can be associated with a verbose level. When a verbose level is turned ON, these custom messages will be visible at that point of time only.
[024] By way of the verbose mode control, the spread of information can be controlled in horizontal plane on a single line, as will be illustrated in later sections of the present disclosure. As such, the amount of data from the code that will be printed can be controlled. The techniques further provide an option to show all the messages from previous log level along with the selected verbose level. For example, if a verbose level-3 is chosen, then all the messages which would have been visible for verbose level-1, verbose level-2, and verbose level-3 (but not of verbose level-4, since it is higher level than verbose level-3) may be shown. Similarly, if verbose level-4 is chosen, then all messages from verbose level-4 to verbose level-1 may be shown.
[025] In one embodiment, a block diagram of a system 100 for logging ventilator data is illustrated in FIG. 1, in accordance with an embodiment. The system 100 may include a data logging device 102. The data logging device 102 may be a computing device having data processing capability. In particular, the data logging device 102 may have capability for logging data associated one or more ventilators. As will be understood by those skilled in art, the ventilators are devices that provide mechanical ventilation to patients by moving breathable air into and out of their lungs, to assist the patient breathe when the patient’s is breathing capability is compromised. Examples of the data logging device 102 may include, but are not limited to a desktop, a laptop, a notebook, a netbook, a tablet, a smartphone, a mobile phone, an application server, a web server, or the like. In some example embodiments, the data logging device 102 may be a cloud-based computing system.
[026] The system 100 may further include a data storage 104. For example, the data storage 104 may store various types of data required by the data logging device 102 for logging ventilator data. The data logging device 102 may be communicatively coupled to the data storage 104 via a communication network 108. The communication network 108 may be a wired or a wireless network and the examples may include, but are not limited to the Internet, Local Area Network (LAN), Wireless Local Area Network (WLAN), Wi-Fi, Virtual Private Network (VPN), Long Term Evolution (LTE), Worldwide Interoperability for Microwave Access (WiMAX), and General Packet Radio Service (GPRS). In an alternative embodiment, the data logging device 102 may be communicatively coupled to other components of the ventilator system via a communication port.
[027] As will be described in greater detail in conjunction with FIG. 2 to FIG. 4, in order to log ventilator data, the data logging device 102 may receive status data associated with one or more peripherals associated with a ventilator, for example from a real-time communication channel associated with the ventilator. The data logging device 102 may process the received status data for further storage and analysis. In addition, the data logging device 102 may also facilitate storage of raw status data. The data logging device 102 may communicate the processed and/or unprocessed status with other external devices via the communication network 108. The data logging device 102 may further receive at least one selection of a verbose level from a plurality of verbose levels. Each of the plurality of verbose levels is configured to format the status data into an associated custom message format. The data logging device 102 may further format the status data into at least one associated custom message format corresponding to at least one selected verbose level, and render the status data in the at least one associated custom message format along with a predefined default message format.
[028] In order to perform the above-discussed functionalities, the data logging device 102 may include a processor 110 and a memory 112. The memory 112 may store instructions that, when executed by the processor 110, cause the processor 110 to log ventilator data, as discussed in greater detail in FIG. 2 to FIG. 10. The memory 112 may be a non-volatile memory or a volatile memory. Examples of the non-volatile memory may include, but are not limited to, a flash memory, a Read Only Memory (ROM), a Programmable ROM (PROM), Erasable PROM (EPROM), and Electrically EPROM (EEPROM) memory. Examples of volatile memory may include, but are not limited to, Dynamic Random Access Memory (DRAM), and Static Random-Access memory (SRAM). The memory 112 may also store various data (e.g. log data, verbose level data, priority level data, etc.) that may be captured, processed, and/or required by the system 100.
[029] The data logging device 102 may further include one or more input/output devices 114 through which the data logging device 102 may interact with a user and vice versa. By way of an example, the input/output device 114 may be used to display a message rendered corresponding to the verbose level selected by a user, as will be discussed later. The system 100 may interact with one or more external devices 106 over the communication network 108 for sending or receiving various data. Examples of the one or more external devices 106 may include, but are not limited to a remote server, a digital device, or another computing system.
[030] The system 100 may further include one or more ventilators 116-1, 116-2, … 116-N (hereinafter also collectively referred to as one or more ventilators 116 or simply ventilators 116). The data logging device 102 may be communicatively coupled to the one or more ventilators 116 via the communication network 108. The data logging device 102 may be configured to log the data associated with the one or more ventilators 116. In an alternative embodiment, the data logging device 102 is implemented entirely inside the ventilators 116.
[031] Referring now to FIG. 2, a functional block diagram of a logging module 200 for logging ventilator data is illustrated, in accordance with an embodiment of the present disclosure. In some embodiments, the logging module 200 may include a logger API (Application Programming Interface) abstraction layer 202, an init setup module 204, a timestamping module 206, a priority module 208, a thread module 210, a message formatter module 212, a verbose control module 214, and a system logging module 216.
[032] The logger API abstraction layer 202 may act as a gateway into core logger module functionalities. As such, the logger API abstraction layer 202 may allow other back-end modules to access the core functionalities, for example, when using the thread module 210. The logger API abstraction layer 202 may further pass on data back to a callee that may relate to case can be any function in the back-end modules.
[033] The init module 204 (also referred to as setup module 204) may handle initialization of the data logging device 102. For example, depending upon the arguments passed on to init function of the init module 204, the init module 204 may initialize the setting based on which it will work. This will provide a wide range of selection criteria among various fields that may be requested to be present in the init module 204. Further, the init module 204 may allow setting the verbose level. It should be noted that there may be a maximum of six elements which can be configurable on the verbose level. In other words, there may be six possible predefined verbose levels. Also, it should be noted that the number of verbose levels may not be limited to six and may be varied based on user requirement.
[034] The timestamping module 206 may fetch data from a real-time communication (RTC) channel and pack the data into a specific timestamp format. By way of an example, the data may relate to status data associated with various peripherals of a ventilator. Further, the timestamp format may be configurable between various different formats. One example timestamp format may be a Date-and-Time format. This timestamp format may be formatted to milliseconds level. Furter, the timestamp format may be in form of DD/MM/YY:HH/MM/SS/mSS. Another example timestamp format may be a Systick-Time format. The timestamping module 206 may read the Systick value from a register and record the value at that point. This recording, by default, may be in mS/uS as xxxx.xxxxxx.
[035] The priority module 208 may receive a selection of a predefined priority level from a plurality of predefined priority levels, and insert a selected predefined priority level to the status data. It should be noted that in the process of logging data, certain errors may be encountered. It may be important to classify the errors into different priority levels, in accordance with a degree of severity associated with the error. The priority of the message may dynamically vary for each call, therefore, there is a need to ensure a solution for performing insertion of correct priority level into the log package. To this end, the priority module 208 is configured to insert the selected predefined priority level to the status data. By way of an example, there may exist four priority levels, namely: a first priority level (also referred to as “ALERT” level), a second priority level (also referred to as “WARNING” level), a third priority level (also referred to as “INFO” level), a fourth priority level (also referred to as “DEBUG” level). The first priority level (i.e. the “ALERT” level) may pertain to a very critical issue (with a patient) that needs urgent attention (e.g. of a medical care staff). The second priority level (i.e. the “WARNING” level) may pertain to a medical condition that can lead to a critical issue, and therefore requires the medical care staff to closely monitor the patient. The third priority level (i.e. the “INFO” level) may indicate that information is required about a certain action or a process. The fourth priority level (i.e. the “DEBUG” level) may be used to indicate a need to debug variables. The “DEBUG” level may be user-defined.
[036] By way of an example, a message to be printed is as follows:
[7325.548963] [ALERT] [main] [module.c:20] [MCU2UI]
[037] Further, an example of a format associated with the above message is as follows:
[Timestamp] [Type/Priority] [Thread] [File:] [Module][Message]

[038] It should be further noted that a value may be determined for each event (error), and then based on a predefined threshold, the priority level may be determined and associated.
[039] The verbose control module 214 may enable a control to turn ON or turn OFF certain fields in the logging process, on the basis of a single input whilst the data logging is in process. In other words, the verbose control module 214 may provide a switch-like functionality which can allow the users to do minor changes in terms of what fields can appear during the logging process.
[040] The thread module 210 may extract the information about the current running thread, the file, and the line of code execution. This information may be then sent to the message formatter module to combine. A user may be extract information of a desired granularity level, suing the thread module 210. For example, the thread module 210 may allow the user to choose whether they wish to extract a Name stack, an e-mail stack, etc. The message formatter module 212 may convert the logged data into a user-interpretable format. As such, the message formatter module 212 may then combine the data coming from all the other modules before sending the data across over the terminal or pushing it into some log file. The message formatter module 212 may then combine all the data and format into a very specific sequence as suggested.
[041] The system logging module 216 may capture the system state log for Linux system. The system logging module 216 may further periodically check the status of the peripherals and print their status in the log. The system logging module 216 may further monitor system resource consumption to understand if something is happening which might result into instability in other modules, if the same is inferred from the logs. It should be noted that all the modules may send data to the message formatter module 212 which may generate the log, for example, at the end of the day.
[042] Referring now to FIG. 3, a functional block diagram of a system 300 (corresponding to system 100) for logging ventilator data is illustrated, in accordance with an embodiment of the present disclosure. The system 300 may include the data logging device 102, a ventilator control board (VCB) 310, and a server 312. In some embodiments, the data logging device 102 may implement a logging module 302, one or more back-end modules 304, a log compressing module 306, and a network manager 308.
[043] The one or more back-end modules 304 may be communicatively coupled with the VCB 310 and may receive data coming from the VCB 310. The one or more back-end modules 304 may use the logging module 302 at the time of logging data. In other words, the logging module 302 is invoked every time a data entry is entered in the log. Logging format for data parameters can be specified separately.
[044] The log compressing module 306 may be configured to compress the log file. As such, the compressing can be managed in the main thread itself just by invoking the log compressing module 306. The network manager 308 may send the data across to the server 312. For example, the network manager 308 may send the data to the server 312, either periodically (i.e. based on a predefined periodic interval) or based on request from a user (when the data is requested by the user).
[045] The system 300 may be designed in such a way that the individual components in the data logging device may be plugged-in/out of the system without a significant impact on functioning of other components in the system. Such a design ensures that if one of the components malfunctions or is absent, the entire system does not break down.
[046] Referring now to FIG. 4, a block diagram of a system 400 (corresponding to system 100) for logging ventilator data is illustrated highlighting various components of the back-end module, in accordance with an embodiment of the present disclosure. The system 400 may include the data logging device 102, as referred in FIGs. 1-3.
[047] The data logging device 102, in some example embodiments, may implement a back-end module 420. The back-end module may include multiple modules including a ventilator control board (VCB) communication module 402, a packet parser module 404, a store manager 406, a database manager 408, and a user interface (UI) communication module 410. The system 400 may implement a main control module (thread control) 412 and a logging module 414. Moreover, the system 400 may include a VCB 416 and a user interface (UI) 418 communicatively coupled to the back-end module 420.
[048] As mentioned above, the data coming from the VCB 416 may be received by the one or more back-end modules, and in particularly by the VCB communication module 402. One of the functions of the VCB communication module 402 may be to ensure completeness and correctness of the data received from the VCB before passing the received data to the packet parser module 404. The VCB may implement error checking and error correction mechanisms to ensure completeness and correctness of the data received from the VCB. The logging module 414 may be used every time when the data logging is required. It should be further noted that the system logging module 216 may be decoupled from the rest of modules and database, so that the data logged by the system logging module 216 is stored independently. Once the data is correctly received from the VCB 416, the packet parser module 404 may parse the data. For example, the packet parser module 404 may parse data frames received from the VCB 416 and extract meaningful data from these frames. One of the functions of the packet parser may be to convert the format of the data frames received from the VCB to the format supported by the other components of the system 400.
[049] The store manager 406 may acts as a cache before writing data into the database manager 408.The database manager 408 may manage the data written in and out of the database in an efficient manner. Further, a network manager may send the data across to a server periodically or depending on when the data is requested. To this end, the UI communication module 410 may facilitate the communication of the data to the server via a UI. The (central) main control module 412 (also referred to as thread control module) may manage all the other modules, such as the modules referred above. For example, extra activities like log compressing etc. may be managed by the main control module 412 by invoking call to another program/module. The main control module 412 is also configured to perform initial configuration of all the other modules, establishing and managing communication connections between all the other modules of the system 400.
[050] Referring now to FIG. 5, a flowchart of a method 500 of logging ventilator data is illustrated, in accordance with some embodiments. The method 500 is explained in conjunction with FIG. 1. Accordingly, the method 500 may be performed by the data logging device 102. At step 502, status data associated with one or more peripherals associated with a ventilator may be received. In some embodiments, the status data may be received from a real-time communication channel associated with the ventilator. At step 504, a time stamp may be attached to the status data received from the real-time communication channel. The time stamp may be based on at least one of the Date-and-Time format and the Systick-Time format. This is already explained above in conjunction with FIG. 2
[051] At step 506, at least one selection of a verbose level from a plurality of verbose levels may be received. It should be noted that each of the plurality of verbose levels may be configured to format the status data into an associated custom message format. At step 508, the status data may be into at least one associated custom message format corresponding to at least one selected verbose level. For example, each of the plurality of custom message formats may correspond to an associated amount of information to be rendered.
[052] The status data may be logged in a predefined format, as illustrated in FIG. 6. FIG. 6 illustrates a snapshot 600 of an example format of a message, in accordance with some embodiments. The logging may happen in above format, as shown in FIG. 6. A simple log file with *.log format may be created. Furter, the format may be compressed significantly so that log size can be reduced. After performing some post processing, the data may be stored in a compressed form, instead of compressing it after the file is created. The log files may be stored locally on the system.
[053] One or more verbose levels may be provided that allows to turn ON or OFF certain fields depending on the level defined. For example, four verbose levels may be provided, as is illustrated via a snapshot 700 of an example format of a message in FIG. 7, in accordance with some embodiments. As shown in FIG. 7, the one or more verbose levels, i.e., “Verbose level: 1”, “Verbose level: 2”, “Verbose level: 3”, and “Verbose level: 4” provide for creating custom messages which can be put throughout a code. When a verbose level is turned ON, then the corresponding messages will be visible at that point of time only. In other words, the messages along with the verbose level may be included in the code, and whenever an event corresponding to that message is invoked, the message may be printed based on the selected verbose level.
[054] Each of the verbose level may log an associated level of detail of information. When a user wants to log only basic information like ‘flow of data’ the lower verbose level (verbose level: 1 or verbose level: 2) may suffice. However, when greater details are desired, like for the purpose of DEBUGGING or activation of priority levels, a higher verbose level (verbose level: 3 or verbose level: 4) may be set. As will be understood, greater amount of detail/information (i.e. higher verbose level) may require additional computing capacity. As such, the option to choose the verbose levels allows optimize the data logging and therefore the computing system’s overall performance.
[055] For example, FIG. 7 shows four different messages, each message associated with a respective verbose level. Further, as shown in another snapshot 800 of an example message in FIG. 8, at the last of each message, there may be simple print statement which does not have any value specified, and will be printed in log irrespective of the verbose level.
[056] Referring now to FIG. 9, a snapshot 900 of different example messages is illustrated, in accordance with some embodiments. As shown in the example message in FIG. 9, the spread of information in horizontal plane on single line may be controlled. Along with that an amount of data from the code which will be printed may be controlled as well. As such, a user may choose to either show all the messages from previous verbose level as well. For example, if the user chooses verbose level to be 3, then all messages visible during verbose level 1, verbose level 2, and verbose level 3 may be printed, except that of verbose level 4, since it (verbose level 4) is higher verbose level that the chosen verbose level 3. On a similar note, if verbose level 4 is selected, then the user may be allowed an option to choose to show all messages from verbose level 4 to verbose level 1.
[057] Returning back to FIG. 5, at step 510, a log file may be generated. The log file may be associated with the status data corresponding to each of the associated custom message format and the predefined default message format. For example, the log file may include a “*.log” extension. At step 512, the status data may be rendered in the at least one associated custom message format along with a predefined default message format, as explained above. Further, at step 514, the status data may be sent to a server (e.g. server 312). As will be understood, the status data may be pushed to the server to create space for more data to be logged on the local database of the system. For example, the status data may be sent to the server based on a predefined periodic interval and/or a request from a user. In some embodiments, additionally, the status data may be formatted into the at least one associated custom message format corresponding to at least one selected verbose level and the selected predefined priority level. This is further explained in conjunction with FIG. 10.
[058] Referring now to FIG. 10, a flowchart of a method 1000 of formatting the status data based on a selected predefined priority level is illustrated in accordance with some embodiments. At step 1002, a selection of a predefined priority level from a plurality of predefined priority levels may be received. For example, as mentioned above, there may exist four priority levels, namely: a first priority level (also referred to as “ALERT” level), a second priority level (also referred to as “WARNING” level), a third priority level (also referred to as “INFO” level), a fourth priority level (also referred to as “DEBUG” level).
[059] At step 1004, the selected predefined priority level may be inserted to the status data. At step 1006, the status data may be formatted into the at least one associated custom message format corresponding to at least one selected verbose level and the selected predefined priority level.
[060] As will also be appreciated, the above-described techniques may take the form of computer or controller implemented processes and apparatuses for practicing those processes. The disclosure can also be embodied in the form of computer program code containing instructions embodied in tangible media, such as floppy diskettes, solid state drives, CD-ROMs, hard drives, or any other computer-readable storage medium, wherein, when the computer program code is loaded into and executed by a computer or controller, the computer becomes an apparatus for practicing the invention. The disclosure may also be embodied in the form of computer program code or signal, for example, whether stored in a storage medium, loaded into and/or executed by a computer or controller, or transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, wherein, when the computer program code is loaded into and executed by a computer, the computer becomes an apparatus for practicing the invention. When implemented on a general-purpose microprocessor, the computer program code segments configure the microprocessor to create specific logic circuits.
[061] The disclosed methods and systems may be implemented on a conventional or a general-purpose computer system, such as a personal computer (PC) or server computer. It will be appreciated that, for clarity purposes, the above description has described embodiments of the invention with reference to different functional units and processors. However, it will be apparent that any suitable distribution of functionality between different functional units, processors or domains may be used without detracting from the invention. For example, functionality illustrated to be performed by separate processors or controllers may be performed by the same processor or controller. Hence, references to specific functional units are only to be seen as references to suitable means for providing the described functionality, rather than indicative of a strict logical or physical structure or organization.
[062] It is intended that the disclosure and examples be considered as exemplary only, with a true scope and spirit of disclosed embodiments being indicated by the following claims. , Claims:
CLAIMS
We claim:
1. A method of logging ventilator data, the method comprising:
receiving, by a data logging device, status data associated with one or more peripherals associated with a ventilator;
receiving, by the data logging device, at least one selection of a verbose level from a plurality of verbose levels, wherein each of the plurality of verbose levels is configured to format the status data into an associated custom message format;
formatting, by the data logging device, the status data into at least one associated custom message format corresponding to at least one selected verbose level; and
rendering, by the data logging device, the status data in the at least one associated custom message format along with a predefined default message format.

2. The method as claimed in claim 1, further comprising:
generating a log file associated with the status data corresponding to each of the associated custom message format and the predefined default message format,
wherein log file comprises a “*.log” extension.

3. The method as claimed in claim 2, wherein the log file is configured to be compressed to reduce size of the log file.

4. The method as claimed in claim 1, wherein each of the plurality of custom message formats corresponds to an associated amount of information to be rendered.

5. The method as claimed in claim 1, further comprising:
sending the status data to a server based on at least one of:
a predefined periodic interval; and
a request from a user.

6. The method as claimed in claim 1, wherein the status data is received from a real-time communication channel associated with the ventilator.

7. The method as claimed in claim 6, further comprising:
attaching a time stamp to the status data received from the real-time communication channel, wherein the time stamp is based on at least one of:
a Date-and-Time format; and
a Systick-Time format.

8. The method as claimed in claim 1, further comprising:
receiving a selection of predefined priority level from a plurality of predefined priority levels;
inserting a selected predefined priority level to the status data; and
formatting the status data into the at least one associated custom message format corresponding to at least one selected verbose level and the selected predefined priority level.

9. A system for logging ventilator data, the system comprising:
a processor; and
a memory communicatively coupled to the processor, wherein the memory stores a plurality of processor-executable instructions, which on execution by the processor, cause the processor to:
receive status data associated with one or more peripherals associated with a ventilator;
receive at least one selection of a verbose level from a plurality of verbose levels, wherein each of the plurality of verbose levels is configured to format the status data into an associated custom message format;
format the status data into at least one associated custom message format corresponding to at least one selected verbose level; and
render the status data in the at least one associated custom message format along with a predefined default message format.

10. The system as claimed in claim 9, wherein processor-executable instructions, on execution by the processor, further cause the processor to:
receive a selection of predefined priority level from a plurality of predefined priority levels;
insert a selected predefined priority level to the status data; and
format the status data into the at least one associated custom message format corresponding to at least one selected verbose level and the selected predefined priority level.