Creating canonical training datasets through data transformations

Abstract

A method (500) includes obtaining a data set (158) including health data (152) in accordance with a fast health care interoperability resource (FHIR) standard. The health data includes a plurality of healthcare events (153). The method includes generating an event table (210E) using the data set, the event table including the plurality of healthcare events and indexed by time and a unique identifier for each patient visiting. The method further includes generating a feature table (210T) using the dataset, the feature table including static data and indexed by a unique identifier for each patient visiting. The method comprises: training a machine learning model using the event table and the feature table (320); and predicting a health outcome of the patient using the trained machine learning model and one or more additional healthcare events associated with the patient (422).

Description

Technical Field

[0001] The present disclosure relates to using data transformation to create a canonical training data set. Background Art

[0002] Clinicians routinely use patient healthcare metrics that change over time (e.g., periodic readings of blood pressure, heart rate, sodium / blood sugar levels, etc.) to identify high-risk populations. As sensors become more numerous and more data is shared across institutions, clinicians must sift through more and more data to understand trends and identify probabilities of “personalized” patient outcomes. Additionally or alternatively, hospital administrators are tracking operational and quality of care metrics such as length of stay, equipment supplies, staffing levels, etc. The ultimate goal is to calculate the probability of a positive or negative outcome in the future so that timely interventions can be implemented. Summary of the invention

[0003] One aspect of the present disclosure provides a method for transforming data to create a canonical training data set for a machine learning model. The method, when executed by data processing hardware, causes the data processing hardware to perform an operation. The operation includes obtaining a data set that includes health data in accordance with the Fast Healthcare Interoperability Resources (FHIR) standard. The health data includes a plurality of healthcare events. The operation includes generating an event table using the data set, the event table including the plurality of healthcare events. The event table is indexed by time and a unique identifier for each patient visit. The method includes generating a feature table using the data set, the feature table including static data. The feature table is indexed by a unique identifier for each patient visit. The method also includes: training a machine learning model using the event table and the feature table; and predicting a health outcome for the patient using the trained machine learning model and one or more additional healthcare events associated with the patient.

[0004] Implementations of the present disclosure may include one or more of the following optional features. In some implementations, obtaining a data set includes: receiving a training request that defines a data source for the data set; and retrieving the data set from the data source. Optionally, the operation also includes normalizing one or more codes of the health data. In some examples, the operation also includes normalizing one or more units of the health data.

[0005] The data set may include a comma separated value file. In some implementations, the feature table includes patient demographic data. The event table may represent the data set as a structured time series. In some examples, the data set includes nested data. In some examples, the operations also include generating a user-configurable feature table including context-specific static features, the user-configurable feature table being indexed by a unique identifier for each patient visit. In some of these examples, generating the user-configurable feature table includes receiving context-specific static features from a user.

[0006] Another aspect of the present disclosure provides a system for transforming data to create a canonical training data set for a machine learning model. The system includes data processing hardware and memory hardware in communication with the data processing hardware. The memory hardware stores instructions that, when executed on the data processing hardware, cause the data processing hardware to perform operations. The operations include obtaining a data set that includes health data in accordance with the Fast Healthcare Interoperability Resources (FHIR) standard. The health data includes a plurality of healthcare events. The operations include using the data set to generate an event table that includes the plurality of healthcare events. The event table is indexed by time and a unique identifier for each patient visit. The method includes using the data set to generate a feature table that includes static data. The feature table is indexed by a unique identifier for each patient visit. The method also includes: using the event table and the feature table to train a machine learning model; and using the trained machine learning model and one or more additional healthcare events associated with a patient to predict a health outcome for the patient.

[0007] This aspect may include one or more of the following optional features. In some implementations, obtaining a data set includes: receiving a training request that defines a data source for the data set; and retrieving the data set from the data source. Optionally, the operations also include normalizing one or more codes of the health data. In some examples, the operations also include normalizing one or more units of the health data.

[0008] The data set may include a comma separated value file. In some implementations, the feature table includes patient demographic data. The event table may represent the data set as a structured time series. In some examples, the data set includes nested data. In some examples, the operations also include generating a user-configurable feature table including context-specific static features, the user-configurable feature table being indexed by a unique identifier for each patient visit. In some of these examples, generating the user-configurable feature table includes receiving context-specific static features from a user.

[0009] The details of one or more implementations of the present disclosure are set forth in the accompanying drawings and the description below. Other aspects, features, and advantages will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 is a diagram of an example system for transforming Fast Healthcare Interoperability Resources (FHIR) data.

[0011] Figure 2A It is a schematic diagram of the timetable and characteristics table.

[0012] Figure 2B is a schematic diagram of an exemplary event table.

[0013] Figure 2C is a schematic diagram of an exemplary characteristics table.

[0014] Figure 3 is a schematic diagram of the model trainer.

[0015] Figure 4 is a schematic diagram of the components of an exemplary model.

[0016] Figure 5 is a flow diagram of an example arrangement of operations of a method for transforming FHIR data.

[0017] Figure 6 is a schematic diagram of an example computing device that can be used to implement the systems and methods described herein.

[0018] Like reference numerals in the various drawings indicate like elements. DETAILED DESCRIPTION

[0019] Clinicians routinely use patient healthcare metrics that change over time (e.g., periodic readings of blood pressure, heart rate, sodium / blood sugar levels, etc.) to identify high-risk populations. As sensors become more numerous and more data is shared across institutions, clinicians must sift through more and more data to understand trends and identify probabilities of “personalized” patient outcomes. Additionally or alternatively, hospital administrators are tracking operational and quality of care metrics such as length of stay, equipment supplies, staffing levels, etc. The ultimate goal is to calculate the probability of a positive or negative outcome in the future so that timely interventions can be implemented.

[0020] Implementations herein include data transformers to reduce the time-consuming burden of organizing data by providing a platform to predict the probability of outcomes (e.g., health outcomes) for users (e.g., patients), for example, based on longitudinal patient records (LPRs) associated with the users or patients. Clinicians and managers can use data transformers as tools to help prioritize issues of concern and reduce the time spent on data analysis. Data transformers provide solutions for training machine learning (ML) models using data from an institution's patient population or hospital metrics. Data transformers can implement predictive endpoints that can be easily integrated into upstream applications.

[0021] refer to Figure 1 In some implementations, the example data transformation system 100 includes a remote system 140 that communicates with one or more user devices 10 via a network 112. The remote system 140 can be a single computer, multiple computers, or a distributed system (e.g., a cloud environment) with scalable / elastic resources 142, which include computing resources 144 (e.g., data processing hardware) and / or storage resources 146 (e.g., memory hardware). A data repository 150 (i.e., a remote storage device) can be overlaid on the storage resources 146 to allow one or more of the clients (e.g., user devices 10) or computing resources 144 to use the storage resources 146 scalably. The data repository 150 is configured to store one or more records 152, 152a-n in one or more data sets 158, 158a-n. For example, the record 152 includes a health data record (i.e., health data) in the Fast Healthcare Interoperability Resources (FHIR) standard format. The records 152 can be grouped together into any number of data sets 158. Data repository 150 may be a FHIR data repository. In some examples, records 152 are in comma separated value (CSV) format, however records 152 may be stored in any suitable format.

[0022] The remote system 140 may be configured to receive a data transformation query 20 from a user device 10 associated with a respective user 12 via, for example, a network 112. The user device 10 may correspond to any computing device, such as a desktop workstation, a laptop workstation, or a mobile device (i.e., a smart phone). The user device 10 includes computing resources 18 (e.g., data processing hardware) and / or storage resources 16 (e.g., memory hardware). The user 12 may construct the query 20 using a structured query language (SQL) interface. The query 20 may request the remote system 140 to process some or all of the data set 158, for example, to train one or more machine learning models using data from the data set 158. The trained machine learning model may be used to make predictions based on the training data (e.g., predicting a patient's health outcome).

[0023] The remote system 140 executes a data transformer 160. The data transformer 160 obtains a data set 158 ​​that includes, for example, health data in accordance with the FHIR standard. In other examples, the data set 158 ​​includes different electronic health data (EHR). In some examples, the remote system 140 retrieves the data set 158 ​​from the data repository 150 or receives the data set 158 ​​from the user device 10. The query 20 may include a data source (e.g., the data repository 150) for the data set 158. In response to determining the data source from the query 20, the data transformer 160 retrieves the data set 158 ​​from the data source. The data set 158 ​​includes a plurality of healthcare events 153 for one or more patients. For example, the healthcare events 153 may include doctor visits or other appointments, admission details, procedures, tests, measurements (e.g., vital signs), diagnoses, medications, and prescriptions, etc. Each event 153 includes data that describes or otherwise quantifies the event (e.g., date and time, descriptions and values ​​of vital signs, medications, test results, etc.). Healthcare events 153 may include tabular encoded numerical and textual data (e.g., EHR data), imaging data (e.g., encoded images), genomics (e.g., encoded sequence and location data), social data, and / or wearable device data (e.g., high frequency waveforms, tabular encoded numerical data, etc.).

[0024] In some implementations, the FHIR health data of dataset 158 ​​includes nested data. Health data stored using the FHIR standard is typically in a highly nested format that allows entries to be repeated at different levels. Since many models (e.g., machine learning models) typically require "flat" (i.e., non-nested) data as input, machine learning models are typically unable to learn correctly from standard FHIR data. In order to be usable, the data must first be "flattened." However, machine learning practitioners typically have difficulty flattening this data efficiently and in a standard manner that is reusable across multiple use cases. Other types of data, such as EHR data, are also typically not "ML-ready." For example, EHR data is typically sparse, heterogeneous, and unbalanced.

[0025] The data transformer 160 generates an event table 210E using the FHIR dataset 158, which includes each of the healthcare events 153 of the dataset 158. In some implementations, the event table 210E is indexed by time (i.e., the point in time at which the event occurred) and / or a unique identifier (ID) for each patient visit. The event table 210E may include columns including the time at which the event 153 occurred, the code for the event 153, one or more values ​​associated with the event, the unit of the value, etc. The data transformer 160 also generates a characteristics table 210T using the FHIR dataset 158. Similar to the event table 210E, the characteristics table 210T may be indexed by a unique ID for each patient visit. The characteristics table includes columns associated with the patient's ID, the visit ID, the patient's gender, the patient's birthday, the patient's admission code, or other columns that describe or define characteristics of the patient associated with the patient ID.

[0026] As discussed in more detail below, the remote system 140 can use the event table 210E and the feature table 210T to assist multiple downstream applications. For example, the remote system 140 can use the "flattened" data of the event table 210E and the feature table 210T to train one or more machine learning models. The trained machine models can be used to make predictions, such as for predicting a patient's health outcome. The event table 210E and the feature table 210T preserve the dataset 158 ​​in a structured time series by keeping the dataset 158 ​​as sequence data (e.g., a sequence of labs, vital signs, procedures, medications, etc.) in a reusable manner across many different use cases.

[0027] In some implementations, the data transformer 160 generates a user-configurable feature table including context-specific static features indexed by a unique ID for each patient visit. The data transformer 160 may receive the context-specific static features from the user 12 via the user device 10. The user-configurable feature table allows the user 12 to inject their own context-specific static features that use the same patient visit as the event table 210E and the feature table 210T as a key.

[0028] Reference now Figure 2A, the schematic diagram 200 includes an exemplary health record 152 in accordance with the FHIR standard. The data of the record 152 is nested and is generally not available in most models in such a nested format because the model requires the data to be flat. The data transformer 160 transforms each record 152 of the data set 158 ​​into an event table 210E and a feature table 210T. Here, the event table 210E has multiple columns, including a "time" column (i.e., the time when the event 153 occurred or was recorded), a "code" column that defines or identifies the event (e.g., a visit ID that identifies a patient's temperature reading), a "value" column (e.g., 98.6 for a temperature reading), and a "unit" column (e.g., degrees Fahrenheit for a temperature reading). These columns are merely exemplary, and the event table 210E may include different and / or additional columns depending on the data set 158 ​​and the desired use case of the data. For example, the event table 210E may include a patient ID column that identifies the patient. The event table 210E represents the data set 158 ​​as a structured time series. Figure 2B An exemplary event table 210E is included, which has columns associated with patient ID, visit ID, observation ID, value, and value unit. In this example, there are two rows with the same patient ID because the same patient is associated with two different visit IDs (e.g., two different visits or tests).

[0029] The feature table 210T also includes a plurality of columns. The feature table 210T typically includes static data (or at least data that is less dynamic than the data in the event table 210E), such as patient demographic data (e.g., age, gender, height, weight, etc.). Here, the feature table 210T includes an ID column. The ID column may correspond to the code column of the event table 210E. The feature table 210T also includes an age column, a diagnosis column, and a gender column, however, these columns are merely exemplary, and the feature table 210T may include any appropriate columns. For example, the feature table 210T includes a patient ID column, an admission code, etc. Figure 2C An exemplary feature table 210T is included, which has columns for patient ID, visit ID, gender, birthday, and admission code. Here, there are two rows with the same patient ID, but each row has a different visit ID, thus indicating that the same patient has two different visits.

[0030] In some implementations, the data transformer normalizes one or more codes, units, numerical data, or any other aspects of the data set 158 ​​into a machine learning friendly format when generating the event table 210E and / or the feature table 210T. For example, the code "US" can be normalized to "ultrasound" or the pound unit (i.e., lbs) can be normalized to kilograms.

[0031] Reference now Figure 3In some implementations, the event table 210E and the feature table 210T are used (e.g., by the remote system 140) to train one or more machine learning models 320. Here, the schematic 300 includes a model trainer 310 that receives the event table 210E and the feature table 210T and trains a plurality of machine learning models 320. Each model 320 can be trained to make different predictions based on the training. For example, one model 320 predicts a patient's prognosis based on the patient's event history.

[0032] In some examples, model 320 is a multi-task model that is trained using event table 210E and feature table 210T to simultaneously predict outcomes and forecast observations. That is, since such health records often have a serious label imbalance problem (i.e., the distribution of labels in the training data is skewed) and since labels may be sparse, delayed, and / or difficult to define, a multi-task model is advantageous. For example, a multi-task model provides signal enhancement due to the high data neighborhood problem, is semi-supervised, naturally fits outcomes based on time series, and provides additional model evaluation information.

[0033] Reference now Figure 4 In some implementations, the model 320 includes a shared network 410, a main network 420, and an auxiliary network 430. The shared network 410 receives the event table 210E and the feature table 210T. In some examples, the shared network 410 includes an encoder (such as a long short-term memory (LSTM) encoder). The encoder refines the data from the tables 210E and 210T into a lower dimensional representation. The shared network 410 generates a first output 412 for the main network 420 and a second output 414 for the auxiliary network 430. The main network 420 uses the first output 412 from the shared network 410 to predict an outcome 422 (e.g., a patient's health outcome). In some examples, the main network 420 includes a classifier (e.g., a dense layer on top of the encoder output) to predict the outcome 422. The auxiliary network 430 uses the second output 414 from the shared network 410 to predict or forecast a time series 432 for an observed value. In some implementations, the time series is an LSTM rollout of a structured time series with a mask loss. Auxiliary network 430 may include a decoder (e.g., an autoregressive LSTM model) that produces fixed-interval predictions for multivariate time series event data. Networks 410, 420, 430 may be jointly trained (e.g., via model trainer 310) using a weighted total loss.

[0034] After the model 320 is trained, the user 12 can request a prediction via a prediction request that includes events and features for a specific patient similar to the data used to train the model 320. The user can provide data in a FHIR format, for example, and the system 100 can automatically flatten the data into an event table 210E and a feature table 210T for processing by the model 320. In other examples, the prediction request includes data pre-processed in a format suitable for the model 320. Using the provided data, the model 320 predicts a health outcome 422. Optionally, the model 320 additionally forecasts one or more observations via a time series 432.

[0035] In some implementations, the model trainer 310 trains the model 320 in response to a request. For example, the request 20 may include a request to train the model 320 to predict one or more specific health outcomes 422. In response to the request, the system 100 generates the event table 210E and the feature table 210T based on the data specified by, for example, the request (e.g., FHIR data or any other resource library). The system 100 can select a group from the data to train the model 320. The system can select the group based on the request 20 (i.e., based on predicting the expected health outcome 422). For example, a user can request that the model 320 predict the likelihood of a health outcome 422 (e.g., death, illness, discharge, etc.) within three days of admission. In this example, the system 100 can ensure that the group used to train the model 320 only includes patient records whose discharge date is more than two days after admission. The user 12 and / or the system 100 can generate or customize the group used to train the model 320 based on the health outcome 422 to be predicted. For example, the user 12 may submit a query or request to the system 100 that includes a plurality of parameters defining the health outcome 422. Accordingly, the user 12 (e.g., via the user device 10) and / or the system 100 may query or filter the data records 152 to obtain data records 152 associated with the desired health outcome 422.

[0036] In some implementations, the model 320 can be trained to predict multiple different health outcomes simultaneously. For example, the model 320 includes two or more different output layers, each of which provides a corresponding classification result for a corresponding health outcome 422.

[0037] Therefore, the implementation in this article includes a data transformation system 100, which maintains sequence data (e.g., sequences of laboratories, vital sign measurements, procedures, medications, etc.) as a structured time series via an intermediate event table 210E and a feature table 210T. The event table 210E can capture events and index them by time and the unique ID of the patient's visit. The feature table 210T can capture relatively static data, such as patient demographics. The system 100 can normalize data (e.g., codes, units, etc.) into a format compatible with machine learning. The system 100 provides a table mode, and in addition to training a machine learning model, users can also use the table mode to aggregate and segment data segments to gain insights, perform anomaly detection, etc. The system allows the injection of external data (e.g., data representing context-specific static features using a specific patient visit as a keyword). Models trained using the event table 210E and the feature table 210T can predict the probability of an outcome based on longitudinal patient records. These predictions allow clinicians and managers to determine priorities without spending a lot of time on data analysis.

[0038] Figure 5 5 is a flowchart of an exemplary arrangement of operations of a method 500 for transforming data. The computer-implemented method 500, when executed by the data processing hardware 144, causes the data processing hardware 144 to perform operations. At operation 502, the method 500 includes obtaining a data set 158, the data set including a health data record 152 in accordance with the Fast Healthcare Interoperability Resources (FHIR) standard. The health data includes a plurality of healthcare events. At operation 504, the method 500 includes using the data set 158 ​​to generate an event table 210E, the event table including the plurality of healthcare events. The event table 210E is indexed by time and a unique identifier for each patient visit. At operation 506, the method 500 includes using the data set 158 ​​to generate a feature table 210T, the feature table including static data. The feature table 210T is indexed by a unique identifier for each patient visit. At operation 508, the method 500 includes using the event table 210E and the feature table 210T to train the machine learning model 320. At operation 510 , the method 500 includes predicting a health outcome 422 for the patient using the trained machine learning model 320 and one or more additional healthcare events associated with the patient.

[0039] Figure 6600 that can be used to implement the systems and methods described in this document. Computing device 600 is intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The components shown here, their connections and relationships, and their functions are intended to be exemplary only and are not intended to limit the implementation of the inventions described and / or claimed in this document.

[0040] The computing device 600 includes a processor 610, a memory 620, a storage device 630, a high-speed interface / controller 640 connected to the memory 620 and a high-speed expansion port 650, and a low-speed interface / controller 660 connected to a low-speed bus 670 and the storage device 630. Each of the components 610, 620, 630, 640, 650, and 660 is interconnected using various buses and can be installed on a common motherboard or installed in other ways as appropriate. The processor 610 can process instructions for execution within the computing device 600, including instructions stored in the memory 620 or on the storage device 630, to display graphical information of a graphical user interface (GUI) on an external input / output device (such as a display 680 coupled to the high-speed interface 640). In other implementations, multiple processors and / or multiple buses and multiple memories and multiple types of memories can be used as appropriate. In addition, multiple computing devices 600 can be connected, each of which provides a portion of the necessary operations (for example, as a server group, a blade server group, or a multi-processor system).

[0041] Memory 620 stores information non-temporarily within computing device 600. Memory 620 may be a computer-readable medium, a volatile memory unit, or a non-volatile memory unit. Non-temporary memory 620 may be a physical device for temporarily or permanently storing programs (e.g., instruction sequences) or data (e.g., program state information) for use by computing device 600. Examples of non-volatile memory include, but are not limited to, flash memory and read-only memory (ROM) / programmable read-only memory (PROM) / erasable programmable read-only memory (EPROM) / electronically erasable programmable read-only memory (EEPROM) (e.g., typically used for firmware, such as bootloaders). Examples of volatile memory include, but are not limited to, random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), phase change memory (PCM), and disk or tape.

[0042] The storage device 630 is capable of providing mass storage for the computing device 600. In some implementations, the storage device 630 is a computer-readable medium. In various implementations, the storage device 630 may be a floppy disk device, a hard disk device, an optical disk device, or a tape device, a flash memory or other similar solid-state memory device, or an array of devices (including devices in a storage area network or other configurations). In additional implementations, a computer program product is tangibly embodied in an information carrier. The computer program product contains instructions that, when executed, perform one or more methods, such as those described above. The information carrier is a computer or machine-readable medium, such as the memory 620, the storage device 630, or a memory on the processor 610.

[0043] The high-speed controller 640 manages bandwidth-intensive operations of the computing device 600, while the low-speed controller 660 manages less bandwidth-intensive operations. Such a division of responsibilities is exemplary only. In some implementations, the high-speed controller 640 is coupled to a memory 620, a display 680 (e.g., through a graphics processor or accelerator), and a high-speed expansion port 650 that can accept various expansion cards (not shown). In some implementations, the low-speed controller 660 is coupled to a storage device 630 and a low-speed expansion port 690. The low-speed expansion port 690, which can include various communication ports (e.g., USB, Bluetooth, Ethernet, wireless Ethernet), can be coupled to one or more input / output devices, such as a keyboard, a pointing device, a scanner, or a networking device, such as a switch or a router, for example, through a network adapter.

[0044] The computing device 600 can be implemented in a variety of different forms, as shown. For example, it can be implemented as a standard server 600a or multiple implementations as a group of such servers 600a, as a laptop computer 600b, or as part of a rack server system 600c.

[0045] Various implementations of the systems and techniques described herein can be implemented using digital electronic and / or optical circuit systems, integrated circuit systems, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include implementations using one or more computer programs that can be executed and / or interpreted on a programmable system that includes at least one programmable processor, which can be special purpose or general purpose, coupled to receive data and instructions from and transmit data and instructions to a storage system, at least one input device, and at least one output device.

[0046] A software application (i.e., software resource) may refer to computer software that causes a computing device to perform tasks. In some examples, a software application may be referred to as an "application," "app," or "program." Example applications include, but are not limited to, system diagnostic applications, system management applications, system maintenance applications, word processing applications, spreadsheet applications, messaging applications, media streaming applications, social networking applications, and gaming applications.

[0047] These computer programs (also referred to as programs, software, software applications, or code) include machine instructions for a programmable processor and may be implemented in high-level procedural and / or object-oriented programming languages ​​and / or in assembly / machine languages. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, non-transitory computer-readable medium, apparatus, and / or device (e.g., disk, optical disk, memory, programmable logic device (PLD)) for providing machine instructions and / or data to a programmable processor, including a machine-readable medium that receives machine instructions in the form of a machine-readable signal. The term "machine-readable signal" refers to any signal for providing machine instructions and / or data to a programmable processor.

[0048] The processes and logic flows described in this specification can be performed by one or more programmable processors (also referred to as data processing hardware), which execute one or more computer programs to perform functions by operating on input data and generating outputs. The processes and logic flows can also be performed by a dedicated logic circuit system, such as an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). For example, processors suitable for executing computer programs include both general-purpose microprocessors and special-purpose microprocessors, and any one or more processors of any kind of digital computer. Typically, the processor will receive instructions and data from a read-only memory or a random access memory or both. The basic elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices for storing data, such as a magnetic disk, a magneto-optical disk, or an optical disk, or be operably coupled to receive data from one or more mass storage devices or transfer data to one or more mass storage devices or both. However, a computer does not have to have such a device. Computer-readable media suitable for storing computer program instructions and data include all forms of nonvolatile memory, media, and memory devices, including, for example, semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices); magnetic disks, such as internal hard disks or removable disks; magneto-optical disks; and CD ROM and DVD-ROM disks. The processor and memory may be supplemented by, or incorporated in, special purpose logic circuitry.

[0049] To provide interaction with a user, one or more aspects of the present disclosure may be implemented on a computer having a display device (e.g., a CRT (cathode ray tube), an LCD (liquid crystal display) monitor, or a touch screen) for displaying information to the user, and optionally a keyboard and a pointing device (e.g., a mouse or trackball) by which the user can provide input to the computer. Other kinds of devices may also be used to provide interaction with the user; for example, the feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user may be received in any form, including sound, speech, or tactile input. In addition, the computer may interact with the user by sending documents to and receiving documents from a device used by the user; for example, by sending a web page to a web browser on a user's client device in response to a request received from the web browser.

[0050] A variety of implementations have been described. However, it should be understood that various modifications may be made without departing from the spirit and scope of the present disclosure. Therefore, other implementations are within the scope of the following claims.

Claims

1. A computer-implemented method (500) executed by data processing hardware (144) to cause the data processing hardware (144) to perform an operation, characterized in that: The operations include: obtaining a data set (158) comprising health data (152) in accordance with a Fast Healthcare Interoperability Resources (FHIR) standard, the health data (152) comprising a plurality of healthcare events (153); generating an event table (210E) including the plurality of healthcare events (153) using the data set (158), the event table (210E) being indexed by time and a unique identifier for each patient visit; generating a characteristics table (210T) including static data using the data set (158), the characteristics table (210T) being indexed by a unique identifier for each patient visit; Using the event table (210E) and the feature table (210T) to train a machine learning model (320); and A health outcome (422) for the patient is predicted using the trained machine learning model (320) and one or more additional healthcare events (153) associated with the patient.

2. The method (500) according to claim 1, characterized in that: Wherein obtaining the data set (158) comprises: receiving a training request (20), the training request defining a data source for the data set (158); and The data set is retrieved from the data source (158).

3. The method (500) according to claim 1 or claim 2, characterized in that: The operations also include normalizing one or more codes of the health data (152).

4. The method (500) according to any one of claims 1 to 3, characterized in that: The operations also include normalizing one or more units of the health data (152).

5. The method (500) according to any one of claims 1 to 4, characterized in that: The data set (158) comprises a comma separated value file.

6. The method (500) according to any one of claims 1 to 5, characterized in that: Wherein the characteristics table (210T) includes patient demographic data.

7. The method (500) according to any one of claims 1 to 6, characterized in that: The event table (210E) represents the data set (158) as a structured time series.

8. The method (500) according to any one of claims 1 to 7, characterized in that: Wherein the data set (158) includes nested data.

9. The method (500) according to any one of claims 1 to 8, characterized in that: The operations further include generating a user-configurable features table comprising context-specific static features, the user-configurable features table being indexed by the unique identifier for each patient visit.

10. The method (500) of claim 9, characterized in that: Wherein generating the user configurable feature table includes receiving the context-specific static features from a user (12).

11. A system (100), characterized in that: include: Data processing hardware (144); as well as Memory (146) hardware in communication with the data processing hardware (144), the memory (146) hardware storing instructions that, when executed on the data processing hardware (144), cause the data processing hardware (144) to perform operations, the operations comprising: obtaining a data set (158) comprising health data (152) in accordance with a Fast Healthcare Interoperability Resources (FHIR) standard, the health data (152) comprising a plurality of healthcare events (153); generating an event table (210E) including the plurality of healthcare events (153) using the data set (158), the event table (210E) being indexed by time and a unique identifier for each patient visit; generating a characteristics table (210T) including static data using the data set (158), the characteristics table (210T) being indexed by a unique identifier for each patient visit; Using the event table (210E) and the feature table (210T) to train a machine learning model (320); and A health outcome (422) for the patient is predicted using the trained machine learning model (320) and one or more additional healthcare events (153) associated with the patient.

12. The system (100) according to claim 11, characterized in that Wherein obtaining the data set (158) comprises: receiving a training request (20), the training request defining a data source for the data set (158); and The data set is retrieved from the data source (158).

13. The system (100) of claim 11 or claim 12, characterized in that The operations also include normalizing one or more codes of the health data (152).

14. The system (100) according to any one of claims 1 to 3, characterized in that The operations also include normalizing one or more units of the health data (152).

15. The system (100) according to any one of claims 11 to 14, characterized in that The data set (158) comprises a comma separated value file.

16. The system (100) according to any one of claims 11 to 15, characterized in that Wherein the characteristics table (210T) includes patient demographic data.

17. The system (100) according to any one of claims 11 to 16, characterized in that The event table (210E) represents the data set (158) as a structured time series.

18. The system (100) according to any one of claims 11 to 17, characterized in that Wherein the data set (158) includes nested data.

19. The system (100) according to any one of claims 11 to 18, characterized in that The operations further include generating a user-configurable features table comprising context-specific static features, the user-configurable features table being indexed by the unique identifier for each patient visit.

20. The system (100) of claim 19, wherein: Wherein generating the user configurable feature table includes receiving the context-specific static features from a user (12).

Images