FORM 2
THE PATENT ACT 1970
(39 of 1970)
&
PROVISIONAL/COMPLETE SPECIFICATION
( See Section 10 and rule13)
1 TITLE OF THR INVENTION
. MONITORING PLATFORM FOR CONSOLIDATING DATA FROM EXISTING MEDICAL DEVICES IN A
HEALTHCARE ENVIRONMENT
2. APPLICANT Cognota Healthcare Private Limited
(a) NAME : Indian .
(b) NATfONALITY Flat No 6,3rd Floor, Hoshbanoo Mansion Near BPL Gallery Naupada
(c) ADDRESS; Thane 400602 email:rajendra.patil@cogota healthcare.com T: 9699576634

3. PREAMBLE TO THE DESCRIPTON
COMPLETE
The following a pecification perticuary describes the inention and the manner in which it is to be perfirmed

Invention relates to medical monitoring systems

4.DESCRIPTON (Description shall start from next page)

5. CLAIMS (not proialonal specification, Claims sholud start with the preamble
I/We claim on seperate page
6. DATE AND SIGNATURE (to be given at the end of last page of specification)
7. ABSTRACT OF THE INVENTION (to be given along with complete specification on separare page)

2. FIELD OF INVENTION
The present invention relates to medical monitoring systems and, more particularly, to a monitoring platform for consolidating data from existing medical devices in a healthcare environment.

3. SUMMARY OF INVENTION
It is, therefore, the primary object of the present invention to provide a method, system, and computer program product for monitoring diverse medical devices. It is another object to provide a medical device monitoring platform that consolidates data from multiple medical devices using their native hardware mechanisms and protocols. These and other objects are herein accomplished by a method, system and computer program product for selectively and proactively monitoring an existing fleet of medical devices. Through a central dashboard and/or by push-alerts physicians can check in on their patient's conditions by consolidated reports that include biometric, objective and subjective data on their health status.

4. DESCRIPTION OF DRAWINGS.
Other objects, features, and advantages of the present invention will become more apparent from the following detailed description of the preferred embodiments and certain modifications thereof when taken together with the accompanying drawings in which:
FIG. 1 is an illustration of the hardware architecture according to the
present invention.
FIG. 2 is a block diagram of a signal processor 50;
FIG. 3 is a block diagram of the communicator device 10;
FIG. 4 is a screenshot of the command center software 40 main screen;
FIG. 5 is a screenshot of the communicator device 10 configuration
screen;
FIG. 6 is a screenshot of the signal processor 50 configuration screen;
FIG. 7 is a screenshot of the medical device 30-to-communicator device
10 mapping screen;
FIG. 8 is a screenshot of the patient-to-communicator 10 mapping
screen;
FIG. 9 is a screenshot of the command center patient detail view screen;
FIG. 10 is a screenshot of the Escalation Configuration portal;
FIG. 11 is a screen shot of the Escalation Configuration Detail Screen;
FIG. 12 is a screen shot of a patient alert;
FIG. 13 is a screen shot of the Text/SMS/email Template Setup Screen
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
The present invention is a system and method for consolidating communications from multiple diverse medical devices all to a common medical dashboard and record repository FIG. 1 is an illustration of the hardware architecture, which includes an existing hospital netw6rk 20 which is a distributed client-server computer hardware architecture as typically maintained at a healthcare facility. The hospital network 20

preferably includes a medical records repository comprising a database server 24 in communication with non-transitory computer memory 25, which may be local or any distributed storage array. The database server 24 runs database management software to provide database services to client-server network 20. The database server 24 preferably hosts a network database on the non-transitory computer memory. 25, preferably an SQL server database, and even more preferably Microsoft™ SQL Server. Other examples of suitable database servers are MySQL (a popular open source database), Oracle™, DB2™, Informix™, Ingres™, and SQL Server™. The medical records repository 24, 25 shown in FIG. 1 is a part of the local client/server environment 20, but may alternately be a cloud-based repository connected directly to the internet.
One or more communicator devices 10 are in communication with the hospital network 20. Communicator devices 10 allow central and real time monitoring of a large number of connected medical devices 30 and allows medical devices 30 to communicate with the hospital network 20 and beyond to a command center 40. Each communicator device 10 communicates via secured WIFI, wired or other network-based communication and allows authorized hospital users to access the data of the medical devices 30 remotely, working in conjunction with signal processors 50 to provide an interface between the hospital server network 20 and medical devices 30 such as infusion pumps present in the hospital. In addition to providing remote access the communicator devices 10 communicate with command center software 40, which allows the entire system to be centrally monitored & recorded. The command center software 40 has configurable escalation and notification features (to be described) that push patient status changes to the appropriate person involved / associated with providing patient care. The notification and escalation alerts are based on configurable profiles for key attributes, and push notification may be by SMS'text message or email. This flexible configuration and precise attribute-

based escalation saves enormous time in dealing with device malfunctions or irregularities, and it allows overall staff performance;in the hospital to be evaluated & improved.
The.signal processors 50 are hardware devices that directly connect with the medical devices 30 (single or stacked). The signal processors 50 are designed to accept various incoming signals: (i) direct RS-232 cable, (ii) WiFi connection, (iii) Bluetooth connection, (iv) HDMI connection, (v) USB connections, (vi) Infrared connections, (vii) Zigbee IEEE 802.15.4-based signals, etc. Each signal processor 50 takes the input signals and converts or maps them to output signals to be sent to communicators 10 either through secure WiFi, Ethernet cable, Bluetooth or Zigbee IEEE 802.15.4-based signals. Several signal processors 50 can connect to one communicator 10, and each signal processor can connect to one or more medical devices 30 and can simultaneously process signal that are coming from each connected device.
FIG. 2 is a block diagram of an exemplary signal processor 50, which serves as a data aggregator to collect the data over an Infrared Data Association (IrDA) port from Medical devices 30 at regular intervals. The collected data is then transferred to the associated Communicator 10 via Bluetooth (BLE) protocol, version 5.2. Importantly, each signal processor 50 is protocol agnostic. This way, signal processors 50 can collect raw IR data from any make/model of medical device 30. Data extraction from raw data, as well as protocol correctness and integrity checking is done by the Communicator 10. The signal processor 50 architecture is based around a multi-protocol RF Transceiver microcontroller (MCU) 110 such as an ST Microelectronics M32WB50CGU5 with off-board IrDA transceiver 165, and on-boar'd RF transceiver with 802.15.4, Bluetooth, Bluetooth v5.0, Thread, Zigbee© 2.402GHz ~ 2.48GHz and 48-UFQFN communication. Supporting ICs include 5v power supply 120, a wireless interface 130 (RF connector

jack and multilayer band pass filter with pre- and post-LC filtering for conditioning) for transmission/receipt of wireless signals RF-RF1 to MCU 110 , a wireless interface 130, an EEPROM 140, an on-board USB compatible backup battery and battery charger 150, a 5vdc voltage regulation circuit 155 with a switching regulator such as a Texas Instruments® Buck-Boost Switching Regulator. In addition, a display 170 is provided. The signal processors 50 are capable of transmitting and receiving over a variety of wired or wireless connections and protocols including (i) direct RS-232 cable, (ii) WiFi connection, (iii) Bluetooth connection, (iv) HDMI connection, (v) USB connections, and (vi) infrared connections; and (vii) Zigbee IEEE 802.15.4-based signals, etc. XBee S2C is a RF module designed for wireless communication or data exchange and it works on ZigBee mesh communication protocols that sit on top of IEEE 802.15.4 PHY. The module provides wireless connectivity to end-point devices in any ZigBee mesh networks including devices from other vendors.). FIG. 3 is a block diagram of an exemplary communicator 10. Communicator 10 is a multi-functional processor programmed to collect data from multiple signal processors 50 located in the field using BLE 5.2 protocol as indicated above. One skilled in the art will understand that other wired connections may suffice including serial, ethernet, I2C, SPI, etc., as well as other wireless protocols (Zigbee, Thread, LoRa, etc.). The communicator 10 collects the raw data from the signal processors 30 and extracts the relevant information. This staged architecture allows custom protocols integration of a wide variety of medical devices, as well as different devices of the same family. The extracted data is then transferred to'a hospital server 20 via an application programming interface (API). Communicator 10 is a processor-on-a-chip, such as Texas Instruments® OMAP3530 BeagleBoard with the functionality of a basic computer with video out provided through separate S-Video and HDMI connections. Built-in storage and memory are provided. As seen in FIG. 3, the Beagleboard processor 102 is configured with any number of serial transmit and receive channels, here two of each being shown

(Serial_TX_l, Serial_RX_l, Serial TX_2, Serial TX_2). Each pair of serial transmit and receive channels, e.g., (Serial_TX_l, Serial_RX_l) are dedicated to a single signal processor 50. Raw data from the signal
processor 50 cast in BLE 5.2 protocol as indicated above is received at
i
a 2.45GHz bandpass RF receiver / filter 104 and passed to an MCU 106 which extracts the relevant information. In the illustrated embodiment the MCU 106 is an ultra-low-power dual core MCU available from ST Microelectronics®, with a primary oscillator for the SYSCLK (overall system clock) and a secondary oscillator for the RTCCLK (real-time clock). The MCU 106 collects the raw data from the signal processor 50, extracts the relevant information, and transmits it to the Beagleboard processor 102. The extracted data is then transferred to a hospital server 20 via an application programming interface (API). A display 107 is also provided. In accordance with the invention, the system requires initial configuration from the command center 40 including a mapping of communicator 10 with signal processor(s) 50, mapping with the patient, configuring escalation parameters and contact methods. (through communicator) from a central location are handled. This' is accomplished centrally using the command center software 40.
FIG. 4 is a screenshot of the command center software 40 main screen. The command center software 40 main screen allows a permissioned used to add, view and update communicator device(s) 10, signal processor(s) 50, configure alert escalations, and to check current status of all installed communicator devices 10. The command center software 40 main screen generally comprises a composite of patient-specific information tiles each indicating Bed No., Patient Name, Age, Sex, Attending Physician, and mapped devices beneath. Icons at right offer a more detailed view of the patient's personal info, medical records, arid alert profiles. A filter bar appears above to allow filtering of the displayed patients by Medical Center and Unit. When a device is mapped to a patient the device status appears beneath the patient in succinct format, including device name, device ID, and status indicator Careen

thumbs-up icon) and progress chart. Hovering over the status indicator
drops down a more detailed view of progress including a bar chart bf
units delivered and remaining (for an infusion pump) and flow rate.
Effective use of the command center software 40 main screen requires
configuration of communicator devices 10 and signal processors 50 arid
mapping of patients to communicator devices 10 to signal processors .
50 to medical devices 30.
Configuring Communicator Device-10
FIG. 5 is a screenshot of the command center software 40 configuration screen which enables addition and configuration of communicator devices 10. The communicator configuration screen includes a top-half fillable form that allows a permissioned user to add communicator devices 10, and a bottom-half listing of existing communicator devices 10. When a communicator device 10 is selected at bottom its details appear in the top-half form and can be edited. This way, a user can conveniently view and update communicator device 10 setup and check current status of all installed communicator devices 10. All system data is converted to a generic SQL-based data format by separate cross-reference tables, and the communicator device 10 table is shown below.

Field Description
Action This icon uses for edit/Update the communicator
Identification No. Unique ID assigned to Communicator Box by organization
Name Descriptive name for the Communicator Box
IP Address LP. Address of Communicator Box
Subnet Subnet address
Location Location/ Ward where Communicator Box is installed
Status Status of Communicator Box

Date of Date of first installation of the Communicator
Installation Box
Version No. Version of software/Firmware installed
Remarks Any Comments useful for admin person about
box.
Configuring Signal Processor 50
FIG. 6 is a screenshot of the command center software 40 configuration
i screen which enables addition and configuration of signal processors 50. The
signal processor configuration screen includes a top-half fillable form that
allows a permissioned used to add signal processors 50, and a bottom-half
listing of existing signal processors .50. When a signal processor 50 is selected
at bottom its details appear in the top-half form and can be edited. This way,
a user can conveniently view and update signal processor 50 setup and check
current status of all installed signal processors 50. All system data is
converted to a generic SQL-based data format by separate cross-reference
tables, and the signal processor 50 table is shown below.

Sr# Field Description
1 Action This icon uses for edit/Update the Device
2 Identification Unique ID assigned to Signal Processor by
No. organization
3 Name Descriptive name for the Signal Processor Box
4 Mfg. Device ID Mfg. Device ID given to Signal Processor (Unique Identification of Device to which Signal Processor is connected)
5 Device Type Medical device type like Volumate/ Injectomate for which Signal processor is installed
6 Device Status Current Status of Signal Processor
7 Date of Date of first installation of the Signal Processor
Installation with medical device

8 Remarks Any Comments useful for admin person about box.
On this screen Mfg. Device ID is the unique ID assigned by the manufacturer of device, and it is stored and used for mapping Signal Processors 50 with the Command Center 40.
Mapping Medical Device 30 with Signal Processor 50 and/or Communicator 10
FIG. 7 is a screenshot of the command center software 40 configuration screen which enables mapping of each medical device 30 with a communicator device 10. Note that signal processors 50 are mapped one-to-one to each medical device 30, and so the same "Add Device" screen as FIG. 6 may be used to add signal processors 50 along with the medical device 30 associated with it. The mapping screen includes a top-half tillable form that allows a permissioned used to map any existing communicator device 10 with any existing medical device 30, and a bottom-half listing of existing mappings with current device 30 status. When a medical device 30 is selected at bottom details appear in the top-half form and can be edited. This way, a user can conveniently view and update communicator-to-medical device mappings and check current communication status of each medical device 30 with its associated Communicator 10. All system data is converted to a generic SQL-based data format by separate cross-reference tables, and the signal processor 50 table is shown below.

Sr# Field Description
1 Action This icon when checked edits/updates the Configuration Device
2 Location Ward of the hospital where communicator is located
3 Communicator Communicator located in the selected ward

4 Device Signal Processor list which needs to be map with communicator for the selected ward. That means communicator of the ward will be in Sync with all mapped signal processors through WIFI, Bluetooth or other communication protocol.
5 Status Current communication status of the Signal Processor with Communicator
6 Date of Date of configuration of the Signal Processor
Installation with the communicator
7 Remarks Any Comments useful for admin person about box.
Mapping Patient-to-Communicator 10 Association:
FIG. 8 is a screenshot of the command center software 40 configuration screen which enables mapping of each patient with a communicator device 10. The command center software 40 configuration screen establishes a dynamic link between the patient, the medical device 30, and the signal processor 50. The mapping allows data from medical devices 50 to, be associated with a given patient. If a given medical device 10 gets moved from patient to patient and from time to time it can be re-mapped, and Ithe consequent data associated with the new patient. The patientj to-communicator 10 mapping screen is accessible from the command center software 40 main screen by clicking on the "View Active Devices (3rd icon)" icon, and provides a pop-up listing of active medical devices 30 and for each a click-through button for the device mapping details and current device status. This way, a user can conveniently view and update patient-to-communicator mappings and check current communication status of each medical device 30 with its associated Communicator 10. A user can conveniently view all active devices 30 from the list and map selected devices 30 to the patient using device mapping option. Also, the patientt-to-communicator 10 mapping screen gives the option to disconnect medical

devices 30 from the patient. After each signal processor 50 is connected with each medical device 30 and is connected with an associated communicator device 10, the communicator device 10 is further connected to the database 25 in FIG. 1. This connection involves two phases:
Phase 1: data gathering, which entails three substeps:
o Step #1: Signal processor 50 gets data from Medical device 30; Data is pulled by various methods such as through RS-232 cable directly connected to medical device 30 and signal processor 50 or signal processor 50 reading medical device 30 data by wireless frequencies, etc. o Step #2: Communicator 10 then pulls the collected data into local memory at pre-set intervals. The intervals are configurable for each device 30 type. For example, for Agilia© patient monitor a default interval is 5 milliseconds, o Step #3: Each communicator device 10 runs a program that pushes collected data to database 25 for permanent storing and/or other actions.
- Phase 2: Data Display to Command Center
All information collected in Phase 1 is pulled from the database 25 at specified time intervals to display on the command center 40 main screen. This interval is configurable at application level. For example: In case of Agilia© details periodically saved in database 25 are infused volume, total volume to be infused, device serial number, patient id, date time and error information, etc. Given configuration of communicator devices 10 and signal processors 50 and mapping of patients to communicator devices 10 to signal processors 5:0 to medical devices 30 as described above, it becomes possible to navigate the Command Center 40 main screen to filter by medical center and/or ward, view patient details, and view and configure patient alerts as follows

Command Center 40
Referring back to FIG. 4, the Command Center 40 may be used for real time monitoring of all active devices (through communicator) from a central location. The Command Center 40 main screen filters by medical center and/or ward, allows viewing of patient details, and allows viewing and configuration of patient alerts as follows:

Sr# Field Description
1 Medical Center Filter to selected ward
2 Escalation To view/ update escalation configuration as per ICU ward selected from the medical center drop down
3 Icon - Patient wise view/ update escalation
Escalation Configuration configuration
4 Icon - View More View patient details in broad view
5 Icon - View Active Device Map active device (signal processor) with patient
Patient Detail View
FIG. 9 is a screenshot of the command center software 40 patient detail view screen. The command center software 40 patient detail view screen allows a permissioned user to view medical device details and current status of any patient. The command center patient detail view screen generally comprises a composite of patient-specific information tiles including patient information at top left (same as FIG. 2), a monthly recap report (top center) that presents a month'-timeline of alerts, a report listing (top right) with a list of available reports (blood, lab, etc.). The lower tiles present detailed progress graphs and charts for each mapped instrument.

Escalation Configuration Setup Screen
As mentioned above in regard to FIG. 2 the Command Center 40 allows custom configuration of patient alerts based on level-wise escalation profiles. The basic purpose of escalation is to notify hospital staff (Nurse, Employee, Doctor) as to event occurrences that require some action from authority. FIG. 10 is a screenshot of the Escalation Configuration portal. To access this screen from FIG. 2 the user must click on 'Escalation' (top right). The command center software 40 patient escalation screen allows a permissioned user to configure level wise escalation for different medical device 30 errors, or alert categories. In accordance with the invention, it is possible to set a limited time duration for each escalation, and to specify a customizable text/SMS/email template for resulting alerts.
Various levels of escalation may be implemented for various events. For example, two levels of escalation Level 1 and Level 2 can be implemented for the following events:
Plunger head alarm memory
Disengagement alarm memory
Occlusion alarm memory
Syringe flange clasp
Plunger head
Occlusion
Disengagement
Limit volume
End of infusion
Low Battery
Flanges, etc.
Whenever any of the above listed events occur with a medical device 30, the command center software 40 will start the escalation process by sending notifications to Level 1 authorities. If the hospital staff takes the required action within the allocated time (timing is configurable based on event severity), then the application will stop escalation. If the hospital staff fails to take the required action within the allocated time escalation continues. The

command center software 40 sends notification to Level 2 users. The user can also specify a time interval between Level 1 and Level 2.
The escalation setup begins by clicking on the Command Centre (FIG. "2) "Escalation' option from the navigation menu at top, as per FIG. 10. The Escalation List window will appear as shown in the inset. Already configured escalation listings are displayed in a grid. A'new escalation can be added by clicking the Add button (top right), which redirects to the add escalation window of FIG. 11. Here the user selects the ICU and doctor or employee for which escalation needs to be configured.
Options are provided for selecting 'Escalation level' (here Level 1 or Level 2) as per above. The user can select the Event(s) on which occurrence escalation should be triggered, which can be a device warning, alert state (e.g., device stopped or disengaged). The user can select User type from options such as Helper, Nurse, Doctor etc., which engenders a pop-up list of specific users to whom notification will be sent. The user can also add optional remarks. They then select a template by selecting a communication type from the "Template For:" drop-down list: SMS, email, phone call, etc. For example, if the user selects SMS they can program the escalation duration after the device event triggers. Additional templates can be added or removed from the Template List.
Escalation profiles vary based on the types of medical devices 30. For example, for an Agilia® Infusion Pump there are various data parameters various type of alerts which mentioned on below table.

Alerts Escalations for the Agilia Device
Plunger head alarm memory
Disengagement alarm memory
Occlusion alarm memory
Syringe flange clasp
Plunger head

Occlusion
Disengagement
Limit volume
End of infusion
Battery
Flanges
Raising of occlusion module in progress on other
As another example, an alert escalation profile for a Draeger® patient monitor is as follows:

Alerts Escalations for the Draeger Device
Device not connected
Device not powered
Battery low
No Alarm
Advisory Alarm
Serious Alarm
Life Threatening Alarm
Alarm Active
Alarm Silenced
Latched Alarm
All Alarms off
Parameter Cannot be determined
Parameter Condition Over-range
Parameter Condition Under-range
Heart Rate Asystole
Parameter Status = Artifact
RS232-the

Alerts Escalations for the Pulse Monitoring Device
Device not connected
Device not powered
Memory overflow
Device not working
Battery low
FIG. 12 is a screen shot of the Escalation Configuration Detail Screen. The Escalation Configuration Detail Screen includes a top-half fillable form that allows a permissioned used to complete an escalation profile for any existing medical device 30, and a bottom-half listing of existing escalation profiles with current status. When an escalation profile is selected at bottom details appear in the top-half form and can be edited. All escalation data is converted to a generic SQL-based data format by separate cross-reference table. This way, a user can conveniently view and update any escalation profile and check current status of each, and custom-configure level wise escalation for different device 30 errors and alert categories based on combinations/subcombination of the parameters shown below:

Sr# Field Description
1 Action This icon uses for edit/Update the Escalation for selected ICU.
2 ICU Name Ward of the hospital for which we want to set escalation level
3 Device Type Type of Device (Agilia, Draeger, etc.; from drop down)
4 Escalation Escalation levels 1/ Escalation levels 2
Level Ideally level 1 will be triggered immediately after • device status of error found in the database

5 Triggered Options for different device alerts and errors.
When E.g. Device Stop, Device Not Connected, etc.
6 User Type User Category for user selection
7 User User list for configuring in escalation level
8 Duration Duration when to selected escalation level
(Mins) should get triggered
9 Template For SMS Template, we can selected custom template for different escalation level
10 Send SMS Is send SMS to user when escalation triggers? Yes - will send SMS to user No - will not send SMS to user
11 Send Is'send notification to user when escalation
Notification triggers?
Yes - will notify user in HIS portal
No - will not notify user in HIS portal
12 Send To Is SMS/ notification send to Consultant doctor
Consultant of the patient
Doctor Yes - SMS and notification will be sent to doctor • No - SMS and notification will not be sent to doctor
13 Remarks Any Comments
When a patient alert is triggered based on a level-wise escalation profile it appears in FIG. 2 and is broadcast by text/SMS/email according to a Text/SMS/email template.
. FIG. 12 is a screen shot of a patient alert appearing on the Command Center 40 main screen and prompting attention to check on a particular device in a particular room for some specific issue.
FIG. 11 is a screen shot of the Text/SMS/email Template Setup Screen. Using this screen, a user can configure templates for Texting/SMS/email transmission of alerts. Each template supports transactional fields related to patient, device, location, etc. as follows:

Sr# Field Description
1 Template Name User defined template name
2 Template For SMS/email template for category - ICU/ Appointment/ Lab/ Radiology
3 Active Active/ Inactive status for template
4 Doctor In While sending SMS/email to selected user, is
charge SMS/email to be sent to consultant doctor as well?
It should now be apparent that the above-described invention provides an improved system capable of selectively and proactively adding a centralized monitoring capability with clinically-relevant alerts to an existing fleet of medical devices. Through a central dashboard and/or by push-alerts physicians can check in on their patient's conditions by consolidated reports that include biometric, objective and subjective data on their health statujs.
This has been a description of the present invention and, the preferred embodiment of the present invention, as well as various alternate embodiments of the present invention.

5. CLAIMS We claim:
1. A system for monitoring an existing fleet of medical devices
through a central dashboard and/or by push-alerts physicians can check in on their patient's conditions by consolidated reports that include biometric, objective and subjective data on their health ; status.