WO2013036677A1 - Groupe de calcul informatique médical - Google Patents

Groupe de calcul informatique médical Download PDF

Info

Publication number
WO2013036677A1
WO2013036677A1 PCT/US2012/054010 US2012054010W WO2013036677A1 WO 2013036677 A1 WO2013036677 A1 WO 2013036677A1 US 2012054010 W US2012054010 W US 2012054010W WO 2013036677 A1 WO2013036677 A1 WO 2013036677A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
signal data
user
phenotype
sensors
Prior art date
Application number
PCT/US2012/054010
Other languages
English (en)
Inventor
Rob WYNDEN
Andrew V. NGUYEN
Michael Bobak
Original Assignee
The Regents Of The University Of California
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by The Regents Of The University Of California filed Critical The Regents Of The University Of California
Publication of WO2013036677A1 publication Critical patent/WO2013036677A1/fr

Links

Classifications

    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/20—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for computer-aided diagnosis, e.g. based on medical expert systems
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/67—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for remote operation
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H15/00—ICT specially adapted for medical reports, e.g. generation or transmission thereof

Definitions

  • the methods include obtaining signal data for a subject from one or more body sensors; storing data associated with the subject; associating respective ones of the signal data with respective ones of the data associated with the subject; and storing at least a portion of the signal data or associations between the signal data and the data associated with the subject. Further, in certain aspects the methods include associating patterns within the signal data with patterns associated with the subject.
  • the methods may facilitate creating a retrospective analysis of an event (e.g., an adverse event such as a heart attack, seizure, or hypoglycemic event), detecting the occurrence of an event (e.g., a hypoglycemic event), and/or predicting the future occurrence of an event (e.g., a hypoglycemic event).
  • an adverse event such as a heart attack, seizure, or hypoglycemic event
  • detecting the occurrence of an event e.g., a hypoglycemic event
  • predicting the future occurrence of an event e.g., a hypoglycemic event.
  • Systems for use in practicing methods of the invention are also provided.
  • the systems and methods have utility in a variety of clinical and non-clinical applications.
  • FIG. 1 is a graphical illustration of an example medical informatics system.
  • FIG. 2 is a graphical illustration of one implementation of a SACS.
  • FIGs. 3-4 are logical diagrams of example MICC systems.
  • FIG. 5 is a network diagram of one example of a MICC implementation
  • FIG. 6 is an example workflow of how MICC can be used when integrating with an existing infrastructure.
  • FIGs. 7-8 are graphical illustrations showing the processes of feature extraction, change detection, and machine learning applied to data obtained from one or more biomedical sensor(s).
  • FIGs. 9-14 are graphical illustrations of example information displays that can be rendered by entities associated with a medical informatics system
  • FIG. 15 is a block flow diagram of a process of managing user data.
  • FIG. 16 shows results of feature extraction on arterial blood pressure waveform data, depicting variants of the Sliding Window PSD algorithm with varying parameters.
  • the light gray plot has a window size of 1024 points (roughly 8 seconds) and a skip size of 500 points (4 seconds); the blue plot has a window size of 1024 points and a skip size of 125 points
  • the brown plot has a window size of 512 points (roughly 4 seconds) and a skip size of 128 points (roughly 1 second); all have a period of 0.008 sec (125 Hz) which is the period of the recorded samples.
  • FIG. 17 shows the impact of initial values on single-pass algorithms.
  • the plot is zoomed out on the Y-axis (measured in volts), where the signal ranges from 0 to 50 V.
  • the bottom panel is moved forward in time 20 seconds, where the EKG then reads between -300 and 300 mV.
  • FIG. 18 shows the application of several feature extraction algorithms on the arterial blood pressure waveform data immediately before and after the onset of ventricular tachycardia.
  • the top chart shows the application of the Sliding Window PSD algorithm with several different parameters.
  • the second chart shows the application of the P2PDelta- Amplitude algorithm to a previously extracted feature (beat-to-beat systolic pressure).
  • the third chart shows the application of the P2PDelta-Time algorithm to a previously extracted feature (beat-to-beat systolic pressure).
  • FIG. 19 shows the application of EM clustering as applied to MIMIC-II data.
  • FIG. 20 shows instance information for cluster 0 of FIG. 19.
  • the methods include obtaining signal data for a subject from one or more body sensors; storing data associated with the subject; associating respective ones of the signal data with respective ones of the data associated with the subject; and storing at least a portion of the signal data or associations between the signal data and the data associated with the subject.
  • MIBC Medical Informatics Compute Cluster
  • the methods facilitate creating a retrospective analysis of an event (e.g., an adverse event such as a heart attack, seizure, or hypoglycemic event), detecting the occurrence of an event (e.g., a hypoglycemic event), and/or predicting the future occurrence of an event (e.g., a hypoglycemic event).
  • an adverse event such as a heart attack, seizure, or hypoglycemic event
  • detecting the occurrence of an event e.g., a hypoglycemic event
  • predicting the future occurrence of an event e.g., a hypoglycemic event.
  • Systems for use in practicing methods of the invention are also provided. The systems and methods have utility in a variety of clinical and non-clinical applications.
  • an example MICC system 10 that facilitates aggregating, managing, and/or analyzing data.
  • This system 10 includes a Signal Archiving and Computation System (SACS) 12, an Integrated Data Warehouse (IDW) 14, an analysis engine 16 and a data store 18.
  • SACS 12 is configured to collect and/or store signal data from one or more sensors 20 (e.g., a physiological sensor, such as a blood pressure monitor, heart rate monitor, EEG, EKG, etc.).
  • the IDW 14 is configured to store data associated with a subject (e.g. data from a patient's electronic health record, laboratory or pharmacy databases, etc.).
  • the analysis engine 16 is communicatively coupled to the SACS 12 and the IDW 14 and configured to associate signal data collected by the SACS 12 with data associated with the subject obtained via the IDW 14.
  • the data store 18 is communicatively coupled to the analysis engine 18 (and optionally the SACS 12) and configured to store at least a portion of the signal data or associations between the signal data and the data associated with the subject.
  • MICC facilitates the collection, storage, and analysis of a broad range of data.
  • One such type of data is referred to herein as “signal data” and “sensor data.”
  • the terms “signal data” and “sensor data” may be used interchangeably herein, and are used to refer to the raw as the raw and/or derived data that is output by one or more biological sensors.
  • Examples of signal data include the raw source voltage as analog to digital values of arterial blood pressure, intracranial pressure, EKG, and EEG, or their physical unit converted equivalents, as well as any other physiological parameter for which automated data collection exists within the clinic such as instantaneous heart rate, respiration rate, or systolic blood pressure.
  • signal data includes data that is output by two or more biological sensors, such data may be combined using approaches described more fully herein, and shall still be considered "signal data.”
  • Signal data may include time series notations, as described more fully herein, and such time series information shall also be considered to be part of the signal data.
  • Signal data is collected from a subject.
  • MICC In addition to signal data, MICC also facilitates the collection, storage, and analysis of a "clinical data.”
  • clinical data is used broadly and generically to refer to all non-signal data that is known or obtained about a user.
  • Clinical data thus may include data not generated in a clinic or other healthcare setting. Examples of clinical data thus include any data that is stored in nursing, laboratory, and/or pharmacy databases, as well as data that is contained in electronic health records. Further examples of clinical data include image data, such as radiological images, as well as food/diet diaries, calendars, user responses to questions, and the like.
  • Clinical data are often stored via nursing, laboratory, and pharmacy databases as well as electronic medical records, which are sometimes consolidated into an IDR (integrated data repository) or CDW (clinical data warehouse), with images often being stored in a radiology picture archival and communication system (PACS).
  • IDR integrated data repository
  • CDW compact data warehouse
  • EPC radiology picture archival and communication system
  • Existing Databases may be used herein to describe such existing databases that contain data or information on the subject. This can include, but is not limited to, electronic health records, pharmacy databases, insurance claims databases, calendars, activity logs, etc.
  • IDW Integrated Data Warehouse
  • An IDW may also store instances of the computable phenotype, and provide these instances to the various engines within a MICC system (e.g., signal processing, feature extraction, statistical/machine learning, and rules/CEP).
  • aspects of the systems and methods provided herein relate to data that is generated in a clinical environment, such as a hospital or other healthcare provider.
  • a modern clinical environment may generate a wealth of data for a patient, particularly if the patient is undergoing an invasive procedure or is in an intensive care unit (ICU).
  • ICU intensive care unit
  • the sensor data may comprise data obtained from sensors within a user's phone (e.g., smartphone). Such sensor data may be obtained for purposes unrelated to clinical monitoring or diagnosis (e.g., drowsiness monitoring, measuring the user's alertness while on the job, and the like).
  • a "clinical phenotype” is any observable characteristic or trait of a patient. The term is meant to include, for example, morphology, development, behavior, biochemical, and/or physiological properties.
  • the phrase "computable phenotype” is used herein to refer to a clinical phenotype that is formally defined as the combination of attributes, weights, and rules, derived from signal data and/or clinical data, that is expressed in a computable standard format.
  • signal data collection for 45 signals e.g. 14-channel EEG, 12-lead EKG, arterial blood pressure, and other waveforms
  • signal data collection for 45 signals requires approximately 350 GB of raw disk storage per bed; for 200 beds, with data replication, at least 70 TB of capacity would be necessary per year.
  • approximately 40 GB to 100 GB of raw disk storage may be used per bed per year.
  • a MICC may facilitate the identification of associations between signal data and clinical phenotypes. Moreover, a MICC may facilitate the creation and/or identification of computable phenotypes, using, for example, high-throughput data storage according to any suitable data storage mechanism(s) available and generally known in the art (e.g., storage provided by the HDF5 technology suite and associated tools such as those used on the BioHDF project, "NoSQL" databases, PhysioNet tools, etc.).
  • the signal data would be associated with clinical data that has been extracted from an integrated data warehouse system, as shown in FIG. 1. Examples of methodologies used to draw associations include biostatistics, machine/statistical learning, and hybrid systems.
  • the data may be temporarily or permanently stored in the IDW.
  • a compute cluster may be deployed using various frameworks that facilitate parallelizing computation, such as MapReduce, PVM (parallel virtual machine), MPI (message passing interface), etc.
  • a MICC may not include parallel computation.
  • the MICC may also accept plug-ins implemented in the above frameworks to support a suite of potential data mining services for informatics or analytics.
  • the services provided on the MICC can be utilized by researchers and can leverage the scale of data housed within the MICC signal stores and integrated data warehouses.
  • These MICC services include algorithms for pattern detection and classification within a warehouse of clinical signal data and data extracted from the integrated data repository. Any combination of machine learning, biostatistics and/or data exploration tools may be used to provide insight into challenging clinical questions in a variety of clinical and non-clinical domains.
  • Data mining services provided on the MICC can include, for example, the pattern based interactive diagnosis of disorders, pattern classification applied to electrocardiography, and pattern recognition analysis of coronary artery disease.
  • Data mining services may also include, for example, determining of the cost effectiveness of interventions (e.g., hypertension interventions, health education counseling, and the like), determining of the effectiveness of interventions (e.g. sleep apnea interventions, exercise regiments, and the like), and determining the effectiveness of healthcare providers (e.g., a clinic, physician group, and the like).
  • interventions e.g., hypertension interventions, health education counseling, and the like
  • determining of the effectiveness of interventions e.g. sleep apnea interventions, exercise regiments, and the like
  • determining the effectiveness of healthcare providers e.g., a clinic, physician group, and the like.
  • implementation of MICC can focus on collecting large amounts of clinical signal data and establishing new, better, and/or more accurate clinical phenotypes, including computable phenotypes. Once these improved phenotypes have been established, retrospective studies can be conducted that compare the clinical phenotypes present in a patient's electronic medical record against phenotypes generated by MICC using the patient's clinical signal data. The MICC-generated phenotypes can then be evaluated for their accuracy and ability to provide clinical decision support.
  • the services provided on the MICC may enable simple retrospective reviews of clinical signal data by combining them with semantically harmonized data from the IDW via a unified visualization layer.
  • a MICC e.g., as a plug-in or other module
  • a future event e.g., a hypoglycemic event
  • the detection of an event in progress e.g., arrhythmia
  • Detection of an event in progress or the likelihood of a future event may trigger one or more notifications (e.g., a text message, display on a dashboard, phone call) so as to alert a user and/or to prevent the occurrence of the event.
  • a MICC as described herein can be utilized to facilitate various services and can be implemented in office environments, manufacturing environments, health clubs, gyms, weight loss programs, etc., in addition to medical centers, clinics, hospitals, etc.
  • a MICC as described herein can be utilized to facilitate various services and can be implemented in office environments, manufacturing environments, health clubs, gyms, weight loss programs, etc., in addition to medical centers, clinics, hospitals, etc.
  • any suitable body or biometric sensor that provides output relating to a user and/or health of the user can also be used.
  • sensors that may be utilized herein include, but are not limited to, multipurpose sensors such as, e.g., the BodyBugg® sensor distributed by Apex Fitness, Inc., pedometers, personal satellite positioning system (SPS) location devices, etc.
  • SPS personal satellite positioning system
  • the present disclosure provides systems for aggregating, managing, and/or analyzing data, such as medical data.
  • An example of a system architecture that can be employed in connection with a MICC as described herein is now presented; however, other architectures can also be used.
  • this system 10 includes a Signal Archiving and Computation System (SACS) 12, an Integrated Data Warehouse (IDW) 14, an analysis engine 16 and a data store 18.
  • SACS 12 is configured to collect and/or store signal data from one or more sensors 20.
  • the IDW 14 is configured to store data associated with a user (e.g. clinical data).
  • the analysis engine 16 is communicatively coupled to the SACS 12 and the IDW 14 and configured to associate signal data collected by the SACS 12 with data associated with the user obtained via the IDW 14.
  • the data store 18 is communicatively coupled to the analysis engine 18 (and optionally the SACS 12) and configured to store at least a portion of the signal data or associations between the signal data and the data associated with the user.
  • Signal data may be obtained from one or more sensors. Sensors may be referred to herein as “physiological sensors”, “body sensors,” “biometric sensors,” and “biological sensors,” with such terms used interchangeably to broadly and generically refer to any sensor that provides output relating to a user and/or health of the user (e.g., a subject, patient, etc.).
  • any of a broad range of sensors may be used in the systems and methods of the present disclosure.
  • the number, type, and/or placement of sensors utilized to collect data from a user may vary depending upon at least the condition(s) for which the user is being monitored, the purpose(s) of monitoring the user, and other factors.
  • Sensors of interest include single-purpose sensors, and multi-purpose sensors such as, e.g., the BodyBugg® sensor distributed by Apex Fitness, Inc.
  • sensors examples include, but are not limited to, sensors such as, pedometers, personal satellite positioning system (SPS) location devices, global positioning system (GPS) location devices, EEG (e.g., wet- and/or dry-EEG sensors), MEG, ECG sensors, SSEP sensors, EMG sensors, EKG sensors, ECoG sensors, temperature sensors, spirometers (such as for measuring FVC, FEV1, FEV1 , PEF, FET, MVV, MEF75*, and the like), accelerometers, pulse oximeters, blood glucose sensors (e.g., continuous or non- continuous blood glucose monitoring sensors), thermometer, intracranial pressure sensors, blood pressure sensors (e.g., continuous or non-continuous), and the like.
  • SPS personal satellite positioning system
  • GPS global positioning system
  • EEG e.g., wet- and/or dry-EEG sensors
  • MEG ECG sensors
  • SSEP sensors EMG sensors
  • EKG sensors EKG sensors
  • ECoG sensors temperature
  • Suitable sensors also include, but are not limited to, sensors that measure one or more physiological parameters, such as temperature, blood pressure, pulse, respiratory rate, oxygen saturation, end tidal C0 2 , FVC, FEV1, FEV1 , PEF, FET, MVV, MEF75*, location, blood sugar, and the like.
  • a sensor may measure just one physiological parameter, such as temperature.
  • a single sensor may measure two or more parameters, including 3 or more, e.g. 5 or more, 10 or more, 20 or more, or 30 or more.
  • Sensors may be configured to transmit signal data by any convenient means.
  • a sensor may include a wired connection such that the signal data is transmitted via a physical connection to, e.g., a MICC system.
  • a sensor may be configured to transmit signal data via a wireless connection, such as Wi-Fi, Bluetooth, cellular (e.g., 3G, 4G, LTE and the like) or other wireless protocol.
  • a sensor may be configured to transmit signal data directly to a
  • the senor may establish a direct connection to the MICC (e.g., physical connection and/or wireless connection).
  • connection to a MICC may include an authentication and/or security protocol which may identify the sensor and/or user for which the signal data is being collected.
  • a sensor may transmit its signal data either directly or indirectly.
  • a sensor transmits signal data to a MICC indirectly.
  • An example of an indirect connection would be a sensor that includes a Bluetooth module that may be paired with a user' s device (e.g., computer, tablet, phone, smartphone, and the like), which device is used to connect with a MICC.
  • a user's device may be used to aggregate signal data from two or more sensors, which it may transmit to a MICC.
  • FIG. 3 presents one example of an indirect connection.
  • signal data from one or more sensors is transmitted through, or to, a cloud.
  • data may be transmitted through a cloud (e.g., via a cloud).
  • data may be transmitted to a cloud (e.g., ginger.io, SaaS, etc.).
  • data may be transmitted to a cloud, from where MICC , MICC pulls data into the SACS and/or IDW.
  • the cloud may be public or private. Additionally, user-generated data may be transmitted to the cloud. User generated data may take a variety of different forms, such as survey information (e.g., "how severe is your pain today?" or "what did you eat for lunch?), free form text, and the like. The survey information may be entered by a user using any convenient means, such as a phone (e.g., smartphone), computer, tablet and the like.
  • the user generated data and the sensor data is then transmitted from the cloud to a MICC system comprising an IDW (described below).
  • the MICC system may then output (e.g., via display, e-mail, or other type of notification, as described more fully below) information to a user.
  • the sensor(s) and user generated data need not ever connect directly with a MICC.
  • a sensor may transmit data directly and/or indirectly.
  • signal data may include continuous (e.g., waveform) data.
  • Time-series data may involve describing a physiological signal as a set of key- value pairs, where the key is a timestamp and the value is the measurement (e.g., a voltage, concentration, or any other recording by a sensor). Any of a variety of timestamps may be used in describing such time-series data (e.g., a timestamp encoded as the number of milliseconds since the epoch (January 1, 1970), as a timestamp encoded as the number of days from the epoch, and the number of picoseconds of the current day that have elapsed, etc.)
  • a sensor may be configured to provide a timestamp, such as by including an internal record of time.
  • the sensor's timekeeping means may be updated and/or synchronized with one or more other sensors.
  • the timekeeping means of the sensor is calibrated and/or synchronized upon connection of the sensor to a MICC (e.g., each time a sensor connects, upon first connection, upon regular connections, and the like).
  • MICC may provide a sensor with instructions to update its internal timekeeping means to a particular value upon such a connection between the MICC and a sensor.
  • an intermediary device e.g., a smartphone
  • two or more sensors are used to record signal data from a user.
  • about 5 to about 10 sensors about 10 to about 15 sensors, about 15 to about 20 sensors, about 20 to about 25 sensors, about 25 to about 30 sensors,
  • Such sensors may be identical (e.g., exactly the same, but placed at a different position on the user' s body) or different. Identical sensors may be used to provide data redundancy and reduce the likelihood of data loss if, for example, a sensor fails, falls off, or the like. In other aspects, a heterogeneous mix of sensors may be used. In such aspects, the sensors may record the same sensor value (e.g., location, environmental temperature, etc.) or different values.
  • a sensor may be used to collect information from an individual subject (e.g., a single patient).
  • a population of subjects e.g., such as 3 or more, 4 or more, 5 or more, and the like
  • one or more sensors may be used to collect information simultaneously from a population of subjects (e.g., 2 or more subjects, such as 3 or more, 4 or more, 5 or more, and the like).
  • a sensor may be used to measure the ambient temperature and/or chemical composition of an area (e.g., a room) in which one or more subject is present. In such embodiments, the one or more sensors may thus record signal information for a plurality of subjects simultaneously.
  • a MICC In some implementations of a MICC, computation and archival tasks may be bundled into a single entity. As a result, the MICC may utilize a SACS that is a bundled archival and computation system.
  • a non-limiting example of a SACS 12 is provided in FIG. 2, and is described in
  • FIG. 2 presents an overview of the primary components of this implementation of a SACS.
  • the primary components involve: 1) data storage, 2) metadata storage, 3) MapReduce, and 4) data visualization.
  • These are implemented in this particular, non- limiting example of a SACS using: 1) HBase, 2) a metadata relational database management system (a metadata RDBMS) (e.g., MySQL), 3) Hadoop/MapReduce, and 4) data visualization (e.g., Chronoscope with the Google Web Toolkit).
  • a metadata RDBMS metadata relational database management system
  • MapReduce e.g., MySQL
  • data visualization e.g., Chronoscope with the Google Web Toolkit
  • a SACS can be configured to store (e.g., archive) and/or process signal data.
  • a SACS may be configured to collect signal data from one or more sensors.
  • Signal data may be collected and/or stored by the SACS as time-series data.
  • This abstraction may be employed for the design and implementation of the SACS because it provides a common abstraction allowing for the storage of data at all granularities, from hours to minutes to seconds to microseconds. As a result, the SACS may be able to absorb all clinical signal data whether it is waveform data that is sampled at 1 kHz or numeric data sampled once an hour.
  • a SACS can store these data in any suitable storage system.
  • the SACS 12 stores the data in HBase, a distributed column store, such that each row represents a slice in time, identified by a timestamp encoded as the number of milliseconds since the epoch (January 1, 1970).
  • Each column contains the data of a particular signal for a particular patient. For example, one column might store the arterial pressure of patient A, another stores the temperature of patient A, and another might store the arterial pressure of patient B.
  • these data are stored sparsely such that gaps in the data do not take up any storage space.
  • All of the data within HBase are stored as binary data in order to maximize storage efficiency.
  • the column identifiers are stored as 4-byte integer values in their binary form. The mapping between these identifiers and their human-understandable counterpart is stored in a separate database.
  • Stored data can be configured to be easily and quickly recallable, minimizing access latency. For archival purposes, data that do not require low-latency access can be moved to a more efficient storage system. By offloading the long-term storage of data, a primary storage system is kept lean allowing it to continue to serve low-latency requests.
  • the signal metadata may be stored in a separate database instance.
  • this may be a database that stores metadata, such as MongoDB, a relational database, a non-relational database, and the like).
  • the metadata resides in a document-oriented database. However, this could also be implemented in a traditional relational database.
  • the SACS may integrate a signal processing system allowing for in-situ processing of the data. This is desirable considering the large anticipated amounts of data (e.g., upwards of 50 TB per year of clinical signal data for a 200-bed medical center). With increasing amounts of data, an in-situ processing environment negates the need to marshal data between the storage platform and the processing/analysis platform.
  • the processing environment may be implemented within the Hadoop platform and/or other suitable platforms and can leverage the MapReduce programming paradigm.
  • a SACS could also, or instead, integrate other processing platforms such as R, Matlab, or other home-grown systems, though such integration may prevent in-situ processing of the data.
  • the SACS may process the data and store the results of the processing back into the storage system. By storing the output of processing in the same storage system, the derived data is immediately available to subsequent processing tasks. This facilitates the chaining of multiple processing steps easily and efficiently.
  • the results may be stored back to the storage layer (e.g., HBase) with the corresponding metadata stored back to the Metadata RDBMS (e.g., Mongo and/or another suitable database platform).
  • HBase storage layer
  • Metadata RDBMS e.g., Mongo and/or another suitable database platform.
  • This metadata may be used to ensure that the HBase setup is as efficient as possible. Nearly all of the data in HBase may be stored in a binary format so it is not easily consumed by humans.
  • the metadata stored in the RDBMS may provide the bridge between the binary storage and the human-consumable data.
  • the metadata consists of the name and description of the algorithm, the numeric identifier that is used as the column header in HBase, as well as any other parameters of the algorithm (e.g. sliding window size, thresholds, etc.).
  • IDW Integrated Data Warehouse
  • An IDW stores some or all of the clinical data that is associated with a patient.
  • this data examples include data from the electronic health record (EHR), data from laboratory and pharmacy databases, or data from the nursing documentation system. While these data can be collected in a centralized manner in any sort of relational database, the IDW stores the data in such a way that it is easily computable (e.g. in a standard format, and/or as semantically harmonized data). The IDW can provide a means for bringing in data in a semantically interoperable manner and providing access to said data via a SOAP- or REST-based interface.
  • the IDW is utilized to analyze the clinical signal data in the context of the clinical data. For instance, the IDW can enable larger scale studies to take advantage of the data already available in the patient's clinical record. As with the in-situ data processing, the IDW can make the clinical data available and semantically meaningful.
  • IDW information may come from many different sources. Accordingly, semantic harmonization and/or normalization of the data may be useful or required to make the data useful. Combining two or more such types of information may be useful for establishing a more comprehensive picture of the overall health of patients than may be accomplished using only one source of information. For example, a term such as "MS,” when used within a clinical finding, may have many different meanings. If the finding were a cardiology finding, one may conclude that MS stands for "mitral stenosis.” If the finding were a finding related to
  • MS stands for "morphine sulfate.”
  • morphine sulfate There are likely hundreds or more of such domain specific interpretations of clinical data that exist. Additionally, multiple possible biological pathways or forms of environmental stress may cause the exact same "clinical phenotype.” For example, an ITP patient may have low platelet counts due to Graves' Disease, or due to exposure to Helicobacter pylori bacteria and can sometimes be originally detected following abnormal serum liver tests and Graves patients often have liver disease. If the original clinical findings are on the topic of Graves disease or a bacterial infectious disease then within which domain should the term " ⁇ " be later interpreted?
  • IRP intraosteal phosphate
  • Inosine triphosphate which is associated with gene defects leading to SAE's after liver transplants. Accordingly, by aggregating multiple sources of information about the patient, in a semantically harmonized manner, the nature of clinical information may be made easier to interpret.
  • a "Data Processing Engine” is used herein to describe an engine that is responsible for traditional signal processing of the sensor data as well as normalization of the data (with and/or without context from the IDW).
  • data from existing databases may be normalized and/or semantically harmonized by a Data Processing Engine before loading, or after loading, into a IDW by applying biomedical terminologies and/or ontologies. Such biomedical terminologies or ontologies may be obtained from a terminology server.
  • a “terminology server,” as used herein, is used broadly and generically to describe a computer-accessible resource which provides standardized, machine-readable terminologies and ontologies.
  • a terminology server may, for example, be a computer physically connected to a database, a computer connected to a local network, a computer connected to a proprietary network, or a computer to which one may interface via a web portal. Any convenient means of accessing the information on the terminology server may be employed.
  • the particular means of connecting to a terminology server e.g. through an application programming interface (API)
  • API application programming interface
  • the means of connecting to the terminology server may include using an API based on BioPortal REST services.
  • the data may be normalized using the terminology server via any convenient means known in the art.
  • Such means may include methods described by, for example, AL Rector, et al, Methods Inf Med. 1995 Mar; 34(l-2):147-57; CG Chute, et al, Proc AMIA Symp. 1999:42-6; AM Hogarth, et al, AMIA Annu Symp Proc. 2003; 2003: 861; and PL Whetzel, et al, Nucleic Acids Res. 2011 Jul;39(Web Server issue):W541-5. Epub 2011 Jun 14; the disclosures of which are incorporated herein by reference.
  • the normalized data may then be translated by processing with an ontology mapping engine, using the biomedical terminologies and ontologies obtained from the terminology server.
  • ontology mapping is contained in, for example, Y. Kalfoglou and M. Schorlemmer. The Knowledge Engineering Review Journal (KER), (18(1)): 1- 31, 2003; and Wynden R, et al. Ontology Mapping and Data Discovery for the Translational Investigator. AMIA CRI Summit 2010; the disclosures of which are incorporated herein by reference.
  • Any convenient ontology mapping engine may be employed (e.g. Snoggle, Health Ontology Mapper (HOM), X-SOM, and the like).
  • an analysis engine 16 may be any analysis engine 16.
  • an “engine” is one or more software modules responsible for carrying out a task.
  • An analysis engine may include a dedicated computer or cluster of computers, distinct from the SACS, IDW, or other hardware of a MICC.
  • an analysis engine uses hardware that is also used in whole or in part for SACS, IDW, or other components of a MICC.
  • an analysis engine may utilize all or part of the nodes of a SACS cluster to perform one or more analyses.
  • An analysis engine may perform feature extraction on signal and/or clinical data.
  • an analysis engine may comprise a feature extraction engine.
  • a "Feature Extraction Engine” is used herein to describe a processor that produces feature series using algorithms applied to the sensor data. The algorithms may be specific to a particular use or may be more general algorithms (such as mathematical algorithms).
  • data from the IDW is fed into the Feature Extraction Engine to provide contextual information for the feature extraction algorithms. This includes both non-sensor as well as phenotype data and information. Formally, this engine reduces the input data down to only non-redundant and relevant content. Sometimes, this can also be referred to as automated annotation.
  • feature extraction is meant to broadly encompass the application of one or more algorithms that operate on the input signal and return a derived set of data or a derived signal.
  • feature series is used to refer to the derived set of data or derived signal that is obtained from feature extraction.
  • feature extraction algorithms include, but are not limited to, physiologic algorithms such as systolic peak detection from the arterial pressure waveform or RR-interval extraction from the ECG, and mathematical algorithms such as the rolling mean or permutation entropy.
  • physiologic algorithms such as systolic peak detection from the arterial pressure waveform or RR-interval extraction from the ECG
  • mathematical algorithms such as the rolling mean or permutation entropy.
  • feature extraction is a specific type of dimensionality reduction.
  • the raw data itself is difficult to process and use from a computational standpoint - there are increasingly large amounts of data and most of it is not directly useful. But, through feature extraction (or dimensionality reduction), it is possible to transform and distill the data into a smaller set that is more pertinent and useful to the question being asked.
  • An analysis engine may perform change detection on a feature series.
  • change detection is used broadly to refer to the application of one or more algorithms to detect one or more changes in a feature series, and is an example of a specific class of feature extraction.
  • change detection algorithms of interest include, for example, change- point detection algorithms (e.g., Difference-of-Means algorithm and the like).
  • change detection algorithms return derived sets of data.
  • change series is used to refer to the derived set of data that is obtained from change detection.
  • the change series may include the same size or a smaller set of data when compared to the input data. Change series may contain additional parameters quantifying the change.
  • An analysis engine may be used to perform learning (e.g., supervised and/or unsupervised machine learning, and/or statistical learning) on data.
  • An analysis engine in a MICC system supports several approaches to the analysis of signal data, using both supervised and unsupervised machine and statistical learning in order to derive relationships between the clinical signal data and the status of the patient. That is, an analysis engine may comprise a statistical/machine learning engine.
  • a "Statistical/Machine Learning Engine” is an engine that combines the extracted features from the time series data with data from the IDW to develop computable phenotypes or models of conditions of interest.
  • machine learning system is used broadly and generically to refer to a system that learns to recognize complex patterns in empirical input data and then makes intelligent decisions based future empirical input data.
  • a “machine learning algorithm” is used to encompass an algorithm, such as a supervised and/or unsupervised machine learning, and/or statistical learning algorithm, that may be used to recognize complex patterns in empirical data input.
  • An analysis may comprise an inference engine.
  • An “Inference engine” is used broadly and generically herein to refer to an artificial intelligence (AI) computer program that attempts to derive answers from a knowledge base and a set of input parameters. This may also be referred to herein as "Expert System,” with the terms used interchangeably.
  • AI artificial intelligence
  • machine learning algorithms of interest include, but are not limited to, AODE; artificial neural network; backpropagation; Bayesian statistics; Naive Bayes classifier; Bayesian network; Bayesian knowledge base; Case -based reasoning; Decision trees; Inductive logic programming; Gaussian process regression; Learning Vector Quantization; Instance-based learning; Nearest Neighbor Algorithm; Analogical modeling; Probably approximately correct learning (PAC) learning; Symbolic machine learning algorithms; Subsymbolic machine learning algorithms; Support vector machines; Random Forests; Ensembles of classifiers; Regression analysis; Information fuzzy networks (IFN); Linear classifiers; Fisher's linear discriminant; Logistic regression; Quadratic classifiers; k-nearest neighbor; C4.5; Hidden Markov models; Data clustering; Expectation-maximization algorithm; Self-organizing maps; Radial basis function network; Vector Quantization; Generative topographic map; A priori algorithm; Eclat algorithm;
  • one or more machine learning algorithms may be obtained from a machine learning library, such as Apache Mahout.
  • the machine learning algorithm(s) may be modified or optimized so as to be run on multiple nodes simultaneously, such as on a cluster (e.g., a compute cluster or a cluster of nodes in a SACS implementation).
  • the machine learning algorithm(s) are optimized to be implemented on top of an Apache Hadoop implementation.
  • the machine learning algorithm(s) may be optimized to be implemented in a non-parallel environment, such as those provided by Weka, R, and the like.
  • a MICC system is not limited to just these approaches. In an embodiment the
  • MICC system is implemented in Java and designed to be extensible, allowing advanced users the ability to create the functionality they may require.
  • one machine learning algorithm is applied to data of a SACS and/or IDW.
  • 2 or more different machine learning algorithms may be applied, e.g., about 2 or more, including 3 or more, e.g., 4 or more, 5 or more, 6 or more, 7 or more, 8 or more, 9 or more, about 10 or more, such as about 10 to 20 or more, about 20 to 30 or more.
  • the output(s) or prediction(s) from the machine learning algorithms may themselves be fed in to one or more machine learning algorithms. Further, the outputs or predictions from a plurality of machine learning algorithms may be combined.
  • simple voting procedures may be used (e.g., consensus), while in other aspects individual predictions are giving varying weights.
  • FIGs. 7-8 show the processes of feature extraction, change detection, and machine learning by an analysis engine.
  • information from one or more sensors is collected as signal data by a SACS (not shown).
  • the analysis engine performs feature extraction to produce a feature series.
  • the analysis engine then performs change detection on the feature series to produce a change series.
  • this change series is used in one or more machine learning approaches by the analysis engine, combining data obtained from the IDW, to validate whether an alarm is valid.
  • FIG. 8 an analysis engine is shown where the IDW contains a computable phenotype. In this instance, the computable phenotype from the IDW is applied to the change series to detect a seizure in the subject.
  • a data store may be communicatively coupled to the analysis engine 18 (and optionally the SACS 12) and configured to store at least a portion of the signal data or associations between the signal data and the data associated with the user.
  • a data store may consist of one database (e.g., a relational database, distributed column-store, etc.). In other aspects, a data store may instead refer to two or more databases. Any convenient database and/or data structure may be used to store at least a portion of the signal data or associations between the signal data and the data associated with the user. Additional Components
  • a MICC may further include one or more additional components, such as various input/output devices, and the like.
  • a MICC may include a variety of network switches, firewalls, and servers.
  • Such servers may be, for instance, outbound messaging servers (e.g., running on Tomcat, GlassFish, etc.), web servers (e.g., dashboard web servers running on Tomcat); data ingestion/buffer servers (e.g., sFTP, servers running on Tomcat); job, analytic, and/or workflow management servers (e.g., Oozie, Hue, servers running on Tomcat); and the like.
  • SSC Support Server Cluster
  • a cluster of physical or virtual servers are managed as part of each subsystem. These servers provide the infrastructure for operating and managing MICC. This includes providing basic network services (e.g., FTP/web servers, firewalls and intrusion detection systems for enhancing network security, domain name servers, and routers) as well as providing more technical services. For example, web-based data visualization and interaction tools or connectors to the electronic medical record may be hosted within the SSC.
  • basic network services e.g., FTP/web servers, firewalls and intrusion detection systems for enhancing network security, domain name servers, and routers
  • web-based data visualization and interaction tools or connectors to the electronic medical record may be hosted within the SSC.
  • a "clinical dashboard” may be utilized by MICC, where information derived from clinical signal data can be combined with information derived from other clinical data to provide the clinician with a high-level view of the patient's clinical status. Details can be immediately available to the clinician through a "zoom” feature, but only if desired by the clinician. This allows the clinician to focus on the areas of interest without being distracted by large amounts of unnecessary or unrelated data.
  • the dashboard combines information and data from the various subsystems described above. Signal data are pulled from the SACS and visually combined with data from the IDW. Clinical data from the IDW are overlaid on top of the signal data as annotations that are coded by color and shape. This allows the user to easily interpret the signal data in the context of the patient's other data.
  • the dashboard can also be rearranged and group the signals such that the display can be customized to a particular patient, disease, or user.
  • the dashboard may be deployed as a server-based application with a thin client. This centralizes the security of the system and the only data actually sent to the client machines are a series of images. None of the actual patient data is ever sent directly to the client. This enables the use of mobile devices such as smart phones and tablets with negligibly increased security risk.
  • the dashboard can be implemented as a web application (e.g., Java and JavaScript-based, etc.) that is deployed within the Support Server Cluster.
  • the dashboard can be deployed as a tiered set of applications tailored to classes of client devices. For instance, high-end, dedicated workstations may have a rich feature set while more limited devices such as smartphones may have a more limited feature set.
  • FIGs. 9-14 Sample dashboard screens that may be rendered by the MICC as described herein are illustrated by FIGs. 9-14, respectively.
  • a MICC system may include a communications module so as to "push" information to a user.
  • a "user” is anyone or anything that uses the data/information generated by the MICC system, and/or from whom sensor data is collected (e.g., a subject, patient, etc.). This includes, but is not limited to, other software programs, systems, clinicians, patients, caregivers, family members, employers, payers, and hospital administrators.
  • information may be sent to a user using any number of communication protocols such as SMS/text message, email, Facebook message, automated phone call, alpha(numeric) page, and the like. Any of a variety of communications modules known in the art may be employed herein.
  • FIG 4. presents a non-limiting example a MICC implementation.
  • a plurality of sensors may collect information for each of a plurality of subjects.
  • the sensors may include, for example, those collected by a bedside monitor, by mobile sensors, and/or by home-based sensors. These sensors may be the same for all subjects, or may be different for different subjects. Additionally, certain or all subjects may also generate user generated data (e.g., in response to surveys and the like).
  • the sensor data and user generated data may be transmitted by wired and/or wireless transmission to a public and/or private cloud.
  • the cloud may then transmit the information to the particular MICC implementation.
  • User generated data is stored in the IDW, which also includes information obtained from existing databases (e.g., EHR, labs, and the like).
  • the IDW also stores computable phenotypes, and non-sensor data for the subjects.
  • the cloud transmits the sensor data to a database (e.g., as part of a SACS implementation).
  • Data from the sensor data and non-sensor data may be processed by a Data
  • the information may also be processed by a Feature Extraction Engine, which produces a feature series.
  • the feature series, sensor data, and other data from the IDW may be processed by a Rule/CEP engine.
  • a "Rule/CEP Engine” is an engine responsible for executing sets of "rules” that are part of the computable phenotype to trigger actions. These actions may include, but are not limited to, updating data in the IDW, updating the computable phenotype, or pushing information to a user through a dashboard or other communication medium. Accordingly, the Rule/CEP Engine may in certain aspects push an output (e.g., notification) to a user.
  • Complex Event Processing also referred to herein as “CEP” is used to refer to the processing of many events happening across all the layers of an organization or a plurality of organizations or entities, identifying the most meaningful events within the event cloud, analyzing their impact, and taking subsequent action in real time.
  • FIG. 5 presents a network diagram of a non- limiting example of a MICC implementation.
  • SACS includes a plurality of slave nodes ("Hadoop Slave N"), as well as a JobTracker and NameNode.
  • the SACS also includes a network switch.
  • the IDW in this implementation includes several databases (e.g., MongoDB, MonetDB).
  • Ontology mapping is provided with a HOM instance.
  • a network switch is used to facilitate communication among the components of the IDW.
  • the network switches of the SACS and of the IDW are in communication with a firewall and/or router.
  • the firewall/router is further in communication with a rule engine responsible for executing sets of rules to trigger actions (e.g., update the dashboard, update data in the IDW).
  • the firewall is also in communication with an outbound messaging server, and a dashboard, which comprises a dashboard web server, job/analy tic/workflow management server, and a data ingestion/buffer server.
  • the components of the MICC are further housed behind a firewall, which connects to the internet.
  • the internet may comprise a cloud (e.g., a public and/or private cloud), or the internet generally.
  • FIG. 6 presents an example workflow of how a MICC may be integrated and/or used within an existing infrastructure.
  • one MICC system may be implemented to serve a population (e.g., a physician practice, insurance group, and the like).
  • a plurality of MICC systems may be implemented. These systems may be identical or substantially identical.
  • the systems provided herein are designed to facilitate the discovery, clinical trial, and deployment of decision support technology based on clinical signal data. This may be achieved by, for instance, deploying multiple MICC systems.
  • each MICC system may contain data that is identical to the other system(s).
  • services developed within the Retrospective Research Cohort System can be promoted to the Clinical Study Subsystem for clinical trials; after successful trials, the same service can be promoted to the Decision Support Advisor Subsystem for deployment in the clinical setting.
  • the RRCS is a MICC implementation designed to conduct research and retrospective studies on the potential efficacy of MICC services for improved clinical decision support.
  • the RRCS is not a clinical operational system, but instead can be used to conduct informatics or clinical research on decision support; it provides a platform for the initial discovery of associations between signal data and the clinical phenotype. Retrospective studies conducted on the RRCS on MICC services that show promise for clinical improvement can then be promoted to other MICC subsystems as appropriate, following adequate funding and IRB approval.
  • the RRCS does not need to be housed on the same subnet as the other MICC subsystems.
  • the CSS is a clinical operational subsystem that enables the conduct of clinical trials on the safety and efficacy of MICC services. Upon published proof of safety and efficacy, MICC services can be introduced into regular clinical decision support. Decision Support Advisor System (DSAS)
  • the DSAS is a clinical operation subsystem. It is used to house robust MICC services on which proof of safety and efficacy have been provided following clinical trials.
  • the DSAS is used to alert users (e.g., a physician, caregiver, etc.) about potential problems detected by MICC regarding patient health. The alerts are also appended to the patient's chart and made available to researchers to be considered at patient treatment review boards.
  • the DSAS is not configured to govern any clinical treatment; in contrast, the DSAS is a "copiloting" system that alerts trained physicians about potential problems in patient health that may otherwise be very difficult to detect. The final decision about the proper treatment of the patient will remain the responsibility of the physician.
  • Clinical signal data is defined as raw waveform data as well as data from feature extraction algorithms performed at the point of data collection.
  • An example is the SEDline Patient Sleep Index, which is derived from the associated EEG waveforms.
  • CEP Complex event processing
  • Plug-ins that implement specific clinical use cases. Examples of such plug-ins include automated neonatal seizure detection, false arrhythmia detection, neuromonitoring for intraoperative nerve compression, sleep/sedation index, etc.
  • MICC is designed to be a platform on which plugins can be developed, tested, and deployed.
  • Plugins may be use-case centric. For example, a plugin may be developed for specific use cases on the RRCS, then moved through the CSS and DSAS for clinical trials and production deployment, respectively.
  • MICC provides an environment to facilitate clinical research rooted in the clinical signal data.
  • the end product of such research would be a plugin that can be deployed as a clinical decision support tool.
  • the MICC system is also designed to facilitate the clinical trial of a developed algorithm without any retooling of the plugin.
  • the plugin Once the plugin has been found to be safe and effective, it can then be deployed on a production instance of the MICC platform (the Decision Support Advisor System).
  • the components of the plugin include the algorithms with which to process the data, parameters of the algorithms, training data from machine or statistical learning algorithms, as well as rules to manage the application of the various algorithms or to provide expert system functionality.
  • the plugin also contains the components of the dashboard that provide the visualization layer for the plugin.
  • the plugin architecture allows for the deployment of a centralized MICC system and subsequent deployment of plugins in a modular manner enabling different sites the ability to purchase and deploy only those plugins that benefit their local patient population.
  • the next step may be to conduct informatics- driven clinical research to generate improved clinical phenotypes.
  • clinicians can take a data-driven approach to classifying patient clinical states or conditions.
  • An example of an improved clinical phenotype can be found when looking at blood pressure.
  • a patient's blood pressure can be hypertensive, hypotensive, or
  • MICC can be used to identify associations between patient physiology data and a complex assortment of patient data including all contents of the IDW with a full record of clinical EMR data, clinical lab data, biomarker data, procedure and risk adjusted diagnosis as well as information regarding the discharge disposition and patient encounter.
  • a computable phenotype is defined herein as a patient level concept instead of only a description of biochemical states. While complex associations of that sort are useful to researchers, tools that can assist researchers with the interpretation of those associations are desirable.
  • MICC includes an embedded agent-based modeling environment. The agent based modeling subsystem is used to discover and characterize multiple hypotheses that potentially can be used to explain the basis for associations found with the MICC in patient data.
  • the MICC can predict the likely future phenotype of a patient. These agent-based predictions are communicated back by the system as an additional means of predicting or determining the patient phenotype.
  • a process 100 of managing user data includes the stages shown.
  • the process 100 is, however, an example only and not limiting.
  • the process 100 can be altered, e.g., by having stages added, removed, rearranged, combined, and/or performed concurrently. Still other alterations to the process 100 as shown and described are possible.
  • signal data are collected from one or more sensors.
  • data associated with a user are stored.
  • respective ones of the signal data are associated with respective ones of the data associated with the user.
  • at stage 108 at least a portion of the signal data or associations between the signal data and the data associated with the user are stored at a data store.
  • a process is terminated when its operations are completed.
  • a process may correspond to a method, a function, a procedure, a subroutine, a subprogram, a program, etc.
  • a process corresponds to a function
  • its termination corresponds to a return of the function to the calling function or the main function.
  • embodiments may be implemented by hardware, software, firmware, middleware, microcode, or any combination thereof.
  • the program code or code segments to perform the necessary tasks may be stored in a machine-readable medium such as a storage medium or other storage(s).
  • a processor may perform the necessary tasks.
  • a code segment may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements.
  • a code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.
  • Systems of the present disclosure may include a plurality of SACS, IDWs, processors, and the like. Any convenient number of SACS, IDWs, processors, and the like are contemplated. For example, a system may include 2, 3, 4, 5, 6, 7, 8, 9, 10 or more IDWs.
  • a system may include 2, 3, 4, 5, 6, 7, 8, 9, 10 or more processors.
  • the system may be a distributed grid system.
  • a software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.
  • a storage medium may be coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor.
  • the subject methods and systems may be used to monitor, analyze, and/or treat a variety of subjects.
  • the subjects are "mammals” or “mammalian", where these terms are used broadly to describe organisms which are within the class mammalia, including the orders carnivore (e.g., dogs and cats), rodentia (e.g., mice, guinea pigs, and rats), and primates (e.g., humans, chimpanzees, and monkeys).
  • the subjects are humans.
  • the subject methods may be applied to human subjects of both genders and at any stage of development (i.e., fetal, neonates, infant, juvenile, adolescent, adult), where in certain embodiments the human subject is a juvenile, adolescent or adult. While the present invention may be applied to a human subject, it is to be understood that the subject methods may also be carried-out on other animal subjects (that is, in "non-human subjects”) such as, but not limited to, birds, mice, rats, dogs, cats, livestock and horses.
  • suitable subjects of this invention include those who have and those who have not previously been afflicted with a condition, those that have previously been determined to be at risk of suffering from a condition, and those who have been initially diagnosed or identified as being afflicted with or experiencing a condition.
  • a MICC may collect and/or analyze data from 2 or more subjects, including 10 or more, e.g., 3 or more, 5 or more, 10 or more, such as about 10 to 20 subjects, about 20 to 30 subjects, about 30 to 40 subjects, about 40 to 50 subjects, about 50 to 60 subjects, about 60 to 70 subjects, about 80 to 90 subjects, about 90 to 100 subjects, about 100 to 125 subjects, about 125 to 150 subjects, about 150 to 175 subjects, about 175 to 200 subjects, about 200 to 250 subjects, about 250 to 300 subjects, about 300 subjects, about 300 to 350 subjects, about 350 to 400 subjects, about 450 to 500 subjects, about 500 to 600 subjects, about 600 to 700 subjects, about 700 to 800 subjects, about 800 to 900 subjects, about 900 to 1000 subjects, about 1000 to 2000 subjects, about 2000 to 3000 subjects, about 3000 to 4000 subjects, about 4000 to 5000 subjects, about 5000 to 7500 subjects, about 7500 to 10,000 subjects
  • Subjects may be of the same general type (e.g., all rodents) or heterogeneous
  • all or a substantial fraction of subjects have one or more characteristics in common, such as age, geographic location, sex, common experience (e.g., former or current military service), and the like.
  • cardiovascular conditions including cardiovascular disease, e.g., atherosclerosis, coronary artery disease, hypertension, hyperlipidemia, eclampsia, pre-eclampsia, cardiomyopathy, volume retention, congestive heart failure, QT interval prolongation, aortic dissection, aortic aneurysm, arterial aneurysm, arterial vasospasm, myocardial infarction, reperfusion syndrome, ischemia, sudden adult death syndrome, arrhythmia, fatal arrythmias, coronary syndromes, coronary vasospasm, sick sinus syndrome, bradycardia, tachycardia, thromboembolic disease, deep vein thrombosis, coagulopathy, disseminated intravascular coagulation ("DIC"), mesenteric ischemia, syncope, venous thrombo
  • cardiovascular disease e.g., atherosclerosis, coronary artery disease, hypertension, hyperlipidemia, eclampsia, pre
  • neurodegenerative conditions including neurodegenerative diseases, e.g., Alzheimer's Disease, Pick's Disease, Parkinson's Disease, dementia, delirium, amyotrophic lateral sclerosis, and the like;
  • neuroinflammatory conditions including neuroinflammatory diseases, e.g., viral meningitis, viral encephalitis, fungal meningitis, fungal encephalitis, multiple sclerosis, Charcot joint, schizophrenia, myasthenia gravis, and the like; orthopedic inflammatory conditions including orthopedic inflammatory diseases, e.g., osteoarthritis, inflammatory arthritis, regional idiopathic osteoporosis, reflex sympathetic dystrophy, Paget' s disease, osteoporosis, antigen- induced arthritis, juvenile chronic arthritis, and the like; lymphoproliferative conditions including lymphoproliferative diseases, e.g., lymphoma, lymphoproliferative disease, Hodgkin's disease, inflammatory pseudomotor of the liver, and the like; autoimmune conditions including automimmune diseases, e.g., Graves disease, Raynaud's, Hashimoto's, Takayasu's disease, Kawasaki's diseases, arteritis, scleroderma, CR
  • OB-GYN conditions including OB-GYN diseases, e.g., amniotic fluid embolism, menopausal mood disorders, premenstrual mood disorders, pregnancy-related arrhythmias, fetal stress syndrome, fetal hypoxia, amniotic fluid embolism, gestational diabetes, pre-term labor, cervical incompetence, fetal distress, peri- partum maternal mortality, peripartum cardiomyopathy, labor complications, premenstrual syndrome, dysmenorrhea, endometriosis, fertility and subfertility conditions such as infertility, early pregnancy loss, spontaneous abortion, failure of implantation, amenorrhea, luteal insufficiency, and the like; sudden death syndromes, e.g., sudden adult death syndrome, and the like; menstrual related disorders,
  • cardiomyopathy and the like; fibrosis; post-operative recovery conditions such as post-operative pain, post operative ileus, post-operative fever, post-operative nausea, and the like; post- procedural recovery conditions such as post- procedural pain, post procedural ileus, post- procedural fever, post-procedural nausea, and the like; chronic pain; trauma; hospitalization; glaucoma; disorders of thermoregulation; fibromyalgia; and the like.
  • Non-limiting exemplary embodiments of the present disclosure are provided as follows:
  • a medical informatics system that implements a medical informatics compute cluster (MICC), the system comprising:
  • a Signal Archiving and Computation System comprising a processor programmed to collect signal data from one or more body sensors;
  • IDW Integrated Data Warehouse
  • an analysis engine communicatively coupled to the SACS and the IDW and comprising a processor programmed to associate respective ones of the signal data with respective ones of the data associated with the user;
  • a data store communicatively coupled to the analysis engine and configured to store at least a portion of the signal data, the data associated with the user, or associations between the signal data and the data associated with the user.
  • SSC Support Server Cluster
  • the system of 4 wherein the SSC is further configured to secure at least a portion of the data associated with the user, the signal data or the data stored by the data store.
  • the system of any of 1-5 further comprising a dashboard module communicatively coupled to at least one of the data store, the SACS, or the IDW and configured to render a visual representation of at least a portion of data stored in the MICC for display.
  • the system of 6 wherein the dashboard module is further configured to obtain the visual representation from a remote entity such that no data stored by the MICC are sent to the dashboard module.
  • the system of 6 further comprising a module configured to display alerts to the dashboard module indicative of detection of a computable phenotype.
  • a phenotype generation module communicatively coupled to the data store and comprising instructions that, when executed by a processor, generate at least one phenotype based on data stored by the MICC.
  • the system of 9 wherein the phenotype generation module is further configured to generate the at least one phenotype via machine learning.
  • the system of 9 further comprising a complex event processing module
  • the phenotype comprises one or more rules and the system further comprises a plugin communicatively coupled to the phenotype generation module and configured to initiate at least one action according to the one or more rules.
  • the system is configured to continuously process and analyze incoming signal data by applying components of the plugin to detect rich phenotypes.
  • the system of any of 1-15 wherein the SACS collects signal data from ten or more body sensors.
  • the system of any of 1-16 wherein the SACS collects signal data from 50 or more body sensors.
  • the system of any of 1-17 wherein the one or more body sensors measure at least one of temperature, blood pressure, pulse, respiratory rate, oxygen saturation, and end tidal C0 2 .
  • the system of any of 1-18 wherein the one or more body sensors measure at least two of temperature, blood pressure, pulse, respiratory rate, oxygen saturation, and end tidal C0 2 .
  • the system of any of 1-19 wherein at least one body sensor comprises an EEG or MEG sensor.
  • the system of 20 or 21, wherein at least one body sensor comprises a plurality of EEG sensors
  • the system of any of 1-24, wherein at least one body sensor measures the user's blood glucose.
  • the system of 10, wherein the generation of the phenotype comprises application of a supervised machine learning algorithm.
  • the system of 36 wherein the generation of the phenotype comprises application of at least one of AODE; artificial neural network; backpropagation; Bayesian statistics; Naive Bayes classifier; Bayesian network; Bayesian knowledge base; Case-based reasoning; Decision trees; Inductive logic programming; Gaussian process regression; Learning Vector Quantization; Instance-based learning; Nearest Neighbor Algorithm; Analogical modeling; Probably approximately correct learning (PAC) learning;
  • a system comprising:
  • a dashboard module comprising a processor programmed to display data associated with an informatics system
  • a display module communicatively coupled to the dashboard module, the display module configured to display alerts to the dashboard module indicating detection of a computable phenotype associated with the informatics system.
  • the informatics system comprises a Signal Archiving and Computation System (SACS) comprising a processor programmed to collect signal data from one or more body sensors; and an Integrated Data Warehouse (IDW) comprising memory comprising data associated with a user.
  • SACS Signal Archiving and Computation System
  • IDW Integrated Data Warehouse
  • the informatics system comprises a Support Server Cluster (SSC) comprising a processor programmed to provide network services for at least one of the SACS or the IDW.
  • SSC Support Server Cluster
  • the dashboard module is further configured to obtain the visual representation from a remote entity such that no data stored by the informatics system are sent to the dashboard module.
  • a data store module comprising a database and a processor programmed to collect and store incoming signal data in the database
  • a plugin operably coupled to the data store module comprising instructions for processing signal data, wherein the instructions, when executed by the processor of the data store module, cause the processor to process at least part of the incoming signal data;
  • a module configured to the data store module and the plugin and configured to continuously process and analyze the incoming signal data by applying components of the plugin to detect computable phenotypes.
  • the system of 46 wherein the incoming signal data comprises data from two or more body sensors.
  • the system of 46 or 47 wherein the incoming signal data comprises data from four or more body sensors.
  • the system of any of 46-48 wherein the incoming signal data comprises data from ten or more body sensors.
  • the system of any of 46-50 wherein at least one body sensor measures at least two of temperature, blood pressure, pulse, respiratory rate, oxygen saturation, and end tidal C0 2 .
  • a computer system the system comprising:
  • memory operably coupled to the processor, wherein the memory includes instructions stored therein for generating a clinical phenotype for a subject, wherein the instructions, when executed by the processor, cause the processor to:
  • a computer-readable medium having computer-executable instructions stored thereon to generate a computable phenotype for a subject, wherein the instructions, when executed by one or more processors of a computer, causes the one or more processors to:
  • a system for managing medical data comprising:
  • a system for managing medical data comprising:
  • a method of managing data via a medical informatics compute cluster comprising:
  • the method of 61 further comprising securing at least a portion of the data associated with the user, the signal data or the data stored by the data store.
  • the method of 62 further comprising rendering a visual representation of at least a portion of data stored by the data store for display.
  • the method of 63 further comprising obtaining the visual representation from a remote entity such that no data stored by the data store are processed at an entity that performs the rendering.
  • the method of 61 further comprising generating at least one phenotype based on data stored by the MICC.
  • the method of 61 further comprising generating decision support information based at least in part on the at least one phenotype and the data stored by the data store.
  • the method of any of 61-66 wherein the signal data is collected and stored from two or more body sensors.
  • the method of any of 61-67 wherein the signal data is collected and stored from four or more body sensors.
  • the method of any of 61-68 wherein the signal data is collected and stored from ten or more body sensors.
  • the method of any of 61-69, wherein the one or more body sensors measure at least one of temperature, blood pressure, pulse, respiratory rate, oxygen saturation, and end tidal C0 2 .
  • a method of producing a computable phenotype comprising:
  • a method of detecting the occurrence of an event in a user comprising: collecting, with a processor, signal data from one or more body sensors;
  • EXAMPLE 1 DESIGN AND IMPLEMENTATION OF A SIGNAL ARCHIVING AND COMPUTATION SYSTEM
  • Described herein is a non- limiting example implementation of a Signal Archiving and Computation System. Components of this particular implementation of a SACS are first described, followed by a description of the system. The SACS described here is used in the MICC implementations used in the Examples that follow.
  • MIMICII dataset was utilized as the dataset to test this implementation of a SACS.
  • the MIMICII dataset is described in Saeed, et al. 2002. Computers in Cardiology 29 (September): 641-644; the disclosure of which is incorporated herein by reference.
  • the subset that was utilized consists of waveform data with a recorded sampling frequency of 125 Hz, and numeric time-series data sampled at 1 minute intervals. This data was collected from nearly 500 patient-records, totaling approximately 45,000 hours of waveform data. Other clinical data, such as the laboratory, pharmacy, and nursing databases, are also available and time-correlated with the signal data. All of the data have been de-identified. MapReduce
  • Map and Reduce may be utilized for parallelizing computation.
  • One benefit of the MapReduce approach is the ability to focus solely on the computation, and not the shuffling of data between processors.
  • a second benefit of MapReduce is in data-locality. With the MapReduce paradigm, most of the computation is done on the slave node that contains a copy of the input data. This results in a minimal amount of data being sent over the network, increasing overall efficiency.
  • each "job” that needs to be run is split into two separate tasks - a map task and a reduce task.
  • the map task is a user-defined function and handles the initial "mapping" of the input data, taking a ⁇ keyl, value 1> pair as input and outputting an intermediate ⁇ key2, value2> pair. Oftentimes, the map task maps multiple different values to the same key.
  • the reduce task is also user-defined and takes the intermediate ⁇ key2, value2> pairs and merges all of the values that correspond to the same key.
  • One example of a reduce task is to take the running sum or mean of values with the same key.
  • Hadoop is an open-source implementation of the MapReduce parallel programming paradigm. Hadoop provides both a distributed file system (called HDFS) as well as the MapReduce parallel computation framework. Data are stored in the HDFS and made available to the various slave nodes for computation. Hadoop is an Apache Foundation project and is written in Java though hooks are in place to facilitate the deployment of code written in other languages such as C or Python. Hadoop is a master-slave architecture where a single master node coordinates many slave machines which carry out the actual computation.
  • HDFS distributed file system
  • MapReduce parallel computation framework Data are stored in the HDFS and made available to the various slave nodes for computation.
  • Apache Foundation project is written in Java though hooks are in place to facilitate the deployment of code written in other languages such as C or Python.
  • Hadoop is a master-slave architecture where a single master node coordinates many slave machines which carry out the actual computation.
  • each slave machine prioritizes computations on data of which it has a copy. This minimizes the shuffling of data over the network, decreasing the necessary network IO bandwidth. Additional nodes can be added to the cluster to increase storage capacity or computational power as necessary, during which the data are automatically rebalanced to the new nodes. Hadoop has been used in clusters ranging from a handful of nodes to thousands of nodes (e.g., 4,000 or more), demonstrating its ability to scale as needed.
  • HBase is a distributed column-store that runs on top of the Hadoop system. As a result, it depends on the distributed file system as well as the MapReduce framework. HBase provides a storage system where the full power of the MapReduce paradigm is available while also providing convenient, lower latency, random-access to the data. There are other possible alternatives within the Hadoop project that may serve a similar purpose in a SACS, such as Pig and Hive.
  • HBase's approach to tables, rows, and columns is different than in traditional relational databases.
  • each row is identified by a sortable row key.
  • Each row can contain an arbitrary number of columns resulting in the sparse storage of tables.
  • the columns are identified by a combination of "column family" and "label.”
  • the column family is important during schema design because data are stored in a per-column family basis. When a value is written to the database, it is stored with its row key, column family and label identifiers along with other internal data. This results in substantial storage overhead if the identifiers are large in size.
  • MongoDB is a document-store database and also has an integrated MapReduce computational framework. It is also a "NoSQL" database and is designed to be deployed in a clustered environment.
  • FIG. 2 presents an overview of the primary components of this implementation of a SACS.
  • the primary components involve: 1) data storage, 2) metadata storage, 3) MapReduce, and 4) data visualization.
  • These are implemented in this particular, non- limiting example of a SACS using: 1) HBase, 2) MongoDB, 3) Hadoop, and 4) Chronoscope with the Google Web Toolkit, respectively.
  • the signal data are stored in HBase, while the signal metadata and other clinical data are stored in MongoDB.
  • Data in HBase and MongoDB are accessible from the Hadoop/MapReduce environment for processing as well as from the data visualization layer.
  • the hardware comprises 1 master node, 6 slave nodes, and several supporting servers.
  • hardware was provided via a cloud environment, namely the Amazon EC2 cloud environment.
  • each row key was the timestamp of a signal's value at a particular point in time. This timestamp was recorded as an 8-byte value of the number of milliseconds from the epoch (January 1, 1970 00:00:00.000).
  • each column contained the value of a particular signal for a particular patient corresponding to the row key timestamp. For example, each of the following would be stored in a separate column in a hypothetical use case: (i) arterial blood pressure values for patient A, (ii) arterial blood pressure values for patient B, and (iii) ECG Lead I values for patient A.
  • the columns can also contain the values resulting from different feature extraction algorithms. For example, one particular feature extraction algorithm extracts the beat- to-beat systolic pressures from an arterial blood pressure waveform. In this case, the column contains the systolic pressure value at a particular timestamp for a particular patient.
  • Each value is stored along with its row key and column identifier. As a result, there is a noticeable increase in storage overhead. To mitigate this, the identifiers were stored in binary form. Because the row key identifiers are numeric values representing the number of milliseconds from the epoch, they are stored as standard 8-byte binary data.
  • the column identifiers are a combination of a patient identifier as well as a signal identifier. Currently, the number of patients has been limited to a 2-byte value and the signal identifier to a 4-byte value. These values, however, are easily changed should the underlying dataset require it.
  • MongoDB may be replaced with any convenient database (e.g., any standard relational database) while preserving functionality.
  • This database contained all of the patient demographic information, patient clinical data (e.g. data from other clinical databases) as well as the mappings to the column identifiers used in HBase.
  • each slave machine is computing its own rolling mean of the subset of data it has a copy of, independent of any of the other slave machines.
  • One general solution is to force each map task to process an entire patient record. This, however, negates the data locality benefit since a single slave machine will be requesting data stored on other slave machines.
  • splits of the data.
  • the splits can be made such that there is adequate overlap between one map task and the next. While this results in some additional shuffling of data over the network, the majority of the computation is still data-local.
  • the visualization layer was built using the
  • Google Web Toolkit along with Chronoscope (a charting tool) from Timepedia.
  • a user may specify which signals they want to plot, both raw signals as well as derived signals from feature extraction algorithms, along with the time period of interest.
  • the visualization tool has direct access to the MongoDB instance in order to properly map the binary identifiers to their human-readable counterparts.
  • This data visualization system has the ability to overlay annotations on top of the signal data, allowing for the display of pertinent events from the patient's clinical history over the signal data time (FIGs. 11-16).
  • Sliding Window Central Tendency Measure (CTM) calculations were first run within the Matlab environment to take advantage of both its processing and visualization capabilities. However, the Sliding Window CTM was very slow when run via Matlab. To take advantage of the Hadoop MapReduce environment, the data was imported into Hadoop and processed via MapReduce. In order to visualize the data, it first needed to be exported from Hadoop and imported into Matlab for plotting. Because many different window sizes were tested, both of these approaches were tedious and time-consuming.
  • the SACS implementation addressed both of these issues by providing an environment that can efficiently process the data while making it immediately available for viewing. This allowed for experimenting with various parameters of the Sliding Window CTM in a fraction of the time otherwise.
  • EXAMPLE 2 AUTOMATED ARRHYTHMIA DETECTION USING A MEDICAL INFORMATICS COMPUTE CLUSTER
  • Clinical alarms represent one of the primary means that clinicians use to monitor the status of their patients. These alarms are critical to ensuring a workflow that allows clinicians to care for more than one patient. These alarms are based on physiological sensors such as an electrocardiogram (ECG/EKG), blood pressure, or intracranial pressure. These physiological sensors offer one of few truly objective windows into a patient's clinical status or condition.
  • ECG/EKG electrocardiogram
  • blood pressure blood pressure
  • intracranial pressure intracranial pressure
  • any physiological signal can be described as a set of key-value pairs where the key is a timestamp and the value is the measurement.
  • This measurement can be a voltage, concentration, or any other recording by a sensor.
  • MICC was designed to enable any workflow, including as a three-stage computational pipeline addressing these and other issues associated with storing, analyzing, and/or mining physiological signal data.
  • the primary stages of this pipeline involve (i) feature extraction; (ii) change detection; and (iii) machine learning.
  • the result is a computational framework in which any clinical condition can be described as a set of changes of extracted features of a set of physiological signals.
  • Feature extraction is typically used to refer to a specific form of dimensionality reduction: the transformation of data into a smaller set of features that can accurately describe the original data.
  • feature extraction is a data processing algorithm that is being applied to highlight a particular characteristic of the underlying data.
  • the CTM algorithm only provides a single piece of information from an entire input dataset: the percentage of points within a certain radius. While this has been used with some success in medicine, it would not work in MICC since a change series is required, in which specific change points can be detected. Thus, the CTM algorithm was adapted to use a sliding window, and the output was changed to instead give the radius which contains N-percentage of the points, where N is a user-defined parameter.
  • FFT Fast Fourier Transform
  • the Fourier transform was applied on top of a sliding window, as in short- time Fourier transforms.
  • the Fourier transform was further distilled down to produce a time series in which change points can be detected. This is achieved by calculating the power spectral density and taking the root-sum-square of the PSD, giving a one-dimensional time series that is representative of the underlying frequency components of the signal. Change (Point) Detection
  • Each of the feature extraction algorithms effectively creates a new time-series data stream.
  • change detection algorithms are applied to detect any change points.
  • change detection algorithms perform differently depending on characteristics of the underlying data, parameter choices, thresholds, etc.
  • a difference-of- means algorithm was incorporated into the computational pipeline describe here.
  • MICC may describe changes in a patient' s clinical status or condition in terms of a set of detected changes in physiological signals.
  • sliding windows are again used to aid in the machine learning phase. After the application of a sliding window to the change points, a combination of supervised and unsupervised methods was used to examine the data.
  • Israel Deaconess Medical Center from Philips bedside monitors.
  • the exact type and number of sensors varies from patient to patient due to differences in the underlying clinical condition and treatment protocol. However, most of the patient records contain at least one EKG signal and the arterial blood pressure.
  • ventricular fibrillation subset there are 143 patient records that have been imported into MICC. Each of these contains at least one V-Fib alarm (as determined by the Philips EKG built- in algorithms). This dataset was reduced to 138 patient records to include those that have lead II of the EKG, so as to simplify the application of the computational pipeline to the EKG waveform data. The data were recorded at 125 Hz despite higher sampling rates in some cases such as the EKG.
  • the bottommost plot shows three variants of the Sliding Window PSD algorithm with varying parameters - the red plot has a window size of 1024 points (roughly 8 seconds) and a skip size of 500 points (4 seconds); the blue plot has a window size of 1024 points and a skip size of 125 points (1 second); the brown plot has a window size of 512 points (roughly 4 seconds) and a skip size of 128 points (roughly 1 second); all have a period of 0.008 sec (125 Hz) which is period of the recorded samples.
  • the top plot is zoomed out on the Y-axes (measured in volts) where the signal ranges from 0 to 50 V. However, if we move forward in time 20 seconds, we see that the EKG typically reads between -300 and 300 mV.
  • the R-wave detection algorithm depends on the maximum value seen and is unable to detect any R-waves due to the abnormally high initial values. This issue is somewhat mitigated by the splitting mechanism inherent in the parallel mapreduce paradigm.
  • FIGs. 19-20 A cluster was identified (cluster 0, FIG. 19) as warranting further interest. The identified cluster is subsequently reviewed with a clinician to help identify condition(s) that were present at the time of the event.
  • EXAMPLE 3 PROCESSING DATA FROM EXISTING DATABASES FOR INCLUSION IN MICC
  • FIG. 4 depicts a flowchart of an example MICC system.
  • data contained in existing databases e.g., non-signal data
  • IDW the IDW
  • Data contained in existing databases may be in a variety of forms. Accordingly, this data may need to be converted into a normalized format prior to aggregation in MICC, so that data from multiple sources may be combined and analyzed. Such normalization may be achieved using an ontology mapping engine.
  • the particular ontology mapping engine is the Health Ontology Mapper (HOM).
  • HOM leverages a single terminology server to allow multiple hospitals or other health care providers to translate clinical information by leveraging the same definitions of clinical terminology, the same data dictionaries representing source clinical software environments and the same set of instance maps used to translate clinical information into standard clinical terminology.
  • Each instance of HOM connects to the terminology server using an API (Application Program Interface) based on BioPortal REST services. These REST services have been extended to support HOM queries for clinical instance data maps. HOM can query these services in a dynamic fashion allowing the application of instance maps to clinical data to occur after the data has already been loaded into a warehouse.
  • API Application Program Interface
  • HOM facilitates the loading of clinical data into a warehouse to enable further analysis.
  • HOM alleviates the need to translate clinical information statically and no longer requires the employment of IT development staff to translate clinical data during the warehouse loading process.
  • Traditional warehouse data loading is called ETL (Extract Transform Load) processing whereas HOM uses ELT (Extract Load Transform) processing using a set of tag handler components called HOM UETL (Universal ETL).
  • the HOM UETL process generates two sets of files. First it generates bulk import files for loading the warehouse. These bulk import files are a native database format supported by all database vendors and UETL currently supports the bulk import file formats of Oracle, Sybase IQ, MonetDB, InfiniDB and SQL Server. Bulk import files are the fastest possible means of importing data into a warehouse. Data loaded into the warehouse in this manner is unmodified and is stored within the warehouse in the same format as it was read from the data source.
  • the second set of files generated by UETL is the concept dimension files. These concept dimension files encode the location of the data within the data source as a simple hierarchical list of parent child terms relating the name of the source, the name of the table and the name of the source column from which the data was read.
  • both a concept path for the data warehouse and an URI can be constructed for the NCBO BioPortal.
  • Concept dimension files are generated in bulk import format and can therefore be directly loaded into the data warehouse to provide a complete concept ID for each of the facts stored.
  • the concept dimension files are then also loaded into Protege Mapping Master, a program used to load information into NCBO BioPortal and to translate hierarchical terms into OWL (Object Web Language) format.
  • OWL Object Web Language
  • HOM also includes a feature called HOM ViewCreator that provides the capability to make the results of mapped data more easily accessible by researchers.
  • the ViewCreator can allow access to mapped data, using JDBC, from within Microsoft Excel or biostatistics packages such as SAS, ST ATA, SPSS and R.
  • ViewCreator based views can also be used to build downstream databases or to load information into data mining tools such as Cognos or Business Objects.
  • the UETL data loading process also includes methods for the removal of PHI
  • ProxyGen Service that replaces PHI with proxy identifiers.
  • HIPAA protected patient identifiers with proxy IDs. For example, proxy identifiers replace the patient' s name, the name of his physician, and the patient' s social security number during the data loading process. Further, if the same HIPAA protected source information is encountered from any subsequent data source the same proxy identifiers are returned. This allows the data warehouse to link patient data without any need to store the PHI within the warehouse. By using this technique it is possible to build a warehouse that is a HIPAA Limited Data set that contains only limited dates of service and which has a HIPAA de-identified user interface. By supporting the ProxyGen feature HOM can greatly lower the potential legal liability of using patient data for research or other purposes such as quality improvement.
  • the ProxyGen service also provides the ability to de-identify any downstream database that is connected to the data warehouse. This is provided via a set of REST services (a web based application program interface) that can be called by any database that extracts information from the warehouse.
  • the ProxyGen REST services allow PHI to be submitted from downstream databases as well as from UETL loaded source databases. Downstream databases can send PHI to the ProxyGen service and if the same PHI data are submitted the same proxy values will again be returned as those used previously during the UETL loading process.
  • ProxyGen not only scrubs PHI from any incoming clinical data source but it can also remove PHI from any downstream database that is connected to the data warehouse as well.
  • the ProxyGen REST services eliminate the need to retain PHI within any warehouse or warehouse-connected database, as PHI is no longer required for record linkage.
  • a report can be created that allows investigators to contact patients.
  • Investigators may supply of a list of proxy ID's for patients that they are interested in. If IRB (Institutional Review Board) approval to contact those patients has been provided then by accessing the ProxyDB a listing of patient contact information for those patients can be provided. This is possible because the ProxyDB contains an association between the proxy ID's and each patient's PHI. Unstructured text handling during load
  • the HOM UETL component also optionally contains an embedded copy of the
  • NCBO Annotator service for annotating unstructured text.
  • Annotator clinical findings extracted from source clinical environments can be annotated with BioPortal medical terminologies such as SNOMED/CT.
  • the annotator feature supports named entity recognition and negation.
  • Annotator is not a fully featured NLP (natural language processing) environment but instead is packaged as an automated annotation component used internally by HOM and only during the data loading process.
  • HOM runs Annotator on incoming full-text (unstructured) data it first identifies a set of BioPortal URI' s for portions of medical
  • HOM selects multiple URI' s to be annotated for topic areas of interest so that the same unstructured data can be interpreted within multiple contexts. For example if HOM uses Annotator to select terms of interest in Cardiology, Orthopedic Surgery, and Pediatrics then annotations would be subsequently generated on the same unstructured text multiple times, once for each of those 3 domains. In this manner HOM UETL can select specific types of unstructured clinical findings and annotate those findings for usage within multiple domains of interest.
  • BioPortal can then be used to dynamically translate warehoused information by traversing maps defined on BioPortal. These maps translate information from source data format into standard medical terminologies. For example, the local hospital discharge data stored within both GE UCare as well as within EPIC can be translated into the same HL7 Discharge Disposition format. Subsequent maps that utilize discharge disposition can then reference the standard HL7 Discharge format. After a map has run the same data exists within the warehouse in both its raw untranslated form and in one or more translated standard medical terminologies. Additional mappings of the same source data can then be added at any time in the future without any need to reload the source data.
  • maps defined on BioPortal These maps translate information from source data format into standard medical terminologies. For example, the local hospital discharge data stored within both GE UCare as well as within EPIC can be translated into the same HL7 Discharge Disposition format. Subsequent maps that utilize discharge disposition can then reference the standard HL7 Discharge format. After a map has run the same data exists within the warehouse in
  • the HOM Interpreter dynamically translates local clinical instance data by communicating with the BioPortal REST services API (application program interface). This translation into standard ontologies happens when requested by the researcher and after the data has already been loaded into the warehouse.
  • the instance maps stored on BioPortal can define three difference classes of clinical instance data maps, including 1-to-l maps; many-to-1 maps; and automatic maps (many- to-many).
  • the HOM 1-to-l maps will translate a single term within the value set of the source data system into a single term for the value set of the target medical terminology.
  • the HOM many-to- 1 maps will look for the presence of multiple value set terms from the source data and translate that information into a single target terminology term.
  • These 1-to-l and many-to- 1 maps are defined using Protege and the BioPortal web interface.
  • Automatic maps allow a terminologist to check-in algorithms that execute on source data to determine the target terms. Examples of these "auto maps” include the normalization of clinical lab data into bins of "Low”, “Low-Normal”, “Normal”, “High-Normal” and “High”. Automatic maps can also include calls to third party terminology servers such as RxNav and may contain biostatistical programs or calls to machine learning libraries.
  • a subject is provided with a series of sensors for continuous recording of physiological parameters.
  • the sensors include (i) an accelerometer, (ii) pulse oximeter, (iii) a head-mounted sensor array comprising a plurality of dry EEG sensors, and (iv) an EKG sensor.
  • Each sensor transmits the data it receives from the user via a built-in Bluetooth module to the user's smartphone.
  • the user's smartphone runs a custom software application that receives this sensor data, establishes a connection to a MICC, and uploads the sensor data to the MICC.
  • the custom software application presents a login screen to the user where they can login to their account over a secure (e.g. SSL) connection.
  • SSL secure
  • the user can remove this public key from their account to disable access by the smartphone in situations such as a lost smartphone.
  • This public/private key pair is used by the SSH protocol to establish secure access to the data ingestion server via the sFTP protocol.
  • the custom software application can send buffer files of the sensor data and any tags or annotations to the server. The transmission can occur at any interval, which, in this case, is every minute.
  • the custom software application uses the sFTP protocol to ensure successful transmission of the file(s). In situations where there is no or poor wireless (e.g. cellular, wifi, etc.) connection quality, the custom software application will automatically reattempt transmission when a suitable wireless connection is reestablished.
  • the file(s) are successfully transmitted to the data ingestion server, the file(s) are parsed by a server-side daemon that monitors for new files. This daemon will extract the sensor and non-sensor data as well as associated timestamps and store them within the MICC system.
  • the MICC records that sensor data for the user and aggregates the sensor data with the non-sensor data it has stored for that user.
  • Non-sensor data that is stored for the user includes the user' s calendar, location data, and annotations that are entered by the user in response to questions posed to him by the application (e.g., "What did you eat for dinner?" or "How many guests did you have dinner with?”)
  • the readings are used to compare the user to a model of a tired state, or an intoxicated state.
  • these models are produced as follows. First, a group of healthy volunteers is recruited for participation in a drowsiness study. Each volunteer is provided with (i) an accelerometer; (ii) pulse oximeter, (iii) a head-mounted sensor array comprising a plurality of dry EEG sensors, and (iv) a EKG sensor. The user is then asked to perform a motor task. The user is kept awake, and is subsequently asked to perform that identical motor task each hour for 18 consecutive hours. A drowsy state is determined as a performance decrease of about 10% over the initial control. The sensor data is collected and aggregated with the available non- sensor data in a MICC. Feature extraction algorithms are run on the data for all patients. A plurality of machine learning algorithms is run on the data set. The resulting models are used as definitions as drowsy a state. These models are stored within MICC and are continually applied to new, incoming data.
  • an alarm is automatically triggered to notify one or more user-defined persons.
  • the alarm is sent automatically by MICC, via SMS, e-mail, to a display, or other user- defined output device.
  • a networked (e.g., Bluetooth) blood glucose monitor is provided with individual juvenile subjects.
  • the monitor is configured to communicate with a MICC upon the completion of a blood glucose reading.
  • MICC keeps track of the time elapsed since the last reading was recorded. An alarm is triggered if either of two conditions is present: (i) the time since the last reading was received exceeds a user-defined threshold, or (ii) the time since the last reading was received exceeds a patient- specific threshold modeled based off of the patient's glucose reading history.
  • a message is sent via MICC to the user(s) specified in that subject's MICC record.
  • the manner in which the message is sent is user-defined, and selectable from SMS, e-mail, and other communication means.
  • a user-configurable option is to also, or instead, be notified each time a reading has been taken, as well as the value of that reading.
  • MICC also stores the value of each reading taken by the subject. Recorded values are compared with the subject's prior readings to determine activity level trending. If the value change exceeds a MICC-learned threshold, an alarm is sent via MICC to the user(s) specified in that subject's MICC record. In such instances, the default setting is to notify the parent(s) of the juvenile, as well as the health care provider at his or her school, if the reading was taken during school hours.
  • MICC In addition to the sensor data described above, MICC also aggregates the sensor data with non-sensor data, such as the subject's recorded diet and activity information.
  • Non- sensor information includes the subject's calendar information.
  • the calendar information is annotated by a parent to identify potentially hazardous events (e.g., a soccer practice), and MICC can trigger an alarm based on the non-existence of sensor data within a given time of that event.
  • potentially dangerous activity is automatically detected by the system based upon the aggregate of the information. For example, MICC detects in a user that in prior cases where the subject had a blood glucose range comparable to his most recent recording, and failed to have a meal within 90m of his scheduled soccer practice, he suffered a hypoglycemic episode. Alerts are automatically sent to one or more individual(s) where potentially dangerous activity is detected a priori.
  • MICC keeps track of the subject's movement over a given period.
  • the period is user-definable, with a default being a 24 hour period.
  • the amount of movement is compared with the subject's prior recordings, and decreases in a day's recorded movement are reported via an alarm to a user-defined caregiver.
  • MICC automatically triggers an alarm when movement is not detected for a given interval at a time of day in which the user is normally active. For example, if the user's prior history indicates that she does not spend greater than 2 hours sedentary, an alarm may be triggered automatically by MICC when that time without movement is exceeded. In this aspect, MICC may automatically serve to alert others of an adverse event, such as a fall that has prevented the subject from moving or calling for help.
  • MICC compares the mobility of that user to those of other users of comparable age and/or overall health. Decreases in a user' s mobility relative to this population are flagged and an alarm is triggered. The precise alarm that is triggered depends upon the severity of the change. The thresholds for what constitutes a severe or minor change are user- definable, as are the person(s) who receive the alarm for each classification.
  • a patient is provided with a pulse oximeter for home-based use by the physician.
  • the sensor is configured to communicate via wireless protocol (e.g., Bluetooth) with the user's smartphone.
  • the smartphone uploads the sensor data from the pulse oximeter to the physician' s MICC.
  • a custom application on the smartphone also asks the patient to rate the quality of the previous night's sleep and sends this information to the MICC.
  • the MICC aggregates the sensor data obtained for a given patient with all non- sensor data available for that patient. The resulting data is then compared to a local model of sleep apnea for diagnosis.
  • EXAMPLE 8 SLEEP APNEA INTERVENTION OUTCOMES MEASUREMENT IN A PHYSICIAN PRACTICE
  • each patient is provided with a pulse oximeter for home-based use.
  • the sensor is configured to communicate via Bluetooth with the user's smartphone.
  • the smartphone uploads the sensor data from the pulse oximeter to the physician practice's MICC.
  • a custom application on the smartphone also asks the patient to rate the quality of the previous night' s sleep and sends this information to the MICC.
  • the MICC aggregates the sensor data obtained for a given patient with all non- sensor data available for that patient. This procedure is simultaneously completed for all other patients being treated in the practice for the same condition. The resulting data is then queried and processed by managers of the practice to gain insights into which treatment(s) are effective.
  • EXAMPLE 9 DETERMINING THE COST EFFECTIVENESS OF A HYPERTENSION EDUCATION PROGRAMS
  • an insurance payer provides its members with a home blood pressure measurement device.
  • the measurement device is networked, such that measurements are uploaded to the insurance company's MICC.
  • the MICC aggregates the sensor data obtained for a given patient with all other non-sensor data available for the patient, specifically including the amount spent in aggregate for the subject's hypertension control over the period.
  • the insurance carrier offers education programs to a subset of its members. The effectiveness of the programs at reducing
  • hypertension is measured by comparing the blood pressure measurements of those patients with those of a control group.
  • a self-insured employer provides its employees with a continuous glucose monitoring device.
  • the device is networked, and communicates directly with the self-insured employer's MICC.
  • the sensor data is aggregated with the non-sensor data known for that patient, including previous treatments, and the costs that the employer has incurred for the treatment of that patient's condition.

Landscapes

  • Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Medical Informatics (AREA)
  • Public Health (AREA)
  • Epidemiology (AREA)
  • Primary Health Care (AREA)
  • General Health & Medical Sciences (AREA)
  • Data Mining & Analysis (AREA)
  • Pathology (AREA)
  • Databases & Information Systems (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Measuring And Recording Apparatus For Diagnosis (AREA)

Abstract

L'invention concerne des systèmes et des procédés qui permettent d'agréger, de gérer et/ou d'analyser des données, telles que des données médicales, par l'intermédiaire d'un groupe de calcul informatique médical (MICC). Selon certains aspects, les procédés consistent à obtenir des données de signal pour un sujet par un ou plusieurs capteurs corporels ; à stocker des données associées au sujet ; à associer des données respectives du signal parmi les données de signal à des données respectives parmi les données associées au sujet ; à stocker au moins une partie des données de signal ou des associations entre les données de signal et les données associées au sujet. En outre, selon certains aspects, les procédés consistent à associer des motifs dans les données de signal à des motifs associés au sujet. Les procédés peuvent faciliter la création d'une analyse rétrospective d'un événement (par exemple un événement indésirable tel qu'une crise cardiaque, une crise d'épilepsie ou un événement hypoglycémique), la détection de la survenue d'un événement (par exemple un événement hypoglycémique), et/ou la prédiction de la survenue future d'un événement (par exemple un événement hypoglycémique). L'invention concerne également des systèmes devant être utilisés pour mettre en pratique les procédés de l'invention. Les systèmes et les procédés ont une utilité dans une diversité d'applications cliniques et non cliniques.
PCT/US2012/054010 2011-09-06 2012-09-06 Groupe de calcul informatique médical WO2013036677A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201161531572P 2011-09-06 2011-09-06
US61/531,572 2011-09-06

Publications (1)

Publication Number Publication Date
WO2013036677A1 true WO2013036677A1 (fr) 2013-03-14

Family

ID=47832563

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2012/054010 WO2013036677A1 (fr) 2011-09-06 2012-09-06 Groupe de calcul informatique médical

Country Status (1)

Country Link
WO (1) WO2013036677A1 (fr)

Cited By (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104065685A (zh) * 2013-03-22 2014-09-24 中国银联股份有限公司 面向云计算环境的分层存储系统中的数据迁移方法
WO2014201096A1 (fr) * 2013-06-12 2014-12-18 Paul Esch Appareil d'intégration de réflexe quantique
DE102014207091A1 (de) * 2014-04-14 2015-10-15 Siemens Aktiengesellschaft Verfahren und Klassifikationssystem zum Abfragen von Klassifikationsfällen aus einer Datenbasis
WO2016040295A1 (fr) * 2014-09-09 2016-03-17 Lockheed Martin Corporation Procédé et appareil de détection de maladies
US20160140442A1 (en) * 2014-11-14 2016-05-19 Medidata Solutions, Inc. System and method for determining subject conditions in mobile health clinical trials
WO2017105196A1 (fr) * 2015-12-17 2017-06-22 Gonzalez Estrada Pedro Gabriel Système multi-agents d'assistance pour un diagnostic médical
US9710858B1 (en) 2013-08-16 2017-07-18 United Services Automobile Association (Usaa) Insurance policy alterations using informatic sensor data
US20170249434A1 (en) * 2016-02-26 2017-08-31 Daniela Brunner Multi-format, multi-domain and multi-algorithm metalearner system and method for monitoring human health, and deriving health status and trajectory
WO2017201323A1 (fr) * 2016-05-18 2017-11-23 Massachusetts Institute Of Technology Procédés et systèmes de détection pré-symptomatique de l'exposition à un agent
US9870295B2 (en) 2014-07-18 2018-01-16 General Electric Company Automation of workflow creation and failure recovery
US10121207B1 (en) 2013-10-04 2018-11-06 United Services Automobile Association Insurance policy alterations using informatic sensor data
CN109464128A (zh) * 2019-01-09 2019-03-15 浙江强脑科技有限公司 睡眠质量检测方法、装置及计算机可读存储介质
CN109490072A (zh) * 2018-10-09 2019-03-19 广东交通职业技术学院 一种土木工程建筑用检测系统及其检测方法
CN109528203A (zh) * 2019-01-21 2019-03-29 郑州大学 一种基于多源信息融合的交互式脑卒中患者步态训练及评测系统
US10332638B2 (en) 2015-07-17 2019-06-25 Massachusetts Institute Of Technology Methods and systems for pre-symptomatic detection of exposure to an agent
CN110502607A (zh) * 2019-06-26 2019-11-26 中电万维信息技术有限责任公司 一种电子病历系统、查询电子病历的方法及服务器
US10489863B1 (en) 2015-05-27 2019-11-26 United Services Automobile Association (Usaa) Roof inspection systems and methods
US10614525B1 (en) 2014-03-05 2020-04-07 United Services Automobile Association (Usaa) Utilizing credit and informatic data for insurance underwriting purposes
US10672078B1 (en) 2014-05-19 2020-06-02 Allstate Insurance Company Scoring of insurance data
US10713726B1 (en) 2013-01-13 2020-07-14 United Services Automobile Association (Usaa) Determining insurance policy modifications using informatic sensor data
WO2020163451A1 (fr) * 2019-02-08 2020-08-13 General Electric Company Systèmes et procédés de présentation de données flexible conversationnelle
TWI703958B (zh) * 2018-11-21 2020-09-11 英華達股份有限公司 智能人體監測系統及其腹部聲音監測裝置
US20200342968A1 (en) * 2019-04-24 2020-10-29 GE Precision Healthcare LLC Visualization of medical device event processing
US10945642B2 (en) 2016-01-14 2021-03-16 Koninklijke Philips N.V. Apparatus and method for monitoring disease progression in a subject
CN112639990A (zh) * 2018-04-30 2021-04-09 小利兰·斯坦福大学托管委员会 用于使用个人数字表型维持健康的系统和方法
US10991049B1 (en) 2014-09-23 2021-04-27 United Services Automobile Association (Usaa) Systems and methods for acquiring insurance related informatics
CN113196407A (zh) * 2018-12-19 2021-07-30 美敦力泌力美公司 用于为个人用户生成个性化的饮食和健康建议或推荐的自动方法和系统
US11087404B1 (en) 2014-01-10 2021-08-10 United Services Automobile Association (Usaa) Electronic sensor management
US20210257110A1 (en) * 2019-02-08 2021-08-19 General Electric Company Systems and methods for conversational flexible data presentation
US20210279289A1 (en) * 2018-05-18 2021-09-09 Koninklijke Philips N.V. System and method for prioritization and presentation of heterogeneous medical data
US11416941B1 (en) 2014-01-10 2022-08-16 United Services Automobile Association (Usaa) Electronic sensor management
CN115101179A (zh) * 2022-06-23 2022-09-23 卫宁健康科技集团股份有限公司 医疗不良事件引起的费用监测方法、装置及电子设备
US11540879B2 (en) 2021-04-16 2023-01-03 Physcade, Inc. Personalized heart rhythm therapy
US11587682B2 (en) * 2020-05-15 2023-02-21 Medable Inc. Method and system to integrate data, analyze and develop improved care plan for a patient at home
US11670421B2 (en) 2020-06-01 2023-06-06 Medable Inc. Method and system enabling digital biomarker data integration and analysis for clinical treatment impact
US11847666B1 (en) 2014-02-24 2023-12-19 United Services Automobile Association (Usaa) Determining status of building modifications using informatics sensor data

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030216939A1 (en) * 2002-05-14 2003-11-20 Hitachi, Ltd. Clinical pathway management support information system
US20050246314A1 (en) * 2002-12-10 2005-11-03 Eder Jeffrey S Personalized medicine service
US20060218010A1 (en) * 2004-10-18 2006-09-28 Bioveris Corporation Systems and methods for obtaining, storing, processing and utilizing immunologic information of individuals and populations
US20070118399A1 (en) * 2005-11-22 2007-05-24 Avinash Gopal B System and method for integrated learning and understanding of healthcare informatics

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030216939A1 (en) * 2002-05-14 2003-11-20 Hitachi, Ltd. Clinical pathway management support information system
US20050246314A1 (en) * 2002-12-10 2005-11-03 Eder Jeffrey S Personalized medicine service
US20060218010A1 (en) * 2004-10-18 2006-09-28 Bioveris Corporation Systems and methods for obtaining, storing, processing and utilizing immunologic information of individuals and populations
US20070118399A1 (en) * 2005-11-22 2007-05-24 Avinash Gopal B System and method for integrated learning and understanding of healthcare informatics

Cited By (85)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10713726B1 (en) 2013-01-13 2020-07-14 United Services Automobile Association (Usaa) Determining insurance policy modifications using informatic sensor data
WO2014146543A1 (fr) * 2013-03-22 2014-09-25 中国银联股份有限公司 Procédé de migration de données dans un système de stockage multi-niveau dans un environnement informatique en nuage
CN104065685A (zh) * 2013-03-22 2014-09-24 中国银联股份有限公司 面向云计算环境的分层存储系统中的数据迁移方法
WO2014201096A1 (fr) * 2013-06-12 2014-12-18 Paul Esch Appareil d'intégration de réflexe quantique
US9918897B2 (en) 2013-06-12 2018-03-20 Paul Esch Quantum reflex integration apparatus
US10181159B1 (en) 2013-08-16 2019-01-15 United Services Automobile Association (Usaa) Determining and initiating insurance claim events
US10510121B2 (en) 2013-08-16 2019-12-17 United Stated Automobile Association (USAA) System and method for performing dwelling maintenance analytics on insured property
US9710858B1 (en) 2013-08-16 2017-07-18 United Services Automobile Association (Usaa) Insurance policy alterations using informatic sensor data
US9984417B1 (en) 2013-08-16 2018-05-29 United Services Automobile Association (Usaa) System and method to determine insurance mitigation actions based on informatic data
US10163162B1 (en) 2013-08-16 2018-12-25 United Services Automobile Association (Usaa) Systems and methods for utilizing imaging informatics
US9811862B1 (en) 2013-08-16 2017-11-07 United Services Automobile Association (Usaa) Determining risks related to activities on insured properties using informatic sensor data
US9818158B1 (en) 2013-08-16 2017-11-14 United Services Automobile Association (Usaa) Utilizing credit and informatic data for insurance underwriting purposes
US10102584B1 (en) 2013-08-16 2018-10-16 United Services Automobile Association (Usaa) Streamlined property insurance application and renewal process
US9886723B1 (en) 2013-08-16 2018-02-06 United Services Automobile Association (Usaa) Determining appliance insurance coverage/products using informatic sensor data
US10943300B1 (en) 2013-08-16 2021-03-09 United Services Automobile Association (Usaa) System and method for reconciling property operation with a budget amount based on informatics
US9947051B1 (en) 2013-08-16 2018-04-17 United Services Automobile Association Identifying and recommending insurance policy products/services using informatic sensor data
US10121207B1 (en) 2013-10-04 2018-11-06 United Services Automobile Association Insurance policy alterations using informatic sensor data
US11423429B1 (en) 2014-01-10 2022-08-23 United Services Automobile Association (Usaa) Determining status of building modifications using informatics sensor data
US11526949B1 (en) 2014-01-10 2022-12-13 United Services Automobile Association (Usaa) Determining risks related to activities on insured properties using informatic sensor data
US11966939B1 (en) 2014-01-10 2024-04-23 United Services Automobile Association (Usaa) Determining appliance insurance coverage/products using informatic sensor data
US11941702B1 (en) 2014-01-10 2024-03-26 United Services Automobile Association (Usaa) Systems and methods for utilizing imaging informatics
US10169771B1 (en) 2014-01-10 2019-01-01 United Services Automobile Association (Usaa) System and method to provide savings based on reduced energy consumption
US11532004B1 (en) 2014-01-10 2022-12-20 United Services Automobile Association (Usaa) Utilizing credit and informatic data for insurance underwriting purposes
US11532006B1 (en) 2014-01-10 2022-12-20 United Services Automobile Association (Usaa) Determining and initiating insurance claim events
US11526948B1 (en) 2014-01-10 2022-12-13 United Services Automobile Association (Usaa) Identifying and recommending insurance policy products/services using informatic sensor data
US11461850B1 (en) 2014-01-10 2022-10-04 United Services Automobile Association (Usaa) Determining insurance policy modifications using informatic sensor data
US11416941B1 (en) 2014-01-10 2022-08-16 United Services Automobile Association (Usaa) Electronic sensor management
US11227339B1 (en) 2014-01-10 2022-01-18 United Services Automobile Association (Usaa) Systems and methods for utilizing imaging informatics
US11164257B1 (en) 2014-01-10 2021-11-02 United Services Automobile Association (Usaa) Streamlined property insurance application and renewal process
US11151657B1 (en) 2014-01-10 2021-10-19 United Services Automobile Association (Usaa) Insurance policy modification based on secondary informatics
US10552911B1 (en) 2014-01-10 2020-02-04 United Services Automobile Association (Usaa) Determining status of building modifications using informatics sensor data
US11138672B1 (en) 2014-01-10 2021-10-05 United Services Automobile Association (Usaa) Determining and initiating insurance claim events
US11120506B1 (en) 2014-01-10 2021-09-14 United Services Automobile Association (Usaa) Streamlined property insurance application and renewal process
US10679296B1 (en) 2014-01-10 2020-06-09 United Services Automobile Association (Usaa) Systems and methods for determining insurance coverage based on informatics
US10699348B1 (en) 2014-01-10 2020-06-30 United Services Automobile Association (Usaa) Utilizing credit and informatic data for insurance underwriting purposes
US11113765B1 (en) 2014-01-10 2021-09-07 United Services Automobile Association (Usaa) Determining appliance insurance coverage/products using informatic sensor data
US10740847B1 (en) 2014-01-10 2020-08-11 United Services Automobile Association (Usaa) Method and system for making rapid insurance policy decisions
US11087404B1 (en) 2014-01-10 2021-08-10 United Services Automobile Association (Usaa) Electronic sensor management
US11068992B1 (en) 2014-01-10 2021-07-20 United Services Automobile Association (Usaa) Insurance policy modifications using informatic sensor data
US10783588B1 (en) 2014-01-10 2020-09-22 United Services Automobile Association (Usaa) Identifying and recommending insurance policy products/services using informatic sensor data
US10977736B1 (en) 2014-01-10 2021-04-13 United Services Automobile Association (Usaa) Determining risks related to activities on insured properties using informatic sensor data
US11847666B1 (en) 2014-02-24 2023-12-19 United Services Automobile Association (Usaa) Determining status of building modifications using informatics sensor data
US10614525B1 (en) 2014-03-05 2020-04-07 United Services Automobile Association (Usaa) Utilizing credit and informatic data for insurance underwriting purposes
DE102014207091A1 (de) * 2014-04-14 2015-10-15 Siemens Aktiengesellschaft Verfahren und Klassifikationssystem zum Abfragen von Klassifikationsfällen aus einer Datenbasis
US10672078B1 (en) 2014-05-19 2020-06-02 Allstate Insurance Company Scoring of insurance data
US9870295B2 (en) 2014-07-18 2018-01-16 General Electric Company Automation of workflow creation and failure recovery
WO2016040295A1 (fr) * 2014-09-09 2016-03-17 Lockheed Martin Corporation Procédé et appareil de détection de maladies
JP2017527399A (ja) * 2014-09-09 2017-09-21 レイドス イノベイションズ テクノロジー，インコーポレイティド 疾患検出のための装置及び方法
US10991049B1 (en) 2014-09-23 2021-04-27 United Services Automobile Association (Usaa) Systems and methods for acquiring insurance related informatics
US11900470B1 (en) 2014-09-23 2024-02-13 United Services Automobile Association (Usaa) Systems and methods for acquiring insurance related informatics
US20160140442A1 (en) * 2014-11-14 2016-05-19 Medidata Solutions, Inc. System and method for determining subject conditions in mobile health clinical trials
US11804287B2 (en) * 2014-11-14 2023-10-31 Medidata Solutions, Inc. System and method for determining subject conditions in mobile health clinical trials
US10929934B1 (en) 2015-05-27 2021-02-23 United Services Automobile Association (Usaa) Roof inspection systems and methods
US10489863B1 (en) 2015-05-27 2019-11-26 United Services Automobile Association (Usaa) Roof inspection systems and methods
US10332638B2 (en) 2015-07-17 2019-06-25 Massachusetts Institute Of Technology Methods and systems for pre-symptomatic detection of exposure to an agent
WO2017105196A1 (fr) * 2015-12-17 2017-06-22 Gonzalez Estrada Pedro Gabriel Système multi-agents d'assistance pour un diagnostic médical
US10945642B2 (en) 2016-01-14 2021-03-16 Koninklijke Philips N.V. Apparatus and method for monitoring disease progression in a subject
US20170249434A1 (en) * 2016-02-26 2017-08-31 Daniela Brunner Multi-format, multi-domain and multi-algorithm metalearner system and method for monitoring human health, and deriving health status and trajectory
WO2017201323A1 (fr) * 2016-05-18 2017-11-23 Massachusetts Institute Of Technology Procédés et systèmes de détection pré-symptomatique de l'exposition à un agent
US20210236053A1 (en) * 2018-04-30 2021-08-05 The Board Of Trustees Of The Leland Stanford Junior University System and method to maintain health using personal digital phenotypes
JP7488572B2 (ja) 2018-04-30 2024-05-22 ザ ボード オブ トラスティーズ オブ ザ レランド スタンフォード ジュニア ユニバーシティー パーソナルデジタルフェノタイプを使用して健康を維持するシステム及び方法
CN112639990A (zh) * 2018-04-30 2021-04-09 小利兰·斯坦福大学托管委员会 用于使用个人数字表型维持健康的系统和方法
US11786174B2 (en) * 2018-04-30 2023-10-17 The Board Of Trustees Of The Leland Stanford Junior University System and method to maintain health using personal digital phenotypes
EP3788588A4 (fr) * 2018-04-30 2022-01-26 The Board Of Trustees Of The Leland Stanford Junior University Système et procédé pour maintenir la santé à l'aide de phénotypes numériques personnels
US20210279289A1 (en) * 2018-05-18 2021-09-09 Koninklijke Philips N.V. System and method for prioritization and presentation of heterogeneous medical data
US11775585B2 (en) 2018-05-18 2023-10-03 Koninklijke Philips N.V. System and method for prioritization and presentation of heterogeneous medical data
CN109490072A (zh) * 2018-10-09 2019-03-19 广东交通职业技术学院 一种土木工程建筑用检测系统及其检测方法
CN109490072B (zh) * 2018-10-09 2021-07-27 广东交通职业技术学院 一种土木工程建筑用检测系统及其检测方法
TWI703958B (zh) * 2018-11-21 2020-09-11 英華達股份有限公司 智能人體監測系統及其腹部聲音監測裝置
CN113196407A (zh) * 2018-12-19 2021-07-30 美敦力泌力美公司 用于为个人用户生成个性化的饮食和健康建议或推荐的自动方法和系统
CN109464128A (zh) * 2019-01-09 2019-03-15 浙江强脑科技有限公司 睡眠质量检测方法、装置及计算机可读存储介质
CN109528203A (zh) * 2019-01-21 2019-03-29 郑州大学 一种基于多源信息融合的交互式脑卒中患者步态训练及评测系统
WO2020163451A1 (fr) * 2019-02-08 2020-08-13 General Electric Company Systèmes et procédés de présentation de données flexible conversationnelle
US11600397B2 (en) 2019-02-08 2023-03-07 General Electric Company Systems and methods for conversational flexible data presentation
US20210257110A1 (en) * 2019-02-08 2021-08-19 General Electric Company Systems and methods for conversational flexible data presentation
US11031139B2 (en) 2019-02-08 2021-06-08 General Electric Company Systems and methods for conversational flexible data presentation
US11404145B2 (en) 2019-04-24 2022-08-02 GE Precision Healthcare LLC Medical machine time-series event data processor
US11984201B2 (en) 2019-04-24 2024-05-14 GE Precision Healthcare LLC Medical machine synthetic data and corresponding event generation
US20200342968A1 (en) * 2019-04-24 2020-10-29 GE Precision Healthcare LLC Visualization of medical device event processing
CN110502607A (zh) * 2019-06-26 2019-11-26 中电万维信息技术有限责任公司 一种电子病历系统、查询电子病历的方法及服务器
US11587682B2 (en) * 2020-05-15 2023-02-21 Medable Inc. Method and system to integrate data, analyze and develop improved care plan for a patient at home
US11670421B2 (en) 2020-06-01 2023-06-06 Medable Inc. Method and system enabling digital biomarker data integration and analysis for clinical treatment impact
US11583346B2 (en) 2021-04-16 2023-02-21 Physcade, Inc. Personalized heart rhythm therapy
US11540879B2 (en) 2021-04-16 2023-01-03 Physcade, Inc. Personalized heart rhythm therapy
CN115101179A (zh) * 2022-06-23 2022-09-23 卫宁健康科技集团股份有限公司 医疗不良事件引起的费用监测方法、装置及电子设备

Similar Documents

Publication Publication Date Title
WO2013036677A1 (fr) Groupe de calcul informatique médical
Razzak et al. Big data analytics for preventive medicine
Chang et al. Pima Indians diabetes mellitus classification based on machine learning (ML) algorithms
Hong et al. Big data in health care: Applications and challenges
Kim et al. Medical informatics research trend analysis: a text mining approach
Johnson et al. Machine learning and decision support in critical care
Dhayne et al. In search of big medical data integration solutions-a comprehensive survey
Ho et al. Limestone: High-throughput candidate phenotype generation via tensor factorization
US20230197223A1 (en) Health care information system providing additional data fields in patient data
US11295867B2 (en) Generating and applying subject event timelines
Baker et al. Continuous and automatic mortality risk prediction using vital signs in the intensive care unit: a hybrid neural network approach
Meyfroidt et al. Computerized prediction of intensive care unit discharge after cardiac surgery: development and validation of a Gaussian processes model
Hoodbhoy et al. Machine learning for child and adolescent health: a systematic review
Chaudhry et al. Machine learning applications in the neuro ICU: a solution to big data mayhem?
Adegboro et al. Artificial intelligence to improve health outcomes in the NICU and PICU: a systematic review
Thiagarajan et al. DDxNet: a deep learning model for automatic interpretation of electronic health records, electrocardiograms and electroencephalograms
Gowsalya et al. Predicting the risk of readmission of diabetic patients using MapReduce
Osop et al. Electronic health records: Improvement to healthcare decision-making
Chung et al. Big data analysis and artificial intelligence in epilepsy–common data model analysis and machine learning-based seizure detection and forecasting
Ebada et al. Applying apache spark on streaming big data for health status prediction
Mahoto et al. Knowledge discovery from healthcare electronic records for sustainable environment
Loku et al. Automated medical data analyses of diseases using big data
Zaman et al. A review on the significance of body temperature interpretation for early infectious disease diagnosis
Bhoi et al. Cognitive and Soft Computing Techniques for the Analysis of Healthcare Data
Shara et al. Early identification of maternal cardiovascular risk through sourcing and preparing electronic health record data: machine learning study

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12829495

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12829495

Country of ref document: EP

Kind code of ref document: A1