Patent ID: 12250329

DETAILED DESCRIPTION

The invention is described more fully hereinafter with reference to the accompanying drawings, in which embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure is thorough, and will fully convey the scope of the invention to those skilled in the art. Like reference numerals in the drawings denote like elements.

The following detailed description is provided to gain a comprehensive understanding of the methods, apparatuses and/or systems described herein. Various changes, modifications, and equivalents of the systems, apparatuses and/or methods described herein will suggest themselves to those of ordinary skill in the art. Descriptions of well-known functions and structures are omitted to enhance clarity and conciseness.

FIG.1shows an exemplary embodiment of a data-acquisition-system1. The data-acquisition-system is configured to acquire data generated during surgical and/or other medical procedures performed on a patient7by one or more medical-operators8(e.g., surgeons, anesthesiologists, nurses). A medical service-provider may own and control the data generated during the medical-procedure and acquired by the data-acquisition-system. In an alternate embodiment, a medical service provider will not create identifiable data, or a de-identified copy of the data will be generated, in which case the data will be transmitted directly by the data-acquisition-system to a data-management system10.

The data-acquisition-system may include a plurality of sensors2, one or more imaging devices3, a data acquisition module4, a controller module5, a display module6, an operator-input-module9, and/or a de-identification-module. During a medical procedure, such as a surgery, data may be acquired by various sensors, electrodes, and imaging systems. The sensors, electrodes, and imaging systems may be attached to the patient or positioned such as to acquire the desired information. The results of these measurements may be displayed on computer monitors and displays6. The data may be saved as data files on various on-site computers or on remote data storage facilities.

The one or more sensors may include one or more of the following: sensors configured to measure one or more temperatures at various places on or inside the body of the patient; sensors for acquiring information about the heart's electrical activity (e.g., electrocardiograms); sensors measuring a respiratory rate; blood pressure sensors; sensors measuring cardiac output; sensors measuring arterial blood oxygen level such as pulse oximeters; sensors measuring venous oxygenation; sensors measuring pulmonary functions such as end-tidal carbon dioxide; sensors measuring arterial pH; sensors for neurophysiological monitoring; sensors for monitoring intracranial pressure in patients suffering from head trauma, or patients having a high intracranial pressure because of brain tumors, or patients having intracranial hemorrhage; sensors disposed on catheters inserted in the circulatory system (e.g., position sensors); sensors monitoring airflow, airborne oxygen content, and air temperature (e.g., ventilator systems and anesthesia delivery machines); etc. The imaging devices may include one or more visible camera configured to monitor the surgical field; cameras configured to perform imaging inside the body, such as endoscopic cameras; and IR cameras. The imaging devices may further include X-ray imaging machines; Computer Tomography (CT) imaging machines; MRI machines; PET scanners; etc. The data-acquisition-system may further include a sound-recording-device configured to record sound (e.g. discussions between medical operators) data during medical procedure.

The display-module may be a computer monitor and may be configured to show some of the data acquired by the sensors in real time. The control-module may be configured to control the sensors and imaging devices. The data acquisition module may be connected with the sensors and the imaging devices so as to receive information from the sensors and imaging devices via cable connections, Wi-Fi, Bluetooth or any other suitable connection means known by those skilled in the art. The data acquisition module may store the data on-site (e.g., computer hard drives, flash memory modules, optical memory, etc.) or on remote data storage facilities such as in the cloud or in data centers. The operator-input-module9may enable the operator to enter information about the patient and about the medical procedure to be performed. This data entry may be via a touchscreen where the user may be presented a set of questions and answers or categories to select from, text input via a keyboard or touchscreen, speech, or other means known by those skilled in the art.

FIG.2shows a data-management-system10connected with a data-acquisition-system1and configured to process and manage data generated during surgical and other medical procedures. The data-management-system10may include one or more of the following: a data-storage-system11, one or more blockchain-systems12, one or more data-analytics-units13, one or more user-access-modules14, one or more user-analytics-modules15, and a record-generator-module16. The data-storage-system may include one or more records-databases for storing data received from the data-acquisition-system1and from other data-acquisition-systems where other medical-procedures are performed. The blockchain-systems may be configured to render immutable the data in the records-database. The data-analytics-unit may be connected with the records-database and may be configured to process and perform analytics on the data. The user-access-module may allow users (e.g., researchers, hospital administrators, government, etc.) to access the data in the database and to perform studies on the data associated with medical procedures. The users may perform data analytics on the data in the records-database by using the data-analytics-unit connected with records-database or by using user-data-analytics-units15(e.g., modules located on user's computer).

The functioning of the data-acquisition-system and data-management-system is explained hereinafter with reference to a certain medical-procedure (e.g., surgery) performed on a certain patient by one or more medical-operators (e.g., surgeons) in a hospital or other facility of a medical service-provider.FIG.3shows an exemplary embodiment of the data flow in a data-management-system connected with a data-acquisition-system. The sensors generate sensor-data21which is transmitted, intermittently or continuously, to the data-acquisition-module. The medical-operator generates operator-data22associated with procedure. The operator-data may include one or more of the following: information about patient identity and medical history, current status of the patient, information regarding the procedure to be performed including steps, purpose, monitoring parameters, patient risk factors, end results, etc. The data-acquisition-system may form a procedure-data-structure23which may include sensors-data (e.g., all or part of the data acquired from the sensors during the procedure, which may be processed using standard techniques known in the art such as noise removal, feature extraction, etc.) and the operator-data. The data-acquisition-system may include a de-identification-module configured to remove from the procedure-data-structure all information which may identify the patient thereby forming the de-identified procedure-data-structure24. The de-identified procedure-data-structure24may be sent to the data-management-system10where it may be stored (i.e., the entire or part of the procedure-data-structure) in a procedure-record25of the records-database11. The de-identified procedure-data-structure24may be sent to the data-management-system10via an internet connection, a wireless intranet connection, wired connection, or other data transmission methods known in the art. In an alternative embodiment, the de-identification of the health information is not performed, and patient identity is linked to the data in procedure-data-structure23.

FIG.4shows an exemplary embodiment of a procedure-record25for a medical procedure performed on a patient. As seen the procedure-record may include a description of the surgical procedure, patient de-identified information (e.g., age, medical conditions, medical history), sensor data (e.g., intracranial pressure data, blood pressure data), and imaging data (e.g., X-ray images, MRI scans, surgery videos).

The procedure-record25may be rendered immutable by a blockchain system. The blockchain system may include a private or a public blockchain. The procedure-record25my include one or more datasets26(see for example dataset-1, dataset-2, and dataset-n inFIG.3). The datasets may have substantially the same size (e.g., 100 kB, 1 MB, 10 MB, etc.), the size being predetermined so as to be suitable for storing on the blockchain. In the exemplary embodiment shown byFIG.3the datasets are stored on the blockchain20, each of the datasets having a specific address on the blockchain20(i.e., address-1, address-2, address-n). For each of the datasets stored on blockchain, a counterpart-dataset (i.e., a copy of the dataset) may be stored on the records-database. The blockchain-addresses may be stored in the databases. The datasets stored on blockchain may be rendered immutable and their integrity may be ensured by the blockchain technology. The datasets may be accessed (for example, via a download) by using their address but the datasets cannot be altered. The data-management-system may further store links to the blockchain-addresses and/or the datasets on a website associated with the database so as to allow others (e.g., healthcare administrators, researchers, physicians, surgeons, etc.) to view and access specific datasets and procedure-records. The data integrity of the counterpart-datasets may be periodically evaluated by comparing the counterpart-datasets (stored on the records-database, not on blockchain) with the corresponding blockchain stored dataset and the dataset hash value.

FIG.5shows an exemplary embodiment of the data-management-system in which the hashes of the datasets are stored on the blockchain. In this embodiment the data-management-system may include a hash-module. The hash-module is configured to employ a hash-function to calculate hash values28for the datasets26of the procedure-record (see dataset-1, dataset-2, dataset-n). The data-management-system may store the dataset hash values on the blockchain as block-hash-values29, wherein each of the block-hash-values29has a specific address on the blockchain20. The blockchain-system may further store the blockchain addresses of the dataset-hash-values in the database and as associated with their corresponding procedure-record25. For example, consider dataset-1and block-hash-1of the procedure-record-1stored on the blockchain at time-1. The blockchain address-1(where block-hash-1is located on the blockchain) is stored on the database and is associated with dataset-1of the procedure-record.

The blockchain-system may be configured to verify the integrity of any one of the datasets by calculating a hash of the dataset and comparing the calculated hash with the corresponding block-hash stored on the blockchain. For example, once the dataset-1is stored in the database and its corresponding block-hash-1is stored on the blockchain, the blockchain-system may verify the integrity of dataset-1(at a verification-time which is after time-1) by calculating the hash value of dataset-1(as stored in the database at the verification-time) and comparing the calculated hash with the block-hash-1stored on the blockchain. If the calculated hash is different from block-hash-1, then dataset-1has been corrupted or altered. If the calculated hash is identical with block-hash-1, then dataset-1has not been altered. This way the blockchain-system is able to periodically verify the integrity of the datasets in the procedure-records and to keep the procedure-records immutable.

FIG.6shows an exemplary embodiment of a data-management-system connected with a plurality of data-acquisition-systems31. Each of the data-acquisition-systems31is configured to acquire sensor and imaging data generated during a specific medical procedure performed on a certain patient. For example, data-acquisition-system-1may be used to acquire data during a medical-procedure-1performed on patient-1by operator-1of a service-provider-1; whereas data-acquisition-system-2may be used to acquire data during a medical-procedure-2performed on patient-2(which is different from patient-1) by operator-2(different from operator-1) of a service-provider-2(which may be different form service-provider-1). Each of the data-acquisition-systems31may perform the operations described above with reference toFIG.3or the operations described with reference toFIG.5, thereby forming their own de-identified procedure-data-structure. For example, data-acquisition-system-1may form a de identified procedure-data-structure-1whereas data-acquisition-system-2may form de-identified procedure-data-structure-2.

The data-management-system may include a centralized-database32configured to receive the procedure-data-structure generated by various data-acquisition-systems and to form procedure-records (see e.g., Record-1, Record-2, to Record-n inFIG.6) corresponding to each of the procedure-data-structure. The data in the centralized-database (e.g., the procedure-records) may be rendered immutable via one or more blockchains34by operations such as described above with reference toFIG.3or the operations described with reference toFIG.5.

The centralized-database32may be configured to enable a plurality of users33(e.g., user-1to user-5inFIG.6) to access the data in the centralized-database. The users may be researchers, scientists and other professionals which may use the procedure-records to perform various studies. The centralized-database may be made accessible to the public or to a specific group of people. The centralized-database may be connected with or may include an interface and search module enabling users to search, select, view, and/or download data in the database. The centralized-database may be connected with a data-analytics-module36enabling users to perform data analytics studies on various data. Alternatively, users may be enabled to access data (e.g., download files) and to perform data analytics and other studies via their own data analytics software or other analytics resources.

The data-management-system may include a classification-module for categorizing and forming classes/groups of medical-procedures into one or more data-classes. The procedure-records stored by the centralized-database may be categorized/classified function of various classification-parameters of the procedure-record and/or the corresponding medical procedure, such as: the type of medical procedure; patient's age; procedure's date; type of equipment used during the medical-procedure; physiological parameters recorded by sensors during the medical procedure (patient's blood pressure, cranial pressure, body temperature, heart rate, etc.).FIG.7shows an exemplary embodiment of a centralized-database32in which the procedure-records are classified and grouped in data-classes35(e.g., data-class-1, data-class-2, data-class-3) by the type of medical procedure. These classes may be inferred or automatically determined from the sensor data, user input, or a combination thereof. For example, data-class-1may include the procedure-records for brain-surgeries, data-class-2may include the procedure-records for open heart surgery, and data-class-3may include the procedure-records for spine surgery. The grouping of procedures in classes may be performed so that the classes are the optimal “data units” for performing analytics and studies. For example, a person who wants to study a specific occurrence during open heart surgery is most likely to want to consider the data in the procedure-records for open heart surgery. The data in a data-class may be analyzed via data analytics procedures (e.g. data-mining, machine learning, artificial Intelligence) with the purpose of finding “correlations” between various medical-parameters, patient-parameters and medical-outcomes.

This classification may be performed via a wide variety of techniques known to those skilled in the art. In a non-limiting embodiment, the classification may be done with Natural Language Processing techniques. For example, topic modeling may be applied to procedure records and may be used to create a ‘topic’ frequency vector for each procedure note to compare notes across procedures and cluster procedures with similar ‘topic’ distributions into groups to facilitate search. Term frequency vectors extracted per note may be combined with similarity calculations across the corpus of notes, vector similarity computation techniques such as cosine similarity or Jaccard similarity may be used, whereas the vectors may contain weighted term frequencies such as but not limited to Term Frequency-Inverse Document Frequency (TF-IDF) or may contain unweighted term frequencies.

Named Entity Recognition algorithms may be used to identify drugs and diseases in the notes and classify the notes based on such entities. Machine translation algorithms may be used in case of notes in different languages. Supervised learning classification algorithms may cause these and other features to automate assignment of the procedure into categories that are relevant for the users of the database (for example, procedure names commonly accepted in the medical profession, or ICD10may be used to categorize based on diagnoses or disease codes). Combinations of terms such as bigrams, trigrams, or any type of n-gram may be used as features for a classifier. Word embeddings or sentence embeddings may also be used as features. Classification algorithms may include but are not limited to standard techniques known in the art, such as: decision trees, k-nearest-neighbors, naïve-bayes, support vector machine, neural networks, random forests, or ensemble methods, to name a few. The procedure data may not necessarily be in textual format.

In another embodiment the notes may be spoken to by a physician during a procedure and transformed into a textual note via a speech to text translation algorithm. Features such as intonations, breathing rate, rate of speech, etc. may be used as well to identify procedures that were complex or where unexpected events occurred during a procedure.

The classification of the procedure may not necessarily require textual data; in another embodiment, a video of the surgical area may be used instead (or still images from a camera) in order to classify the type of procedure, complications, blood loss, or any other adverse events, as well as to identify standard steps common to most procedures within a procedure category. Such data may be used to train a surgical robot in both standard flows of procedures as well as remedies in cases of complications. In an embodiment the images or video could include timestamps. The classification of the procedure may include video, photographic, sound, text, sensor data, as well as any combination thereof.

FIG.8shows an exemplary embodiment of a data-management-system including a centralized-database32, such as inFIG.6, connected with a data-analytics-module36, a search module37, and a data-verification-module38. The data-analytics-module36may include tools for selecting specific data in the procedure-records by various parameters, such as anesthiology related data, patient's blood pressure, patient's age, type of procedure, etc. The data-analytics-module may include tools enabling users to perform certain analytics operations and protocols (e.g., data-mining, machine learning, text analysis, AI-based decision support systems) on the selected data. The data-analytics-unit may be configured to find “correlations” between various medical-parameters, patient-parameters, and medical-outcomes. The search-module37may enable users to search data in the procedure-records according to parameters such as record-number, surgery-type, data-type, patient's current medical conditions, medical history, etc.

The data-verification-module38may enable users to select certain data (e.g., set of procedure-records) and to validate the integrity of the data, i.e., to ensure that the selected data was not altered or corrupted. If the selected data is directly stored on blockchain, then the integrity of the data is ensured by the integrity of the blockchain. If counterparts of the data are stored on the blockchain then the data integrity of the counterpart-datasets may be evaluated periodically (or at specific times) by comparing the counterpart-datasets (stored on the records-database, not on blockchain) with the corresponding blockchain stored dataset. This latter embodiment is particularly useful in situations where the block size of the blockchain implementation is small and cannot fit a full medical procedure record/surgical record dataset; in this case, a hash value calculated based on the dataset is stored on the blockchain together with a location to the dataset, whereas the actual medical procedure record dataset/surgical procedure data can be stored off the blockchain, in a separate database system. Users wishing to verify the integrity of the data can compare the hash value of the dataset per the blockchain entry with the hash value of the dataset stored off the blockchain; should these not match, the dataset is rejected as not the genuine entry.

If the selected data includes datasets for which the integrity is ensured via cryptographic hashes stored on a blockchain, then the data-verification-module may enable users to validate the selected data by calculating the hashes of the datasets and comparing the calculated hashes with the corresponding hashes stored on the blockchain. Please note that the calculated hashes are calculated at the time when the verification is performed (i.e., verification-time) whereas the hashes stored on blockchain were calculated and stored at a blockchain-storing-time which may be essentially the time when the procedure-record was formed.

FIG.9shows an exemplary embodiment of a method for securing the integrity of the data in the records-database. The data in the data-classes35is grouped and/or organized in a plurality of datasets41(i.e., dataset-1, dataset-2, . . . dataset-n). Each of the datasets may be secured via the blockchain by calculating a hash42for the dataset and storing the hash on the blockchain43as a block-hash44. Alternatively, copies of the datasets may be stored directly on the blockchain. The datasets may have substantially the same size (e.g., 1 MB, or 100 kB), the size being predetermined so as to be suitable for storing on the blockchain.

Data-management-systems such as the one described with reference toFIG.6may be difficult to implement because they require that a majority or a large number of service providers (e.g., hospitals, private practices, healthcare companies) agree to have a third party (e.g., administrator of the centralized-database) copy and store their medical data on a system controlled by the third party. Understandably, many healthcare providers are reluctant to give their data to someone else. The data-management-system described below with reference toFIG.10circumvents the problem described above, i.e., having data owned by service-providers copied, stored, and managed by someone else.

FIG.10shows an exemplary embodiment of a data-management-system connected with a plurality of data-acquisition-systems51. Each of the data-acquisition-systems51is configured to acquire sensor and imaging data generated during a specific medical procedure performed on a certain patient. For example, data-acquisition-system-1may be used to acquire data during a medical-procedure-1performed on patient-1by operator-1of a service-provider-1; whereas data-acquisition-system-2may be used to acquire data during a medical-procedure-2performed on patient-2(which is different from patient-1) by operator-2(different from operator-1) of a service-provider-2(which may be different form service-provider-1). Each of the data-acquisition-systems may perform the operations described above with reference toFIG.3or the operations described with reference toFIG.5, thereby forming their own procedure-data-structures (including de-identified data) which may be stored in databases52owned by the service-providers performing the medical procedure.

For example, a procedure-record-1including de-identified procedure-data-structure acquired during medical-procedure-1is stored on database-1, wherein database-1is owned by service-provider-1(e.g. a specific hospital). Similarly, a procedure-record-2including de-identified procedure-data-structure acquired during medical-procedure-2is stored on database-2, wherein database-2is owned by service-provider-2(e.g. a specific hospital). Medical-procedures performed by the same service-provider (e.g. another hospital) may be stored in the same database52.

The data in the databases52may be rendered immutable via one or more blockchains53by the operations described above with reference toFIG.3or the operations described with reference toFIG.5. The blockchains employed by different databases may be different from each other (i.e. each database uses its own blockchain). Alternatively, all or part of the databases may employ a common blockchain.

The data-management-system may include a centralized-data-access-system50which may further include a website and/or a centralized-access-database. The centralized-data-access-system50may include a database-access-module configured to connect the centralized-data-access-system50with a plurality of databases52, each of the databases comprising a plurality of procedure-records. The centralized-data-access-system is configured to enable users54(e.g., user-1to user-5inFIG.10) to access the data in the databases52(e.g., database-1to database-n). The centralized-data-access-system may enable users54to perform specific studies and data analytics on the all or some of the data in the databases52. For instance, auditors may verify the integrity of the database system by comparing the hash of its record with a corresponding hash at the appropriate address on the blockchain. Databases52may be owned and managed by different service-providers (e.g., different healthcare companies, different hospital systems, different provider offices, etc.). The centralized-data-access-system may be owned and managed by a party (e.g., company or non-profit institution) who is legally bound to keep the data securely for the benefit of the public and the owners of the databases52.

Different datasets in the databases may be assigned different permission-levels indicating the conditions in which a user can access the data-file and the specific operations a user can perform on a data-file. For example, a permission level for a certain data-file may prescribe that the data-file cannot be download from the database but may be used in analytics studies (e.g., analytics performed in the database with analytic-tools owned by the database owner) and the user can see the results of the study. Each user may have certain permission-level with respect to a data-file in a certain database. For example, user-1may be permitted to perform certain analytics-operations on some data-files in the database-n owned by hospital-n and to receive the results of the analytics-operations; user-1may be allowed to see the data-files but may not be allowed to download the files from the database-n; user-2may only have audit access, i.e., to compare hash values of records with existing records on the blockchain but may not actually see the contents of the datasets used to create the hash values.; other users may have full access. Editing a record would require creation of a new record with its own separate address pointer on the blockchain, address pointer to the record being updated, address pointer to the external database system (if applicable), and hash value. Variations thereof may be envisaged by those skilled in the art.

The centralized-data-access-system may include one or more computer servers including one or more processors and one or more memories (memory modules, database systems, cloud storage devices, etc.). The computer servers may include connection-ports configured to send and receive information to/from the databases52and the users54via network connections and/or the internet. The centralized-data-access-system may act as the interface between users54and databases52. The centralized-data-access-system may include a search-module enabling users54to search data in the databases52. The centralized-data-access-system may include a data-analytics-unit enabling users to select data and perform various analytics operations and studies on the data in the databases52. The centralized-data-access-system may include one or more websites enabling users to access and use the search-module and the data-analytics-module.

The centralized-data-access-system may include a classification-module for categorizing and forming classes/groups of medical-procedures into one or more data-classes.FIG.11shows an exemplary embodiment of an interface of the centralized-data-access-system50displaying several data-classes56formed by the classification-module. Each of the data-classes56may include pointers (or links) to data files and procedure-records stored in various databases52. The links/pointers may point to procedure-records and/or files stored on different databases52owned by different service-providers. For example, data-class-1may include all procedure-records for which the medical procedure is a brain surgery. Data-class-1may include a procedure-record (e.g. Brain-Procedure-a) which is stored in database-2owned by service-provider-2, a procedure-record (e.g. Brain-Procedure-b) which is stored in database-1owned by service-provider-1, and a procedure-record (e.g. Brain-Procedure-c) which is stored in database-5owned by service-provider-5. The centralized-data-access-system50is connected and provides access to various procedure-records in databases52, wherein each of the databases is owned by a different service-provider (e.g. hospital, private practice, university).

The data-classes may be formed as described with reference toFIG.7. A data-class may include all the procedure-records (in all databases, i.e., database-1to database-n) for which a classification parameter has a certain parameter-value. The classification parameters may include, but not be limited to: the type of medical procedure; patient's age; procedure's date; type of equipment used during the medical-procedure; physiological parameters recorded by sensors during the medical procedure (patient's blood pressure, cranial pressure, body temperature, heart rate, etc.). For example, the classification-parameter for the data-classes shown inFIG.11is the type of medical procedure (e.g., brain surgery, open heart surgery, and spine surgery).

The classification-parameters may be chosen so that the formed data-classes are the optimal “data units” for performing analytics and scientific studies. For example, a person who wants to study a specific occurrence during open heart surgery is most likely to want to consider the data in the procedure-records for open heart surgery. The data in a data-class may be analyzed via data analytics procedures (e.g., data-mining, machine learning, text analytics, etc.) with the purpose of finding relationships between various medical-parameters, patient-parameters and medical-outcomes.

FIG.12shows an exemplary embodiment of a data-acquisition-system connected with a data-management-system, wherein the data-acquisition-system is configured to be included in a portable surgical system60such as the one disclosed in the international patent application PCT/US2017/042266 titled “Ultraportable System for Intraoperative Isolation and Regulation of Surgical Site Environments” and filed on Jul. 14, 2017 by D. Teodorescu et al. The portable surgical system may be used to perform surgery in environments other than operating rooms, such as in the field, outdoors, tents, cottages, residential rooms, etc. When used in field applications (e.g., outdoors, remote areas) the data-acquisition-system most often cannot be connected with databases in real time, such as the ones described with reference toFIGS.2to11, because in the field there may be no available internet or network connections (neither cable connections nor Wi-Fi connections). For in the field applications, the data-acquisition-system may include one or more memories61and/or a satellite-connection-device62.

The memories are configured to store the data generated by the sensors, by the imaging system, and/or data input by the operators. The memories may store the data while there is no connection with the data-management-system. Once a connection with the data-management-system is established (e.g., the data-acquisition-system is connected to internet via a cable, Wi-Fi, or by a satellite connection, or some other means) then the data in the memories may be sent to the databases of the data-management-system (see e.g., databases described with reference toFIGS.2,6,7,10, and11) and stored on the databases in a corresponding procedure-record hashed, and have a corresponding block-hash created.

Especially for the in the field applications, satellite connections are useful because they provide a way to transmit data to databases from the field (e.g., remote areas). The satellite-connection-device may be configured to send (via a satellite connection) to the data-management-system the data generated by the sensors, by the imaging system, and/or data input by the operators. This way data generated during medical procedures performed in the field may be sent to the databases of the data-management-system even in the absence of cable or Wi-Fi connections to the internet.

The above embodiments presented in this disclosure merely serve as exemplary embodiments and it will be apparent to those skilled in the art that various modifications and variations can be made in the present invention without departing from the spirit or scope of the invention. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the present disclosure. The inventions herein may be embodied in many different forms and should not be construed as limited to the exemplary embodiments set forth herein. Rather, these exemplary embodiments are provided so that this disclosure is thorough, and will fully convey the scope of the invention to those skilled in the art.

LIST OF REFERENCES

[1]. Intraoperative Monitoring; Dr. Liji Thomas, MD, News Medical Net (Feb. 27, 2019)[2]. “Recommendations for standards of monitoring during anesthesia and recovery 2015”, Association of Anesthetists of Great Britain and Ireland[3]. “Guidance Regarding Methods for De-identification of Protected Health Information in Accordance with the Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule” published by the U.S. Department of Health and Human Services.[4]. International patent application number PCT/US2017/042266 titled “Ultraportable System for Intraoperative Isolation and Regulation of Surgical Site Environments” and filed on Jul. 14, 2017 by Teodorescu et. al.